Abstract

An architectural component has a rich set of elements specifying its boundary, while an object interface definition in an object-oriented implementation has limited capability. These differences give rise to a gap between architectural components and objects in object-oriented implementations. Given the central importance of software architecture in component-based software engineering, bridging this gap becomes a key goal in component software development. In this paper, we describe the gap and its implications for component management. We also outline a framework to bridge the gap. In this framework, inter-component communication is separated from the components and handled by ports and links which deal with infrastructure level middleware and protocols, including CORBA IIOP and Java RMI. We then describe the prototyping of components based on the framework utilizing JavaBeans with extended JavaBeans introspection features to assist in component assembly.

1. Introduction

Component-based systems mean different things to different people. Component definitions vary depending on viewpoints and programming paradigms. As a result, we find that modules, functions, processes, objects, and so on are referred to as components in the research literature [3], [5], [6], [7] and in industry software products. In addition, composition approaches vary accordingly. While conceptually components do not need to be tied to any particular programming paradigm or point of view, the discussion here lies within the object-oriented software development domain.

Component-based software development for complex system depends upon an analysis of software architecture [1], [2], [3], [4], i.e., upon an understanding of system characteristics and functionality in terms of components and their interactions. We refer to components at the architecture level as architectural components. The boundary of an architectural component is composed of elements such as the events it generates or observes, the services it provides or requires, and non-functional properties such as resource requirement and quality of service. On the other hand, in an object-oriented implementation, an object interface definition only contains services provided in terms of object methods. In short, there is a gap between the notions of architectural components and objects in object-oriented implementations.

We believe this gap has significant implications for component management. It also reflects some differences between academic research and industrial efforts with regard to component-based software engineering. By bridging the gap, components at the architectural level can be smoothly mapped to concrete component models such as JavaBeans and ActiveX, and eventually to objects at the infrastructure level based on CORBA, Java, or COM+ technologies. In the remainder of the paper, we first describe this gap and it's implication for component management, then describe a framework for distributed component-based software development that bridges the gap and the roles of component models such as JavaBeans, ActiveX and infrastructure technologies such as CORBA, Java, and COM+.

2. Architectural Components and Object-Oriented Implementations

In our architectural component model, a component consists of a boundary and a group of internal parts. The boundary of a component is defined by these elements: the events it generates, the events it observes, the services it requires, the services it provides, and additional non-functional properties. Clearly, when the boundary of a component consists only of the element "services it provides", the component is a pure service provider. It is also possible to have a pure event generator or a pure event observer.

Based on this conceptual model, several distinguishing features of the gap that highlight the differences between components and objects can be identified: (1) components have separate interface definitions and implementations, while an object may not have a separate interface definition and implementation, (2) a component boundary consists of a richer set of elements than an object interface, (3) component dependencies are explicitly declared while object dependencies are buried in code, and (4) component relations including subtyping, equivalence, and so on are different from relations in objects and their classes. Not only are inheritance, aggregation, and containment relations between components present, but also relations among interfaces, services, events, and implementations must be managed. It is a consequence of this gap that component management is more complex than object management. The diversity of industry component models and different distributed object infrastructures also contribute to this complexity. For example, relations specifically for JavaBeans or ActiveX components, and distributed infrastructure models such as CORBA and COM+ must also be managed. In essence, component management encompasses the coherent management of elements on three major levels: the architecture level, the component level, and the infrastructure level.

In the next section, we describe a framework that is designed to bridge the gap between architectural components and object-oriented implementations.

3. Bridging the Gap: Framework and Composition

Component-based development differs from object-oriented development not so much in the low level details, but rather in the high level design abstractions. Once the boundary of a component is defined, how does an internal part of a component access services from providers outside the component boundary? How should elements in the component boundary be mapped to elements in an object-oriented interface? For distributed systems, which distributed middleware (CORBA ORB, which ORB, Java RMI, MOM ...?) or lower level protocol (TCP, RPC ...?) should be utilized? Answers to these questions clearly depend on a variety of development and deployment considerations. The choice of answers can potentially introduce strong dependencies between components and infrastructure elements, and between components themselves. We have designed and implemented a framework to address these questions, one that uses Ports and Links to bridge the gap between components and objects.

