| The ESB is a new architecture for integration that is flourishing in corporations around the world. To many casual observers, the ESB as a technology category seems to have come out of nowhere. In reality, though, the ESB has not just "happened." Over time, many catalysts helped it develop and evolve, and lessons were learned from past technology approaches that extend back more than a decade. This chapter will examine some key concepts of the ESB, including the many requirements, technology drivers, and forces in the IT climate that led to the creation of the ESB concept. All of this will be discussed in the context of the recent history and evolution of the ESB. This discussion will illustrate the point that an ESB is not merely an academic exercise; it was born out of necessity, based on real requirements arising from difficult integration problems that couldn't be solved by any preexisting integration technology. The discussion will conclude with a study of an ESB deployment, with a manufacturer exposing inventory management and supply chain optimization functionality to its remote distributors as shared services through an ESB. Sometimes solving a problem requires looking at previous attempts at solutions and learning from their drawbacks. Entire trends had to come about as predecessors to ESB for the IT and vendor communities to have something to point at and say, "I like that," "I don't like that," or "That's what I've been trying to build on my own." The Greek philosopher Plato is credited for the phrase "Necessity is the mother of invention." The ESB is a shining example of invention fostered by necessity. In this chapter we will explore those necessities, and how an ESB addresses them. The ESB concept is the next generation of integration middleware, capable of being applied to a much broader range of integration projects than what could be handled by specialized integration brokers. However, it should be stated that ESB is not just EAI plus web services, nor is it MOM plus web services. A number of recognized trends, both technology-driven and business-driven, have had an equal share of influence on the evolution of the ESB.
- Enterprise Application Integration (EAI).
-
A number of lessons, both good and not so good, have been learned from EAI. As we have seen, there are various downsides and painful lessons. Much of the goodness inherited from EAI is in the "best practices" in data transformation and manipulation that can be carried forward into XML technologies and brought forward into an ESB architecture.
- e-Marketplaces and vertical trading hubs.
-
During the Internet bubble, this technology category was destined to change the model of how companies do business. The expectation was that e-Marketplaces would be universally adopted, inevitably replacing EDI with something more efficient and more accessible, and allowing companies of all sizes to participate in a supply chain. And while the e-Marketplace trend didn't garner the world's lasting attention as much as its early proponents had hoped, its existence on the hype curve caused businesses and IT culture to evaluate new ways of doing business electronically with other business partners. This trend also helped foster the recognition of a need for open standards for protocols and service discovery mechanisms. e-Marketplaces were the first to introduce the model of a loosely coupled, distributed federation of individual companies operating autonomously, but still working together in a supply chain in a collaborative fashion. The e-Marketplace showed the IT sector that supply chains can be improved.
- Java Message Service.
-
JMS is a standard for APIs and behavioral semantics of MOM. The popularity of JMS as a part of the J2EE platform has brought messaging into the mainstream, and has created a marketplace for competing vendors building new messaging systems from the ground up based on today's requirement of communicating reliably and securely across the Internet.
- Application servers.
-
Application servers are important to an enterprise as a means for hosting business logic. They are not a key foundation component of the ESB per se, but they can be integrated using an ESB network. They are being listed here as a catalyst of the ESB concept in that they have nurtured the evolution of some important standards, such as the servlet environment for dynamic processing of requests, JDBC for database connectivity, and the J2EE Connector Architecture (JCA) for a standardized interface to application adapters. Build an ESB Using an Application Server One common question I get is "Why isn't an ESB built on an application server platform?" In the ESB approach to integration, the integration broker functionality itself is not layered on top of the application server. Integration capabilities are deployed as independent services alongside of, or independently of, the application server. There are a number of reasons for this. One is to avoid the over-bloating of functionality. Application servers are not necessarily the best place for every new technology trend that comes along. An ESB requires a lighter-weight container for deploying integration services without having to install an entire application server stack everywhere. And there are other reasons too: the core architecture of an application server isn't designed for hosting loosely coupled services. The deployment model isn't optimized for dynamic reconfiguration and deployment. The code-centric model embeds things into application code that should be dynamically configured, either explicitly or implicitly. The deployment and management model isn't appropriate for distributed deployment of heterogeneous services. A more detailed discussion of this issue is found in Chapter 6. |
Y2K, and post-Internet-bubble economics. Y2K readiness caused an increase in IT spending, with a significant shift toward the purchase of packaged Y2K-ready applications in favor of applications developed in-house. All the hype and excitement around emerging technologies during the Internet bubble led to continued IT spending. Nowadays, the post-Internet-bubble period has caused a major corporate reevaluation of big IT spending, and a shift toward trying to make things work with the existing applications and with a much smaller budget even smaller and more highly scrutinized than in pre-Y2K times. The ESB is well suited for the new economics of integration, both in a monetary sense and in practical application. Web services and SOA. Web services are an industry effort to provide platform-independent SOA using interoperable interface descriptions, protocols, and data communication. Web services are a key core concept of the ESB, and the ESB can be thought of as a middleware manifestation of SOA design principles as applied to integration. Evolution and maturation of standards in support of integration and interoperability. In addition to web services, there are important standards for XML, security, and reliable messaging. The development and adoption of standards, along with communities of supporting vendor implementations, have matured enough to make the benefits of standards-based integration become a reality. The accidental architecture. As we now know, the accidental architecture is something that nobody sets out to create, yet everybody has. We examined the accidental architecture in Chapter 2, and explored how the ESB can help a system migrate away from the accidental architecture in incremental chunks.
|
