WSDL
How does a client know what format to use in making a
request to a service? For that matter, how do the client and the service know
what the request means? The answers to these questions are provided by
information in an XML document, called a WSDL document, that contains a
description of the web service's interface. A WSDL document contains
information specified in Web Service Description Language (WSDL), as defined in the WSDL specification. WSDL defines an XML
schema for describing a web service. To uncover the description for a Web
service, a client needs to find the service's WSDL document. One way, perhaps
the most typical way, to do this is for the client to find a pointer to the
WSDL document in the web service's registration, which can be in aUDDI registry
or an ebXML registry/repository. A typical scenario is that a business
registers its service. The registry entry includes a pointer to a WSDL file
that contains the WSDL document for the service. Another business searches the
registry and finds the service. A programmer uses the interface information in
the WSDL document to construct the appropriate calls to the service.
A WSDL document describes a web service as a collection of
abstract items called "ports" or "endpoints." A WSDL
document also defines the actions performed by a web service and the data
transmitted to these actions in an abstract way. Actions are represented by
"operations," and data is represented by "messages." A
collection of related operations is known as a "port type." A port
type constitutes the collection of actions offered by a web service. What turns
a WSDL description from abstract to concrete is a "binding." A
binding specifies the network protocol and message format specifications for a
particular port type. A port is defined by associating a network address with a
binding. If a client locates a WSDL document and finds the binding and network
address for each port, it can call the service's operations according to the
specified protocol and message format.
Here, for example, is a WSDL
document for an online book search service. Notice in the example that the WSDL
document specifies one operation for the service:
getBooks:
<operation
name="getBooks" ...
|
The input message for the operation, BookSearchInput contains a string value named isbn:
<complexType>
<all>
<element name="isbn"
type="string"/>
</all>
|
The output message for the operation, BookSearchOutput returns a string value named title:
<complexType>
<all>
<element name="title"
type="string"/>
</all>
|
Notice too that the WSDL document
specifies a SOAP protocol binding. The style attribute in the binding element
specifies that the receiver should interpret the payload in the SOAP message as
an RPC method call:
<soap:binding
transport="transport=http://schemas.xmlsoap.org/soap/http"
style="rpc"/>
Alternatively,
the style attribute in a
bindingelement could specify "document".
In that case, a complete document (typically
an XML document) would be exchanged in the call. In fact, the document style of
binding is more typical of services in an SOA. One of the advantages of passing
an XML document to a service instead of an RPC-style message is that it tends
to be easier to validate and to apply business rules.
SOAP
Though agreeing
on the meaning and structure of XML tags makes the use of XML an effective way
to exchange data, it's not sufficient for data interchange over the Web. For
instance, you still need some agreed-upon protocol for formatting an XML
document so that the receiver understands what the main, "payload,"
part of the message is, and what part contains additional instructions or
supplemental content. That's where Simple Object
Access Protocol (SOAP) comes in. SOAP is an XML-based protocol
for exchanging information in a distributed environment. SOAP provides a common
message format for exchanging data between clients and services. The basic item
of transmission in SOAP is a SOAP message, which consists of a mandatory SOAP
envelope, an optional SOAP header, and a mandatory SOAP body. The envelope
specifies two things: an XML namespace and an encoding style. The XML namespace
specifies the names that can be used in the SOAP message. Namespaces are
designed to avoid name clashes -- the same name can be used for different
items, provided that the names are in different namespaces. The encoding style
identifies the data types recognized by the SOAP message. If a header is
provided, it extends the SOAP message in a modular way. It's important to
understand that as a SOAP message travels from a client to a service, it can
pass through a set of intermediate nodes along the message path. Each node is
an application that can receive and forward SOAP messages. An intermediate node
can provide additional services such as transform the data in the message or
perform security-related operations. The SOAP header can be used to indicate
some additional processing at an intermediate node, that is, processing
independent of the processing done at the final destination. Typically, the
SOAP header is used to convey security-related information to be processed by
runtime components. The body contains the main part of the SOAP message, that
is, the part intended for the final recipient of the SOAP message.
Here's an example of a SOAP message designed to retrieve the
price of a book. Notice the <SOAP-ENV:
Envelope>, <SOAP-ENV:Header> and <SOAP-ENV: Body> elements that mark the envelope, header, and body parts of the SOAP
message, respectively. The attribute value must Understand=1 in the header means that the receiver of the SOAP
message must process it.
<SOAP-ENV: Envelope
xmlns:SOAP-ENV=
"http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:
encodingStyle=
"http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Header>
<t:Transaction
xmlns:t="some-URI">
SOAP-ENV:mustUnderstand="1">
</t:Transaction>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<m:GetBookPrice
xmlns:m="some-URI">
<title>My Life and
Times</title>
<author>Felix
Harrison</author>
</m: GetBookPrice>
</SOAP-ENV:Body>
</SOAP-Envelope>
|
A related standard, SOAP Messages With Attachments, specifies the format of a SOAP message that includes attachments (such as, images). SOAP messages (with or without attachments) are independent of any operating system or platform and can be transported using a variety of communication protocols, such as HTTP or SMTP. WS-I Basic Profile 1.0 references SOAP 1.1.
UDDI
:
As mentioned earlier, an SOA can also include a service that
provides a directory or registry of services. But how can a service be
described in a registry so that a program looking for that service can easily
find it and understand what it does? The Universal Description, Discovery,
and Integration (UDDI) specifications define how to publish and discover
information about services in a UDDI-conforming registry. More specifically,
the specifications define a UDDI schema and a UDDI API. The UDDI schema
identifies the types of XML data structures that comprise an entry in the
registry for a service. Think of a UDDI registry as a "Yellow Pages" for
web services. Like the Yellow Pages directory for phone numbers, a UDDI
registry provides information about a service such as the name of the service,
a brief description of what it does, an address where the service can be
accessed, and a description of the interface for accessing the service. The
accompanying figure illustrates the schema. It shows the five types of XML data
structures that comprise a registration.
Here is an
example that shows part of a complete BusinessEntity structure for a
hypothetical company named BooksToGo. The company provides various web
services, including an online book ordering service.
<businessEntity
businessKey="35AF7F00-1419-11D6-A0DC-000C0E00ACDD"
authorizedName="0100002CAL"
operator="www-3.ibm.com/services/uddi">
<name>BooksToGo</name>
<description
xml:lang="en">
The source for all professional books
</description>
<contacts>
<contact>
<personName>Benjamin
Boss</personName>
<phone>
(877)1111111
</phone>
</contact>
</contacts>
|
The API
describes the SOAP messages that are used to publish an entry in a registry, or
discover an entry in a registry. Here, for example, is a message that searches
for all business entities in a registry whose name begins with the characters
"Books":
<find_business generic="2.0"
xmlns=um:uddi-org:api-v2">
<name>Books%</name>
</find_business>
|
For Oracle online training classes please contact : training@virtualnuggets.com
No comments:
Post a Comment