Only a few years ago, concepts in application integration applied to EAI technologies such as messaging oriented middleware (MOM). However, now Web services is the new technology in town. Because Web Services is a different integration paradigm than traditional EAI, opportunities exist for the use of Web services where EAI falls short.

As one Web services writer aptly said, "Both approaches [that is EAI and Web services] are valid but typically not in the same business context. As a result, we do expect that both Web services technology and EAI will complement each other to offer a portfolio of approaches to build composite applications upon. Most likely, this will lead sooner or later to the integration or consolidation of both approaches."

From this article, you will gain the ability first to understand the differences between Web services and traditional EAI technologies, and second, to formulate strategies for augmenting EAI with Web services where it makes sense.

Strengths of Web Services
The primary strength provided by Web services is in establishing integration standards. The benefits of Web services being based on integration standards are flexibility, ubiquity, and convenience of deploying integration solutions. A more detailed look at these integration standards is found in Table 1.

 

"The promise of Web services is to enable a distributed environment in which any number of applications, or application components, can interoperate seamlessly among and between organizations in a platform-neutral, language-neutral fashion. This interoperation brings heterogeneity to the world of distributed computing once and for all."

Flexibility
Integrating applications using a common protocol to transfer information is not a new concept. Traditional EAI technologies have been doing this since the early 1980's with MOM. However, the transports used with MOM technologies were proprietary and thus tied to a particular middleware vendor. As multiple middleware solutions made their way into an enterprise, it became necessary to build adapters between the various middleware software packages. These bridges made the case for a middleware of middlewares. In a sense, enterprises were in the same boat before the MOMs were installed - the middlewares became the new applications to integrate.

The promise Web services addresses is in providing a cross-platform way to connect various Web services together, even across different Web service technology providers (i.e., Apache, Actional, Microsoft, Sun, etc.).

Ubiquity
With the groundwork laid down by previous Internet communications advancements, Web services paves the way for the pervasive enterprise. The strength here lies in the ability to begin extending applications beyond the boundaries of the current systems infrastructure.

Currently we are in the early stages of accessing applications through information appliances such as cell phones and PDAs. By extending the enterprise out to these devices, new interactions within the enterprise are possible. Now business transactions can take place that were once relegated only inside the corporate firewall.

However, these types of deployments have several barriers to entry. One of these barriers is the existence of numerous architectures and platforms on which these information appliances are run. Implementing and exposing needed services through Web services will facilitate the extension of the integrated enterprise out to these devices.

Once Web services deployments reach a critical mass, the friction encountered in connecting other systems and appliances will be reduced to nil. This will primarily be because companies will see the economies of scale in developing tools to provide this functionality. Also, when Web services integration standards, such as quality of service and security, become established, the enterprise will be extended beyond its traditional boundaries, leading to greater business opportunity and efficiency. The enterprise, which takes advantage of Web services pervasively, will see opportunities that were neither seen nor conceived before.

Convenience
Web services provide a mechanism for easy access and consumption. The convenience rests on the fact that Web services are based once again on standards.

Traditional EAI technologies have progressed to the point where they can expose services by metadata and repositories. However, since the technology is proprietary, the various EAI vendors do not interoperate natively. In a general sense, unless an EAI bridge is utilized, this would mean only TIBCO clients can see and have access to TIBCO integration objects.

With Web services, every application may discover and interoperate with comparatively little or no friction.

UDDI (Universal Description, Discovery, and Integration) provides a standard way for Web services to be deployed and discovered. Third-party tools can integrate with a UDDI repository with little or no compatibility issues. Compared to what it would take to connect one EAI vendor's message broker to another's repository, this is a significant improvement.

A Web service deployment has a standard language for describing its semantics. This language is called WSDL (pronounced by some as "wiz-dul"). The acronym stands for Web Services Description Language. By describing a Web service using WSDL, a potential client of the service can quickly understand how it will communicate with the service. This is particularly handy for Web service tool vendors. Web service development tools can easily use WSDL to describe in detail how clients will need to interact with the service.

Strengths of EAI
The maturity of traditional EAI technologies, on the other hand, provides capabilities that have stood the test of time. Industry demands a reliable, efficient, and robust infrastructure to operate the mission-critical applications within an enterprise. It should be noted that all of the strengths listed here also come with the caveat that the EAI technologies are proprietary. At best, integration patterns are shared across technologies, but in platform and execution incompatibilities abound. While bridges do occur between EAI technologies, these bridges are point-to-point and not cross functional between other EAI vendors.

Reliability
Traditional EAI technologies typically provide at least two quality-of-service levels for message delivery, a standard delivery and a more dependable delivery service mechanism. Different vendors use different nomenclature, but the concepts are basically the same.

For instance, Vitria labels the standard message delivery as reliable, while for greater dependability in guarding against the case of a server crash, the guaranteed message delivery quality of service is recommended.

