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

In my usual tradition of trying to mediate hype in the IT industry, I continue my investigation of another claim about the latest "next best thing": Web services. Currently, the evangelists of the church of Web services have been proselytizing their faith to the enterprise application integration (EAI) community. As you know, EAI deals with an organization's ability to communicate with disparate internal systems to promote better efficiency and increase productivity. This space is an old problem, relative to the existence of modern business IT systems, yet an audience is always ready and eager to try the newest snake oil that promises to heal all cuts and bruises.

Behind Web Services

Much has been said and written about Web services in the last year, so many of you probably know what it is and the technologies it represents. But for the sake of creating a foundation for my argument, let me set the stage, once again, and briefly go over the essentials of Web services. In a nutshell, Web services comprise a set of standards for easily dealing with the connectivity of heterogeneous systems across the Internet. More specific, these systems are frequently seen as completely disconnected from one another and usually owned and operated by completely independent entities. In other words, the problem being solved here is the integration of systems that no one person or entity has control over.

These systems may be on a number of different platforms and implemented using a number of different languages. Web services provide a framework and a set of standards that can be used as wrappers around these systems. The owner of one system can still change and modify its behavior without changing the Web service wrapper. This loose coupling allows an extreme amount of flexibility for each implementer, while ensuring that everybody can still communicate with minimal changes.

If you dig deeper into Web services, you hit two cornerstone standards: XML and HTTP. The goal for using XML is its simplicity. It's completely text and somewhat easier to read by a human than a proprietary hexadecimal stream. Although all systems may rely in some way on binary data, they all can read, in some fashion, straight text or strings. Thus, a system can easily adapt to the use of XML, or more simply, transfer information as text. HTTP is also used for its simplicity and, even more important, its ubiquity on the Internet. It's the preeminent protocol to transfer Web content and one of the only protocols allowed free access through firewalls. If you need an easy, currently existing mechanism to transfer data, you should use HTTP.

Upside Vs. Downside

So, the upside of using these standards is their ease of use, ease of integration, and their omnipresence. However, the downside is that they aren't even close to being the most efficient ways to communicate electronically. XML uses two sets of redundant tags to mark up every piece of information it represents. The tags are usually written to be humanly readable, which makes the actual tags a lot longer than they need to be. Also, one character in a Unicode document can be up to four bytes. Four bytes in some other proprietary binary format used by technologies such as DCOM or RMI can hold a lot more information than just one character. Nowadays, disk space is a lot less expensive, so it's not hard-drive space that creates a problem; it's the ability to serialize that data over a connection and have it parsed quickly and efficiently.

HTTP, although used almost everywhere because of its reliability and ubiquity, is also not the most efficient transport protocol. HTTP relies on a constant connection between the client and server when a request is made. When all you need is a Web page, this constant connection causes little overhead. However, in the Web services universe, many transactions are essentially asynchronous, meaning that a response isn't guaranteed and might take several minutes or days to resolve.

HTTP wasn't meant to deal with this kind of asynchronicity. It also relies on only one side initiating communication and the other side only responding to the request. This approach inhibits true peer-to-peer exchanges through Web services. A newer version of HTTP tries to quicken communications by using compression, but it still doesn't resolve some of the previous issues. And although you can implement Web service solutions without HTTP, many of the other prevailing protocols being used with Web services, such as SMTP (email protocol), aren't much more efficient.