Composition and Federation Patterns in Componentware Software Architectures

Problem

• if a software system is constructed as a monolith, it embeds a certain family of functionality, scales to a certain extent and is extensible in prespecified ways.  But it may be difficult for others than the original design team to extend its capabilities, scale the system for flexible unforseen needs, or evolve the system.
• Stovepipe systems are constructed from a fixed collection of functions.  Each of the functions may not itself be best-of-class or extensible but together the system accomplishes today's goals.  Generally, stovepipe systems may not be reconfigurable and may not accomplish tomorrow's goals in a quickly changing environment.
• The unit of replacement (what parts must be replaced if the system is not doing it job) in stovepipe systems in the entire system.  The unit of replication is the entire system.  There is no guarantee that two copies of a stovepipe system will interoperate.
• We need more flexible architectures to meet future needs and preserve Architectural Properties (see .doc foil in companion email at lower cost.

Solution Approach

• Componentware - The promise (not always realized) of componentware is that you will be able to construct larger systems from components that are preexisting and already tested.
• The benefits to system developers is that systems can be constructed more quickly and reliably from tested parts.
• The benefit to end users is to reduce the learning curve for new system that families of systems constructed with similar parts are likely to have a common semantics, which is like but goes beyond a common look-and-feel to provide end-users a general sense of knowing how unfamiliar system will operate because they follow conventions and reuse common parts from know systems.
• Composition Pattern - If a system S can be viewed as a composition of services (aka components) or subsystems and the composition glue is "programmable" then we can say that a system's architecture is constructed using the composition pattern.   This generic pattern implies that the behavior of the system can be evolved by adding or specializing components.  It also implies that there is a binding time (e.g., design time, compile time, run-time) when functionality can be added.
• Federation Pattern - If like systems can interoperate as if they formed a larger whole that provides the same functions of the original systems, then we can say the system's architecture is constructed using the federation pattern.  Federations are a principal means of scaling systems.  We can distinguish between
• homogeneous federations composed of like subsystems with at least the same interfaces and usually the same implementations and which exposing the same interface for the composed system and
• heterogeneous federations where some amount of mediation is required to coerce some subsystem

Examples of Federation Pattern

The following are examples of the federation pattern, where two or more of a kind of a service or system interoperate in a scalable manner.  In all cases, they must expose some kinds of protocols formerly used inside themselves on the outside so their neighbors can interface to them.  For instance:  if two systems contain objects and relationships internally but then there is a need to have relationships that span the two systems then a relationships protocol is define that allows objects in one system to be related to objects in another.

• Services - as in OMG services like
• naming - so multiple name spaces can be federated
• transactions - to allow nested transactions.  See X/Open XA protocol for prepare to commit protocol
• relationships and proposed topology service, also various hypertext linking services - these separate the relationships from the data so the data can be viewed with different collections of relationships.  Also, workflow and compound documents use relationships as a kind of federation glue for hooking together diverse kinds of applications.  Pedigrees and Uncertainty propagation that must be passed across system boundaries will need a federation protocol.  Similarly, annotation.
• query - so a query can be broken into subqueries and operated on by different DBMS'.  The DARPA I*3 community is working on this.
• rules, change management, replication, ... in fact, many functions that used to be inside a system can be externalized and are candidates for federation:  indexing, optimization, concurrency, ...
• Systems - not only services but systems need federation protocols to allow them to operate with others of their kind
• CORBA Interoperability - defines how two or more CORBA implementations can interoperate via IIOP.  This allows multiple distributed systems to operate as one.
• Tracking DBMS and IMDB DBMS - both provided ways to cover geographic regions and transfer objects across DBMS and ownership boundaries as they moved.  The Motorola Iridium system also uses a sophisticated form of federation to manage tracking moving objects by other moving objects (satellites) via handoffs.
• Workflow Interoperability - so multiple workflow systems can interoperate. WfMC is working on this.
• Simulation architectures - the ALP and current day High Level Architecture (HLA) are for federating simulations.  They require component simulations to use common time and send each other coordination messages
• Web architectures - based on standard protocols (URLs, HTML, HTTP) so clients can talk to any server.
• End-to-End X where X = security, quality of service, or some other architectural property like scalability, understandability, etc. - this property of a system will be true if the federation patterns with respect to the property X of its subsystems is preserved in the system as a whole.

Federation Pattern Ontology

• Some terms that need to be defined:  composition, federation, interoperation, control, boundary, seamless, X-unaware, control, copy vs. reference semantics, loose coupling vs tight coupling, consistency management, homogeneous vs heterogeneous federation, negotiation, policy, optimization, end-to-end, scaling, evolution
• See Componentware Glossary.

Open Issues

• The promise of componentware vs the reality of componentwhere.  But this seems to be changing with ActiveX and Java/Beans as large communities share more software.  Still, no one has ever constructed a very large componentware solution (the size of the DDB).
• boundaries and control regimes.   There are many kinds of boundaries (language boundary, legal and national boundaries, policy boundaries, proprietary, persistent, encrypted, versioned, ...).  One needs a way to say what boundaries an object is controlled by.
• packaging.  We need to understand what we mean by inside a system and outside.  That governs a lot of the federation pattern's applicability.  If we can easily migrate functionality between the inside and outside, we get the most benefit since then code works on either side without change.

Conclusion