BBN Technologies / GTE Internetworking
1827 S. Liberty Dr.
Liberty Lake, WA 99019
on Compositional Software Architectures
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.
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.
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.