| Getting from the accidental architecture to a uniform integration infrastructure on a global scale may seem like a daunting task. It's not realistic to get everything ready and then flip a switch to get all your applications onto the new infrastructure. This has been a major reason why organizations continue to add on to the accidental architecture as the status quo, even with the knowledge that they are only perpetuating its associated problems. An ESB provides capabilities that help ease the pain of introduction. Chapter 9 will drill down into a particular case study of how to migrate away from a preexisting integration solution that was based entirely on FTP and nightly batch jobs. Let's now revisit our discussion of the accidental architecture. In Figure 2-6, the solid, dotted, and dashed lines represent different types of connection technologies and communications protocols used to integrate the applications. Note that there is an existing "island of integration" represented by the integration broker, and that the link between the Point-of-Sale (PoS) application and the Finance application is using FTP file transfer. The link between PoS and the Enterprise Resource Planning (ERP) system had previously been upgraded to use SOAP over HTTP as a protocol, as had the link between the Sales Force Automation (SFA) and the Customer Relationship Management (CRM) applications. Figure 2-6. Representative accidental architecture using SOAP communications, FTP, and hand-rolled sockets, and including an integration broker 
2.4.1 Introduce the ESB at an Individual Project Level The ESB can be introduced at a departmental level or on a per-project basis. Adopting the ESB at the project level allows you to get accustomed to doing standards-based integration using ESB service containers, with full confidence that the project will fit into a larger integration network and align with the corporate strategic goals of enterprise-wide integration. The first step in our example ESB adoption is to integrate the front office. In Figure 2-7, the front office CRM, Finance, and SFA are connected into the ESB via "service containers." These containers are key components of the ESB architecture, and are explained in detail in Chapter 6. The nature of the integration through ESB service containers may vary. The interface between the container and the application may be accomplished using a third-party application adapter; the container may expose XML data, which is described using WSDL; or it may be implemented as completely custom-written code. Figure 2-7. The ESB can be adopted on a per-project basis without disrupting the path of point-to-point solutions 
But perhaps what's more interesting is not what's already been integrated into the ESB, but what hasn't been. Figure 2-7 shows that the lines of communication for the existing FTP and SOAP protocols, which were once connected to the front office applications, now run directly into bus components that are configured especially for communicating using those protocols. Applications that are still "outside" of the bus in this case, the PoS and the partner CRM can communicate with the front office applications that are integrated "inside" the bus without requiring any changes, and without any knowledge that they are participating in an ESB infrastructure. Note that the PoS is now connected to an FTP bridge on the ESB, and the CRM application at the partner site now talks to a web service endpoint that is configured as part of the bus. An ESB has been introduced without affecting every combination of point-to-point communication that the ESB-enabled applications had previously connected with. The applications plugged into the bus have been migrated over to use a single interface to the ESB integration container, and have dispensed with the other types of communication links they previously had to manage and maintain. As we will see in Chapter 9, even the newly integrated applications within the domain of the bus can be migrated over to full ESB awareness at their own pace and in accordance with their individual development project timelines. 2.4.2 Propagate the ESB Across a Widely Distributed Enterprise In the next phase of our ESB adoption, the PoS applications are ESB-enabled at each of the remote locations, removing the dependency on the unreliable FTP link. This can be as simple as installing an ESB container at the remote location and plugging into the ESB at headquarters, or it can involve a "mini" integration environment among several applications at each remote site. The two ESB nodes can now be connected using a secure link that is based on reliable messaging (Figure 2-8). Figure 2-8. Separate ESB installations may be linked together securely and reliably across locations 
Furthermore, the remote locations can continue to operate within their own segregated integration environments, but still selectively share data as needed. For example, the remote locations may be independently owned and operated retail stores belonging to a collective franchise. They have no need to share information about their daily operations, but they do need to share data such as price updates and inventory information. The remote ESB nodes can be connected together with the ESB network at headquarters, and can selectively expose message channels to each other to share price updates and so on. 2.4.3 Leave and Layer: Connecting into the Existing EAI Broker The third phase of our ESB adoption project involves bridging into a department that has already been partially integrated with a hub-and-spoke EAI broker. As noted previously, adopting an ESB is not an all-or-nothing proposition. As illustrated in Figure 2-9, the ESB allows an IT department to protect its investment in an existing EAI broker project by bridging it into the ESB installation. Figure 2-9. The "leave-and-layer" approach allows an ESB to bridge into existing EAI broker installations 
Bridging to the EAI broker can occur in several ways. It can be accomplished by using a web services interface, or by binding together the underlying messaging channels. Depending on the implementation of the ESB and the EAI broker, the ESB may even be able to sit on top of the EAI broker's underlying message queue infrastructure, thus partially replacing the EAI broker functionality while retaining the lower-level message channels. 2.4.4 Partner Integration The final step in our ESB adoption is dealing with the issue of integrating with business partners. As illustrated in Figure 2-10, this could involve leaving the SOAP link as is, or it could involve installing an ESB node at the partner site as well. The decision of which approach to use could depend entirely on how close a relationship your organization has with the partner, whether the partner would allow you to install software at their site, or whether they already have an ESB that can link with yours. Figure 2-10. The ESB may individually manage SOAP links with business partners, or may link to another ESB node at that site 
Layered services that are plugged in as an extension of an ESB can manage the logistics of the partner link. For example, a specialized partner manager service could manage the details of ongoing collaborations with partners on a per-partner basis. These details could include which higher-level business protocol is being used (e.g., ebXML, RosettaNet, etc.) as well as conversational state, such as the current state of a message exchange, whether an acknowledgment message is expected, and how much time delay is acceptable to receive a business-level response from a partner. | 