Enterprise J2ME Developing Mobile Java Applications [Electronic resources] نسخه متنی

16.1 What Is SOAP Web Services?

Standardization is key to the success of XML. Raw XML by itself is just a bunch of tags, attributes, and text that can be used to express almost anything in any format. The flexibility gives XML the power of a universal data language. But in any specific application field, the meaning of XML syntax elements must be standardized to ensure interoperability. In order for XML to carry generic data between object-oriented programming systems, we need a syntax system that expresses complex object and type information in serialized XML format.

16.1.1 The SOAP Advantage

SOAP is the most widely used protocol for XML-based object serialization. It is the technology of choice for future ubiquitous Web Services. Compared with competing technologies, SOAP has the following advantages:

Strong type support: SOAP defines more than 40 standard data types through XML Schema and allows users to custom-define complex data types. Such sophisticated data-type support makes SOAP a powerful and rich language for exchanging information among today's widely deployed object-oriented systems.

Flexible and ubiquitous messaging: In addition to strong data-type support, SOAP also supports various messaging schemes. Those schemes include synchronous RPC, asynchronous messaging, multicast messaging (subscription), and complex message routes with multiple intermediaries.

Standardization: Since SOAP has gained mainstream support as a Web Services messaging standard, most other Web Services protocols must interoperate or bind with SOAP. For example, WSDL (Web Services Description Language), UDDI (Universal Description, Discovery, and Integration), and most XML registries support SOAP; XML Digital Signature, XML Encryption, SAML (Security Assertion Markup Language), and other secure XML protocols all provide standard binding with SOAP. Each binding protocol provides syntax of its own special element inside SOAP messages. SOAP's full support for XML namespaces has made it easy to bind with other protocols.

Note

The use of SOAP does present bandwidth and CPU/memory overheads for mobile devices. We have to design our systems carefully to make judicial use of SOAP Web Services. We should use it only to interface with external modules or when universal interoperability is a primary concern.

16.1.2 SOAP Hello World

Listing 16.1 is a Hello World SOAP message. Its body contains a single xsd:string type of element (as defined in XML Schema) that can be mapped to a Java String object. Of course, XML Schema defines much more than the string type. Under the xsd namespace, standard XML Schema provides matching types for all Java basic types, array types, and most Java Collection types. It even supports Base64 encoded binary content for binary arrays.

Listing 16.1. A simple SOAP message

<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://www.w3.org/2001/12/soap-envelope"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<SOAP-ENV:Body>
<message xsi:type="xsd:string">Hello World</message>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

SOAP elements can also represent complex custom types. In Listing 16.2, the message element has three string children and an integer child. It corresponds to a complex Java object that has those four data member fields. That object's Java type corresponds to the mytype XML type in the XML Schema.

Listing 16.2. Another simple SOAP message

<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://www.w3.org/2001/12/soap-envelope"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<SOAP-ENV:Body>
<message xsi:type="mytype">
<from xsi:type="xsd:string">Bob</from>
<to xsi:type="xsd:string">Alice</to>
<mesg xsi:type="xsd:string">Hello World</mesg>
<seqId xsi:type="xsd:int">1</seqId>
</message>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

16.1.3 Architecture of SOAP Web Services

As an infrastructure solution, Web Services is touted as self-contained, automatically discovered, and automatically configured reusable software components. Web Services is much more than SOAPwhich only serves to provide a platform-independent transport layer. Figure 16.1 illustrates the overall architecture of Web Services.

Each Web Service makes a description of its service available as a WSDL document. The WSDL describes technical details on how to access the service. Authorized remote clients can download the WSDL file and generate a stub that matches the SOAP service interface. Any RPC method in a Java stub can be called from clientside Java applications as if it were a local method. All leading Web Services toolkits provide WSDL-to-stub code generators.

Web Services register themselves with central registry databases such as the UDDI registry. The client searches the UDDI, finds out the service it needs, fetches the WSDL file, generates the stub, and starts calling remote methods.