Boundary Services Adapter Connector pattern

Figure 6-10 Boundary Services Adapter Connector pattern

Business drivers

򐂰 More agile integration between organizational (governance) silos. 򐂰 Agility desired over initial integration development costs.

򐂰 Interaction between LOBs and/or regions are constantly changing. 򐂰 Reduce impact of change.

򐂰 Provides lower total cost of ownership.

򐂰 Accelerate integration of mergers and acquisitions.

Tip: If there are many links with different behaviors or a need to frequently

change the links, it is advisable to look at a more robust and flexible linking method. Enterprise Business Service Directory Business Service Directory Zone: Enterprise Service Bus

App Server/ Services <Service Consumer> App Server/ Services <Service Provider> Business Service Directory Business Service Directory App Server/ Services <Service Consumer> App Server/ Services <Service Provider> Hub Hub Hub Zone: Enterprise Service Bus

Boundary Service Boundary

Service

Adapter Connector _HubHubHub Hub Hub Hub Boundary Service Boundary Service Zone: ESB Gateway Boundary Service Adapter Connector Boundary Service Adapter Connector

IT drivers

򐂰 Binding of service request context to ESB capabilities is done at run time. 򐂰 Needs wide variety of ESB capability combinations to support service requests. 򐂰 Limit number of custom components needed.

򐂰 Process changes require minimal component changes. 򐂰 Service-oriented approach.

Pattern description

Boundary Services are an emerging pattern to create runtime-configurable and composible interactions between applications. Boundary Services live at the edge of an application, take the context of an event outside of the boundary, and translate it to a context understood within the boundary. They also take the internal event context and prepare it for external consumption. The Boundary Services Adapter Connector pattern has roots in SOA techniques.

Boundary Services use metadata from the inbound service call (other than the service location) to determine what behaviors the interaction requires. The metadata could be part of the transport header (JMS or HTTP header), part of the message envelope (SOAP header), or part of the message body (XML name value pair).

The metadata will contain the previously agreed-to semantics that describe the service call context to the Boundary Services. This is the contract between the local (service consumer’s) ESB and the foreign (service provider’s) ESB. The semantics in the metadata describe the responsibilities the local ESB expects the foreign ESB to perform on its behalf.

Each Boundary Service or group of Boundary Services focuses on the delivery of one set of capabilities. These Boundary Services implement SOA best practices by hiding their technical implementation and making no assumptions about context and state.

A reliable delivery Boundary Service could offer three service levels: 򐂰 Best effort delivery

򐂰 At least once delivery 򐂰 Once and only once delivery

A data security Boundary Service could also offer two services: 򐂰 Sign message

򐂰 Encrypt message

A logging Boundary Service could offer four services: 򐂰 Process monitoring

򐂰 Trace 򐂰 Debug

The service call context metadata may change from one invocation to the next between the same service consumer and service provider. The Boundary Services adapt to these changes at runtime. Compare this to the design time binding of service call context metadata required by a connector. This is an example of the flexibility and agility that is inherent to a service-oriented design. The Boundary Services can be combined in ways the original designers did not anticipate.

The Boundary Service knows how to map the service call metadata to an internal implementation of that service level. For example, when a logging Boundary Service receives a non-repudiation request, it knows that it is a request to record an event in a tamper-proof log. The actual mechanism to perform this function is internal to the ESB and is not part of the Boundary Service. The Boundary Service only has to know how to map the metadata request to the correct internal functions.

A Boundary Service can map more than one metadata definition to the same internal service. For example “trace” and “debug” could both map to the same level of logging. This is allowable as long as the foreign bus maps the service context metadata to a service level that exceeds the local bus’s expectation. Mapping “once and only once” assured delivery to a “best effort” service would not be acceptable, but mapping a “best effort” request to a “once and only once” service level would be acceptable (but more resource intensive).

Boundary Services can force delivery of a minimum service level. The governance body of the ESB can choose the minimum service levels it will deliver to a foreign service consumer regardless of the request. For example, a service call may request no message logging. This does not mean that the ESB

cannot

Boundary Services Adapter Connectors may not deliver less than the requested service level. If the service level specifies to encrypt the message using 256-bit encryption, then the message cannot be sent with only 128-bit encryption. The Boundary Services Adapter Connectors must honor the service level associated with the semantic definitions agreed upon between the governance bodies. If the service level is only “encrypt,” then either 128-bit or 256-bit encryption is

acceptable.

In some cases the Boundary Service may be based on an industry standard such as WS-Security. In other cases an industry standard may not yet exist that would require a proprietary solution. Following design and development best practices enables the standards-based solution to replace the proprietary solution at some future point.

In some cases the invocation of a Boundary Service may be optional. An example of an optional Boundary Service could be error handling response processing. In some cases the service consumer may want a response in the event of an error and in other cases it is not interested in error conditions. The service call metadata could include metadata requesting an error response on one message, and the next service call may not include this metadata element. A Boundary Service can have a default service level if a specific service level is not selected. A default service level may be set for a logging Boundary Service if the service call metadata does not request any other option. This ensures a minimum level of service that may be required by the governance organization of the ESB receiving the request.