Web Services: Building Cross Platform Applications
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
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:
IDOOX Web Applications and Services Platform: Supports Java, C, and C++.
PythonWare's SOAPLib.py: Supports Python.
EasySoap++: Supports C++.
pocketSOAP: Supports Microsoft Windows COM objects via any automation compatible interface.
SQLData SOAP: Supports Microsoft Windows COM objects.
Kafka: Supports XSLT.
Apache SOAP: Supports Java.
SOAP for Ada 95: Part of the Application Standard Components Library (ASCL), it supports Ada.
SOAP Smalltalk: Supports SmallTalk.
SOAP4R: Supports Ruby.
TclSOAP: Supports Tcl.
Pure SOAP: Supports Delphi.
SOAP::Lite: Supports Perl.
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.