SOAP links disparate applications

Enterprise networks are moving to a distributed model in which multiple devices and computers work together on a network that features localized, rather than centralized, intelligence.

This has resulted in diverse devices being developed with a range of languages and operating systems running myriad applications.

For these devices to work together effectively and efficiently, there must be a common language to tie them together. An early leader in filling this need is the Simple Object Application Protocol (SOAP).

SOAP schema

SOAP is defined by two schemas developed by the World Wide Web Consortium (W3C).

First, the SOAP encoding schema describes how to encode data using a set of defined data types. If these data types are not sufficient, users can define their own data types.

Next, the SOAP envelope schema describes the overall format of SOAP messages. It also defines built-in ways of extending the message format to support custom applications. SOAP specifications developed by the W3C also define how to use HTTP to send and receive SOAP messages. Although SOAP messages can be sent over any protocol, HTTP is used in most applications.

In theory, SOAP can be used to pass almost any type of data between two applications. In practice, it is normally used to make Remote Procedure Calls (RPC). When used to encode RPCs, SOAP is a request/response protocol.

An application encodes an RPC request into a SOAP message and sends it to a remote system.

---

How it works
Subscribe to the Tech Update newsletter
  Here is a weekly newsletter to help you stay abreast of new networking standards and technologies by providing down-to-earth explanations of how they work.

---

The request identifies the requested operation and contains its parameters. The remote system sends back the reply in another SOAP message that contains the operation result.

Because it is based on XML, SOAP is language- and platform-independent. The two applications could be written in different languages and could run on different operating systems.

XML-based SOAP has many advantages over alternative ways of encoding RPC calls. XML's openness and popularity means that XML parsers are widely available, making it easy to write applications that use SOAP.

External Data Representation (XDR), the traditional encoding for RPCs, is not used for anything other than RPCs. Because of this, XDR encoders are not available on many platforms. Remote Method Invocation is tied to the Java language and cannot be used if applications that do not support Java are present in the network.

SOAP is lightweight and easy to use. CORBA could also be used for RPC calls, but it is a heavyweight protocol and difficult to use - overkill for RPC-type applications. CORBA also has trouble penetrating firewalls because it does not use HTTP for its transport protocol. XML-RPC was a precursor to SOAP. Although it is very useful for simple RPC applications, it is not as extensible as SOAP. XML-RPC does not support user-defined data types, and XML-RPC messages cannot be extended to support specific applications.

The downside

SOAP does have some disadvantages. SOAP data encoding is very inefficient, as messages are encoded as text, making the messages cumbersome.

Further, SOAP messages use more bandwidth than equivalent binary messages. When SOAP messages are received, they have to be converted into binary data so the application can act on them. Application developers can use off-the-shelf XML parsers to handle this task.

However, the XML parser will have to be incorporated into the application, making it larger, and a substantial amount of CPU time may be consumed parsing the messages.

If an application does not need to be platform-independent, or if communications bandwidth is at a premium, SOAP might not be the best solution.

However, SOAP support is becoming ubiquitous across many different platforms. If an application will be distributed across many different systems, SOAP is the better choice.

---

Related Links

Apply for your free subscription to Network World. Click here. Or get Network World delivered in PDF each week.

Request a reprint or permission to use this article.