2.3 Leveraging Best Practices from EAI and SOA
Before we go and sacrifice our previous efforts, throw away every
technology, and throw up our hands in defeat, there
a way to leverage some good lessons learned from integration brokers and still move away from the accidental architecture -and that is with the adoption of the ESB. Best practices in integration, which have been refined through experience with integration
, can now be combined with standards-based infrastructure based on XML, web services, reliable asynchronous messaging, and distributed ESB integration
. These collectively form an architecture for a highly distributed, loosely
integration fabric to deliver all the key features of an integration broker, but without all the barriers.
Migrating away from the accidental architecture and refactoring toward a uniform and consistent integration backbone using an ESB involves the prescriptive steps described in the following sections.
2.3.1 Adopt XML
While an ESB is
capable of transporting many types of data formats, adopting XML as the means for exchanging data between applications (Figure 2-2), as has been done in some traditional EAI approaches, can have
benefits. As we will see in Chapter 4, leveraging XML can provide insulation from making global changes to data structures and interfaces across the accidental architecture all at once. The ESB can further facilitate that process by examining the content of XML messages and allowing control over where they are delivered, sometimes altering the
of delivery to include additional services that modify or augment the message.
Figure 2-2. The ESB approach uses XML as the means for sharing data between applications
2.3.2 Adopt Web Services and Implement SOA
Thinking and planning in terms of an SOA is a fundamental step in refactoring toward an ESB. As
in Figure 2-3, the introduction of service-level interfaces provides a common layer of abstraction that creates a separation between the interfaces and the implementation. This eases the construction of composite business process definitions
of coarse-grained service interfaces, using a common interface definition mechanism such as Web Services Description Language (WSDL).
Figure 2-3. Web services and SOA provide a common layer of abstraction that creates a separation between the interfaces and the implementation
While abstraction of service-level interfaces is a step in the right direction, the result is still a bit hard-wired in that the routing logic is tied into the applications (note that in Figure 2-3, the "Process Logic" is still glued in with the applications). Conventional wisdom in web services approaches has been to
the client/server model. Even in a distributed network of web services, one application is always a "client" of another. The paradigm requires the abstraction layer to also include glue code that says "invoke method
on service X, then invoke method
on service Y..." and so on.
What has been missing in web services
to date is the notion of separation of the process routing logic from the interface definition and application logic. As illustrated in Figure 2-4, the ESB provides that separation, while still fully leveraging an SOA.
Figure 2-4. The ESB separates business process routing logic from the interface definitions and service implementations
By separating the interface definition and the process routing logic, we begin to see the bus layer of the ESB form (Figure 2-5). By bringing the business process routing logic and the interface definition into the bus layer, applications can continue to focus on their own implementation logic. As we saw in Chapter 1, the ESB is actually divided into multiple
of functionality. It provides a solid backplane of reliable, asynchronous, message-based communications between applications. This backplane is also where process routing can become intelligent, via the addition of conditional decision points based on the inspection of XML content within a message. This
routing is administratively defined, can be
, and may be supplemented with value-added integration services such as data transformation. The ESB provides an extensible network of integration services that can be extended ad infinitum, yet still can be built incrementally.
Figure 2-5. The ESB reliably connects and coordinates the intelligent interaction between services in an SOA