Developing for Composition

Mike Dean
BBN Technologies / GTE Internetworking
1827 S. Liberty Dr.
Liberty Lake, WA 99019
(509) 255-5935
mdean@bbn.com

OMG-DARPA-MCC Workshop on Compositional Software Architectures
Monterey, CA
January, 1998

Introduction

A traditional view of component-based software architectures consists of two tiers: a set of reusable component building blocks, and a set of application servers which use them. This view is ineffective, as any of the application servers may themselves be specialized, adding to the component base. This position paper uses 3 examples to discuss some of the motivations and techniques for building servers with such specialization in mind.

Plan Server Example

The JTF/AITS Reference Architecture which forms the basis of the DARPA JTF ATD project, leads one to think about a single Plan Server among its core set of services and servers. The Plan Server provides persistent storage of plan objects defined using a common schema, and supports operations upon them.

In actual use, we've found that projects using the Plan Server will often need to extend the common schema and may wish to add their own behaviors on new and existing objects. Absent facilities for mobile code and/or dynamic composition (which would likely incur significant performance penalties even if available) this implies that each such project will need to develop its own specialization of the Plan Server.

We're currently in the process of adapting the JTF ATD Plan Server so that it can be easily specialized, by adapting some of the packaging techniques we've developed for the Web Services and finec2 components used by the Plan Server. These include making server implementation (skeleton) classes visible and packaging code in libraries that can be linked into specializers.

Project-specific specialization of the Plan Server also allows greater flexibility in selecting among the set of Object Services components (consisting of CORBAservices and specializations, plus our own services for persistence and replication) that are becoming a major emphasis in the JTF ATD project.

Naming Example

The CORBA Naming Service provides the ability to associate symbolic names with CORBA object references. Implementations of the Naming Service are currently available from several ORB vendors including Iona (Orbix) and Visigenic (VisiBroker). However, the C++ implementations are packaged as standalone server executables, rather than as libraries suitable for specialization.

Examples motivating specialization of the Name Service come from the development and use of the Cronus distributed computing environment, an object-oriented distributed computing infrastructure that predates CORBA. Names and other identifiers are often very intrinsic properties of objects (e.g. names and Social Security Numbers of people, or hull numbers of ships) that are too important to leave as external associations, but extremely valuable catalog keys. A mount point mechanism was added to the Cronus Catalog Manager (the equivalent of the CORBA Naming Service) to allow a server to present its internally-maintained namespaces as a read-only catalog directory. This could be done in CORBA by having the server implement the CosNaming::NamingContext interface. It may be helpful in implementing this interface, however, if the internal support routines (e.g. facilities for manipulating compound Names, and the implementation of BindingIterator) used to build the Naming Service itself were available.

Events Example

Support for collaboration is a key goal of the JTF ATD, which has led to the development of our Unified Trigger Architecture (UTA). Recently, it's been suggested that we should make more direct use of the CORBA Event Service in setting triggers and delivering notifications. Essentially, each of our objects would become its own EventChannel.

Implementations of the Event Service are also available from several ORB vendors. Visigenic packages their EventChannel implementations in shared libraries so that they can be can be managed within either the supplier or consumer processes. This may also allow for specialization. The Iona implementation is packaged as a separate standalone executable.

Specialization is motivated by the ability to perform "source filtering" of event notifications, suppressing them within the object before they become ORB invocations. With large numbers of objects, this becomes critical to achieving adequate performance. Currently, we support filtering based on event type (read, modify, delete, conflict_detected, etc.). In the future, we expect to add filtering based on object attribute values and cumulative trends (e.g. notify me when the temperature attribute of this object has changed by more than 10 degrees). Our "homebrew" trigger interfaces currently allow for these capabilities.

Our current plan is to specialize the EventChannel interface. Clients using the standard interface will be given default filtering characteristics (e.g. only update and delete events, with no value constraints). Clients using our specialized interfaces will be able to exert finer control.

An alternative implementation option not requiring specialization would be to use delegation to associate an EventChannel within the standard Event Service with each object. This is impractical as it doubles the number of objects, significantly increases the time to set triggers (which are often done on many objects at once using looped invocations within the server), and requires that the EventChannel objects be maintained as the corresponding JTF ATD objects are created and deleted.

We expect to reimplement the Event Service where necessary to provide our own specialization of it. Unfortunately, we won't generally be able to inherit/reuse code from the existing commercial implementations. This will also preclude the use of special implementation features, such as the IP multicast delivery facilities provided by OrbixTalk.

Conclusions

It's difficult to accurately predict in advance which servers are likely to be specialized, and often expensive to retrofit reuse. Fortunately, it's easy to allow for reuse from the beginning, by exposing implementation classes, documenting assumptions and dependencies, and packaging implementations in libraries. I recommend that CORBA developers design and package all of their servers so that they can be easily specialized.

About the Author

Mike Dean is a Division Computer Scientist at BBN Technologies and Chief Programmer of the DARPA Joint Task Force Advanced Technology Demonstration (JTF ATD), which is developing a CORBA-based architecture and infrastructure for use in DARPA and other DoD organizations. His JTF ATD development work includes the Plan Server, the Unified Trigger Architecture, and the nightly build process. Previously, he was one of the principal developers of the Cronus/Corbus distributed computing environment, an object-oriented distributed computing infrastructure that predates CORBA. He received a B.S. from Stanford University in 1982.