Different quality-of-service levels are used depending on the business needs and timeliness of the data in transit. If the relevance of a data message expires within a few seconds, then a high quality-of-service level is probably not needed. A real world example would be the stock ticker example where the real-time nature of the business dictates the necessity of speed. Bringing the server back up after a crash and restoring the stock trades as they came through will probably not be much good. In some trade exchanges, after a few minutes have passed a particular trade price will have no business value.

In contrast, a trade management system, the stock trade journal of record, would not rely as much on the real time aspects, but rather more on the guarantee that entered trades get processed into the trading system. This type of scenario calls for a high quality-of-service level. A stock trader cannot afford to have a few trades get lost somewhere because a thunderstorm causes a power outage.

Efficiency
EAI message transports have the ability to send thousands of message transactions per second on a typical network. This is due largely to the close mapping between the EAI message transports.

When large message throughput is needed, traditional EAI technologies have a comparatively better chance than Web services of being able to efficiently handle the load. Comparatively speaking, the layer of abstraction that Web services provides for integration flexibility leads to greater message data volumes and slower transaction throughput rates. Therefore, efficient message transport is a clear strength for the traditional EAI technology camp.

Some might contend that Web services are efficient because the nature of Web services is both flexible and convenient to develop, leading to lower development costs and thus greater efficiency. While this might be true, there are aspects of project cost other than just development. In fact, studies show that 80% of a system's cost is tied up in the maintenance and support phase of a system's life cycle.

Robustness
As is the case with traditional EAI technologies, mature technologies are often robust because they have stood the test of time. Business issues and problems have challenged the EAI paradigm, causing the EAI vendors to provide solutions to difficult problems. EAI vendors have endured considerable tribulation in getting their software to effectively integrate disparate systems in the face of unforeseen mishaps and catastrophes.

However, through perseverance these EAI vendors have developed mature products for accomplishing the enterprise integration business objective.

When to Use Web Services to Augment EAI
Taking Web services in one hand and traditional EAI technologies in the other, system integrators now have access to a greater toolset of technologies in which to provide enterprise solutions. There are times where exposing a system as a Web service is more effective and times when EAI is better.

Given that Web services standards are currently in a state of flux, it is not advisable to integrate the entire enterprise using existing standards. Doing so will likely result in your needing to tear down and rebuild tomorrow. Figure 1 shows an interesting relationship for integration solutions when Uncertainty is plotted as a function of Efficiency Demand.

Uncertainty describes the extent to which a system environment is known and understood. Efficiency points to how well data can be run on a standard network and server configuration. In Figure 1, the less interfaces are understood the more uncertainty one will have in a particular integration scenario. Also, the likelihood that interfaces will change in the future increases the amount of uncertainty. The Uncertainty Threshold depicted in the graph describes an asymptote approached by the line of demarcation separating Web services and EAI. This threshold represents the amount of uncertainty in an integration solution needed to warrant the need of a Web services approach over a traditional EAI approach.

 

Integrating the Technologies
The remainder of this article documents scenarios where it makes sense to augment an EAI integration strategy with Web services. The scenarios described are:

• Connectivity beyond the corporate enterprise
• COTS software approach to integration
• Synchronous transactions
• High uncertainty compared to efficiency demand

Traditional EAI technologies did provide mechanisms for punching through the corporate firewalls. However, these mechanisms were proprietary, which led to inflexible and inconvenient integration solutions, especially when an organization decided to either change EAI vendors or change a particular line-of-business system providing the Web service to the enterprise.

COTS Software Approach to Integration
Commercial Off The Shelf (COTS) products should take advantage of Web services technologies and begin providing such connectivity in their system via Web services mechanisms. Even as Web services standards change through industry innovation, providing connectivity via Web services would increase the convenience of integrating with the existing enterprise by an order of magnitude.

Synchronous Transactions
Integration scenarios calling for synchronous transactions (i.e., request-reply) are prime candidates for exposure to the enterprise by a Web service. The most common Web service implementations use HTTP as their protocol. Unless a proprietary message provider is employed, the very nature of HTTP requires a demand-driven transaction in which the client must make a call to the service requesting information.

High Uncertainty Compared to Low Efficiency Demand
When high uncertainty exists relative to the efficiency demand of an integration solution, Web services would likely be a better candidate. This scenario plays to Web services' strengths; however, EAI's strengths are less of an advantage in this case.

Since Web services are based on open standards, even changing out the Web services provider should have little impact on the integration with other systems. This type of change could be likened to changing the browser used to view a Web change. Granted there are differences, but most of these differences are minor compared to the differences between the interfaces of line-of-business applications.

Conclusion
From a high level, Web services and EAI seem to offer similar value propositions. As demonstrated here, Web services and EAI provide different strengths to application integration.

The primary benefit of understanding the differences between Web services and traditional EAI solutions is in being able to see where EAI is inadequate and how to provide solutions to these inadequacies with Web services.

In a world where Web services and EAI technologies coexist, opportunities for creative solutions will provide new venues for more effective application integration solutions.

References