next up previous contents
Next: Limitations of Current Component Up: Introduction Previous: Introduction   Contents


Component Architectures

Software components allow composition of software programs from off-the-shelf software pieces. They aid in rapid prototyping and have been used mainly for developing GUIs, database as well as Web applications, and have been found very successful in building these software applications. Object-oriented programming aids in developing software components because of its support for encapsulation, and in separating interface from implementation. Based on these principles, various component models have been developed. Of these, a few such as Microsoft's COM [68], OMG's CORBA [64], and Sun Microsystems' JavaBeans [58] have become popular as distributed application integration technologies. A software component is a set of objects with published interfaces, and it obeys the rules specified by the underlying component model. A component model specifies rules to be obeyed by components conforming to that model. A component model along with a set of ``system components'' defines a component architecture.

Current component technologies cross language barriers, thus allowing an application written using one language to incorporate components written using another. In order to achieve this, components have to provide interface specification in a neutral language called Interface Description Language (IDL). All component models use some form of Interface Description Language. Though these IDLs differ in syntax, they can be used to specify almost the same concept of an interface. An interface consists of a set of ``functions'' or ``methods'' with typed parameters, and return types. These functions or methods can be synchronous (caller waits for return of method) or asynchronous (one-way). Caller of a method is referred to as ``Client'', whereas the object whose method is called is referred to as ``Server''. Client and Server need not reside on the same machine if the underlying component model supports remote method invocation.

Remote method invocation involves marshaling input parameters (or serializing into a message), ``stamping'' the message with the component and method identifier, dispatching that message, and in case of synchronous methods, waiting for the results. On the receiving side, the parameters are unmarshalled, and the specified method is called on the specified component (actually an instance of the component). A similar technique is employed for creating instances of components, or locating components, by invoking methods of system component instances, which provide these services. The server machine, which contains the server component instances, employs a scheduler (or uses the system scheduler) that waits continuously for the next message indicating a method invocation, locates the specified component instance, verifies access controls, if any, and calls the specified method on that component instance. Other services, such as security, privacy, accounting, logging etc are either built into the scheduler, or are available as system services that are invoked as preprocessing and/or post-processing stages for each method invocation.


next up previous contents
Next: Limitations of Current Component Up: Introduction Previous: Introduction   Contents
Milind Bhandarkar 2002-06-12