When using the Direct Connection runtime pattern, shown in the first figure below, the source application uses a connector to access the target application.

The connector itself may be explicitly or implicitly modeled. If the connector is explicitly modeled, the modeler can use decomposition and abstraction techniques to expand the connector to the appropriate level of detail.

The term Connector may be qualified by both the connector variation and by the interaction variation. Some examples are:

• Adapter Connector
• Path Connector
• Message Connector
• Call Connector
• Call Adapter Connector

The source and target applications both rely on services provided by their respective hosting servers. These are modeled using the Application Server/Services component.

The Rules Directory and Domain QoS Providers may or may not exist. If they do exist, it is a modeling decision as to whether they need to be shown in the Runtime pattern. For example, analysis may determine that connection rules are not an important part of the solution, so the Rules Directory may be left off the Runtime pattern.

Direct Connection runtime pattern

Two Application Server / Services nodes are connected via a Connector node. Additionally a Rules Directory node and a Domain QoS Providers may or may not exist.
Design Last Updated: 10-20-2004
(Click a node to get a detailed explanation.)

The basic Direct Connection runtime pattern allows integration between a source and target application that use different protocols using a single adapter connector. Direct Connection using a single adapter connector is shown in the figure below.

Direct Connection using single adapter

Two Application Server / Services nodes are connected via a Adapter Connector node

Design Last Updated: 10-20-2004
(Click a node to get a detailed explanation.)

Direct Connection can also be implemented using federated adapters, as shown in the figure below, to improve reuse potential in multiple point to point scenarios. It supports conversion of the request and response into a common protocol between the adapters.

Direct Connection using federated adapters (aka coupling adapters)

Two Application Server / Services nodes are connected via two federated Adapter Connector nodes

Design Last Updated: 10-20-2004
(Click a node to get a detailed explanation.)

In this second section we specialize the Direct Connection pattern for the SOA environment using the SOA profile. The SOA profile terminology is indicated using the [SOA] qualifier.

[SOA]Direct Connection

Design Last Updated: 10-20-2004
(Click a node to get a detailed explanation.)

There are two ways of modelling the service bus. Either as a line as shown or as an elongated node as used for the Enterprise Service Bus in the more advanced patterns. The service bus provides a base SOA pattern. Increasingly an Enterprise Service Bus will be used to realise the service bus supporting multiple Process Integration patterns over a common ESB. The figure above shows a service consumer connected to two other service providers via a simple service bus. The application pattern overlays in the figure above show that multiple Direct Connection application patterns can be deployed using the service bus. The service consumer (or Source Application) can use the service bus to initiate direct connections to two service providers; one to Target Application 1 and the other to Target Application 2.

In order to focus on the service bus concept, we do not explicitly model adapter connectors or connection rules. The service bus concept is, however, an extension of the Direct Connection with federated adapters runtime pattern described above that enables a set of connected Direct Connections. The service bus approach:

• Minimizes the number of adapters required for each point-to-point connection to link service consumers to service providers.
• Improves reuse in multiple point-to-point scenarios.
• Addresses any technical and information model discrepancies amongst services.

[SOA]Direct Connection with federated adapters

Design Last Updated: 10-20-2004
(Click a node to get a detailed explanation.)

The figure above shows the service bus with the adapter connectors explicitly modelled. The common protocol or format of the service bus is of 'X'-type, and 'X'-type adapter connectors are used to bridge the various service consumers/providers of different types. We call a connected set of 'X'-type adapter connectors such as this an 'X'-type bus. Examples include a HTTP service bus or a JMS service bus.

The service bus can span across multiple system/application tiers, and may extend beyond the enterprise boundary.

A Rules Repository node may also be included to model a service directory, allowing services to be discovered within and outside the enterprise.

You may notice that we don't have separate Runtime patterns for the message and call variations of the Direct Connection application pattern. It is still important to identify that your business scenario requires a message or call application pattern, because you can use this knowledge as a consideration when selecting a Product mapping. In the next section we highlight Product mappings that have a more natural fit to the Application pattern message variation or the Application pattern call variation using both the SOA and Generic runtime patterns.