Viewpoint

Software Components: Which Ones Solve the Implementation Problem?
By Mark Copenhaver

JMJ Technologies, Inc.

There appears to be some confusion about exactly what software components are, and why they’re not already solving some of our problems.

Originally, software components were developed with the intention of reusing code, but the idea has grown into much more. Now we are looking to components for many answers, including allowing developers to utilize third party functionality, allowing integrators to link multi-vendor applications into an integrated solution, and even allowing end users to pick and choose functionality from different vendors to solve their own computing needs.

Along these lines, we can broadly classify software components into two categories: Development development Components components and plug-and-play components. The primary distinction between the two is that development components must be incorporated into an application by the application developer, while plug-and-play components may be incorporated into an application by an integrator, and installer or even an end user.

Development components have been around as long as people have been writing software. Their main purpose is to allow software to be written once and reused many times. They come in all shapes and sizes to fill all sorts of development issues.

Development components help combat the very frustrating and costly "reinventing the wheel" problem by allowing programmers to write code in such a way that other programmers can use the functionality without having to know how it works.

Strength or Weakness

While development components are extremely valuable and will continue to evolve and mature, their strength—that they are incorporated into an application by a software developer—is also their greatest weakness. When an application developer decides to use a particular software component, he or she must write code to allow the application to interact with that component. The details of this interaction are thus "hard coded" into the application. If the developer wishes to use a different component for the same task, he or she must write code to interact with the new component, either replacing the first or providing some configuration mechanism to use one or the other. Either way the end user doesn’t get to use a particular component unless the application developer has written code to facilitate it.

For example, suppose an application developer wanted to display a pie graph to the user. The developer doesn’t want to write all the code required to display pie graphs because it’s reasonably complex and there are dozens of software components on the market which will display pie graphs. The developer selects a component based on the technical and functional needs of the application, and business considerations such as cost, support, maintenance, redistribution royalties, and vendor reputation. The chosen pie graph component comes with a particular mechanism for allowing the application programmer to "tell" the component what to graph, such as colors, the wedge data, and the legend.

This mechanism is called the Application programmer Interface (API). The programmer incorporates the pie graph into his or her application using this particular pie graph component’s API. Now suppose the end user finds a different pie graph component that draws prettier pie graphs. With this model the end user must convince the application developer to incorporate the new pie graph component into the application.

This is where plug-and play components come in. When the application programmer wants to put a pie graph on the screen, the programmer must write code to instruct the computer what to draw. If different components implement different APIs, then the application programmer must write different code for each supported pie graph. This is bad. At the heart of plug-and-play components is the need for the application programmer to be able to write to a single API without necessarily knowing which specific component will be used at runtime. For our example, this means that either all pie graph components implement the same API, or somebody writes a pie graph "middle layer" which presents a single API to the application programmer and in turn handles any differences between supported pie graph components.

Middle Layer Approach

For both technical and non-technical reasons most successful plug-and-play component systems use the "middle layer" approach. A good example is the Open DataBase Connectivity standard (ODBC), which allows an application programmer to interact with a relational database without necessarily knowing which vendor’s database will actually be used at runtime.

So why don’t we just define middle layers for all classes of components, get all application vendors to write to these middle layers, and let the component vendors market directly to the end users? If only it were that simple. First, most opportunities for developing a plug-and-play component standard are far more nebulous than our pie graph example. ODBC was developed only after relational database technology had matured and functionality was relatively consistent from vendor to vendor. Second, many opportunities for really useful component software involve complex data. The problem with complex data is that everyone models it differently, and converting from one model to another is hard.

Let us then distinguish these opportunities for plug-and-play component software into two categories: loosely coupled components and tightly coupled components. Loosely coupled components are generally independent applications that exchange data rather than interact in front of the user. Tightly coupled components, on the other hand, interact with each other more directly and simultaneously, or nearly simultaneously, affect the end user experience. Our pie graph example would be tightly coupled components. A clinical application sending transactions to a billing application would be loosely coupled components.

Solving the Problem

With loosely coupled components, the problem we’re really trying to solve is plug-and-play messaging. For plug-and-play messaging to work, each application must be able to send and receive messages without knowing or caring who’s at the other end. The real problem with plug-and-play messaging is that each application works internally with its own data definitions or schema. For one application to send information to another application, the information must be transformed from one schema to another.

Since an application can’t know in advance the schema of the other application (i.e. plug-and-play), direct transformations from one schema to the other are impossible. Instead, the applications must agree on a common schema to define the content of each type of message, and each application must be responsible for transforming its own data into and out of the common schema. Put another way, two applications can communicate with each other if and only if they support a common set of message definitions.

I should point out here that several message standards have been developed in an attempt to make inter-application communication easier (HL7, X12, Edifact, etc.). While they have largely achieved this, they do not and will not facilitate plug-and-play messaging. Application programmers must still get involved to implement new communication partners. This is largely for two reasons: First, the standards attempt to define a one-size-fits-all schema, and second, these standards don’t provide rich enough transaction, key translation, and constraint features.

The first problem means that as each application developer maps their data into the message, their schema never quite matches the message schema so they make assumptions or define "extended" fields. The second problem means that one application can construct a message that it thinks is perfectly valid, but might be missing some critical data the other application needs to properly interpret the message. Plug-and-play messaging would require independent message definitions, each of which must contain a complete data dictionary, schema and constraint information.

In summary, development components will always be around, but can’t solve some problems that are causing multi-vendor solutions to be difficult to implement. Middle layer solutions can facilitate some tightly coupled plug-and-play component systems, but only if a middlemiddle layer API can be well defined. Plug-and-play messaging can facilitate loosely coupled plug-and-play components, but will require a message definition standard and a message definition clearing-house, neither of which are currently available.

Mark Copenhaver is product manager at JMJ Technologies, Inc., Marietta, GA.