he Web services programming model is breaking down the barriers of cross-platform and cross-language communications. Because it works through simple XML-formatted text messages, code written in any language should be able to interact with code written in any other language, on any platform, anywhere. That sounds good in theory, but practice is often quite different. In this article I'll show you how to put the theory into practice.

SOAP is simple and non-intrusive enough that any tool vendor that supports HTTP can easily support SOAP. In short, SOAP is a wire protocol similar in intent to the Internet Inter-ORB protocol (IIOP) for Common Object Request Broker Architecture (CORBA), Object Remote Procedure Call (ORPC) for Distributed Component Object Model (DCOM), or Java Remote Method Protocol (JRMP) for Java Remote Method Invocation (RMI).

At this point you may be asking why, with so many wire protocols in existence, do we need another one. The answer is that while IIOP, ORPC, and JRMP are binary protocols, SOAP is a text-based protocol that uses XML. Using XML for data encoding gives SOAP some unique capabilities. For example, debugging applications based on SOAP is much easier because text-based XML messages are much easier to read than binary-formatted messages. Also, because all the information in SOAP is in text form, SOAP is much more firewall-friendly than IIOP, ORPC, or JRMP. SOAP requests can use the ubiquitous HTTP port 80. In contrast, the binary protocols typically force administrators to open other ports, which increases the likelihood of security breaches.

In this article, I'll show you how to achieve cross-language interoperability with Web services and SOAP. You'll see how to build a cross-language application featuring two-way communication between a Java service using a VB client, and the same Java service using a Visual C++ client. This simple example walks you through the procedures step-by-step.