Components are such a broad range of technologies that the terminology tends to blur basic distinctions between the different sorts of techniques that are involved. A canonical definition of components would be matter for great debate, but in order to properly frame the concepts in this article and the XML messaging tutorial series, we'll use the following definition.
Component technology is a mechanism for combining various pieces of software into a framework. Each component represents a clear function at a coarse level of granularity that fits into both the framework and other technologies using a very formally defined interface.
A framework is a general environment into which components and individual objects can be placed in order to provide more specific function. For example, a health care framework might have functions and settings that handle regulations and common practices. The individual components and objects within this framework -- perhaps representing practices, insurance groups or even individual physicians -- provide more specific function within the system and rely on the framework to provide the more general environment and rules for their operation.
The easiest way to conceive of the level of granularity is to determine how much processing is performed when a given function of the component is invoked. For instance, say we had a component representing an automobile. A fine level of granularity of its functions might be represented by functions such as "fire spark plug" or "inject fuel." A coarse level of granularity might be represented by the function "accelerate," which encompasses many finely-tuned actions.
The interface is the nature of the functions we can invoke on the component, and the protocol for invoking them. A formal interface for a component representing an encryption system might be of the form "take the given character string, encrypt it, and return the result as another character string. If there is an error, return a null object instead."
Note that there are two broad categories of component technologies: visual components and network components. Visual components include Borland's Delphi and the original JavaBeans. They are usually ways to snap widgets seamlessly into user interfaces within a single code base. Network components are a very different breed, and this article and the associated XML messaging tutorial series focuses on network components.
Network components allow the developer to reuse code, or even reuse individual processes, by having other code within frameworks, or other components, make request to them over a network. There are many specific technologies designed for development and deployment of network components. Well-known examples are Common Object Request Broker Architecture (CORBA), Distributed Component Object Model (DCOM) and Enterprise Javabeans (EJB). There are many other such technologies, ranging from those solving a general need for application glue -- such as XPCOM (from the Mozilla project), to those addressing a highly specialized need -- such as Wireless Application Protocol (WAP).
Where traditional components are king
Traditional component models have been successful largely within a pretty well-bounded domain.
- They work for larger granularities of interface, which means that for each request there is a significant amount of processing being done on the remote side.
- They work well in systems that benefit from the limited descriptiveness of object-oriented technology. (More on this likely controversial statement below.)
- They work well in systems with tight physical coupling. So even if different components reside on different machines, there is usually a direct high-bandwidth network between them, or at the very least a highly-homogeneous network.
- They work well in N-tier applications where the developer has control over the entire scope of the application. They are able to take advantage of proprietary technologies related to operating system, network and software development.
- They are quite efficient if used properly.
- They have had a decade to mature.
Many popular tools provide development and deployment support. And a very important consideration is that traditional components are quite familiar to object-oriented developers.
So what was that about object-oriented technology?
Object-oriented technology is a discipline that borrowed from artificial intelligence the idea of classifying entities into "frames" (known as "classes" in the OO world). Unfortunately, many of the most popular OO technologies and languages have taken the narrowest view of such classification. Many still rely on the original core of OO doctrine: polymorphism, inheritance and encapsulation.
However, when dealing with vast tracts of largely unstructured data (as is common in Internet development), a lot of this neat and rigid categorization breaks down. It becomes harder and harder for traditional component technologies to model such diversity and fluidity of data in a manageable way. The promise of XML-related technology to deal with this problem is one of the reasons XML has exploded onto the scene with such force.
The previous section hinted at some high-level problems with component technology, but here is a summary of some of the more tangible difficulties one can run into when applying traditional component development approaches to systems for Internet deployment:
- Common data representation in requests: A separate portable data representation is used by each component technology, which makes mixing and matching components very difficult.
- Internationalization: Most component tools now have standard means of handling character encodings and other internationalization factors, but most of these techniques are not very general, and therefore add complexity.
- Component discovery and negotiation: Most component tools provide some means of finding components for a particular purpose in order to extend an application after initial deployment. But the techniques involved tend to be tied to particular environments.
- Firewalls: Separation of components from their frameworks or other components by a firewall or some other break in the network topology can introduce difficulties that often have to be solved with proprietary approaches.
- Persistence of messages: In some environments it is useful for the requests from one component to another to be first-class data, which is difficult to accomplish in many component systems.
Not all component technologies suffer from all these problems, and the techniques presented in the XML messaging tutorial series do not necessarily address all these problems. But rather than looking at individual architectural challenges, we'll focus on the fact that the Internet changes many of the fundamental ways in which one considers distributed computing.
The Internet changes everything (but you knew that)
The Internet increases flexibility in that it allows network requests to be made uniformly from a wide variety of platforms, network architectures and programming languages. However, this removes the component developer's flexibility to use proprietary component technologies for development.
One is wary of using Enterprise JavaBeans in case users are running user agents that cannot handle Java remote method requests, or are separated by firewalls. In fact, the user agents might not even be Web browsers -- they might be C++ or Perl programs. For instance, many users have programs automatically retrieve headlines from Slashdot.org, the popular Web log. This is a typical use case for components, but EJB is a poor option for this since the headline-grabbing programs are in C, C++, Python, Perl, TCL, Scheme, etc.
DCOM is a poor option because it shuts out the many Unix users, and is almost as language-constrained as EJB. CORBA supports a great variety of languages, but it typically requires a proliferation of servant components listening on different ports, and its native IIOP network protocol can be problematic considering that some clients might be restricted behind a firewall that prevents access to arbitrary ports.
In addition, component designers might want their products seamlessly integrated into other HTTP-based Web architectures, say in a portal environment. In this case, adding a potential explosion of different communications protocols can be a management headache.
In the end, the most effective way to deploy components for direct use by clients over the Internet is using native Internet protocols. In such cases, XML messaging is a very compelling option because of its broad support across languages and platforms, its reliance on HTTP, which alongside SMTP is one of the most pervasive network protocols in existence (SMTP is less desirable because it is much less of an interactive protocol). Finally, there is an impressive array of related technologies that simplify XML and HTTP development.
We have observed that there are many issues and complexities associated with component technologies of any kind. We could go on forever with discussion of all the particular aspects of XML messaging, but in order to provide a focused and practical approach, this tutorial series will cover a well-defined scope.
What's in scope
The following important aspects of distributed and component computing will be addressed:
- Interface design
- Platform transparency
- Language transparency
- Data marshaling
- Error handling
What's not in scope
Some other matters are beyond the scope of this XML messaging tutorial series. These include:
- Security and user authentication
- Bridging to the component technologies
These are all matters you may have to investigate yourself to complete the development of a practical XML messaging-based component. I'll return to these topics in future articles and tutorials.
Now I urge you to try the XML messaging tutorials. They walk you through the process of building practical XML messaging components in thorough detail. The first two provide background on IDL, needed to provide interface definitions for the components, and HTTP, the communications protocol for the components. The third and fourth tutorials focus on XML messaging itself.
You don't have to plow through them all at once. They are designed to be taken in bite size. You can even skip any of the tutorials if it makes sense. For instance, if you are already familiar with CORBA IDL you will not need to take the first tutorial.
This tutorial series will give you a good grasp of the basic techniques for XML messaging, and once you have completed it (and with some practice), you'll be able to deploy your own Web-based components quite smoothly.
- Introduction to XML: A developerWorks tutorial
- Introduction to XML tutorial at Microsoft
- The definitive list of component-related links
- The Component-based Developer's Headquarters: a Web log on component development topics
Uche Ogbuji is a consultant and co-founder of Fourthought, Inc., a software vendor and consultancy specializing in XML solutions for enterprise knowledge management. Fourthought has developed 4Suite, an open source platform for XML, RDF, and knowledge-management applications. Uche is a computer engineer and writer born in Nigeria; he lives and works in Boulder, Colorado. You can contact Uche at email@example.com.