Simple Object Access Protocol is one of the neatest XML based technologies to be introduced as of late, yet many people are still trying to get a handle on all of the new terms and acronyms that SOAP has uncovered. This article is written to help you dig through the SOAP soup we have in front of us and create a foundation for truly understanding what SOAP is all about. This article is not meant to provide in-depth detail about SOAP, but is written as a preparation for future articles where we will get into the guts of SOAP.

Simple Object Access Protocol (SOAP)

As the root of our conversation, SOAP has been developed to solve an aging problem with developing applications for the Internet: interoperability. Imagine a world where you can access objects and services on remote (or local) servers in a platform-independent manner. Today’s world is polluted with different operating systems, different firewalls, different methods of making remote procedure calls, and different platforms. In order to interoperate across the Internet both the client and server need to understand each others security types and trusts, service deployment schemas, and implementation details, not to mention speak the same platform language (e.g. COM to COM, ORB to ORB, EJB to EJB, etc.).

With SOAP, an end to all of this platform-specific confusion has arrived. Based on the already industry wide accepted IETF HTTP standard and W3C XML standard, SOAP bridges the gap between competing object RPC technologies and provides a light-weight messaging format that works with any operating system, any programming language, and any platform.

Simply stated, SOAP provides a way to access services, objects, and servers in a completely platform-independent manner. Using SOAP you can query, invoke, communicate with, and otherwise touch services provided on remote systems without regard to the remote system’s location, operating system, or platform.

You can read the entire SOAP v1.1 spec on Microsoft’s website at

Service Description Language (SDL)

In order to utilize a service on a remote server using SOAP, you (your program) need to understand what the remote service is capable of. Notice the difference between understanding the capabilities of the remote service and understanding the remote service’s implementation (platform specific information). Using SDL, SOAP provides a way to query the remote service and learn about its capabilities, such as how it represents data types and commands. For example, using SDL one could learn that a particular service accepts two integers, adds them, and returns the sum as an integer.

SDL is an XML grammar, or in other words, SDL is simply an XML document, thus it inherently has all of the great XML traits (e.g. it is extensible). SDL is very similar in concept as IDL (interface definition language) except that IDL is platform specific and SDL is platform independent (another trait of XML).

SOAP Contract Language (SCL)

Much like SDL, the SOAP Contract Language is designed to expose the capabilities of a service, but also goes much farther. Microsoft has published the SCL specification with the following comment, “We published the SCL specification so we could solicit broad feedback from the industry. We’ll update the public toolkit to use SCL once the specification takes into consideration the feedback we’re going to get and is in a reasonably stable state. Until then it (the toolkit) will continue to use a form of SDL.” Because of the extended capabilities of SCL, it will replace SDL once it matures.

In addition to describing a service’s capabilities, SCL goes much further by defining the actual “contract” by which endpoints (the server and the client) communicate. This contract contains both a description of the endpoint and the messages it will accept, and optional orchestration information that describes the flow of messages between endpoints.

Discovery of Web Services (DISCO)

DISCO provides a way to discover and retrieve an SDL or SCL description of services on remote machines. This is the final piece of SOAP that puts everything together. Using the Discovery Document Format (which is also an XML grammar), one can send a discovery document to a remote server and, if any SOAP enabled services (AKA web service) exist, receive back an SDL or SCL description of the services provided.

You can read more about DISCO at

Remote Object Proxy Engine (ROPE)

ROPE provides a set of COM components that assist in building SOAP messaging into your applications. The ROPE components (in the form of rope.dll) have two models of complexity, one for VB-like simplicity and one for VC-like control.

If you were to call a SOAP method without using ROPE you would have to format the SOAP calls into XML, package the call into an HTTP request and send it, receive the HTTP response and parse the returning XML. ROPE takes care of all of that complexity for you. ROPE is not required to use SOAP, but it sure makes things easier.

Microsoft’s Visual Studio 6.0 SOAP Toolkit contains some helpful information and examples of how to implement ROPE. No SOAP on a ROPE jokes here!

SOAP Toolkit

Microsoft has made it easy to begin working with SOAP by publishing a SOAP toolkit for Visual Studio 6.0. While the toolkit is not supported, it does contain a healthy help file to help you learn how to use it. Using the toolkit you do not need to master XML and SOAP or learn wire protocol. It makes adding SOAP capabilities to your applications very easy and leverages your knowledge and experience in existing tools (Visual Studio).

The toolkit contains:

  • Server side reference listeners
  • Remote Object Proxy Engine (ROPE)
  • SDL and source code generator (wizard)
  • Documentation
  • Code samples
  • Architectural Sample (full source code!)

You can download the July 2000 release of the toolkit from the MSDN downloads site (


As you can see, SOAP is a complete technology ready to be put to use. Each part of SOAP has been well thought out and developed, and will make developing Internet applications and services much easier. Stay tuned for future articles on SOAP where we will dive into the guts of the XML and examine specific uses of SOAP technology.

Related Links

Related posts

Using XML to build an ASP+ config.web Editor

Introduction ASP+ configuration information is stored in XML-based configuration files. Using built-in features of IIS 5.0 and IE 5.0 such as the FileSystemObject, the XML Document Object Model (DOM) and XML Data Islands, we can easily develop a rich tool for modifying and editing these configuration files. In this...

Read More

Saving HTML Form Data to XML

Introduction This example assumes that you are familiar with ASP, XML and HTML 4.0. Storing your form submissions in XML Usually form submissions in ASP are written to some sort of database management system. However, if you need your form submission data to be more portable, it can be...

Read More

Editing XML with XSL and ASP

Introduction This example assumes that you are familiar with ASP, XML and HTML 4.0. Data stored in XML files can easily be edited from the Web This article is a follow up to the Saving HTML Form Data to XML article. If you have not read Saving HTML Form Data to...

Read More