CS835 - Data and Document Representation
& Processing
|
Lecture 10 - Distribution and
Collaboration
|
A WSDL document defines a web service using these major elements:
|
Element |
Defines |
|
<portType> |
The operations performed by the web service |
|
<message> |
The messages used by the web service |
|
<types> |
The data types used by the web service |
|
<binding> |
The communication protocols used by the web service |
The main structure of a WSDL document looks like this:
<definitions> <types> definition of types........ </types> <message> definition of a message.... </message> <portType> definition of a port....... </portType> <binding> definition of a binding.... </binding> </definitions> |
A
WSDL document can contain other elements:
extension elements and service
element that makes it possible to group together the definitions of several web
services in one single WSDL document.
o <portType> element - most important WSDL element
o defines :
o
a web service
o
the operations that can
be performed
o
the messages that are
involved.
o The <portType> element can be compared to a
function library (or a module, or a class) in a traditional programming
language.
o <message> element defines the data elements of an operation.
o Each messages can consist of one or more parts.
o The parts are comparable to the parameters of a
function call in a traditional programming language.
o <types> element defines the data types that are used by the web service.
o WSDL uses XML Schema syntax to define data types.
<binding> element defines the message format and protocol
details for each port.
This
is a simplified fraction of a WSDL document:
<message name="getTermRequest"> <part name="term" type="xs:string"/></message> <message name="getTermResponse"> <part name="value" type="xs:string"/></message><portType name="glossaryTerms"> <operation name="getTerm"> <input message="getTermRequest"/> <output message="getTermResponse"/> </operation></portType> |
portType element defines:
o "glossaryTerms" as the name of a port
o "getTerm" as the name of an operation
getTerm
operation has :
o an input message called
"getTermRequest"
o an output message called
"getTermResponse"
message elements define the parts of each message and
the associated data types.
o glossaryTerms is a like function library
o "getTerm" is a function with
"getTermRequest" as the input parameter
o getTermResponse as the return parameter.
o <portType> element is the most important WSDL element.
o Defines:
o
a web service
o
the operations
that can be performed,
o
the messages
that are involved.
o The port defines the connection point to a web
service.
o Similar to a function library (or a module, or a
class) in a traditional programming language.
o Each operation can be compared to a function in a
traditional programming language.
The
request-response type is the most common operation type, but WSDL
defines four types:
|
Type |
Definition |
|
One-way |
The operation can receive a message but will not return a
response |
|
Request-response |
The operation can receive a request and will return a
response |
|
Solicit-response |
The operation can send a request and will wait for a
response |
|
Notification |
The operation can send a message but will not wait for a
response |
A one-way operation example:
<message name="newTermValues"> <part name="term" type="xs:string"/> <part name="value" type="xs:string"/></message><portType name="glossaryTerms"> <operation name="setTerm"> <input name="newTerm" message="newTermValues"/> </operation></portType > |
o
Port glossaryTerms
defines a one-way operation called "setTerm"
o
"setTerm" operation
allows input of new glossary terms messages using a "newTermValues"
message with the input parameters "term" and "value".
o
No output is defined
for the operation.
A request-response operation example:
<message name="getTermRequest"> <part name="term" type="xs:string"/></message> <message name="getTermResponse"> <part name="value" type="xs:string"/></message><portType name="glossaryTerms"> <operation name="getTerm"> <input message="getTermRequest"/> <output message="getTermResponse"/> </operation></portType> |
o
Port "glossaryTerms"
defines a request-response operation called "getTerm"
o
"getTerm"
operation requires an input message called "getTermRequest" with a
parameter called "term", and will return an output message called
"getTermResponse" with a parameter called "value".
WSDL bindings defines the message format and protocol details for a web service.
A request-response operation example:
<message name="getTermRequest"> <part name="term" type="xs:string"/></message> <message name="getTermResponse"> <part name="value" type="xs:string"/></message><portType name="glossaryTerms"> <operation name="getTerm"> <input message="getTermRequest"/> <output message="getTermResponse"/> </operation></portType><binding type="glossaryTerms" name="b1"><soap:binding style="document"transport="http://schemas.xmlsoap.org/soap/http" /> <operation> <soap:operation soapAction="http://example.com/getTerm"/> <input> <soap:body use="literal"/> </input> <output> <soap:body use="literal"/> </output> </operation></binding> |
o
The binding element
has two attributes - the name attribute and the type attribute.
o
name attribute defines the name of the binding
o
type attribute points to the port for the binding, in this case the
"glossaryTerms" port.
o
soap:binding element has two attributes - the style attribute and
the transport attribute.
o
The style attribute can
be "rpc" or "document".
o
The transport attribute
defines the SOAP protocol to use. In this case we use HTTP.
o
The operation
element defines each operation that the port exposes.
o
SOAP action has to be
defined for each corresponding operation.
o
Must specify how the
input and output are encoded. In this case we use "literal".
·
UDDI is a
platform-independent framework for :
§
Describing Services
§
discovering businesses
§
integrating business
services by using the Internet.
·
UDDI stands for
Universal Description, Discovery and Integration
·
UDDI is a directory for
storing information about web services
·
UDDI is a directory of
web service interfaces described by WSDL
·
UDDI communicates via
SOAP
·
UDDI is built into the
Microsoft .NET platform
·
UDDI uses World Wide
Web Consortium (W3C) and Internet Engineering Task Force (IETF) Internet
standards such as XML, HTTP, and DNS protocols.
·
UDDI uses WSDL to
describe interfaces to web services
·
Cross platform
programming features are addressed by adopting SOAP, known as XML Protocol
messaging specifications found at the W3C Web site.
·
Any industry or
businesses of all sizes can benefit from UDDI
·
Before UDDI, there was
no Internet standard for businesses to reach their customers and partners with
information about their products and services.
· There a no method for integrating diverse systems and processes.
Problems the UDDI specification can help to solve:
·
Making it possible to
discover the right business from the millions currently online
·
Defining how to enable
commerce once the preferred business is discovered
·
Reaching new customers
and increasing access to current customers
·
Expanding offerings and
extending market reach
·
Solving customer-driven
need to remove barriers to allow for rapid participation in the global Internet
economy
·
Describing services and
business processes programmatically in a single, open, and secure environment
Example – Airline Industry
·
If the industry
published an UDDI standard for flight rate checking and reservation, airlines
could register their services into an UDDI directory.
·
Travel agencies could
then search the UDDI directory to find the airline's reservation interface.
·
When the interface is
found, the travel agency can communicate with the service immediately because
it uses a well-defined reservation interface.
·
UDDI is a
cross-industry effort driven by all major platform and software providers like
Dell, Fujitsu, HP, Hitachi, IBM, Intel, Microsoft, Oracle, SAP, and Sun, as
well as a large community of marketplace operators, and e-business leaders.
·
Over 220 companies are
members of the UDDI community.
|
The full WSDL 1.2 syntax as described in the W3C Working Draft is listed below. <wsdl:definitions name="nmtoken"? targetNamespace="uri"> <import namespace="uri" location="uri"/> * <wsdl:documentation .... /> ? <wsdl:types> ? <wsdl:documentation .... /> ? <xsd:schema .... /> * </wsdl:types> <wsdl:message name="ncname"> * <wsdl:documentation .... /> ? <part name="ncname" element="qname"? type="qname"?/> * </wsdl:message> <wsdl:portType name="ncname"> * <wsdl:documentation .... /> ? <wsdl:operation name="ncname"> * <wsdl:documentation .... /> ? <wsdl:input message="qname"> ? <wsdl:documentation .... /> ? </wsdl:input> <wsdl:output message="qname"> ? <wsdl:documentation .... /> ? </wsdl:output> <wsdl:fault name="ncname" message="qname"> * <wsdl:documentation .... /> ? </wsdl:fault> </wsdl:operation> </wsdl:portType> <wsdl:serviceType name="ncname"> * <wsdl:portType name="qname"/> + </wsdl:serviceType> <wsdl:binding name="ncname" type="qname"> * <wsdl:documentation .... /> ? <-- binding details --> * <wsdl:operation name="ncname"> * <wsdl:documentation .... /> ? <-- binding details --> * <wsdl:input> ? <wsdl:documentation .... /> ? <-- binding details --> </wsdl:input> <wsdl:output> ? <wsdl:documentation .... /> ? <-- binding details --> * </wsdl:output> <wsdl:fault name="ncname"> * <wsdl:documentation .... /> ? <-- binding details --> * </wsdl:fault> </wsdl:operation> </wsdl:binding> <wsdl:service name="ncname" serviceType="qname"> * <wsdl:documentation .... /> ? <wsdl:port name="ncname" binding="qname"> * <wsdl:documentation .... /> ? <-- address details --> </wsdl:port> </wsdl:service></wsdl:definitions>
|
|
|
·
Need to allow Internet
communication between programs.
·
Applications
communicate using Remote Procedure Calls (RPC) between objects like DCOM and
CORBA
·
HTTP was not designed
for this.
·
RPC represents a compatibility
and security problem - firewalls and
proxy servers will normally block this kind of traffic.
·
A better way to
communicate between applications is over HTTP, because HTTP is supported by all
Internet browsers and servers.
·
SOAP was created to
accomplish this.
·
SOAP provides a way to
communicate between applications running on different operating systems, with
different technologies and programming languages.
A
SOAP message is an ordinary XML document containing the following elements:
·
A required Envelope
element that identifies the XML document as a SOAP message
·
An optional Header
element that contains header information
·
A required Body element
that contains call and response information
·
An optional Fault
element that provides information about errors that occurred while processing
the message
All
the elements above are declared in the default namespace for the SOAP envelope:
http://www.w3.org/2001/12/soap-envelope
and
the default namespace for SOAP encoding and data types is:
http://www.w3.org/2001/12/soap-encoding
Important
syntax rules:
·
A SOAP message MUST be
encoded using XML
·
A SOAP message MUST use
the SOAP Envelope namespace
·
A SOAP message MUST use
the SOAP Encoding namespace
·
A SOAP message must NOT
contain a DTD reference
·
A SOAP message must NOT
contain XML Processing Instructions
<?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope"soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:Header> ... ...</soap:Header> <soap:Body> ... ... <soap:Fault> ... ... </soap:Fault> </soap:Body> </soap:Envelope> |
·
Required SOAP Envelope
element is the root element of a SOAP message.
·
It defines the XML
document as a SOAP message.
·
Note the use of the
xmlns:soap namespace. It should always have the value of:
http://www.w3.org/2001/12/soap-envelope
·
it defines the Envelope
as a SOAP Envelope:
<?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> ... Message information goes here ...</soap:Envelope> |
·
A SOAP message must
always have an Envelope element associated with the "http://www.w3.org/2001/12/soap-envelope"
namespace.
·
If a different
namespace is used, the application must generate an error and discard the
message.
·
The SOAP encodingStyle
attribute is used to define the data types used in the document.
·
This attribute may appear
on any SOAP element
·
It will apply to that
element's contents and all child elements.
·
A SOAP message has no
default encoding.
soap:encodingStyle="URI" |
<?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope"soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">...Message information goes here...</soap:Envelope> |
·
The optional SOAP
Header element contains application specific information (like authentication,
payment, etc) about the SOAP message.
·
If the Header element
is present, it must be the first child element of the Envelope element.
·
Note: All immediate child elements of the Header element
must be namespace-qualified.
<?xml version="1.0"?> <soap:Envelopexmlns:soap="http://www.w3.org/2001/12/soap-envelope"soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:Header><m:Trans xmlns:m="http://www.w3schools.com/transaction/" soap:mustUnderstand="1">234</m:Trans></soap:Header>......</soap:Envelope> |
Above
contains:
·
a header with a
"Trans" element
·
a "mustUnderstand"
attribute value of "1"
·
a value of 234
·
SOAP defines three
attributes in the default namespace ("http://www.w3.org/2001/12/soap-envelope")
o
Actor
o
MustUnderstand
o
encodingStyle
·
The attributes defined
in the SOAP Header defines how a recipient should process the SOAP message.
o
A SOAP message may
travel from a sender to a receiver by passing different endpoints along the
message path
o
Not all parts of the
SOAP message may be intended for the ultimate endpoint of the SOAP message
o
They may be intended
for one or more of the endpoints on the message path.
o
The SOAP actor
attribute may be used to address the Header element to a particular endpoint.
soap:actor="URI" |
<?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:Header> <m:Trans xmlns:m="http://www.w3schools.com/transaction/" soap:actor="http://www.w3schools.com/appml/"> 234 </m:Trans></soap:Header>......</soap:Envelope> |
o
The SOAP mustUnderstand
attribute can be used to indicate whether a header entry is mandatory or
optional for the recipient to process.
o
"mustUnderstand="1"
of a child element of the Header element indicates that the receiver processing
the Header must recognize the element.
o
If the receiver does
not recognize the element it must fail when processing the Header.
soap:mustUnderstand="0|1" |
<?xml version="1.0"?> <soap:Envelopexmlns:soap="http://www.w3.org/2001/12/soap-envelope"soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:Header> <m:Trans xmlns:m="http://www.w3schools.com/transaction/" soap:mustUnderstand="1"> 234 </m:Trans></soap:Header>......</soap:Envelope> |
o
The required SOAP Body
element contains the actual SOAP message intended for the ultimate endpoint of
the message.
o
Immediate child
elements of the SOAP Body element may be namespace-qualified
o
SOAP defines one
element inside the Body element in the default namespace
("http://www.w3.org/2001/12/soap-envelope").
o
This is the SOAP Fault
element, which is used to indicate error messages.
<?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:Body> <m:GetPrice xmlns:m="http://www.w3schools.com/prices"> <m:Item>Apples</m:Item> </m:GetPrice> </soap:Body></soap:Envelope> |
o
The example above
requests the price of apples.
o
Note that the
m:GetPrice and the Item elements above are application-specific elements.
A
SOAP response could look something like this:
<?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:Body> <m:GetPriceResponse xmlns:m="http://www.w3schools.com/prices"> <m:Price>1.90</m:Price> </m:GetPriceResponse> </soap:Body></soap:Envelope> |
o
An error message from a
SOAP message is carried inside a Fault element.
o
If a Fault element is
present, it must appear as a child element of the Body element.
o
A Fault element can
only appear once in a SOAP message.
o
The SOAP Fault element
has the following sub elements:
|
Sub Element |
Description |
|
<faultcode> |
A code for identifying the fault |
|
<faultstring> |
A human readable explanation of the fault |
|
<faultactor> |
Information about who caused the fault to happen |
|
<detail> |
Holds
application specific error information related to the Body element |
The
faultcode values defined below must be used in the faultcode element when
describing faults:
|
Error |
Description |
|
VersionMismatch |
Found an invalid namespace for the SOAP Envelope element |
|
MustUnderstand |
An immediate child element of the Header element, with the
mustUnderstand attribute set to "1", was not understood |
|
Client |
The message was incorrectly formed or contained incorrect
information |
|
Server |
There was a problem with the server so the message could
not proceed |
·
HTTP communicates over
TCP/IP.
·
An HTTP client connects
to an HTTP server using TCP.
·
After establishing a
connection, the client can send an HTTP request message to the server:
POST /item HTTP/1.1Host: 189.123.345.239Content-Type: text/plainContent-Length: 200 |
·
The server then
processes the request and sends an HTTP response back to the client.
·
The response contains a
status code that indicates the status of the request:
200 OKContent-Type: text/plainContent-Length: 200 |
·
In the example above,
the server returned a status code of 200.
·
This is the standard
success code for HTTP.
·
If the server could not
decode the request, it could have returned something like this:
400 Bad RequestContent-Length: 0 |
A SOAP
method is an HTTP request/response that complies with the SOAP encoding rules.
·
A SOAP request could be
an HTTP POST or an HTTP GET request.
·
The HTTP POST request
specifies at least two HTTP headers:
o
Content-Type
o
Content-Length.
Content-Type: MIMEType; charset=character-encoding |
POST /item HTTP/1.1Content-Type: application/soap+xml; charset=utf-8 |
Content-Length: bytes |
POST /item HTTP/1.1Content-Type: application/soap+xml; charset=utf-8Content-Length: 250 |
·
A GetStockPrice request
is sent to a server
·
The request has a
StockName parameter
·
A Price parameter will
be returned in the response.
·
The namespace for the
function is defined in "http://www.stock.org/stock" address.
·
The SOAP request:
POST /InStock HTTP/1.1Host: www.stock.orgContent-Type: application/soap+xml; charset=utf-8Content-Length: nnn <?xml version="1.0"?><soap:Envelopexmlns:soap="http://www.w3.org/2001/12/soap-envelope"soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:Body xmlns:m="http://www.stock.org/stock"> <m:GetStockPrice> <m:StockName>IBM</m:StockName> </m:GetStockPrice> </soap:Body></soap:Envelope> |
A SOAP response:
HTTP/1.1 200 OKContent-Type: application/soap; charset=utf-8Content-Length: nnn<?xml version="1.0"?><soap:Envelopexmlns:soap="http://www.w3.org/2001/12/soap-envelope"soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:Body xmlns:m="http://www.stock.org/stock"> <m:GetStockPriceResponse> <m:Price>34.5</m:Price> </m:GetStockPriceResponse> </soap:Body></soap:Envelope> |