Ports are agents that handle service requests or events coming in and going out of a component. Links are responsible for connecting requester ports and provider ports either locally or remotely. As an implementation, Ports and Links are implemented as Java classes. Class Port is subclassed by ServicePort and EventPort. ServicePort is further subclassed by DiscreteServicePort and SessionServicePort. DiscreteServicePort is responsible for discrete service requests, while SessionServicePort handles a group of services that have partially ordered dependencies. This group of services is often defined by an interface. ServicePort is then subclassed by xxxServiceProvidePort and xxxServiceRequirePort; event port is subclassed by EventGeneratePort and EventObservePort. Further, DiscreteServiceProvidePort is subclassed by DataProducePort and DiscreteServiceRequirePort is subclassed by DataConsumePort, and so on. A port corresponds to an element in the component boundary and belongs to a component.

Class Link is subclassed by EventLink, ServiceLink, and EventServiceLink etc. ServiceLink is subclassed by DataLink, DiscreteServiceLink, and SessionServiceLink, each of which is subclassed by LocalxxxLink, RMIxxxLink, IIOPxxxLink, SocketxxxLink, HTTPxxxLink and so on. There is similar subclassing for other types of links. It is a link's responsibility to take care of the details necessary to connect two ports via either a specific type of middleware or a low level protocol. Hence, links are very middleware and protocol dependent, but they remove dependencies between components and infrastructure elements, as well as among component themselves.

Ports and Links are components in their own right. One consequence of this is that components with ports can be composed, or connected: (component parts<-->port) <--> link <--> (port<-->component parts). Note that if we degrade Ports to attribute variables and place the functionality of Links inside components, then the dependencies between components and distributed infrastructure elements, and among components themselves, would be strong and implicit. On the other hand, if Ports and Links are abstracted to the higher component level, then separation of dependency concerns is achieved. For example, ports and links can be replaced without affecting component core functionality. Common object services such as CORBA Naming, Trader, and Security can be used by smart ports or links to select interaction strategies and partners that meet their selection criteria. The framework thus provides a reasonably general and flexible foundation for component assembly: component core functionality is separated from inter-component communications, component independency is achievable, component composability and flexibility are enhanced, and decisions on communication strategies, protocols, and partners are delayed until assembly-time or run-time.

We have prototyped architectural components based on JavaBeans and implemented IIOP links based on IONA OrbixWeb. A bean component is equipped with ports if it has properties that are subtypes of Port. In order to discover what ports a component is equipped with, we extended the Java PropertyDescriptor class with a PortDescriptor class and extended the Java BeanInfo interface with a SoftBeanInfo interface. The SoftBeanInfo interface extends the BeanInfo interface with one operation "PortDescriptor[] getPortDescriptors()". Bean boundary information is discovered by introspection either on a BeanInfo object if available or on the bean itself. We further enhanced the BeanBox from BDK1.0 [8] so that it can extract PortDescriptor information, if available, from the component boundary and use such information to assist visual component assembly. By means of this extension, bean components can not only be composed using events but also be assembled using ports and links.

4. Conclusions and Future Work

In this paper we described several differences between architectural components and objects in object-oriented implementations, the implications for component management, a framework to bridge the gap, and a prototype implementation based on the framework. The key feature provided by this approach is the smooth transition between architectural, component, and infrastructure level design and development for component-based software engineering.

Future work is focused on architecture level component-based software engineering. In this regard, we are working to integrate architectural description languages and architecture analysis tools in our prototype.

References

Biography

H. Alan MacLean is manager of the Distributed Software Technology Program in the Applied Research and Technology organization at The Boeing Company. His research interests are in distributed computing. He has a Ph.D. degree in Mathematics from Kansas State University.