Intelligent Enterprise

Better Insight for Business Decisions

RSS
Webcasts
Whitepapers
Subscribe
Home

September 17, 2002

The Web Services Placebo

Contrary to the hype, Web services aren't the answer to your EAI dilemma

by Michael J. Hudson

Continued from Page 1

The EAI Connection

So, what does this have to do with EAI? In the B2B world, the flexibility and ability to operate across the Internet on completely disparate systems owned by completely independent entities is a major benefit. In such a scenario, you can easily dismiss any of the downsides of Web services. However, in EAI solutions, the major drivers are not only interoperability but also speed and efficiency, and with those requirements, Web services don't really meet the need.

The important thing to remember is that an EAI environment is your internal business environment where you have a lot more control over the platforms, languages, and software that you deploy and implement. When dealing with multiple companies in an electronic supply chain scenario, you have little or no control of these variables. So, in that case, Web services may be appropriate. However, internally, even if you have one system completely written in C++ on a Windows platform and another written in Java on a Solaris machine, you still have a lot of choices for integration that are much more effective and efficient than using Web services.

Java has a Connector Architecture built specifically for this kind of integration and focuses more on your internal plumbing than the format of your data. It provides a way to communicate with other existing internal systems using a number of technologies, including sockets or native APIs. It means that there's a lot more coupling than with a generalized Web services solution, but it's still quite modular, and you get an increase in performance that is 10-fold more than what you would get with Web services.

Again, the key here is that with EAI and any internal integration projects, you control the technologies. It might be easier and more cost-effective to move your strategic business applications onto the same platform or to rewrite them in the same language. A number of companies specialize in EAI services and, thus, provide adapters between many popular third-party ERP and CRM systems and your internal strategic business applications. With a Web services solution, a large number of new layers are introduced and Web services' tendency toward asynchronous communication can be a thorn in anyone's side. All these Web service layers force you to run a number of actions for every transaction you need to execute.

For instance, a general Web service scenario usually mandates that one system creates the XML message and sends it to the receiver, which accepts the message, translates it to invoke the appropriate code that you need, generates a response, and then translates that response into an outgoing XML message that eventually will need to be translated similarly by the original system. There's always extra layers of translation (often slow and inefficient) that go on when using Web services. In contrast, current EAI bridging technologies usually enforce only one or two layers of translation.

Still Young Yet

Another thing to note and mention is that Web services are still a very young set of standards that don't explicitly support strategic considerations such as security, transaction handling, or even session contexts. These requirements are usually essential in EAI environments. The loose coupling and disconnected nature of Web services guarantees that request and response scenarios will be somewhat unreliable, and the ability to hold a session or transaction context over a long period of time is unpredictable.

As Web services evolve over time, some of these limitations might be addressed. However, on a fundamental level, Web services were never meant to be an EAI solution, but rather a very effective and flexible B2B solution. Too much overhead is involved for it to be effective anywhere else. XML and Web services are definitely beneficial standards that solve real-world problems. However, the key is knowing which problems they solve and not trying to force them into situations they weren't meant to answer.

Rate This Article

Comments:

Optional e-mail address:

Sometimes, using Web services in an EAI environment may make sense - perhaps as an internal R&D effort on how to use and implement Web services. However, in general, it's like trying to use email to communicate with someone who's right next to you. But then again, like many IT people (myself included) who like to play around with new technologies for their own sake, you'll often still here the response, "What's so wrong with that?"

Michael J. Hudson [mhudson@blueprinttech.com] is a framework engineer for Blueprint Technologies, a software architecture firm based in McLean, Va. His current work includes developing enterprise architectural solutions for clients such as NASA.