| For the past decade, through the era of EAI and the evolution of the Internet and application server technology, a clear dividing line has developed between the communications and application integration infrastructure within the four walls of a corporation, and the "external" communication with business partners, vendors, and customers. This separation has been driven largely by the capabilities and limitations of the technology. To date, technology such as application server infrastructure has been specifically designed to make clear distinctions between what's inside the firewall and what's outside the firewall. This distinction is evidenced by completely separate architectural approaches, with different programming models required for building applications. In the J2EE application server architecture, for example, this is manifested as a web container versus an EJB container. Hub-and-spoke EAI brokers could get as far as the corporate boundaries, but were not really built for scaling beyond that. Various bridging technologies were designed to bridge the gap at the "edge" of the network. In many legacy cases, this is "bolted on" as an afterthought. The majority of the work being done in the area of web services has also been focused on this "edge" of the network. But just where exactly is this "edge" of the network anyhow? Before we get to that, let's explore another ancestor of the ESB, the e-Marketplace, also known as the e-Commerce Trading Hub. 3.3.1 e-Commerce Trading Hubs In a trading network of business partners, there is the desire to move away from expensive EDI Value Added Networks (VANs) and use the public Internet as a means of communications wherever possible, and to lower the barrier of entry such that small to medium enterprises can afford to participate. This was the impetus behind the creation of e-Marketplaces and trading exchanges such as those powered by CommerceOne and GE Global eXchange Services (GXS). A trading exchange acts as an intermediary, or semiprivate business portal, that facilitates electronic commerce between buyers and suppliers in a supply chain. The majority of the interactions within the "portal" are not browser-based they are performed directly between specialized applications that require little or no human interaction. The interactions occur between applications residing in a trading partner, and backend applications residing in the trading hub. These backend trading hub applications provide value-added functions such as the dispersion of Requests For Quote (RFQs) between a buyer and multiple suppliers, or Availability To Promise (ATP) data from suppliers to buyers (Figure 3-3). Figure 3-3. Deployment topologies of e-Commerce trading hubs encountered some interesting technical challenges 
This environment introduced some rather challenging requirements, some of which seemed at odds with each other. For example, e-Marketplace deployment topology depicted in Figure 3-3 requires secure access between the applications at the partner sites and the applications in the trading partner hub, using the public Internet as the vehicle for communication. This scenario also requires reliable messaging, but the traditional MOM vendors did not have a MOM infrastructure that was capable of spanning across the public Internet in a scalable and secure fashion. The suppliers communicating through the same trading hub are often fierce competitors with each other, so it is imperative that they not be able to see each other's data. This requires full authentication and access control between the trading partners and the trading hub. Functionality in the trading hub must be exposed to trading partners through a service interface. A supplier must also be able to freely share its data with the trading hub, and the trading hub applications must be able to selectively pass that data along to buyers, but not to other suppliers. A supplier must never be able to masquerade as another supplier and get access to its sensitive data. An e-Marketplace community could potentially consist of thousands of trading partners, all communicating through the same trading hub. Trading partners need to be able to asynchronously communicate with the trading hub in a "fire-and-forget" mode using reliable messaging. Some very important ESB capabilities were born out of these requirements. For example: Strict authentication and access control between the entities connecting to each other Scalable clustering of message servers (Figure 3-3) to handle large volumes of message traffic from potentially thousands of concurrently connected trading partners Complete segregation of data channels Selective control over which channels can be opened up between application endpoints, across intermediary hubs Selective access to shared service interfaces and endpoint destinations Coordination of the business-level message exchange between applications that are separated by physical network domains and geographical location Secure MOM communication through all the firewalls that exist between the trading hub and the suppliers and buyers
Another contributor to the vision of the ESB architecture was the requirement for a trading hub to do business with other industry-related vertical trading hubs. This means that segregated groups of applications (the trading hub backend apps) need to selectively expose and share their interfaces and data with groups of applications residing in other trading hubs. Each trading hub and each trading partner needed to be able to maintain their own autonomy and local integration environments while communicating in a larger e-Commerce network. This network of trading hubs and trading partners could potentially fan out ad infinitum. The evolution of e-Marketplace infrastructure has significantly contributed to the emergence of ESB providers offering the underpinnings to support the requirements of e-Marketplaces. The vendors building trading exchanges looked at a variety of EAI brokers and application server technology, and turned to the messaging vendors for help. Some of the newer messaging vendors were already beginning to provide the required underpinnings for the routing, segregation, and fan-out deployment topology. This process of defining requirements, talking to vendors, and designing this infrastructure took more than a year. During this time, a number of messaging vendors and EAI broker vendors put a great deal of effort into ensuring that their next-generation products would be able to support the requirements of e-Marketplace vendors, and this helped to contribute to the emergence of the ESB concept. 3.3.2 The Extended Enterprise: The Ever-Changing Edge Fast-forward a couple of years, and it turns out that the technology requirements of large-scale trading exchanges are the same requirements of corporations building out their own integration networks. While the e-Marketplace never really took hold as a business model, there remained a need to provide common shared services across departmental and corporate boundaries. This need expands well beyond supply chain scenarios. Due to mergers and acquisitions, collaborating business partners, and globally distributed business units, varying modes of communication are based on the degree of trust between the business entities. This model represents the "extended enterprise." In the extended enterprise, the "edge" of the network is always changing or perhaps there was never really a single outer edge to begin with. For example, in a global organization of semi-independent business units, there are many firewalls, but also a need to have a distributed integration backbone that transcends the underlying topology (Figure 3-4). Figure 3-4. Corporate IT domains: intra-corporate requirements have technology challenges very similar to e-Marketplaces 
There are different levels of trust when dealing with business partners. Reliable messaging requires that a piece of MOM software be installed on either side of the communication link. Sometimes it is acceptable business practice to tell a business partner, "If you want to do business with me, you must install this software at your site." In such a case, it's perfectly acceptable, from a technology point of view, to have an efficient, reliable MOM link between the two organizations. Chapter 5 will provide more information about MOM wire protocols, and new reliable SOAP protocols that can help (but not completely alleviate) the requirement to have MOM software installed on both sides of the wire. When your relationship with a business partner is not as close, you may instead need to supply clear instructions on how to send business documents over a secure HTTP link, and manage business message exchanges using a layered service that specializes in partner links. 3.3.3 Corralling the Ever-Changing Edge of the Network The ESB provides the architecture that separates the higher-level SOA and integration fiber, which includes the management of physical destinations as abstract endpoints and the transformation and routing, from the details of the underlying protocols. This means that the network boundaries can change over time, and an ESB can support the changing of the underlying protocol (i.e., from MOM to SOAP-over-HTTP to WS-Rel*) without affecting the higher-level integration functions that sit above all of that. In the trading hub example, SOA, data transformation, and routing of messages based on context was the job of the value-added services that resided inside the hub. As we take the lessons learned and the concepts of trading hubs and apply them toward in-house IT integration, we can make those same concepts available as independently deployed services. | 