Home > Articles > Networking

Web Services: Building Cross Platform Applications

  • Print
  • + Share This
When people talk about Web Services these days, they're usually referring to SOAP-based Web Services. In this article, Scott Seely and Brad Gaster tell you what Web Services are and shows you why they're just one of the reasons for making the jump to cross-platform technologies such as SOAP.
From the author of

Thanks to the Internet and ubiquitous networking, developers rarely have the luxury of developing their applications in a homogeneous environment. Why? Businesses rarely have only one platform in place. They may have mainframes, UNIX boxes, Apple computers, and Windows machines owned by different groups throughout the business. Typically, these businesses have little or no interest in moving to a unified computing environment. Often, a machine in one part of the business exposes some functionality that another would like to get access to. How do you do this? If you make up your own rules, you will likely spend a lot of time and effort inventing the communication mechanisms. Not only that, but you have to spend time implementing the solution on every platform that wants to use that functionality. There has to be something better.

When the Extensible Markup Language (XML) first came out, a number of companies started using it as a cross-platform remote procedure call (RPC) mechanism. XML had the benefit of wide industry acceptance, meaning that most platforms and languages have access to an XML parser. The largest problem with using XML this way is that, in 1998, no standards existed for what XML RPC messages should look like. So, a standard initially came out for XML-RPC. For whatever reasons, this protocol never took off in force. (I am aware that many implementations of XML-RPC exist and are used for business critical applications.) In late 1999, UserLand, DevelopMentor, and Microsoft released version 0.9 of the Simple Object Access Protocol (SOAP) specification. For reasons unknown to me, this XML based RPC protocol really took off. By May of 2000, version 1.1 of the specification had been released and two major players, Microsoft and IBM, had both released SOAP implementations, complete with source code. Today, dozens of implementations exist for most languages and computing platforms.

What's so great about this? Functionality that used to be tied to one language or computing environment can now be exposed to any consumer, whether it is a programmable logic controller (PLC) on a factory floor or a mainframe in the corporate computing center or anything in between. The other good news on SOAP: the World Wide Web Consortium has accepted the SOAP v1.1 specification and is using it to create the XML Programming/SOAP specification. The standard has the support of many industry heavyweights, including Sun, Microsoft, and IBM.

With all this talk about SOAP, I need to step back and define what a Web Service is. A Web Service is a collection of functions or messages that a provider exposes for other machines to use when exchanging data. Today, several definitions exist for Web Service exchange models using MIME, HTTP-GET, HTTP-POST, and SOAP. For various reasons, when people talk about Web Services they usually imply SOAP-based Web Services.

SOAP Toolkits

Many technologies like SOAP have told great connectivity stories. COM, CORBA, Java RMI, and DCE-RPC all had great stories as long as your platform and language agreed on what the implementation should look like. That story is no different with SOAP. If two implementations do not cooperate, then there is no value. Fortunately, SOAP implementers have pushed very hard for interoperability between implementations. Here's a sampling of SOAP Toolkits:

For a full listing of known SOAP implementations, please visit SoapWare.org's SOAP Directory. As you can see from the above listing, you should have no issues adopting SOAP. A large number of languages have code ready for you to adopt and adapt to your own projects. The large number of implementations shows that SOAP truly is an accessible protocol.

  • + Share This
  • 🔖 Save To Your Account