WSDL:
The Web Services Description Language (WSDL)
and Universal Description, Discovery, and Integration (UDDI), along with SOAP,
form the essential building blocks for Web Services. Each one, taken
separately, serves its own particular purposes.
Basic
WSDL Syntax:
WSDL documents use the following elements:
•
definitions.
Associates the Web Service with its namespaces.
•
types. A
container for data type definitions, typically using a XML Schema
Definition (XSD) or possibly some other type
system.
•
message.
An abstract, typed definition of the data contained in the message.
•
operation.
An abstract description of an action that the Web Service supports.
•
portType.
The set of operations supported by one or more endpoints.
•
binding.
A specification of the protocol and data format for a particular portType.
•
port. An
endpoint, defined in terms of a binding and its network address (typically a
URL). This is not a TCP/IP port, which is represented by a number.
•
service.
A collection of related endpoints.
Example:
<?xml version=‖1.0‖?>
<definitions name=‖MyService‖
targetNamespace=‖http://mySite.com/myService.wsdl‖
xmlns:tns=‖http://mySite.com/myService.wsdl‖
xmlns:xsd1=‖http://mySite.com/myService.xsd‖
xmlns:soap=‖http://schemas.xmlsoap.org/wsdl/soap/‖
xmlns=‖http://schemas.xmlsoap.org/wsdl/‖>
<import namespace=‖http:/mySite.com/myService/schemas‖
location=‖http:// mySite.com/myService/myNameSpace.xsd‖/>
<types>
<schema
targetNamespace=‖http://mySite.com/myService.xsd‖
xmlns=‖http://www.w3.org/2000/10/XMLSchema‖>
<element name=‖MyRequest‖>
...
</element>
</schema>
</types>
<message name=‖GetMyInput‖>
<part name=‖body‖ element=‖xsd1:MyRequest‖/>
</message>
<message name=‖GetMyOutput‖>
<part name=‖body‖ element=‖xsd1:myParameter‖/>
</message>
<portType name=‖MyServicePortType‖>
<operation name=‖MyMethod‖>
<input message=‖tns:GetMyInput‖/>
<output message=‖tns:GetMyOutput‖/>
</operation>
</portType>
<binding name=‖MyServiceSoapBinding‖
type=‖tns:MyServicePortType‖> <soap:binding style=‖document‖
transport=‖http://schemas.xmlsoap.org/soap/http‖/>
<operation name=‖MyMethod‖>
<soap:operation
soapAction=‖http://mySite.com/MyMethod‖/>
<input>
<soap:body use=‖literal‖/>
</input>
<output>
<soap:body use=‖literal‖/>
</output>
</operation>
</binding>
<service name=‖MyService‖>
<documentation>My first
service</documentation>
<port name=‖MyServicePort‖
binding=‖tns:MyServiceBinding‖> <soap:address
location=‖http://mySite.com/myService‖/>
</port>
</service>
</definitions>
The types Element:
Thetypeselementcontainsdatatypedefinitionsthatarerequiredbythemessages
describedintheWSDLdocument:
<types> <schematargetNamespace=‖http://mySite.com/myService.xsd‖
xmlns=‖http://www.w3.org/2000/10/XMLSchema‖> <elementname=‖MyRequest‖>
...
</element>
</schema>
</types>
The
message and portType Elements:
Within the definitions element is one or more
message elements:
<message name=‖GetMyInput‖>
<part name=‖body‖ element=‖xsd1:MyRequest‖/>
</message>
<message name=‖GetMyOutput‖>
<part name=‖body‖ element=‖xsd1:myParameter‖/>
</message>
SOAP
Binding:
When using WSDL documents to describe Web
Services that will exchange SOAP mes-sages (that is, SOAP endpoints), you need
to have a way to indicate within the WSDL document all the necessary
information about the SOAP messages that will be exchanged. WSDL uses
extensibility elements to provide this information. The SOAP binding that is
provided with WSDL supplies the following information:
• An indication that the WSDL binding is bound to
the SOAP protocol.
• How to specify the address for the SOAP
endpoints.
• For the HTTP binding of SOAP, the URI for the
SOAPAction HTTP header
• A list of definitions for all Header elements
in the SOAP Envelope.
• A way of specifying SOAP roots in XSD.
The
service Element:
The service element represents a collection of
port elements, where each port repre- sents the availability of a binding at a
particular endpoint:
<service name=‖MyService‖>
<documentation>My first
service</documentation>
<port name=‖MyServicePort‖
binding=‖tns:MyServiceBinding‖> <soap:address
location=‖http://mySite.com/myService‖/>
</port>
</service>
The binding attribute of the port element ties
it to the corresponding binding element defined previously.
The
documentation Element:
You should also notice the documentation child element of the
preceding service ele- ment. This element essentially allows you to provide a
human-readable comment and is allowed in every other element as well.
The
import Element
The import element is an optional element that
allows you to break up a WSDL document into multiple documents. When present,
it must immediately follow the definitions element. The following example
imports a schema, but it is possible to import any WSDL elements, including the
definitions element, essentially allowing you to import
an entire WSDL document:
<import
namespace=‖http:/mySite.com/myService/schemas‖ location=‖http://
mySite.com/myService/mySchema.xsd‖/>
The import element is particularly useful for
breaking up a WSDL document into inter- face and implementation documents.
soap:binding,
soap:operation, soap:header, and soap:body
The following example shows a SOAP binding of a
request/response operation over
HTTP:
<binding name=‖MyServiceSoapBinding‖
type=‖tns:MyServicePortType‖> <soap:binding style=‖rpc‖
transport=‖http://schemas.xmlsoap.org/soap/http‖ />
<operation name=‖MyMethod‖>
<soap:operation
SOAPAction=‖http://mySite.com/MyMethod‖ style=‖rpc‖ />
<input>
<soap:body use=‖encoded‖
namespace=‖http://mySite.com/myService‖
encodingStyle=‖http://schemas.xmlsoap.org/soap/encoding/‖ /> <soap:header
message=‖tns:MyMethod‖ part=‖MyHeader‖ use=‖literal‖/>
</input>
<output>
<soap:body use=‖encoded‖
namespace=‖http://mySite.com/myService‖ encodingStyle=‖http://schemas.xmlsoap.org/soap/encoding/‖
/>
</output>
</operation>
</binding>
Note that the style attribute of the
soap:binding element is set to rpc. In the case of a one-way operation over
SMTP, for example, the style attribute would have a value of document (and
document is the default if the attribute is omitted). The transport attribute
(here, set to the URI of the HTTP binding in the SOAP specification) indicates
to which transport of SOAP this binding corresponds.
soap:address, soap:fault, and soap:headerfault
There are a few additional elements in the SOAP binding worth
mentioning. First, the soap:address element simply assigns a URI to a port:
<service name=‖MyService‖>
<port name=‖MyServicePort‖
binding=‖tns:MyServiceBinding‖> <soap:address
location=‖http://www.mySite.com/MyServiceURL/‖ />
</port>
</service>
The soap:fault element specifies the contents
of the SOAP Fault element:
<fault>
<soap:fault name=‖MyFault‖ use=‖encoded‖
encodingStyle=‖http://schemas.xmlsoap.org/soap/encoding/‖
<http://schemas.xmlsoap.org/soap/encoding/>/>
</fault>
Finally, the soap:headerfault element follows
the syntax of the soap:fault element but refers to SOAP Fault in Header
elements.
WSDL
Implementations:
Because WSDL is a bridge technology in the
sense that it bridges SOAP and UDDI, you‘re unlikely to find a WSDL toolkit
that stands by itself. The two most popular WSDL implementations, therefore,
are parts of other toolkits:
• The Microsoft SOAP Toolkit. This toolkit,
covered in depth in Chapter 15, is primarily aimed at developers who want to
work with SOAP in a Microsoft environment, although it does support
Microsoft‘s UDDI implementation.
• The IBM Web Services Toolkit (WSTK). This
toolkit provides WSDL support, several security enhancements, UDDI integration,
and support for the IBM WebSphere application server. The WSTK also includes
the open-source Web Services Description Language for Java Toolkit (WSDL4J)
Demo
Client Application MyClass.java
public class MyClass
{
public int
MyMethod (String arg)
{
return 47;
}
public static void main ( String[] args )
{
System.out.println( ―output‖ );
}
}
Introduction
to UDDI:
If WSDL is The Empire Strikes Back, then UDDI
is The Return of the Jedi, concluding the chapters on Web Services. Universal
Description, Discovery, and Integration (UDDI) is a platform-independent, open
framework for describing services, discovering businesses, and integrating
business services using the Internet as well as public registries of Web
Services designed to store information about businesses and the services they
offer. UDDI is also a specification for building such registries as well as an
application programming interface (API) that exposes the functionality of the
registries. Fundamentally, UDDI provides for the publication and discovery of
Web Services, which are the key functional components of the Service-Oriented
Architecture explained in Chapter 14,
―Architecting Web Services.‖
The UDDI Consortium, established by hundreds of
companies, emerged in response to a series of challenges posed by the new Web
Services model. These challenges included the following:
•
How do
you discover Web Services?
•
How
should information about Web Services be categorized?
•
How do
you handle the global nature of Web Services? How do you provide for
localization?
•
How can
interoperability be provided, both in the discovery and invocation mechanisms?
•
How can
you interact with the discovery and invocation mechanisms at runtime?
For UDDI to provide the foundation for Web
Services registries, therefore, it had to serve two primary roles within the
Web Services model: Service publication and service discovery).
The rest of this chapter addresses how UDDI‘s
publication and discovery capabilities operate as well as how UDDI addresses
the listed challenges.
UDDI
Basics:
Public UDDI registries are hosted by operator
nodes, which are companies such as Microsoft and IBM that have committed to
running public UDDI nodes. The public reg- istry system is loosely modeled
after the Domain Name Service (DNS) system, in that there are multiple registries
responsible for synchronizing their data with each other. Currently, each
public UDDI node synchronizes with the others daily, but a more fre- quent
schedule is in the works.
Likewise, as is the case with the DNS system,
UDDI registries are not repositories of data; rather, in their roles as
registries, they simply provide information on how to find and invoke Web
Services. Just as the DNS system provides for unique domain names,
UDDI relies on globally unique identifiers
(GUIDs), which are URNs that uniquely iden- tify the resources in each
registry.
There are three levels of information available in each UDDI
registry, which correspond roughly to the features of a phone book:
• White pages. These pages provide listings of
companies that can be queried by name, text description, contact information,
and known identifiers (like Dun and Bradstreet‘s DUNS numbers).
• Yellow pages. These pages allow for the looking
up of companies by the kind of services they offer, organized into established
business categories (industry codes, location, and products and services).
These categories are organized into taxonomies.
• Green pages. These pages provide information about how to interact with compa- nies‘ Web Services by exposing service descriptions and binding information.
The
Structure of UDDI:
The XML schema that provides the structure of
UDDI defines four core types of infor-mation in a UDDI registry, as shown in
Figure.
• Business information. Provided by the
businessEntity element. The
businessEntity element supports the ―white
pages‖ and ―yellow pages‖ taxonomies, allowing for structured information about
companies. This element is the top-level information manager for the
information in the registry about a particular business.
•
Service
information. Provided by the businessService element. This element supports the
―green pages‖ functionality. The business Service structure contains a group of
Web Services related to a category of services or possibly a business process.
Each businessService element contains one or more technical Web Services
descriptions, which describe how to find and bind to each of the Web Services.
•
Binding
information. Provided by the bindingTemplate element, which is the element
contained within the businessService element that provides the information
needed to bind to and invoke a Web Service.‖
•
Specifications
for services. Enclosed within each bindingTemplate element are special elements
that list references to information about specifications for services. These elements,
called tModel elements (from ―technical models‖), are metadata about each
specification, providing information on a specification‘s name, publishing
organizations, and URLs to the specifications themselves. T Model elements have
several uses within a UDDI registry, in particular, representing technical
specifications for wire protocols (such as SOAP), interchange formats (WSDL),
and sequencing rules. Each specification registered as a tModel in a UDDI
registry receives a unique GUID.
T Model
Structure;
Understanding tModel elements is critical to
understanding how UDDI works, because they form the basis of how UDDI deals
with the meaning of the various specifications it deals with. The concept of a
tModel is necessarily somewhat nebulous, because tModel elements consist of
metadata (data about data). tModel elements provide a reference sys- tem for
UDDI registries that is based on abstraction (in other words, a tModel can
define just about anything).
The primary use for tModel elements within UDDI is to represent a technical specifica-tion for example, wire protocols (such as SOAP), interchange formats, and the like. When two parties wish to communicate using a particular specification, they must share a mutually agreed on technical identity for the specification they share. This technical identity can be registered in a tModel. Once such a specification is uniquely defined in this way, other parties can refer to it by referring to its unique tModel identifier, which is called a tModelKey. tModelKey elements act as ―technical fingerprints‖ that uniquely designate individual specifications.‖.
•
The
other main use for tModel elements supports how UDDI handles its search
capabil-ity. Searching, of course, is an essential part of UDDI‘s ―find‖
capability. Searching is provided for in UDDI with the use of two structures:
identifierBag and categoryBag. The identifierBag structure defines
organizational identity. It consists of name/value pairs that record and define
identification numbers—for example, ―DUNS number 12345‖ or ―SS# 987-65-4321.‖
The categoryBag elements, on the other hand, are name/value pairs that
correlate specific taxonomy information—for example, ―Florists 45311‖ (from the
NAICS taxonomy), ―Massachusetts US-MA‖ (from the ISO 3166 Geographic Taxonomy),
or ―Boston 516499‖ (from the GeoWeb taxonomy). A particular florist in Boston,
Massachusetts would possess all three of these categoryBag elements, as well as
each identifier‘s supercategories. The tModel, then, is used to correlate
different levels of these hierarchies—for example, to express the relationship
that Boston is within Massachusetts, or that florists are retailers.
Publishing
and Finding WSDL Descriptions in a UDDI Registry:
In order to understand how UDDI uses WSDL as a
description language, you must be clear on how WSDL documents are mapped to the
UDDI structure. As discussed earlier, WSDL documents can be organized as
service implementation and service interface documents. The service
implementation document maps to the UDDI businessService element, whereas the
service interface document maps to the tModel elements, as shown in Figure‖.
The first step in publishing a WSDL description
in a UDDI registry is publishing the ser vice interface as a tModel in the
registry. Here are the steps to follow to create the appropriate tModel:
1. Set the name field of the tModel to the
targetNamespace attribute of the definitions element in the interface document.
This field is used to locate the appropriate tModel.
2. The description field of the tModel corresponds
to the documentation elementof the interface document. This field can have a
maximum of 256 characters.
3. Set the overviewURL field of the tModel to the
URL and binding specification in the interface document.
Set the categoryBag field of the tModel so that its keyed reference
is uddi org:types and its keyValue is wsdlSpec. This defines the UDDI entry as
a WSDL service interface definition.
tModel.xml—A
tModel Created from a WSDL Service Interface
<?xml version=‖1.0‖?> <tModel
tModelKey=‖‖>
<name>http://www.myclassservice.com/MyClass-interface</name>
<description xml:lang=‖en‖>
Service interface definition for our demo
Service. </description>
<overviewDoc>
<description xml:lang=‖en‖>
WSDL Service Interface Document </description>
<overviewURL>
http://www.myclassservice.com/MyClass- interface#MyClass_ServiceBinding
</overviewURL>
</overviewDoc>
<categoryBag>
<keyedReference
tModelKey=‖UUID:C1ACF26D-9672-4404-9D70-889DFDA9D9F8‖ keyName=‖uddi-org:types‖
keyValue=‖wsdlSpec‖/>
<keyedReference
tModelKey=‖UUID:DB77450D-9FA8-45D4-A7BC-9C8C7D998F8D‖ keyName=‖Sample Web
Service‖
keyValue=‖12345678‖/>
</categoryBag>
</tModel>
Next, we must create the businessService and
bindingTemplate elements that corre- spond to the WSDL service implementation
document shown in Listing 16.2. The businessService has the following fields.‖:
• The name field of the businessService is set to
the name attribute of the service element in the implementation document.
• The description field of the businessService
comes from the documentation element in the implementation document. The
bindingTemplate has the following fields:
•
The
description field of the bindingTemplate comes from the first 256 characters of
the documentation element of the port element, if it exists.
• The accessPoint field is set to the value of
the location attribute of the extension element that is associated with the
port element, in the case of a SOAP or HTTP binding.
• The bindingTemplate contains one t Model
Instance Info field for each t Model it
references.
• The overviewURL field directly references the
service implementation document;
however, it is only used to provide human
readability.
<businessService businessKey=‖...‖
serviceKey=‖...‖>
<name>MyClass_Service</name>
<description xml:lang=‖en‖>
IBM WSTK V2.4 generated service definition file
</description>
.
<bindingTemplates>
<bindingTemplate bindingKey=‖...‖
serviceKey=‖...‖>
<description></description>
<accessPoint URLType=‖http‖>
http://localhost:8080/soap/servlet/rpcrouter </accessPoint>
<tModelInstanceDetails>
<tModelInstanceInfo tModelKey=‖[tModel Key
for Service Interface]‖>
<instanceDetails>
<overviewURL>
http://localhost:8080/wsdl/MyClass_Service-interface.wsdl </overviewURL>
</instanceDetails>
</tModelInstanceInfo>
</tModelInstanceDetails>
</bindingTemplate>
</bindingTemplates>
<categoryBag>
<keyedReference
tModelKey=‖UUID:DB77450D-9FA8-45D4-A7BC-3663DA8D8CFB‖ keyName=‖Sample Web
Service‖
keyValue=‖84121801‖/>
</categoryBag>
</businessService>
UDDI
Invocation Model:
Now that we can build a business Service and
its various elements, let‘s step through the process for using a UDDI registry
to find and invoke a Web Service.‖:
1. You use the UDDI business registry to locate
the business Entity information that was previously published by a company
advertising a Web Service.
2. You either request more specific information
about the business Service or request the entire business Entity structure.
This structure contains the relevant
Binding Template information needed to connect
to the service. You put this binding information into a cache.
3. You refer to the tModel key information in the
binding Template to obtain relevant information on the specifications needed to
invoke the desired Web Service, and you use this information to write the
program that will access the service.
4. The program invokes the Web Service using the
binding Template information that has been cached.
5. If the call to the Web Service fails, refresh
the binding Template information. If the new call succeeds, refresh the cache.
Otherwise, keep trying.
By using cached binding information and taking
a ―retry on failure‖ approach, the UDDI registry infrastructure is not burdened
by unnecessary calls but rather allows for seamless operation when binding
information changes. This approach to scalability is quite similar to the way
the DNS system works.‖
Related Topics
Privacy Policy, Terms and Conditions, DMCA Policy and Compliant
Copyright © 2018-2023 BrainKart.com; All Rights Reserved. Developed by Therithal info, Chennai.