Chapter: XML and Web Services : Web Services Building Blocks

Key Building Block for Web Services

SOAP:

SOAP is a standard way of serializing the information needed to invoke services located on remote systems so that the information can be sent over a network (or ―wire‖) to the remote system, in a format the remote system can understand, regardless of what platform the remote service runs on or what language it‘s written in. If you‘re familiar with RPC architectures such as CORBA and DCOM, this description of SOAP should sound familiar, because SOAP resembles the wire protocols underlying both architectures: the Internet Inter-ORB Protocol (IIOP) that underlies CORBA and Microsoft‘s Distributed Component Object Model (DCOM) protocol, respectively. In fact, SOAP can be thought of as a simplified XML-based replacement for these protocols.

Key Building Block for Web Services:

SOAP provides an additional advantage over traditional ORPC architectures: Because SOAP messages are self-describing, the method calls contained in a SOAP message can vary each time the message is sent. In addition, it is possible to marshal several method calls in a single SOAP message. With a traditional ORPC, each call to a remote method must be handled as a separate roundtrip. A SOAP message, however, can be constructed on-the-fly to send data to multiple methods. Used judiciously, this capability can more than compensate for the slowness of SOAP‘s text-based messages as compared to the binary messages of CORBA and DCOM.

Basic SOAP Syntax:

• SOAP is a messaging framework, consisting of an outer Envelope element that contains an optional Header element and a mandatory Body element.

• SOAP is an encoding format that describes how objects are encoded, serialized, and then decoded when received.

• SOAP is an RPC mechanism that enables objects to call methods of remote objects.

SOAP Message Structure and Namespaces:

Let‘s start with a simple example of a message we might want to send—a request to the server for a person‘s phone number. We might have an interface (here, written in Java)

that would expose a method we might call to request the phone number:

public interface PhoneNumber

{

public String getPhoneNumber(String name);

}

Let‘s say, then, that instead of using CORBA or RMI, our client sends an XML-format-ted request to the server. This XML might look like the following:

<?xml version=‖1.0‖?>

Notice that the root node corresponds to the Java interface, and the method as well as its parameter are nodes, too. We then use our client to create an HTTP request, and we put the preceding XML in the body of an HTTP POST. We might expect a response from the server that looks something like the following:

<?xml version=‖1.0‖?>

The root node retains the name of the interface, but the method name has the word

―Response‖ appended to it, so the client can identify the correct response by appending ―Response‖ to the calling method name.

In general, constructing request and response messages like the preceding ones is a sim-ple but limited approach. The biggest limitation is that the vocabulary that the client and server use to exchange messages must be agreed upon beforehand. If there is a new method or a new parameter, both the client and the server must reprogram their interfaces. In addition, in a complex message, there could easily be confusion if two methods have parameters with the same name.

In order to resolve these limitations with such simple message formats, SOAP takes advantage of XML namespaces. Let‘s take a look at the same request message recast in SOAP:

<SOAP-ENV:Envelope xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/” xmlns:xsi=”http://www.w3.org/1999/XMLSchema-instance” xmlns:xsd=”http://www.w3.org/1999/XMLSchema” SOAP-ENV:encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/”>

<SOAP-ENV:Header> </SOAP-ENV:Header> <SOAP-ENV:Body>

<ns:getPhoneNumber xmlns:ns=”PhoneNumber”> <name xsi:type=”xsd:string”>John Doe</name>

</ns:getPhoneNumber> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

Let‘s break down this request and take a closer look. First of all, its root node isEnvelope, which has an optional Header section and a mandatory Body section. The SOAP Envelope is then enclosed in the outer transport envelope, which might be HTTP, SMTP, and so on. All SOAP messages are structured like this, as shown in Figure.

You declare namespaces with the xmlns keyword. There are two forms of namespace declarations: default declarations and explicit declarations. In our sample request, all the declarations are explicit. Explicit declarations take the following form:

xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/

The default declarations look like this:

xmlns=”SomeURI”

SOAP Envelope Element:

The SOAP Envelope element is the mandatory top element of the XML document that represents the SOAP message being sent. It may contain namespace declarations as well as other attributes, which must be ―namespace qualified.‖ The Envelope element may also contain additional subelements, which must also be namespace qualified and follow the Body element.

SOAP Header Element:

The SOAP Header element is optional and is used for extending messages without any sort of prior agreement between the two communicating parties. You might use the Header element for authentication, transaction support, payment information, or other capabilities that the SOAP specification doesn‘t provide.

Let‘s take a look at a typical Header element:

<SOAP-ENV:Header>

<t:Transaction xmlns:t=―myURI‖ SOAP-ENV:mustUnderstand=―1‖></t:Transaction>

</SOAP-ENV:Header>

SOAP Body Element:

The mandatory Body element is an immediate child of the Envelope element and must immediately follow the Header element if a header is present. Each immediate child ofthe Body element is called a body entry. The Body element is used to carry the payload of the SOAP message, and there is a great deal of latitude in what you can place in the Body element. Body entries are identified by their fully qualified element names. Typically, the SOAP encodingStyle attribute is used to indicate the serialization rules for body entities, but this encoding style is not required.

Data Types:

The SOAP specification allows for the use of custom encodings, but typically you are likely to use the default encoding defined in http://schemas.xmlsoap.org/soap/ encoding/. If you use this encoding, you get to take advantage of its data model, which is structured to be consistent with the data models of today‘s popular programming languages, including Java, Visual Basic, andC++.

Sending SOAP messages:

