Book Excerpt: When to Use Web Services

1 2 3 Page 3
Page 3 of 3

Yahoo is extending its enterprise software service offering by adding a set of Web APIs. These Web APIs will let you integrate Yahoo content with your business applications. For example, you could integrate Yahoo content with your CRM application. When a salesperson looks up a customer contact in the contact management system, the application can send a query to Yahoo to retrieve and display the latest headlines about the customer. Although it's true that this information is available for free through the Yahoo portal, there's an obvious value to being able to integrate news with a CRM solution. Yahoo plans to license the Web APIs as part of the Yahoo enterprise service offering. Yahoo may also license these APIs to CRM application providers to enable a prepackaged Yahoo-ready solution. When Not to Use Web Services

As much as I like Web services, I want to caution you that they aren't always the appropriate solution. XML is tremendously versatile, but it isn't the most compact or efficient mechanism for transferring data. A SOAP message is much bigger than a comparable native binary message used with RPC, RMI, CORBA, or DCOM. It also takes a lot more time to process an XML message than a binary message. Even with the best-performing implementations, SOAP messaging can take 10 to 20 times longer than RMI or DCOM.[2] The performance differential gets worse as the message grows in size and complexity. You want to be cautious when trying to use Web services in situations with stringent requirements for real-time performance. I don't recommend using Web services to transfer very large files (> 10MB).

You shouldn't view SOAP as a total replacement for traditional middleware technologies, such as RPC, RMI, CORBA, and DCOM. These technologies still have an important place in application development. They were designed to provide a seamless, high-performance mechanism to communicate among various components within a homogeneous application system or service.

It's quite appropriate to use these technologies to build individual applications. For example, if you were developing in Java, you would probably want to build the application using J2EE component technologies, such as servlets and Enterprise JavaBeans. These components communicate with each other using RMI.

After you have developed your application, you probably want to expose it to the rest of the world using SOAP and WSDL. The traditional technologies weren't designed to integrate heterogeneous application systems, and they certainly weren't designed to communicate across the Internet. The point is that you want to use the right tool for the job. Web services were designed to support heterogeneous integration and Internet communication.

You might consider using SOAP in place of some proprietary messaging infrastructures, particularly if you are using these technologies to perform simple point-to-point integration. Keep in mind, though, that as of this writing, basic SOAP doesn't provide the same level of reliability as message queuing software, nor does it give you inherent notification facilities to support publish and subscribe functionality.[3]

A number of folks position Web services as the death knell for EAI software. My view is that if Web services can replace your EAI software, then EAI software is overkill for your project. EAI software does many things that SOAP, WSDL, and UDDI simply can't do by themselves. The software category known as EAI consists of a collection of various types of software that work together to deliver a comprehensive integration solution. EAI software includes messaging infrastructure, application adapters, data extraction and transformation tools, message brokers, and rules engines. Web services technology could replace the messaging infrastructure, but it can't replace the rest of the pieces. These other pieces, particularly the application adapters, are complementary to Web services technology. Most EAI vendors are adding support for Web

Special Report

Web Services Hurdles

Stories in this report:

Copyright © 2004 IDG Communications, Inc.

1 2 3 Page 3
Page 3 of 3
  
Shop Tech Products at Amazon