A position paper presented at the 1998 International Workshop on Component-Based Software Engineering

Abstract

In this paper, we present a connector model for software architectural representation of complex component collaborations. Our connector model is based on research in software architecture and object-oriented modeling, and part of a design framework for modeling component-based systems that are built using object integration technologies like the OMG's CORBA. We propose connectors as pattern-like, transferable abstractions of component interconnection and interoperation that can be used to model the abstract architecture of a system. Connectors describe a rationale for introducing individual component features and adaptations, and advance the understanding of the concrete programming architecture of an integrated object system.

1. Introduction

Current software architecture research [1] views and models a software system as a set of components and connectors. Components are abstractions of system level computational entities, connectors are abstractions of component interrelationships. The components, and the mechanisms guiding their interoperation (like communication styles and interaction protocols), are recorded as separate, distinct architectural abstractions. This separation of design concerns leads to system representations that make information about component connections explicit, thus favors a compositional design approach to integrate components by means of connectors.

Object technologies like the OMG's CORBA [2], on the other hand, are enabling technologies that aim to facilitate integration implementation of diverse software components in distributed, heterogeneous environments [3]. CORBA and similar object integration technologies define a standard component interconnection and interoperation model, and promote object-oriented principles to encapsulate incompatible component implementations: All integrated software entities are considered objects that export object-like interfaces and interact by means of (synchronous) method invocation. Further and varied communication and interaction models for cooperating components are introduced with general purpose object services like the CORBAServices [4], which are mapped to the basic object communication model of the object request broker. For example, the Events service defines an asynchronous, decoupled communication model for CORBA components; the Transactions service augments the basic object model with the notion of distributed transactions and specific transaction processing models. Object integration technologies in this way synergistically combine object, distribution, middleware, and even further technologies like database technology.

In our research, we focus attention on suitable architectural abstraction concepts of components and connectors for systems that are built using object integration technologies like CORBA. Our aim is to provide abstract modeling constructs that relate well to programming constructs of component infrastructure technology to support smooth transitioning between different software development phases and system descriptions. In this paper, we present our connector model for object-oriented component integration. We start with a discussion of related work of software architecture research and of object-oriented modeling that focuses on the description of component collaborations, and identify issues for describing ORB component collaborations. We propose connectors as pattern-like transferable abstractions of system level component interconnection and interoperation. Connectors are architectural abstractions of component coordination in the abstract architecture of a system only. Connectors describe a collaboration rationale for component adaptations, which are then modeled in the concrete architecture of a system. The concrete architecture consists of component abstractions only that relate to component models of ORB object infrastructure technology. By establishing these two levels of architectural description, the understanding of complex component interplay is advanced: the abstract architecture represents the system on a very abstract level using connectors, the concrete architecture exhibits individual component adaptations which have been made because of connector collaboration rationale.

2. Focus on Component Collaborations

2.1. Software Architecture Research

A major field within software architecture research is the development of architectural description languages (ADLs). A well-known exemplar of an ADL is UniCon [5]. In UniCon, connectors are first-class language constructs symmetrical to components that mediate interactions among components. Connectors are specified by protocols that consist of the connector type, additional properties, and a list of roles as types that must be satisfied by components. UniCon supports a number of built-in connectors for data flow, procedural, data sharing, or other component connections.
Another exemplar of an ADL is the ACME ADL [6], which has been developed as a common interchange format for architecture design tools. The notion of connectors as employed in ACME is similar to the one of UniCon: Connectors are first-class language constructs that define roles and are characterized by properties like interaction protocols. However, ACME allows the inclusion of different, various ADL-specific information, so that connector protocols, for example, may be expressed in any other specific ADL (that must be understood by tools and system developers in order for the architectural description to be meaningful).

Common to these and other ADLs is that the connectors discussed are of a rather primitive nature, like the recurring example connector "RemoteProcedureCall". Connectors of ADLs are language constructs, but despite their linguistic character, they do not directly correspond to compilation units of programming, but can be realized in various, often undefined ways by means of programming languages and operating systems. ADLs furthermore aim at universal architectural descriptions for diverse classes of software systems and modeling and design problems, and are not restricted nor dedicated to object-orientation.

In the design of ORB-based component systems, however, the component collaborations of interest typically are of a very complex nature (for example, a transactional processing component collaboration), and are based on a specific object-oriented computational model. This requires a more specialized connector model than the universal connector models of ADLs.

2.2. Object-Oriented Modeling

Research in object-oriented modeling comprises the development of object modeling languages, of system development methodologies, and of reusable software solution structures for object-oriented system design. An example of an object-oriented methodology is the UML-based [7] Catalysis methodology [8] that proposes collaborations as an abstraction construct for object interactions. Collaborations are modeled as a set of actions involving multiple participants that are represented as object types. Catalysis collaborations relate to connectors of software architecture, but focus attention on object interactions, and are realized as object operations.

While Catalysis collaborations are specific to particular systems, design patterns are application independent abstractions of a group of interacting objects. Design patterns are structured and named descriptions of recurring design problems and proven generic solutions to these problems that can be customized and applied to different systems, if the systems exhibit similar requirements. A design pattern template structuring pattern descriptions using motivating examples, structural and behavioral object diagrams (class diagrams, statecharts, message sequence diagrams), code examples, and further discussions related to the pattern application, has been introduced by Gamma et al. [9].

