SOA component product mappings

In the previous chapters, we identified and described the following components, or node types, that play a role in an SOA infrastructure:

Chapter 5. ESB and SOA component implementations 141 򐂰 Service Directory

򐂰 Business Service Choreography

򐂰 Enterprise Service Bus patterns: – Enterprise Service Bus – Exposed ESB

– Exposed ESB Gateway

In this book, we do not concentrate on the Direct Connection pattern, other than the discussion in Chapter 6, “Endpoint enablement roadmap” on page 153. For more information about using the Direct Connection pattern in an SOA, refer to Patterns: Service-Oriented Architecture and Web Services, SG24-6303. In the following sections, we discuss the remaining patterns and components, and indicate which technologies may be used to implement them.

5.2.1 Service Directory product mappings

The Service Directory component may exist either as part of the Enterprise Service Bus or as a component in its own right. Where this component exists as part of the Enterprise Service Bus, often it is implemented by the ESB

technology. However, some implementations might involve linking the ESB to an external service directory.

In this section, we discuss only the cases where an explicit Service Directory is required, in which case Service Directory can be considered a node type. Several approaches could be taken to implementing a Service Directory node:

򐂰 UDDI

A dedicated UDDI technology, such as that available with WebSphere Application Server Network Deployment, to provide Service Directory based on Web services standards.

򐂰 LDAP server

LDAP directory servers, such as IBM Tivoli Directory Server, are not specifically intended to provide directories of services but they do provide a flexible directory format that could be adapted to this requirement.

򐂰 Customized database

Where neither UDDI or LDAP are appropriate, a customized directory can be implemented using a database. This is the approach that is taken in

򐂰 Other customized solutions

The preceding three options have concentrated on technologies that provide standards support, use supported products, and are suitable for dynamic service discovery. However, there are many other possibilities such as the provision of simple service directories using collaboration technologies such as Lotus Notes® and Domino, or through basic Web sites. Such directories may not be so suited to dynamic service discovery, but they do fulfill the basic goal of publishing information that describes available services in a SOA.

5.2.2 Business Service Choreography product mappings

Where a separate Business Service Choreography component is required to model and execute service choreographies that encapsulate business logic, a separate runtime component usually is provided. An alternative would be to use the same technology that is used to implement the Enterprise Service Bus (assuming that the technology has appropriate capabilities); however, this is unlikely to be a common scenario, as the intents of the two components are rather separate.

Candidate products for implementing the Business Service Choreography component include:

򐂰 WebSphere Business Integration Server Foundation

򐂰 WebSphere Business Integration InterChange Server

򐂰 WebSphere MQ Workflow

The ESB capabilities of WebSphere Business Integration Server Foundation V5.1 and WebSphere Business Integration Interchange Server are described in 5.3.1, “Assessment of ESB capabilities by product” on page 145. However, that section does not consider their suitability for implementation of the Business Service Choreography component.

Implementation of service choreography using WebSphere Business Integration Server Foundation V5.1 is described in Chapter 10, “Business Service

Choreography” on page 271.

For more details about service choreography, consult Patterns: Serial and Parallel Processes for Process Choreography and Workflow, SG24-6306.

5.2.3 SOA product mappings

The previous chapters defined the following SOA patterns:

򐂰 ESB pattern

Chapter 5. ESB and SOA component implementations 143 򐂰 Exposed ESB pattern

򐂰 Exposed ESB Gateway composite pattern

These are all examples of the Hub runtime pattern in the Patterns for e-business Process Integration patterns - they all represent an infrastructure component for mediating interactions. Additionally, they must support the ESB capabilities that are identified through the discussion of requirement scenarios, architectural issues, and solution patterns as presented in Chapter 4, “Enterprise Service Bus and SOA patterns” on page 73. In any individual situation, those capabilities will determine which technologies are appropriate for implementing an ESB, ESB Gateway, Exposed ESB, or Exposed ESB Gateway pattern.

Depending on the exact ESB capabilities that are required, the following approaches could be taken:

򐂰 Web Services Gateway (available with WebSphere Application Server Network Deployment)

򐂰 WebSphere Business Integration Message Broker

򐂰 WebSphere Business Integration Connect (although this is primarily suited to the Exposed ESB Gateway pattern)

򐂰 Customized implementation based on WebSphere Application Server

򐂰 Customized implementation based on WebSphere MQ

There are certain other technologies that, although primarily intended for other uses, provide certain features that are appropriate to Enterprise Service Bus capability. Though they would not be considered prime candidates for ESB implementation, they do provide features that promote ESB-like access to their function:

򐂰 WebSphere Business Integration Server Foundation

򐂰 WebSphere Business Integration Interchange Server

In this book, we cannot describe all of the possible implementations of each pattern in each technology, but the more common product-based solutions are covered as follows:

򐂰 Implementation of the ESB pattern using the Web Services Gateway is described in Chapter 8, “Enterprise Service Bus: Router variation” on page 175.

򐂰 Implementation of the ESB pattern using WebSphere Business Integration Message Broker is described in Chapter 9, “Enterprise Service Bus: Broker variation” on page 219.

򐂰 Implementation of the Exposed ESB Gateway composite pattern using the Web Services Gateway is described in Chapter 11, “Exposed ESB Gateway composite pattern” on page 299.

An assessment of product features against the ESB capability model is made in