The eXtended Markup Language (XML) is the lingua franca of Web services (and many other technologies); it serves as the base language for type definition, service description, data format, data transfer, messaging, discovery, security, and so on. Web services requesters and providers exchange information using XML documents, which are formatted according to either XML Document Type Definition (DTD) rules or XML schema rules (XSD).

As briefly described in Chapter 8, XML Schema Definition (XSD) is a W3C recommendation, an alternative to DTD, for describing the structure, content, and semantics of XML documents, thereby allowing all parties involved to have a common and exact understanding of the document in question. The XSD defines which elements the document may contain, their attributes, and their relationship. Because XML does not come with predefined tags, the role of XML namespaces and XML schemas is integral for a shared understanding of the document.

An XML document contains:

<element>
  <subelement>
    <field1>.....</field1>
  </subelement>
</element>

Here is a basic XML document representing an address:

<?xml version="1.0" encoding="ISO-8859-1" standalone="yes"?>
<! This is a comment -->
<Address
      xmlns=http://www.basicxml.org/AddressDoc
      xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
      xsi:schemaLocation=
          "http://www.basicxml.org/AddressDoc
            file:./AddressDoc.xsd">
      <Street> 24 Benin Drive</Street>
       <City> San Francisco </City>
      <State> California</State>
      <Country>USA</Country>
</Address      

XML defines simple types, such as string, Base64Binary, hexBi-nary, integer, date, positiveInteger, genativeInteger, nonNegatveInteger, nonPositiveInteger, decimal, boolean, time, dateTime, duration, date, Name, QNane, anyURI, ID, IDREF, and so on.

XML allows user-defined complex types such as the following:

<complexType name"myComplexType">
<sequence>
<element name="tname" type="string" minOccurs="0"/>
<element name="description" type="string"  minOccurs="0"/>
...
</sequence>
<attribute name="objid" type="ID"/>
<attribute name="objref" type="IDREF"/>
</complexType>

See Chapter 15 for more information.

XML documents can be processed and consumed directly by an application as a character stream or serialized and parsed by XML serializers and parsers (e.g., DOM, SAX, StAX).

XML documents can also be displayed using XSL and XSL transformers (XSLT) and style sheets. There is a whole range of XML standards, APIs, tools, editors, and utilities. However, their coverage is beyond the scope of this book. There are tons of online resources, tutorials, and FAQs about XML, such as the following:

The Web Services Description Language (WSDL) is an XML language, based on a general-purpose XML schema, for describing how to access a service, including:

A WSDL structure is made up of two substructures: a service interface definition and a service implementation definition. The service interface definition contains initially an implementation neutral (abstract or reusable) of the service that will be instantiated by the service implementation and includes messages, types, port type, and binding.

Do you have to learn how to write WSDL? Remember, “Things should be made as simple as possible.” The WSDL is generated for each service by the Web services framework when you deploy or publish the service (see Chapter 15). As depicted in Figure 14.2, the requester retrieves the WSDL from a registry (see UDDI later) but could also find/receive it by other means; it then interacts with the service, either via a dynamic invocation (remember the old-time CORBA DII?) or more commonly via a static client or proxy. The other good news is that you don’t have to code against the WSDL, because the Web services framework generates the Web service client (also called proxy) corresponding to your platform (e.g., Java client, .Net client), which shields you from SOAP/WSDL programming.

The following listing is a fragment of the WSDL generated for the Google Spell Check Web Service (see a complete demo in Chapter 16):

 <definitions name="GoogleSearch"
targetNamespace="urn:GoogleSearch"
 ...
  <types>
    <xsd:schema
         xmlns="http://www.w3.org/2001/XMLSchema"
         targetNamespace="urn:GoogleSearch">
    <xsd:complexType name="GoogleSearchResult">
    <xsd:complexType name="ResultElement">
...
    </xsd:schema>
  </types>

  <message name="doSpellingSuggestion">
    <part name="key" type="xsd:string" />
    <part name="phrase" type="xsd:string" />
  </message>
  <message  name="doSpellingSuggestionResponse">

   portType name="GoogleSearchPort">
     <operation name="doSpellingSuggestion">
      <input message="typens:doSpellingSuggestion" />
      <output message="typens:doSpellingSuggestionResponse" /
>
    </operation>
  </portType >

  <binding  name="GoogleSearchBinding"
type="typens:GoogleSearchPort">
      <soap:binding style="rpc"
