- Distributed Computing and Thin Clients
- Component-Based Development
- HTML and XML
- Harris Kern's Enterprise Computing Institute
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Component-Based Development
As distributed computing proliferated, it became more obvious that object-oriented technology (OOT) alone was insufficient to solve many of the remaining problems. As discussed in Part I, one of the shortcomings of OOT was that in order to achieve reuse, the developers often had to build large hierarchies of classes in the same language—even worse, often it had to be the same release of the same language. This created a very tight dependency (or, more accurately, tight coupling) between fairly small units of work and required an understanding of low-level details.
Component-based development (CBD) promotes a slightly less technical view of the world and introduces the concept of components. There are many definitions of the term component, but the following definition is adequate: "A component is an identifiable piece of software that describes and/or delivers a set of meaningful services that are invoked via well-defined interfaces."
OOT practitioners would argue that this is similar to the definition of a class, but the difference is that the services provided by a component are clearly separated from its implementation details. With OOT, the calling program has to be written in an object-oriented language; with few exceptions, the receiving program has to be written in the same object-oriented language. On the other hand, component models such as CORBA and DCOM) require interfaces to be cleanly separated from implementation. This separation allows the calling program to be written in one language and the called program to be written in another language.
NOTE
CORBA, an acronym for Common Object Request Broker Architecture, is a set of specifications led by the Object Management Group (OMG), a worldwide consortium whose mission is to promote interoperability. Multiple vendors offer products that implement these specifications; for example, Iona is a leader in the CORBA ORB (Object Request Broker) market segment. CORBA is the most ambitious example of a component model so far.
DCOM is an acronym for Distributed Computing Object Model, Microsoft's component model. The specifications and implementations are both controlled by a single company, Microsoft. Microsoft is evolving much of DCOM into the .Net architecture, which will be covered in a future article.
Another advantage of CBD is that a component can be mapped into a business abstraction, such as an order. While it's certainly possible to do the same with OOT, practitioners have found that such a complex abstraction usually results in many public classes (which have to be written in the same language), adding to the hierarchy of classes mentioned earlier, and thus increasing complexity.
NOTE
A public class is one which the client may have to learn; this may increase the learning curve.
With CBD, we can create a single order component with a well-defined interface; this component is the public face and can route requests to one or more classes behind the scene. (Astute readers may argue that the same objective can be accomplished in OOT by implementing a Façade pattern. However, most practitioners of OOT don't create a separate interface from the implementation. In Java terms, this means creating an interface and then creating a class that implements that interface.)
The benefits of the CBD approach are twofold:
The abstraction can be discussed in business term, such as an order.
The classes from which the component is composed can be written in multiple languages, allowing legacy code to be salvaged.
Note that a component cannot exist in isolation: it needs an execution context (that is, access to a base set of capabilities), and in most cases this execution context is provided by an application server. While it's not mandatory, CBD is often used with distributed computing because components tend to be spread across multiple locations.
In summary, OOT provides a set of powerful concepts (classes, inheritance, etc.) but it needs to be augmented with CBD to realize the proposed benefits (reuse at the business and code level).
At the moment, a cottage industry has emerged to provide components, which can be broadly classified into two major categories: business components and GUI components (predominantly the ActiveX components). An example of a business component firm is Red Celsius; this firm produces a framework of Enterprise Java Beans (often abbreviated as EJBs, these are server-side components), which can be deployed on any J2EE-compliant application server to provide a full-blown eCRM solution.
NOTE
eCRM stands for electronic customer relationship management; that is, a customer-facing application. Market leaders in the eCRM market include Siebel, Peoplesoft (through the acquisition of Vantive), Oracle, and others.
However, CBD still falls short of its promise due to the following limitation: The interfaces are written in proprietary languages and are often too technical for non–IT people. (Anybody who has ever had to decipher CORBA IDL mappings to multiple implementation languages can attest to this.) As we'll show later, web services address this limitation head-on.