Composition and Federation Patterns in Componentware Software Architectures
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.
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
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
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,
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.
Many of the basic ideas of composition and federation are only known
by example. This little paper, which only scratches the surface,
points out that there is a federation pattern that needs to be better understood
since it is a probable base for scalability in componetware systems.
It appears that the DDB will be constructed as componentware (and not yet
another stovepipe system) so understanding the basic ideas will be key.