transport="http://schemas.xmlsoap.org/soap/http" />
    <operation name="doSpellingSuggestion"></operation>
  </binding>

  <service  name="GoogleSearchService">
    <port name="GoogleSearchPort"
     binding="typens:GoogleSearchBinding">
      <soap:address location="http://api.google.com/search/
beta2" />
    </port>
   </service >

</definitions>

A Web service can be assembled from an existing WSDL, using a top-down approach. See Chapter 5 of the Oracle Application Server 10.1.3 Web Services Developer’s Guide. Database Web services start from database functionality and correspond therefore to the bottom-up approach. Also, WSDL specifications versions (1.1, 1.2) are not covered but can be seen at the following Web sites:

The Simple Object Access Protocol (SOAP) is a simple, lightweight, XML-based RPC protocol, which defines a common shape as well as the processing rules for messages exchanged between objects (remember old-time IIOP?). SOAP enables Web services interoperability by providing XML messaging, which is transport neutral (e.g., HTTP/HTTPS, FTP, SMTP, Messaging Protocols, RPC, BEEP); implementation language neutral (e.g., Java, C/ C++, C#, J#, JScript, Perl, VB, PL/SQL, SQL), and platform neutral (e.g., Java, .NET).

As depicted by Figure 14.3, a SOAP message is represented as a SOAP envelope, which contains an optional header (i.e., SOAP header) and a mandatory body (i.e., SOAP body).

Figure 14.3. SOAP Envelope

The following code is a fragment of a SOAP message sent to the Google Spell Check Web Service (see Chapter 16):

<?xml version="1.0" encoding="UTF-8" ?>
<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:Body>
    <ns1:doSpellingSuggestion
      xmlns:ns1="urn:GoogleSearch"

      SOAP-ENV:encodingStyle=
           "http://schemas.xmlsoap.org/soap/encoding/">
    <key
xsi:type="xsd:string">00000000000000000000000000000000</key>
    <phrase xsi:type="xsd:string">Nelson Mandelo</phrase>
    </ns1:doSpellingSuggestion>
    </SOAP-ENV:Body>
  </SOAP-ENV:Envelope>

The SOAP messages can be transmitted either synchronously or asynchronously using either a Remote Procedure Call (RPC) or document messaging style:

The physical representation (i.e., the wire format) of the SOAP messages exchanged between the service requester and the service provider is controlled by settings in the WSDL, particularly the value of the use attribute of the WSDL binding, which specifies the encoding styles of the message:^[2]

SOAP is by no contest the standard XML messaging technology for Web services. However, the Representational State Transfer (REST) is an alternative XML messaging technology being adopted by Web retailers such as Yahoo, Amazon, and Google for online shopping and search applications. REST Web services use XML documents directly as message payload, instead of SOAP envelopes and HTTP GET/POST and XML to share URIs between distributed applications; the applications or end users perform state transitions (navigate following links), and the next state (next page) is transferred to the application or end user (and rendered). REST is not a standard, but rather an architectural style; however, it is based on standards such as HTTP, URL, XML/HTML/GIF/JPEG, and MIME types (e.g., text/xml, text/html, image/gif, image/jpeg). Products such as Oracle Application Server 10.1.3 support REST with the literal encoding style (use=literal).

The Universal Description Discovery and Integration (UDDI) is an industry standard (supervised by OASIS) for publishing and locating Web services and their descriptions (dynamic discovery) in registries. UDDI also designates a collection of peer directories, known as UDDI Business Registries (UBR), which host information about businesses and their services.

The UDDI specification includes:

Browse the following links for more UDDI resources:

www.oasis-open.org
www.uddi.org
www.uddi4j.org

Throughout this section, we have seen that Web services are standards-based, XML centric, platform independent, programming language neutral, self-contained, self-describing, and self-advertising software modules allowing application-to-application interaction over the Web.^[3] Let’s revisit Figure 14.2 to see how the core Web services technologies (i.e., SOAP, WSDL, UDDI) come into play:

All interactions are SOAP message based. This concludes a high-level “tour d’horizon” of the base technologies that enable Web services, and invokes operations on the services, but while you can publish and deploy Web services using the base technologies, you will rapidly be confronted with solving the usual enterprise deployment requirements of security, reliability, manageability, and so on—and this time with a new dimension: the Web! In order to address these requirements, a set of new Web services–related specifications, recommendations, de facto standards, APIs, and component models are being consolidated into the SOA, which is our next topic.