Configuration, Not Coding
The mantra of the ESB is “configuration rather than coding.” In an ESB, abstract endpoints, which are accessible through application adapters, message queues, Web services invocations, and a variety of other protocols, are configured through a tool interface rather than coded into applications. It’s not that there’s anything wrong with writing code, but there’s plenty of code to be written elsewhere that doesn’t have to do with hard-wiring interdependencies between applications and services.
With its distributed deployment infrastructure, an ESB can efficiently provide central configuration, deployment, and management of services that are distributed across the extended enterprise. Artifacts that affect the behavior of an integration service, such as an XSLT stylesheet that can be used by a data transformation service, are also configurable in an ESB.
The ESB Service Container
The highly distributed nature, and the ESB mantra of “configuration rather than coding” is largely due to traits of the ESB service container. A service container is the physical manifestation of the abstract endpoint, and provides the implementation of the service interface. A service container is a remote process that can host software components.
A service container is simple and lightweight, but it can have many discrete functions. As shown in Figure 2, service containers take on different roles as they are deployed across an ESB.
In its simplest form, a service container is an operating system process that can be managed by the ESB’s invocation and management framework. A service container provides a number of facilities for the service implementation such as event dispatch, thread management, security (encryption, authentication, and access control), and QoS via reliable message delivery. Unlike its distant cousins, the J2EE application server container and the EAI broker, the ESB service container allows the selective deployment of integration functionality exactly when and where you need it, and nothing more than what you need.
A service container can host a single service, or can combine multiple services in a single container environment (see Figure 3).
An ESB service is also scalable in a fashion that is independent of all other ESB services. A service container may manage multiple instances of a service within a container. Several containers may also be distributed across multiple machines for the purposes of scaling up to handle increased message volume (see Figure 4).
The ESB Service Interface
The ESB container provides the message flow in and out of a service. It also handles a number of facilities, such as service life cycle and itinerary management. As shown in Figure 5, the container manages an entry endpoint and an exit endpoint, which are used by the container to dispatch a message to and from the service.
Messages are received by the service from a configurable entry endpoint. Upon completion of its task, the service implementation simply places its output message in the exit endpoint to be carried to its next destination. The next destination may be a reply to the original sender of the message, or more often may be sent along to the next leg of its journey using a forwarding address. The output message may be the same message that it received. The service may modify the message before sending it to the exit endpoint. Or, in the service may create a completely new message to serve as a “response” to the incoming message and send the new message in the exit endpoint.