# Connector and container pattern

The connector pattern is based on the idea of Garlan and Shaw that a realization of an interaction must be a first class citizen of the application model. It must be possible that an interaction - like an application component - has multiple realizations and can be configured. The idea of connectors has been formalized in the context of UML in. A UML connector - a "line" within a composite class - is replaced by an interaction component as shown in the left part of Fig.

The interaction component is typically defined in a model library in form of a <I>template</I>. This is required, since the interaction component must be able to adapt to the context in which it is used. For instance, in case of an operation call of a component, the interaction component must provide the same operation as the component. In most cases, the formal parameter of the template is either an interface or a data-type. The implementation of the interaction component must be adapted as well, in order to correspond to the interface. The implementation body is thus provided in a form a a template of a typical model-to-text (M2T) language, in our case xtend.

The container pattern may be used to modify the way a component interacts with its environment. This pattern has been identified by existing middleware solutions, such as CCM. The container encapsulates an object (component) and can provide additional service and observer or manipulate the interactions with the component. In order to enhance flexibility (and readability) of the application model, it is preferable to add information about the container (in form of rules) to the model, but not the container itself. Thus, a transformation step adds the container to the model.

Connector reification and container expansion