6.1 SOA Through Abstract Endpoints

The square boxes in Figure 6-1 represent the applications and services that need to connect to each other and share data through the bus. From the perspective of the integration architect who is assembling services to form a process flow, all applications and services are treated as abstract endpoints. What the endpoints actually represent can be very diverse. An endpoint may represent a discrete operation, such as a specialized service for calculating sales tax. The underlying implementation of the endpoint could represent a local binding to an application adapter, or a callout to an external web service.

Figure 6-1. Everything that is connected into the bus is viewed as an abstract endpoint

This endpoint abstraction allows an integration architect to use higher-level tools to assemble service endpoints into process flows (Figure 6-2).

Figure 6-2. Integration architect's view of service endpoints in an SOA

An endpoint may represent a single, monolithic application, such as a legacy payroll system. It may represent a suite of applications or an ERP system from an application vendor. It may represent an island of integration from a successful integration broker project. It may represent a whole department or business unit that has a microcosm of its own, yet also needs to link into corporate information channels and share data. It may represent the interface to a business partner with completely separate IT systems.

All service endpoints in an ESB are equal participants in an event-driven SOA, whether the service represents a discrete operation or an interface to an entire ERP suite. From the point of view of the integration architect (you), service endpoints are just logical abstractions of services that are plugged into the bus. The task of building out an integration network involves tying together service endpoints and applying choreography, transformation, and routing rules into process flows between applications. The actual physical locations of the services can be anywhere that is accessible by the bus.

6.2 Messaging and Connectivity at the Core

In Figure 6-3, the series of connected rectangles in the center of the diagram represents the core of the ESB. A key component of this core is a highly scalable enterprise messaging backbone that is capable of asynchronously transporting data as messages in a secure and reliable fashion. The messaging backbone supports the asynchronous store-and-forward capability that was discussed in Chapter 5. This messaging core could represent a proprietary MOM, a MOM based on JMS, or a MOM based on WS-Reliability or WS-ReliableMessaging. Or, the messaging core could be a generic messaging engine that supports any combination of these.

Figure 6-3. Enterprise messaging at the core of the ESB

The service endpoint provides an abstraction away from the underlying protocol (or MOM channel). The ESB allows the underlying protocol to vary depending on the deployment situation and the QoS requirements. The choice of protocol can vary, from proprietary MOM to unreliable HTTP, to WS-Rel*, depending on the criteria for that leg of the trip and the overall QoS requirements of a message flow. From the perspective of the integration architect who is weaving the fabric of integration, the task is to link together service endpoints into process flows. Using administrative tools supplied with the ESB, the technology behind the endpoint definition and the details of the underlying protocol can be dealt with separately, and can even change over time. It is the responsibility of the ESB to map the high-level process flows into individual service invocations across the designated transport.