لطفا منتظر باشید ...
11.1 Web Services Architecture
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 documenta
messageover 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.