The primary motivation for developing the SOAP specification has been to find a way to make RPC architectures simpler and less problematic. The problems with DCOM and CORBA— vendor dependence, firewall unfriendliness, and unnecessary complexity led to the development of early XML-based RPC architectures, such as XML-RPC.

XML-RPC paved the way for SOAP. Although XML-RPC was a straightforward applica-tion of XML, it did not take advantage of XML namespaces and was therefore not fully extensible. For this reason, SOAP was originally thought of as a namespace-capable aug-mentation-toXML-RPC.

• A request-response operation, which is bidirectional. In this type of operation, the server receives a message from the client and replies with a response message.

• A solicit-response operation, which is also bidirectional, except that the server solicits a request from the client, who then responds, essentially putting the response before the request.

• A one-way message sent from the client to the server with no response message returned.

• A notification message sent from the server to the client.

In essence, the bidirectional messages are inverses of each other, as are the unidirectional ones. In addition to these four basic operations, SOAP also supports the forwarding by intermediaries, which can also be either unidirectional or bidirectional. Furthermore, SOAP faults are only supported by bidirectional messages.

SOAP and HTTP:

HTTP supports two request methods: GET and POST. The GET method sends its parame-ters in the URL and is typically used to request Web pages from a Web server. The POST method sends data to the server in a payload that comes after the HTTP header. Because POST payloads can be of indefinite length, SOAP requests transmitted via HTTP are sentas HTTP POST requests.

Here‘s the format of a simple HTTP POST request that you might send when submitting a form on a Web page:

POST /mypath HTTP/1.1

Host: 123.45.67.89

Content-Type: text/plain; charset=‖utf-8‖ Content-Length: 20

Now, let‘s take a look at an HTTP POST request that contains a simple SOAP message:

POST /mypath HTTP/1.1 Host: 123.45.67.89 Content-Type: text/xml Content-Length: 300

SOAPMethodName: urn:mysite-com:PhoneNumber#getPhoneNumber <SOAP-ENV:Envelope xmlns:SOAP-ENV=‖http://schemas.xmlsoap.org/soap/envelope/‖ SOAP-ENV:encodingStyle=‖http://schemas.xmlsoap.org/soap/encoding/‖>

<SOAP-ENV:Body>

<ns:getPhoneNumber xmlns:ns=‖PhoneNumber‖>

In this request, the URI /mypath indicates the SOAP endpoint: It is up to the server to translate this URI into the location of the application charged with accepting this request. The Content-Type for all SOAP messages must be text/xml (as opposed to text/plain for Web pages).

A SOAP response looks pretty much the way you would expect:

<SOAP-ENV:Envelope xmlns:SOAP-ENV=‖http://schemas.xmlsoap.org/soap/envelope/‖ SOAP-ENV:encodingStyle=‖http://schemas.xmlsoap.org/soap/encoding/‖>

<SOAP-ENV:Body>

<m:getPhoneNumberResponse xmlns:m=‖urn:mysite-com:PhoneNumber‖>

Note that the URN for the receiving class appears in the getPhoneNumberResponse ele-ment, but there is no SOAPMethodName HTTP header. Such headers are only required for HTTP requests and are not allowed in responses. In addition, if the server encounters an error and returns a SOAP fault, the first line of the HTTP header would be this:

500 Internal Server Error

SOAP and SMTP:

The Simple Mail Transport Protocol (SMTP) is the established standard protocol for sending e-mail messages. Because SOAP envelopes are nothing more than text messages, e-mailing them is elementary on the surface. However, there are several issues that must be dealt with when using SMTP to send a message to an application.

A SOAP message sent via SMTP goes to a mailbox and waits for the server to act upon it. The mailbox will be typically provided by a Post Office Protocol (POP3) server. Therefore, in order for the server to access the SOAP message in a mailbox, the server will typically use a POP3-to-HTTP bridge to post the incoming message to the processing application, and then take the response and use an HTTP-to-SMTP bridge to send it back to the client. The client must then poll its own POP3 mailbox in order to accept the message.

The Future of SOAP:

It should be clear at this point that SOAP is a work in progress. On the one hand, current implementations are inconsistent in their support of the SOAP 1.1 specification. On the other hand, the current spec leaves much to be desired, as well. This section covers some of the most critical features either missing in the 1.1 spec or poorly supported by the cur- rent implementations.

SOAP with Attachments:

At its core, SOAP consists of self-defining serialization rules that allow for the marshal-ing and unmarshaling of objects into a simple text stream. SOAP‘s focus on objects is quite understandable—after all, it is the Simple Object Access Protocol. However, for SOAP to be a truly useful wire protocol, it must be able to handle large binary objects that don‘t lend themselves to marshaling.

The SOAP Messages with Attachments specification (found at http://www.w3.org/TR/ SOAP-attachments) uses the MIME Multipart/Related mechanism for handling attach- ments. This mechanism is the established protocol for handling e-mail attachments and is therefore well accepted in the technical community. When the technical community turned to the discussion of SOAP attachments using MIME, however, it had a problem: How to handle such attachments without burdening the SOAP specification with addi- tional elements? The answer was to construct the SOAP message package as a Multipart/Related media type. In other words, a ―SOAP message with attachments‖ package is actually a MIME Multipart/Related message, where the SOAP Envelope is one of the parts, instead of the MIME message being included in the SOAP Envelope.

Study Material, Lecturing Notes, Assignment, Reference, Wiki description explanation, brief detail

XML and Web Services : Web Services Building Blocks : Key Building Block for Web Services |