|
From this set of capabilities, you can understand why the term bus is used. Information is transported between many different destinations—between originators and receivers who might be using different communications models and data formats. For this reason, an ESB is an artifact designed to support interoperation between different sources and destinations—such as JMS to Web services, Web services to IBM CICS® systems, publish-and- subscribe to point-to-point integration and so on.
A distinct advantage of an ESB is the flexibility it can provide. You (the user) can decide which of the different capabilities of an ESB you want to use. For example, you might want to specialize on just point-to-point style or publish-and-subscribe communications. Or you can exploit extended ESB capabilities—like transformation of messages, dynamic routing, message enrichment and so on—to derive even greater value.
Services on an ESB
When considering an ESB, you should understand that it is an enterprise service bus. Many services are provided, even if not all services are necessarily exposed externally. For example, ESBs are often regarded as a key step in delivering a service-oriented architecture (SOA). In an SOA, the objective is to provide a logical infrastructure that enables applications to have their interfaces exposed as services that can then be accessed through the ESB (see Figure 1). At the same time, when a message arrives on an ESB, it might invoke some internal ESB service—such as a transformation service—which can take one format and turn it into another that is acceptable to a different application. In other words, an ESB uses services as a means to work with external sources and destinations. Yet an ESB also has services that it can provide internally (over the bus), like transformation, routing, encryption and enrichment.
Why should you want an ESB?
An ESB is the logical next step in the evolution of messaging and of integration technologies. If you think of an SOA as providing consistent ways to describe the endpoints in an enterprise, an ESB offers the mechanism to achieve an SOA. But an ESB can do more. It can provide a mechanism to map and then view the available resources within your organization. Any ESB must be able to provide seamless management capability across an enterprise, as well as heterogeneous communications between services running on the many different types of platforms that are common in most enterprises.
This richness and increased transparency means, at one level, that it should take less effort to integrate heterogeneous environments. On another level, the ability to describe and exploit enterprise resources opens up new options for interoperation, while requiring fewer skills to deliver both development and day-to-day operations.
In reality, ESBs can be used quite differently by different types of organizations. Endpoint users can leverage the ESB’s capabilities to gain easy access to the bus to invoke other services. Specialist users can build an organization’s ESB and extend it to match that enterprise’s specific requirements. This latter group can map and configure what is achieved with an ESB. Specialist users can put into practice what an SOA charts out: define the flows between what comes in and what goes out over the ESB, create the libraries for transformations and routing logic, and so on. The important thing to remember is that there are two separate sets of logic: external applications logic and internal (to the ESB) logic (shown in Figure 2).
An ESB based on IBM products
IBM WebSphere® MQ can provide the base for an ESB with point-to-point messaging, some publish-and-subscribe capability and clustering function. IBM WebSphere MQ Everyplace® complements these capabilities with reduced-footprint messaging for small devices like personal digital assistants (PDAs). Higher in the ESB function stack, IBM WebSphere Business Integration Event Broker and IBM WebSphere Business Integration Message Broker provide value-add services such as routing, transformation and rules-definition handling, as well as fan-in and fan-out capabilities. If you need tight links to the Java development and run-time environments, IBM WebSphere Application Server can provide this function, as well as more-advanced Web-services capabilities.
ESBs and clustering and high availability
Conceptually, an ESB is a logical construct made up of multiple physical instances (and even multiple products) that combine to deliver ESB capabilities. You might choose to have one ESB with several instances of the software in one location (like a giant hub), while another organization might prefer to have many instances distributed around the enterprise or organization. Either is possible, as are a variety of combinations in between.
|
