Component Glue

• http://jerry.cs.uiuc.edu/~plop/plop99/proceedings/Eskelin1/ComponentInteractionPatterns.pdf

• http://jerry.cs.uiuc.edu/~plop/plop99/proceedings/plop99-pdfs.tar.gz

Old version in canonical form included below.

Context

You are building a framework into which components can be plugged. You have defined AbstractInteractions between components. Some components need to communicate but play roles in different interactions, or, although they have compatible roles, they have slightly different type signatures.

Problem

How can users easily plug together incompatible components?

Forces

• Components that need to communicate are not always compatible, especially if they are obtained off-the-shelf (or off-the-net :-).
• Writing and testing new components is time consuming.
• Components that are used to adapt between interfaces of other components must be instantiated and bound along with the components of the system that actually perform the functional aspects of the system, so complicating the system architecture.
• Some forms of adaption, such as type coercions that reduce information content, are dangerous or can become dangerous if other parts of the system change.

• Provide a way that users can conveniently create Adaptors to connect such components without spending too much time on trivial communication issues, or complicating the architecture of their system with components whose only job is to adapt communications between other components.
• Create this ComponentGlue as components are connected via ThirdPartyBinding.
• Highlight potentially dangerous adaptions by implementing them as components rather than ComponentGlue.

In C++, template classes can be created for each interface of the framework's AbstractInteractions that delegate calls through member function pointers. Framework users can instantiate such templates to create ComponentGlue.

Scripting languages can be used to provide ComponentGlue. Components can interpret scripts rather than directly communicating with other components. The scripts can adapt parameters from one interface to another. See the Glue Code and pattern at http://www-dse.doc.ic.ac.uk/~np2/patterns/scripting for a more detailed description.

Resulting Context

It is easier to build a system from components if one doesn't have to implement many new components whose only job is to adapt invocations between other components. The ComponentGlue adaptors do not themselves have to be components: they do not themselves plug into the framework but instead facilitate the plugging of components into the framework.

The architectural view of the system (that part of the system where ThirdPartyBinding's are specified) emphasises only those components that are performing application tasks (the "functional" components), and deemphasises those that are performing communication and interface adaption tasks.

Conversely, type coercions performed within ComponentGlue are not so visible at the architectural level. This can hide dangerous bugs. The ArianeFive disaster is an example of a bug caused by a type coercion that was valid in the software for the Ariane 4 but was invalid when other parts of the system were modified for the Ariane 5.

Known Uses

JavaBeans development tools generate anonymous inner classes to act as glue between components, routing events announced by one component to the method(s) of another component that can handle the events.

Tcl/Tk components use Tcl scripts as glue to tie the components into an application. Components evaluate scripts in the Tcl interpreter to announce events. The interpreter therefore acts as a Mediator between components, and scripts act as application-specific strategies used to parameterise components.

SmalltalkLanguage, RubyLanguage, SchemeLanguage and others reify lexical blocks, that are very convenient for defining glue between components.

NatPryce has written a user interface framework in C++ in which user-interface events are announced through abstract interfaces. Template classes that hold object and member-function pointers are used to route event announcements to methods of objects that can handle the events.

Example

Related Patterns

ComponentGlue objects act as Adapters between incompatible interfaces. They can also be considered as Strategies, parameterising the behaviour of the components that communicate through them.

If ComponentGlue is implemented using scripting, the script interpreter (or script-level object, such as a VisualBasic form) acts as a Mediator between components and the scripts used to react to a component's events can be thought of as Strategies modifying the behaviour of that component.

If components support InterfaceDiscovery and scripting, scripts can be generated automatically from the interface signatures of the components between which they are acting as ComponentGlue. This is termed a BootstrapScript at http://www-dse.doc.ic.ac.uk/~np2/patterns/scripting.

On the other hand, if components SplitDesignTimeAndRunTime, ComponentGlue must be generated during system construction.

Gluing components together may require GoingThroughCustoms.

This page mirrored in ComponentDesignPatterns as of April 29, 2006