SOAP 1.1 is simply a distributed object protocol like DCOM, CORBA IIOP, and Java RMI-JRMP. The most significant difference between SOAP 1.1 and other distributed object protocols is that SOAP 1.1 is based on XML.
Tip
EJB 2.1 and the J2EE 1.4 platform are standardized on SOAP 1.1. At the time of this writing, SOAP 1.2 (the latest version of SOAP) has just been released, but it is not supported by J2EE 1.4/EJB 2.1. From this point forward, we’ll only talk about SOAP 1.1, which we’ll simply call SOAP.
SOAP is defined by its own XML Schema and relies heavily on the use of XML Namespaces. Every SOAP message that is sent across the wire is an XML document that consists of standard SOAP elements and application data. The use of namespaces differentiates the standard SOAP elements from the application data. Here’s a SOAP request message that might be sent from a client to a server:
<?xml version='1.0' encoding='UTF-8' ?> <env:Envelopexmlns:env="http://schemas.xmlsoap.org/soap/envelope/"><env:Header /><env:Body><reservation xmlns="http://www.titan.com/Reservation> <customer> <!-- customer info goes here --> </customer> <cruise-id>123</cruise-id> <cabin-id>333</cabin-id> <price-paid>6234.55</price-paid> </reservation></env:Body></env:Envelope>
The standard SOAP elements are shown in bold while the application
data, the Reservation XML document fragment, is shown in regular
text. SOAP’s primary purpose is to establish a
standard XML framework for packaging application data that is
exchanged between different software platforms, such as Java and
Perl, or Java and .NET. To do this, SOAP defines a set of elements,
each of which is designed to carry different data. The
<Envelope> element is the root of the SOAP
message; all other elements are contained by it. Within the
<Envelope> element are two direct children:
the <Header> element and the
<Body> element.
The <Header> element is generally used for
carrying infrastructure data such as security tokens, transaction
IDs, routing information, and so on. In the previous example, the
<Header> element is empty, which is not
unusual for basic web services. In many cases, we are only interested
in exchanging information and not in more advanced issues, such as
those relating to security and transactions. Although the
<Body> element is required, the
<Header> element is not. From this point
forward, the <Header> element will be
omitted from examples.
The <Body> element carries the application
information that is being exchanged. In the previous example, the
<Body> element contains a
<reservation> element, which is the
application data. It’s an XML document fragment
based on the Reservation XSD developed earlier in this chapter.
It’s called a
“fragment” because
it’s embedded inside a SOAP message, rather than
standing alone.
The SOAP message we just looked at is a Document/Literal message, which means that the message carries an XML document fragment that may be validated against an XML Schema.
The schemaLocation attribute could have been
included; it’s omitted because we assume that the
receiver is already familiar with the schema used for that type of
SOAP message.
The other messaging mode allowed by the WS-I Basic Profile 1.0 and
supported by EJB 2.1 is RPC/Literal. RPC/Literal represents SOAP
messages as RPC calls, with parameters and return values, rather than
arbitrary XML document fragments. The following Java interface
defines a single method called makeReservation( ):
public interface TravelAgent extends java.rmi.Remote {
public void makeReservation(int cruiseID, int cabinID,
int customerId, double price)
throws java.rmi.RemoteException;
}The makeReservation( ) method can be modeled as a
SOAP message using the RPC/Literal messaging style:
<env:Envelope
xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:titan="http://www.titan.com/TravelAgent"/>
<env:Body>
<titan:makeReservation xmlns="http://www.titan.com/TravelAgent" >
<cruiseId>23</cruiseId>
<cabinId>144</cabinId>
<customerId>9393</cusotmerId>
<price>5677.88</price>
</titan:makeReservation>
</env:Body>
</env:EnvelopeThe first element within the <Body>
identifies the web service operation being invoked. In this case,
it’s the makeReservation
operation. Directly under the
<titan:makeReservation> element are the
parameters of the RPC call, each of which is represented by an
element with a value.
EJB 2.1, but not the WS-I Basic Profile 1.0, supports the RPC/Encoded mode of SOAP messaging. Most SOAP applications used RPC/Encoded when web services were first created. However, the web services industry has moved toward Document/Literal and RPC/Literal, primarily because interoperability between platforms using RPC/Encoded proved to be less than perfect, and sometimes downright difficult. While RPC/Encoded SOAP messages rely on SOAP defined types for Arrays, Enumeration, Union, Lists, and the like, RPC/Literal and Document/Literal depend only on XML Schema for their data types, which seems to provide a better system for interoperability across programming languages. Although EJB 2.1 supports RPC/Encoded messaging, it’s really not a very good option to use in web services. RPC/Encoded messaging will not be addressed in this book.
SOAP messages are network protocol-agnostic, which means that a SOAP message is not aware of or dependent on the type of network or protocol used to carry it. That said, SOAP is primarily exchanged using HTTP. The reason for using HTTP is simple. Most Internet products, including web servers, application servers, and wireless devices, are designed to handle the HTTP protocol. The widespread support for HTTP provides an instant infrastructure for SOAP messaging. The fact that SOAP can leverage the ubiquity of HTTP is one of the reasons it has become so popular so quickly.
Another advantage of using HTTP is that SOAP messages can slip through firewalls without any hassles. If you have ever tried to support internal or external customers who are separated from you by a firewall (yours or theirs), you know the headaches a firewall can create. Unless you have direct control over the firewall, your chances of communicating with arbitrary clients using anything but HTTP or SMTP (email) are slim to none. However, because SOAP can be transmitted with HTTP, it slips through the firewall unnoticed. This ability makes life a lot simpler for the application developer, but it’s a point of contention with the security folks. Understandably, the security community is a bit irked about the idea of application developers circumventing their defenses. Using HTTP to carry an application protocol like SOAP is commonly called HTTP tunneling. In the past, support for tunneling by vendors of other distributed object protocols (CORBA IIOP, DCOM, and so on) was sporadic and proprietary, making interoperability extremely difficult. With SOAP, tunneling over HTTP is built into the SOAP 1.1 specification—which means interoperability is no longer a problem. As just about every application server vendor rapidly adopts SOAP, SOAP-HTTP tunneling is becoming ubiquitous.
You can use SOAP 1.1 with other protocols, such as SMTP, FTP, and even raw TCP/IP, but HTTP is the only protocol for which a binding is currently specified. As a result, EJB 2.1 and J2EE 1.4 require support for SOAP 1.1 over HTTP 1.1, but not other protocols.
All this talk about SOAP is designed to give you a better idea of what is going on under the hood, but in practice, you are unlikely to interact with the protocol directly. Like most protocols, SOAP is designed to be produced and consumed by software and is usually encapsulated by a developer API. In EJB 2.1, the API you will use to exchange SOAP messages is JAX-RPC (Java API for XML-based RPC), which hides the details of SOAP messaging so you can focus on developing and invoking web services. While using JAX-RPC, you will rarely have to deal with the SOAP protocol, which is nice because it makes you a lot more productive. JAX-RPC is covered in Chapter 15.