Traditionally, object-oriented modeling has structured system descriptions around programming language units like classes, but has not provided architectural abstraction constructs for system level components and component interconnections. ORB integrated components are, however, of varying granularity and complexity, as complete application systems qualify as objects, if they export object-like interfaces. Wrapped legacy applications can behave externally like an object through well-defined interfaces, but may internally not be designed and implemented in an object-oriented way at all. Class abstractions are problematic in that sense, and special attention must be paid when class associations like generalization/specialization, aggregation, or composition are to be interpreted for ORB component associations. Design patterns and collaborations as in Catalysis are powerful abstractions for ORB software system design, if the level of abstraction is raised from programming to software architecture and to the integration of software components.

3. Connectors as Pattern-like Transferable Abstractions

We propose connectors as transferable abstractions for object-oriented component integration. Connectors abstract component responsibilities and interdependencies for various kinds of collaborations as system level architectural patterns. Connectors are described using roles, role interfaces, and interaction protocols. In the following, we present a connector template for representing the various connector information.

Roles. Roles model collaboration responsibilities to abstract from specific components. A role describes a collaboration participant that is fulfilled by a specific component when instantiating the connector (a component plays one or multiple roles). For example, an "Event Notification" connector for implicit invocation comprises roles like "EventPushSupplier", "EventChannel", or "EventPushConsumer".

Role Interfaces. Role interfaces model role behavior in terms of provided and/or required services. Multiple role interfaces for a single role, and directed usage relationships between a role and other role's interfaces can be specified. For example, the role "EventChannel" provides role interfaces like "EventChannel", "ConsumerAdmin", or "ProxyPushSupplier". Role interfaces may be expressed using an interface definition language like OMG IDL.

Interactions. Interaction protocols describe sequences of requests among multiple roles along with pre- and postconditions to be considered. Interaction protocols refer to services of role interfaces, and describe role interface usages for various interactions of the collaboration. For example, in the "Event Notification" connector the interaction "Connecting as PushConsumer" may specify that an event consumer must register itself to the component playing the role of "EventChannel" via doubled dispatching (use of the "EventChannel" and of the "ConsumerAdmin" interface to obtain a "ProxyPushSupplier" object reference, as described in the OMG's Events service). Other "Event Notification" interactions include "Pushing Event Data", or "Pulling Event Data". Interactions may be expressed using UML generic sequence diagrams (the connector roles are interpreted as UML types), or other protocol formalisms.

Modeling Example. A modeling example describes a use and impact of applying the connector to specific components. The modeling example consists of descriptions of the components, an abstract architecture, and a concrete architecture.

For describing components, we provide a component template that structures component information into three sections: the system level component interfaces, the programming level interfaces of a component implementation, and the internal component realization design. Our component model is described in more detail in [10].

Abstract Architecture. The abstract architecture of a component composition refers to components being related by means of the connector. The component scheme describes the distribution of role responsibilities as defined in the connector to the components involved.
Using connector-based component schemes, a component collaboration is described on a very abstract level of architectural description. This abstract architecture describes in a pragmatic manner that the components are in collaboration according to the defined interfaces and interaction protocols as given with the (component-independent) connector specification.

Concrete Architecture. The concrete architecture of a component composition refers to the architectural description that consists of component abstractions only. The individual component descriptions exhibit all features of the component relevant for the collaboration, i.e., the component customizations and adaptations which have been made because of connector collaboration rationale. As such, a collaboration view on individual components is provided with the concrete architecture. The concrete architecture provides a more implementation-oriented architectural representation, as the component abstractions can be well related to constructs of ORB infrastructure technology.

4. Summary

To focus on component collaborations rather than on single, individual computational entities, has been subject in both software architecture research and object-oriented modeling. We have presented a connector model for object-oriented component integration which combines ideas of software architectural connectors and object-oriented design patterns.

The provision of transferable, reusable abstractions of component collaborations is of predominant importance in the development of ORB-based integrated systems, especially when regarding object services like the CORBAServices, which are now more and more populating the core object integration technologies. The introduction and use of object services describes an impact on the (re)design of (existing) single components and of component configurations, as standard required interfaces and complex interaction models are defined. Connectors can be used to capture and document impacts as introduced by object services as distinct abstractions of design, as has been exemplified for interaction models of the Events, Relationship, and Transaction service [11], [12].

We propose to represent the software architecture of ORB-based integrated component systems on two different levels of abstraction: using connectors for the abstract architecture, and using component abstractions only for the concrete architecture. Architectural abstractions and software solutions of ORB infrastructure technology can in this way be well related, advancing the understanding of complex component compositions.

We are currently investigating connector abstractions for selected CORBAServices, in particular connectors for the Object Transaction Service (as part of a university project with IONA Technologies), and for the application domain of integrating air traffic control software components in a CORBA-based infrastructure (as part of a university project with EUROCONTROL Experimental Centre).

Acknowledgments

To Peter Löhr, Freie Universität Berlin, for his comments on an earlier version of this paper.

References