PROGRAM MANAGERS

Program Managers An Infrastructure for Program Integration Robert Balzer Information Sciences Institute Balzer@isi.edu

It is unrealistic to expect any single integration framework to emerge as THE industry standard anytime soon. Instead, multiple frameworks will continue to flourish and evolve. The community must therefore be concerned with how components or subsystems in different integration frameworks can be integrated together, how components can be designed to operate in multiple integration frameworks, and how the evolving capabilities of these frameworks can be utilized by integrated systems. These concerns are compounded by the fact that integration is primarily performed by third parties that did not develop the components being integrated.

My primary contention is that these and many other integration concerns can be addressed by exposing the full set of architectural interactions that occur between components and by enabling these interactions to be mediated.

Exposing Architectural Interactions

Applications have an Application Program Interface (API) which describes the calls other programs can make upon that application. But this interface contains only a small portion of the interactions that application has with other components. At least conceptually, applications also have an Application Service Interface (ASI) which describes the calls the application makes on other programs, and if it is interactive, an Application Graphic User Interface (AGUI) which describes the calls made between the application and the graphic user interface.

Together, these interactions constitute the architectural behavior of the system they comprise. When we design or analyze the behavior of a system, we do so through these interactions.

Conceptually, this architectural behavior provides an ideal basis for integrating and coordinating additional components into an existing architecture. Unfortunately, currently this basis is only conceptual because the architectural behavior is neither visible nor accessible. Only the parties participating in the interaction can sense its occurrence or access the particulars of that interaction. This invisibility and inaccessibility prevents integrators from actually using that behavior as the basis of integration.

These architectural interactions can be made visible and accessible by reifying them into events and by making those events available through a publisher-subscriber mechanism. This allows "outside" programs to specify and react to the particular interactions they are interested in.

Such a mechanism is powerful enough to enable one program to monitor, track, and coordinate its behavior with the behavior of another program. Moreover, this relationship can be dynamically established and is only dependent on the architectural behavior reification infrastructure, not the explicit cooperation of the interacting components.

Mediating Architectural Interactions

This behavior reification infrastructure is not yet powerful enough to affect the interactions that are occurring. To do so, it must provide the event subscribers with the ability to modify the events and/or substitute new events. Moreover, the original interaction must be suspended while these event modifications and/or substitutions are being made and then resumed using the updated events.

Program Managers

Program Managers are hidden helper programs that utilize this architecture reification infrastructure to specify behavior events to which to react and the coordinating or mediation actions to perform when those events occur.

Many different types of Program Managers can be built. They can be constructed to authenticate users, authorize requests, enforce security or administrative policies, and enhance services (see Architecture "ilities" section).

But we will focus on their use for component integration:

Integration Manager Examples

We have built two integration managers. The first integrates a third party editor (EMACS) into a COTS E-Mail program (Eudora) so that replies are constructed in the editor. This integration manager detects that a reply is being created, extracts the body of that reply, and inserts it into the editor. It then detects the completion of the editing of that reply, extracts the revised reply body from the editor, reinserts it into the E-Mail program, and queues the reply for delivery.

The second integration manager integrates a third party analyzer into PowerPoint to determine the correctness of an architecture relative to a set of design rules and graphically annotate any errors as the architecture diagram is changed by a user. This integration manager detects user changes to a architecture diagram, extracts a topological model of the architecture, passes that model to the external analyzer, and injects any errors returned back into the architecture diagram as graphic annotations.

Both of these integration managers use the ASI and AGUI interfaces to detect critical events occurring in the applications being integrated, and their APIs to extract and insert the information being exchanged.

Additional Integration Opportunities

Publisher-Subscriber Integration

The Publisher-Subscriber paradigm has become a very popular integration mechanism because its event model supports a separation between publishers and subscribers so that neither needs to know the identities of the individuals in the other class producing or consuming those events. Rather, the linkage is made indirectly through the events themselves.

However, the weakness of this paradigm has been that event production was explicit. Special "Announce" or "Publish" statements were wired into the source code. This early binding of which events would be produced prevented third party integrators from specifying the particular events needed for integration. They had to be lucky enough that the required integration events were a subset of the predefined set of published events.

Program Managers eliminate this early binding problem by allowing the events to be detected to be dynamically specified and by allowing those events to be composed from any of the exposed architectural behavior of the managed component.

Virtual Execution Environment

Program Managers can change both the perceived and actual execution environments in which a component operates. By changing the perceived execution environment (i.e. by mediating the responses to "environment" queries), it can determine which resources and services to make available for use by the component and how the component should configure itself.

By changing the actual execution environment, through mediating service requests, Program Managers can substitute one resource and/or service for another and perform the translations needed for such substitutions.

Program Managers can thus create a virtual execution environment for a managed component in which the set of perceived resources and services can be changed and substitute resources and services can be transparently employed.

Adding Architectural "ilities"

Consider using this program manager infrastructure to add architectural "ilities" to an existing system, possibly composed of several third party components, by transparently embedding additional capabilities into the services employed by this system. Accountability can be added to the architecture (as opposed to adding it to the components) by capturing the actions taken by the system and recording them in an audit trail. Availability can be architecturally added by duplicating command and data streams and routing them to distributed copies of critical components of the system that function as "hot backups" for the original components. Security can be architecturally added by transparently encrypting transmissions and decrypting them upon receipt. Performance improvements can be architecturally added by caching data and computations and by compressing transmissions. Finally, scalability can be architecturally added by distributing the workload over multiple copies of the system and coordinating their updates to the system’s state.