11.1 Web Services Architecture | Oracle Application Server 10g Essentials

A well-documented architecture is central to interoperability. From a simplistic viewpoint, the Web Services architecture consists of a client that sends a request in the form of an XML document ”a message ”over a network to a server that hosts a Web Service. The hosted Web Service processes the request and returns the result as an XML document to the client, as shown in Figure 11-1.

Figure 11-1. A Web Service client and service interaction

In many ways, especially when HTTP is used as the transport, this process is similar to a person using a web browser to look at a dynamically generated HTML page, except that it is a computer requesting the result, not a human being. A Web Service client can be a database stored procedure, a servlet or EJB in an application server, a Java client application, or another Web Service, to name just a few possibilities.

From this simplistic explanation you may have noted that a Web Service requires:

A method call in the form of a function or procedure to act as the service
A standardized encoding to ensure that both the client and the service understand the format of the data
A standardized protocol for transporting the serialized data

But how do you know that a particular Web Service even exists? And if you do know that it exists, what are its specifications? These requirements are addressed using a layered architecture, as shown in Figure 11-2 and described in the sections that follow.

Figure 11-2. Web Services architecture stack

11.1.1 Service

For Web Services, the actual service provided can be written in any programming language that has a Web Services implementation, or that can create valid XML documents and stream them to and from a network. Nowadays, that's just about every commonly used programming language. For example, you can use a simple Java class with a function, as in Example 11-1.

Example 11-1. A sample service method written in Java

 public class Stateless {         public Stateless( ) {}         public String sayHello(String param) {                 return "Hello " + param + "!";         } }

The method sayHello( ) returns a String in which the passed parameter is prefixed with the word Hello , and then returned.

11.1.2 Encoding

For both the Web Service requester and provider to understand a conversation, they need to use an agreed-upon vocabulary and syntax. This is where the XML becomes useful. Two popular encoding standards exist: XML-RPC and SOAP. Example 11-2 shows a SOAP-encoded request to execute the sayHello( ) service method from Example 11-1.

Example 11-2. A sample sayHello( ) SOAP request

 <?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/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/ XMLSchema"> <SOAP-ENV:Body> <ns1:  sayHello  xmlns:ns1="urn:test-Stateless" SOAP-ENV:encodingStyle="http://schemas. xmlsoap.org/soap/encoding/"> <  param0  xsi:type="xsd:string">  Don  </param0> </ns1:sayHello> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

Example 11-3 shows the response to the SOAP request in Example 11-2. It may seem that a lot of XML is required just to call a function, but this well-thought-out encoding scheme ensures that a Web Service can exchange any type of data.

Example 11-3. A sample sayHello( ) SOAP response

 <?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/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/ XMLSchema"> <SOAP-ENV:Body> <ns1:sayHelloResponse xmlns:ns1="urn:test-Stateless" SOAP-ENV:encodingStyle="http:// schemas.xmlsoap.org/soap/encoding/"> <  return  xsi:type="xsd:string">  Hello Don!  </return> </ns1:sayHelloResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

11.1.3 Transport

A transport protocol is used to send a request across a network to the server and back again to the client program. HyperText Transport Protocol is commonly used as the transport protocol for Web Services. However, it isn't a requirement. Simple Mail Transfer Protocol (SMTP), File Transfer Protocol ( FTP), and, more recently, Blocks Extensible Exchange Protocol (BEEP) may also be used. Which protocol is used is simply a matter of the Web Service implementation's capabilities.

11.1.4 Service Description

A service description is a document on how to access a Web Service. With XML-RPC, this usually consists of a well-written specification in the form of a word processing document. For SOAP, the Web Services Description Language (WSDL), an XML application (vocabulary) can describe SOAP-encoded Web Services in a standardized computer-readable way. Both document types are typically available on the same server as the hosted Web Service. They identify the names of the available services, the encoding used, the transport protocol, and the location of the service. Example 11-4 is a WSDL document for the service in Example 11-1.

Example 11-4. A sample WSDL document

 <?xml version="1.0" encoding="UTF-8" ?>  <definitions name="Stateless" targetNamespace="http://test/Stateless.wsdl" xmlns="http:// schemas.xmlsoap.org/wsdl/" xmlns:tns="http://test/Stateless.wsdl" xmlns:xsd="http://www. w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"> <documentation>WSDL for Service: Stateless, generated by Oracle WSDL toolkit (version: 1. 1)</documentation>  <types> <schema targetNamespace="http://test/Stateless.xsd" xmlns:tns="http://test/Stateless.xsd"  xmlns="http://www.w3.org/2001/XMLSchema" xmlns:xsd="http://www.w3.org/2001/XMLSchema" />  </types> <message name="sayHelloInput"> <part name="  param0  " type="xsd:string" /> </message> <message name="sayHelloOutput"> <part name="  output  " type="xsd:string" /> </message> <portType name="StatelessPortType"> <operation name="  sayHello  "> <input message="tns:sayHelloInput" />  <output message="tns:sayHelloOutput" />  </operation> </portType> <binding name="StatelessBinding" type="tns:StatelessPortType"> <soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="rpc" />  <operation name="sayHello"> <soap:operation soapAction="urn:test-Stateless/sayHello" />  <input> <soap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"  namespace="urn:test-Stateless" />  </input> <output> <soap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"  namespace="urn:test-Stateless" />  </output> </operation> </binding> <service name="Stateless"> <port name="StatelessPort" binding="tns:StatelessBinding"> <soap:address location="http://www.myserver.com:7779/test/Stateless" />  </port> </service> </definitions>

11.1.5 Service Discovery

The top layer of the Web Services architecture is about discovering what Web Services are available. This functionality is currently accomplished with Universal Description, Discovery, and Integration (UDDI). UDDI is a specification for a network directory of available Web Services.