| The maturity and adoption of relevant standards for integration have helped to foster the emergence of the ESB as a technology trend. The ESB makes full use of standards for integration wherever possible. The use of such standards can have significant effects on a business, as follows: Allows you to leverage existing IT staff, rather than specialist consultants. The amount of information available on XML and web services standards such as SOAP, WSDL, XSLT, XPath, and XQuery is expanding at an ever-increasing rate. There is an educational ecosystem in which information about standards (and budding specifications) becomes available as the standards evolve. The introduction of a popular specification creates a fertile ground for industry experts to write articles, tutorials, and O'Reilly books on the subject, which in turn allows IT professionals to learn more and stay current. This means that the average IT professional can readily attain the expertise he or she needs to become the in-house integration architect. Reduces proprietary vendor lock-in. With a proprietary integration stack, an organization can't simply say, "Well, vendor A wasn't what we expected, so let's try vendor B." This would result in an expensive restart and relearning. Adopting standards as part of an integration infrastructure means the ability to pick and choose best-of-breed implementations from different vendors and have them work together. Java standards. While the ESB concept can be Java-free, Java provides a set of specifications that don't exist elsewhere and that can standardize components and interfaces between those components. These standards define application interfaces, behavioral semantics of middleware and application adapters, and deployment models. Standards such as JMS, MessageDrivenBeans, and JCA can significantly increase the ability to interoperate between enterprise applications and J2EE application servers. J2EE application servers from various vendors have found their way into most, or perhaps even all, enterprise organizations. Increases the ability to integrate with business partners using standard interfaces and standard protocols. A JMS interface to an ESB is currently the only way that application servers from different vendors can talk asynchronously using reliable messaging in a common environment with an SOA. RMI-over-IIOP is (or was) the "blessed" method of application server interoperability, but it doesn't provide a model for loosely coupled interfaces or SOA, nor does it work outside of J2EE. While in theory any J2EE server can interoperate with any other J2EE server using JMS, in practice this doesn't really happen out of the box, nor is there any incentive to do so. An ESB can provide a neutral ground where application servers from multiple vendors can communicate with each other. J2EE Connector Architecture (JCA) can also provide the standard contract for application adapters, which can add to your arsenal of integration with any packaged applications that support Java interfaces. Entire suites of application adapters, available from multiple vendors, use JCA as the unified way of connecting between the adapter and the middleware infrastructure. Once an application is introduced into the ESB through a JCA adapter, its functionality is exposed as a standards-based, event-driven service. This gives you much greater flexibility and reuse than if it were plugged into a proprietary broker through a proprietary adapter.
What Are "Standards," Exactly? When talking about the use and adoption of standards, it is hard to tell just exactly what that word means. We live in a world of multiple overlapping efforts from different standards bodies to define standard specifications. Vendor alliances are producing web services specifications outside the domain of any standards body or consortium. Every once in a while I am challenged on the use of a Java specification as a "standard." The argument is that because the Java Community Process (JCP) is owned by one vendor (Sun Microsystems), the specifications that come out of that process are not really standards they are just specifications. I tend to use the words "standards" and "specifications" interchangeably. As far as I'm concerned, any specification that has been through the JCP should be considered standard enough. That is, it has gone through a formal process in which it was jointly defined by a group of independent companies and/or individuals, and was posted for public review prior to ratification. There are also "de facto standards" such as open source implementations, which either invented their own ways of doing things or conform to industry-accepted "standard" specifications. The Apache SOAP and Apache Axis toolkits are examples of such standards. The evolving WS-* stack of specs from ad hoc vendor collaborations can also be considered de facto standards in that they represent the work and statement of direction for a meaningful constituency of the largest platform vendors. Some of these WS-* specifications have already been submitted to an official standards body, and the rest have been part of a program that involves public feedback sessions. In short, the word "standard," in terms of standards-based integration, refers to either a specification or an implementation that has gained enough traction in the industry to have long-lasting staying power, and is open enough for multiple vendors to implement or repackage it. |
An SOA built upon the combination of enterprise messaging with certain key technologies such as SOAP, WSDL, XPath, and XSLT, with interfaces to Java, .NET, and C++, collectively defines the means for a platform that allows cleaner solutions based on standards. The concept of standards-based integration allows developers to learn and build a valuable skill set that can be used across a variety of integration projects. Integration based on standards also provides IT managers with a larger talent pool of developer resources, and allows for repeatable success patterns that can be carried from project to project. A major European food distribution network was an early adopter of an ESB, and successfully completed their first supply chain automation project in six weeks. One of their directors of IT strategy had this to say about the use of standards for integration in an ESB: "Now we no longer have to worry how long the next integration will take, or even if it is possible." 3.4.1 The New Economics of Integration In the ESB, you deploy what you need, when and where you need it. The licensing model being put forth by vendors leading the charge in ESB technology reflects these physical deployment characteristics. According to a Forrester Research report, license costs for integration brokers begin at $100,000 per project and have an average price of $400,000 to $750,000. In contrast, an ESB license can cost 10 to 15 times less than that. Does this mean that ESB vendors have an unrealistic licensing model that is incapable of sustaining a business? No. The ESB licensing trend is based on the philosophy that integration should be pervasive throughout the enterprise, and a high cost of licensing should not be a hindrance to adoption. This licensing philosophy reflects the technology model, which is to license only what you need on a per-project basis, while building toward the strategic goal of corporate-wide integration. So you can start wherever you need it most, and grow at your own pace without costly obstacles. For integration brokers, you typically pay for consulting services that are four to five times the licensing costs. Because the ESB is based on standards, you can leverage in-house staff and avoid having to pay high fees for consultants who specialize in proprietary integration broker technology. By investing in the adoption of standards and educating your in-house IT staff on standards for integration, you are future-proofing your staff as well as your technology. 3.4.2 Driving Down the Cost of Technology In his book Loosely Coupled, Doug Kaye illustrates his own version of a "technology adoption curve" in support of a discussion on how the cost of a particular technology decreases over time. As an example, he talks about the publishing of O'Reilly books on a particular subject as a significant event in the adoption of a technology, helping to drive down the cost of the technology by making knowledge about it more readily available. You are witnessing that now in terms of the ESB. |