| Before we go and sacrifice our previous efforts, throw away every preceding technology, and throw up our hands in defeat, there is 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 brokers, can now be combined with standards-based infrastructure based on XML, web services, reliable asynchronous messaging, and distributed ESB integration components. These collectively form an architecture for a highly distributed, loosely coupled 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 certainly 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 numerous 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 path 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 illustrated 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 composed 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 mimic 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 a( ) on service X, then invoke method b( ) on service Y..." and so on. What has been missing in web services implementations 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 layers 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 intelligent routing is administratively defined, can be altered, 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 
|
