Why Web Services?

for RuBoard

The concept of RPC is nothing new. In the preceding years we have been proselytized to use DCOM, CORBA, and a number of other RPC protocols. However, none of these protocols has received enough support to make them ubiquitous and thus enable any trading between partners . DCOM and CORBA both used their own data representations that, while similar in many respects, are different enough to prevent any interoperation . They each define their own protocols that don't work very well in a high-latency WAN such as the Internet. DCOM in particular is very "chatty," requiring numerous round trips just to negotiate a simple remote procedure call with no arguments. In addition, with the paranoid mentality of corporations connecting to the Internet through firewalls and the like, the chances are slim of either an IIOP or DCOM request making it through a firewall. Finally, DCOM is a connection-oriented protocol. The downside of this is that after a connection has been set up, DCOM expects to have a long-running conversation with the remote object, making load balancing and load farming a difficult proposition at best.

On the other hand, the underlying protocol of XML Web services, HTTP, has had untold millions of dollars spent on it in the last few years to solve the problems of scalability and fault tolerance in support of the boom in the Web space during the mid 1990s. Well-known best practices exist for scaling HTTP by creating farms of Web servers, using dynamic location-based DNS, and even performing switching in layers 2 “7 of TCP/IP to support quite intelligent load balancing. All this work can now be applied to XML Web services.

With the creation of SOAP came a standard for an XML grammar that can be used to overcome the differences that plagued the various RPC implementations in the past. SOAP defines how any data type, for example, an int, should be encoded, regardless of platform.

for RuBoard