Web Services:
Principles & Technology
Describing Web services
Mike P. Papazoglou
mikep@uvt.nl
Adapted by M. Vavalis
Why is a Service description needed?
• Web services need to be published, discovered, assembled or
orchestrated. Therefore need to be described
• Can be done in XML (Schema)
• Difficult with certain functional and non-functional characteristics
• Service description is a key to
• Making SOA loosely coupled
• Reducing the amount of required
• Common understanding
• Custom programming
2
Why is a Service description needed?
• Service description reduces the amount of required
common understanding and custom programming and
integration
• It is a machine understandable standard describing the operations of
a web service.
• It specifies the wire format and transport protocol that the web
service uses to expose this functionality.
• It can also describe the payload data using a type system.
• Service description + SOAP infrastructure
• isolates all technical details, e.g., machine- & implementation
language-specific elements, away from the service requester’s
application and the service provider’s Web service.
3
References
• WSDL
• http://www.w3.org/TR/#tr_WSDL
• Web Services Description Language (WSDL) Version 2.0 Part 0: Primer
• http://www.w3.org/TR/2007/REC-wsdl20-primer-20070626/
• W3C School Tutorial
• http://www.w3schools.com/wsdl/default.asp
4
Web Services Description Language (WSDL)
•XML-based service representation language used
to describe the details of the complete interfaces
exposed by Web services
•The means to accessing a Web service.
• neither the service requester nor the provider should be
aware of each other’s technical infrastructure, programming
language or distributed object framework (if any).
• WSDL (version 2.0) is NOT yet a W3C standard!
5
<?xml version="1.0" encoding="utf-8" ?>
<description
xmlns="http://www.w3.org/ns/wsdl"
Grand example
targetNamespace= "http://greath.example.com/2004/wsdl/resSvc"
(WSDL) Version 2.0 Part 0: Primer
xmlns:tns= "http://greath.example.com/2004/wsdl/resSvc"
xmlns:ghns = "http://greath.example.com/2004/schemas/resSvc"
xmlns:wsoap= "http://www.w3.org/ns/wsdl/soap"
xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsdlx= "http://www.w3.org/ns/wsdl-extensions">
<documentation>
This document describes the GreatH Web service. Additional
application-level requirements for use of this service -beyond what WSDL 2.0 is able to describe -- are available
at http://greath.example.com/2004/reservation-documentation.html
</documentation>
<types>
<xs:schema
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://greath.example.com/2004/schemas/resSvc"
xmlns="http://greath.example.com/2004/schemas/resSvc">
<xs:element name="checkAvailability" type="tCheckAvailability"/>
<xs:complexType name="tCheckAvailability">
<xs:sequence>
<xs:element name="checkInDate" type="xs:date"/>
<xs:element name="checkOutDate" type="xs:date"/>
<xs:element name="roomType" type="xs:string"/>
</xs:sequence>
</xs:complexType>
<xs:element
name="checkAvailabilityResponse“type="xs:double"/>
<xs:element name="invalidDataError" type="xs:string"/>
</xs:schema>
</types>
<interface name = "reservationInterface" >
<fault name = "invalidDataFault"
element = "ghns:invalidDataError"/>
<operation name="opCheckAvailability"
pattern="http://www.w3.org/ns/wsdl/in-out"
style="http://www.w3.org/ns/wsdl/style/iri"
wsdlx:safe = "true">
<input messageLabel="In"
element="ghns:checkAvailability" />
…
6
An Example
<message name="getTermRequest">
<part name="term" type="xs:string"/>
</message>
<message name="getTermResponse">
defines "glossaryTerms" as the name of a port, and
"getTerm" as the name of an operation
The "getTerm" operation has an input message called
"getTermRequest" and an output message called
"getTermResponse".
<part name="value" type="xs:string"/>
</message>
define the parts of each message and the associated
data types.
<portType name="glossaryTerms">
<operation name="getTerm">
<input message="getTermRequest"/>
<output message="getTermResponse"/>
</operation>
</portType>
Compared to traditional programming,
•
glossaryTerms is a function library,
•
"getTerm" is a function with "getTermRequest" as
the input parameter and getTermResponse as the
return parameter.
7
WSDL as a contract
• An XML document that describes the
mechanics of interacting with a particular
Web service.
• Intended to constrain both the service
provider and the service requester that makes
use of that service.
WSDL represents a “contract” between the
service requester and the service provider
• Platform and language-independent
• Used primarily to describe SOAP-enabled
services.
• Used to describe precisely
Service
Requestor
Address
Operation
Data
Specification
conditions
(declarative)
Connect
Describe
(contract)
• What a service does,
• the operations the service provides,
• Where it resides,
Service
Provider
SOAP
WSDL
Simple Object Access
Protocol
<wsdl> … <wsdl>
• details of the protocol-specific address, e.g., a URL,
and
• How to invoke it,
• details of the data formats and protocols necessary to
access the service’s operations.
XML
8
Characteristics of WSDL
• Operations and messages are described abstractly
• Defines bindings to message formats and protocols
• Endpoints defined by binding concrete network protocol and message format to
abstract operations and messages
• Can describe any endpoint regardless of the underlying network protocol or message
format
• Defines how to locate the endpoint for the service
• Example: URLs for HTTP
• Defines extensible SOAP and HTTP extensions
9
Structure of WSDL documents
• Can be separated into distinct sections:
• service-interface definition
• Describes the general web service interface structure.
• Contains all the operations supported by the service, the operation parameters
and abstract data types.
• service implementation part
• binds the abstract interface to a concrete network address, to a specific protocol
and to concrete data structures.
• A web service client may bind to such an implementation and invoke the
service in question.
• Enables each part to be defined separately and independently,
and reused by other parts
• The combination of these two parts contains sufficient
information to describe to the service requester how to invoke
and interact with the web service at a provider’s site.
• Using WSDL, a requester can locate a web service and invoke any of the
publicly available operations.
10
WSDL document content
• Abstract (interface) definitions
•
•
•
•
<types>
<message>
<operation>
<portType>
data type definitions
operation parameters
abstract description of service actions
set of operation definitions
• Concrete (implementation) definitions
• <binding>
• <port>
• <service>
operation bindings
association of an endpoint with a binding
location/address for each binding
• Also:
• <import>
used to reference other XML documents
11
Web Service Interface Definition
• WSDL specifies a grammar and syntax that
describes web services as a collection of
communicating endpoints.
Service client
• A complete WSDL definition contains all of the
information necessary to invoke a web service.
• The data being exchanged between the
endpoints are specified as part of messages
and every kind of processing activity allowed
at an endpoint is considered as an operation.
• WSDL is layered top of the XML schema and
provides the means to group messages into
operations and operations into interfaces.
• Collections of permissible operations at an
endpoint are grouped together into port types.
• WSDL also provides a way to define bindings for
each interface and protocol combination along
with the endpoint address for each one.
Messages
end
point1
end
point2
end
point3
binding2
end
point4
end
point6
binding3
binding4
binding1
interface
Service
end
point5
binding5
interface
• operation
• operation
• operation
• operation
• operation
• operation
Resource
12
<wsdl:definitions name="PurchaseOrderService"
targetNamespace="http://supply.com/PurchaseService/wsdl"
xmlns:tns="http://supply.com/ PurchaseService/wsdl"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soapbind="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
Abstract data type
<wsdl:types>
definitions
<xsd:schema
targetNamespace="http://supply.com/PurchaseService/wsdl"
<xsd:complexType name="CustomerInfoType">
<xsd:sequence>
<xsd:element name="CusNamer" type="xsd:string"/>
<xsd:element name="CusAddress" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="POType">
<xsd:sequence>
<xsd:element name="PONumber" type="integer"/>
<xsd:element name="PODate" type="string"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="InvoiceType">
<xsd:all>
<xsd:element name="InvPrice" type="float"/>
<xsd:element name="InvDate" type="string"/>
</xsd:all>
</xsd:complexType>
Data that is sent
</xsd:schema>
</wsdl:types>
<wsdl:message name="POMessage">
<wsdl:part name="PurchaseOrder" type="tns:POType"/>
< wsdl:part name="CustomerInfo" type="tns:CustomerInfoType"/>
</wsdl:message>
Data that is returned
<wsdl:message name="InvMessage">
<wsdl:part name="Invoice" type="tns:InvoiceType"/>
</wsdl:message>
Port type with
<wsdl:portType name="PurchaseOrderPortType">
one operation
An operation with
<wsdl:operation name="SendPurchase">
request (input) &
<wsdl:input message="tns:POMessage"/>
response (output)
<wsdl:output message="tns:InvMessage"/>
message
</wsdl:operation>
</wsdl:portType>
</wsdl:definitions>
Listing 1:
Example of WSDL
Interface definition
13
<types> element
• The WSDL <types> element serves as a container that contains all
abstract data types that define a web service interface.
• A <type> element in WSDL is comparable to a data type in Java or
C++.
• WSDL uses a few primitive data types that XML Schema Definition (XSD)
defines, e.g., int, float, long, short, string, boolean, & allows developers
to either use them directly or build complex data types based on those
primitive ones before using them in messages.
• The data types and elements defined in the <types> element are used by
message definitions when declaring the parts (payloads) of messages.
• Any complex data type that the service uses must be defined using a
<types> element.
• Listing 1 illustrates two complex types : POType and InvoiceType.
14
<message> element
• The <message> element describes the payload of a message used by a web service. A
message consists of <part> elements, which are linked to <types> elements.
• In Listing 1 the PurchaseOrder service defines two <message> elements to describe the
parameters and return values of that service.
• POMessage (also below) describes the input parameters of the service, while
• InvMessage represents the return (output) parameters.
<!-- message elements that describe input and output parameters for the
PurchaseOrderService -->
<!--input message -->
<wsdl:message name="POMessage">
<wsdl:part name="PurchaseOrder" type="tns:POType"/>
<wsdl:part name="CustomerInfo" type="tns:CustomerInfoType”/>
</wsdl:message>
<! -- outputput message -->
<wsdl:message name="InvMessage">
<wsdl:part name="Invoice" type="tns:InvoiceType"/>
</wsdl:message>
<!-- message element that describes input and output parameters -->
<wsdl:message name="POMessage">
<wsdl:part name="PurchaseOrder" element="tns:PurchaseOrder"/>
</wsdl:message>
RPC-style
message
document-style
message
15
<portType>, <operation> elements
• A <portType> element defines an abstract type and its operations
but not an implementation. A <portType> element is a logical
grouping of <operations> in a Web service.
• It describes the kinds of operations that a web service supports – the
messaging mode and payloads – without specifying the Internet protocol or
physical address used.
• The <portType> element is central to a WSDL description; the rest of the
elements in the definition are essentially details that the <portType> element
depends upon.
• Operations in WSDL represent the methods exposed by the service:
they include the name of the method and the input and output
parameters.
• A typical <operation> element is composed of at most one <input> or <output>
element and any number of <fault> elements.
• The WSDL example in Listing 1 contains a <portType> named
PurchaseOrderPortType that supports a single <operation> called
SendPurchase.
16
WSDL Implementation
• The purpose of WSDL is to specify a web service abstractly
and then to define how the WSDL developer will reach the
implementation of these services.
• The service implementation part of WSDL contains the
elements <binding>, <port> and <service> and describes
how a particular service interface is implemented by a given
service provider.
• The service implementation describes
• where the service is located, or more precisely,
• to which network address the message must be sent in order to
invoke the web service.
• a WSDL service element. A service implementation document can
contain references to more than one service interface document by
means of <import> elements.
17
WSDL elements hierarchy
Part
Part
Part
Message
….
Operation
abstract endpoint type
(no transport or encoding)
PortType
Port
Service
….
Binding
….
….
endpoint instance
(with network address)
service
(related endpoint instances)
18
service-implementation
concrete endpoint type
(with transport or encoding)
….
service-interface
Message
Part
<wsdl:definitions> . …
<import namespace="http://supply.com/PurchaseService/wsdl"
location="http://supply.com PurchaseService/wsdl/PurchaseOrder-interface.wsdl"/>
<!-- location of WSDL PO interface from Listing-1-->
<!-- wsdl:binding states a serialisation protocol for this service -->
<!-- type attribute must match name of portType element in Listing-1-->
<wsdl:binding name="PurchaseOrderSOAPBinding"
type="tns:PurchaseOrderPortType">
<!-- leverage off soapbind:binding synchronous style -->
<soapbind:binding style="rpc"
transport="http://schemas.xmlsoap.org/soap/http/"/>
<wsdl:operation name="SendPurchase">
Bind an abstract operation
to this implementation &
<!-- again bind to SOAP -->
<soapbind:operation
soapAction="http://supply.com/ PurchaseService/wsdl/ SendPurchase" style="rpc"/>
<!-- furthur specify that the messages in the wsdl:operation use SOAP -->
<wsdl:input>
<soapbind:body use="literal"
namespace="http://supply.com/PurchaseService/wsdl"/>
</wsdl:input>
<wsdl:output>
<soapbind:body use=“literal"
namespace="http://supply.com/ PurchaseService/wsdl"/>
</wsdl:output>
map the abstract
input & output messages
to these concrete messages
</wsdl:operation>
</wsdl:binding>
Listing 2:
Example of WSDL
Implementation
Service name
<wsdl:service name=“PurchaseOrderService">
<wsdl:port name=“PurchaseOrderPort" binding="tns:PurchaseOrderSOAPBinding">
<!-- give the binding a network endpoint address or URI of service -->
<soapbind:address location="http://supply.com:8080/PurchaseOrderService"/>
</wsdl:port>
Michael P. Papazoglou Web Services: Principles &
</wsdl:service>
Technology Prentice-Hall, October 2007 ©
</wsdl:definitions>
Network address of service
19
<binding>, <port>, <service> elements
<binding> element - central element of the implementation description.
• specifies how the client and web service should exchange messages. The client uses
this information to access the Web service.
• contains information of how the elements in an abstract service interface (<portType> element)
are converted into concrete representation in a particular combination of
• concrete protocols, e.g., SOAP or HTTP,
• messaging styles, e.g., RPC or documents styles, and
• formatting (encoding) styles, e.g., literal or SOAP encoding.
<port> element - defines the location of a web service
• we can think of it as the URL where the service can be found.
• associates an endpoint, a network address location or URL, with a specific <binding>
• It is possible for two or more <port> elements to assign different URLs to the same
<binding> element.
• useful for load balancing or fail-over purposes.
<service> element contains a collection (usually one) of WSDL <port> elements.
• is named, and each name must be unique among all services in a WSDL document.
20
<wsdl:message name="POMessage">
<wsdl:part name="PurchaseOrder" type=“tns:POType"/>
< wsdl:part name=“CustomerInfo” type=“tns:CustomerInfoType”/>
</wsdl:message>
<wsdl:message name="InvMessage">
<wsdl:part name=“Invoice" type=“tns:InvoiceType"/>
</wsdl:message>
<wsdl:portType name=“PurchaseOrderPortType">
<wsdl:operation name=“SendPurchase">
<wsdl:input message="tns:POMessage"/>
<wsdl:output message="tns:InvMessage"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="POMessageSOAPBinding"
type="tns:PurchaseOrderPortType">
<soapbind:binding style=“rpc“
transport="http://schemas.xmlsoap.org/soap/http/"/>
<wsdl:operation name=“SendPurchase">
<?xml version= "1.0" encoding= "UTF-8" ?>
<soap:Envelope
xmlns:soapbind="http://schemas.xmlsoap.org/soap/envelope"
xmlns:tns="http://supply.com/ PurchaseService/wsdl ">
<soap:Body>
<tns:SendPurchase>
<POtype>
<PONumber> 223451 </PONumber>
<PODate> 10/28/2004 </PODate>
</POtype>
……
<tns:SendPurchase>
</soap:Body>
</soap:Envelope>
<soapbind:operation style=“rpc“
soapAction="http://supply.com/ PurchaseService/wsdl/ SendPurchase"/>
<wsdl:input>
<soapbind:body use=“literal"
namespace="http://supply.com/PurchaseOrderService/wsdl"/>
</wsdl:input>
<wsdl:output>
<soapbind:body use=“literal"
namespace="http://supply.com/ PurchaseOrderService/wsdl"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
Mapping the SendPurchase
operation to an RPC-style
SOAP message
21
Connecting the serviceInterface with the
service implementation
22
Each message part is defined
by some type, either custom
defined or XSD provided.
part
part
Message
Type-a
custom defined
Elements of WSDL
as part of requestor-service
interaction.
int
XSD built-in
Input & output messages form an
operation. A set of operations forms
a port-type.
A port exposes the service
using a specific binding
port#1
SOAP/HTTP request message
Client #B
SOAP/HTTP response message
service
Java
implementation
HTTP GET request message
Client #B
HTTP response message
port#2
A binding specifies how the
operations are invoked using a
specific protocol, e.g., SOAP.
Michael P. Papazoglou Web Services: Principles &
Technology Prentice-Hall, October 2007 ©
A service is a collection of
related endpoints (ports)
that the client wishes to invoke.
23
Connecting abstract & concrete levels
Concrete Level
Service name = S
Port name = Po
binding = B
soap:address
Binding name = B
port = PT
operation name = Op
input
(or output, fault)
Abstract Level
portType
name = PT
operation name = Op
input
name = in
message = M
(or output, fault)
types
schema
complexType name = T
(or simpleType name = T)
message name = M
part name = Pa
type = T
24
WSDL Message Exchange Patterns
• WSDL interfaces support four common types
of operations that represent possible
combinations of input and output messages
• The WSDL operations correspond to the
incoming and outgoing versions of two basic
operation types:
• an incoming single message passing operation
and its outgoing counterpart (“one-way” and
“notification” operations),
• the incoming and outgoing versions of a
synchronous two-way message exchange
(“request-response” and “solicit response”).
• any combination of incoming and outgoing
operations can be included in a single WSDL
interface
• these four types of operations provide support
for both push and pull interaction models at
the interface level.
One-way Messaging
SOAP Message
Sender
Receiver
Request/Response Messaging
SOAP Request
SOAP Response
Sender
Receiver
Notification Messaging
SOAP Notification
Sender
Receiver
Solicit/Response Messaging
SOAP Request Message
SOAP Answer Message
Sender
Michael P. Papazoglou Web Services: Principles &
Technology Prentice-Hall, October 2007 ©
Receiver
25
One way operation
• A one-way operation is an operation in which the service endpoint receives a
message, but does not send a response.
• An example of a one-way operation might be an operation representing the submission
of an order to a purchasing system. Once the order is sent, no immediate response is
expected.
• Typically thought of as asynchronous messaging. In an RPC environment, a one-way
operation represents a procedure call to which no return value is assigned.
• A one-way message defines only an input message. It requires no output message and
no fault. Next to the request/response message exchange pattern, this is the most
popular message exchange pattern employed today.
<!-- portTyepe element describes the abstract interface of a Web service -->
<wsdl:portType name="SubmitPurchaseOrder_PortType">
<wsdl:operation name="SubmitPurchaseOrder">
<wsdl:input name="order" message="tns:SubmitPurchaseOrder_Message"/>
</wsdl:operation>
</wsdl:portType>
26
Request/response operation
• A request/response operation is an operation in which the service
end point receives a message and returns a message in response.
• If an <operation> element is declared with a single <input> element
followed by a single <output> element, it defines a
request/response operation.
• By listing the <input> tag first, the <operation> indicates that the web service receives a
message that is sent by the client. Listing the <output> tag second indicates that the
web service should respond to the message.
<!-- portTyepe element describes the abstract interface of a Web service -->
<wsdl:portType name="PurchaseOrder_PortType">
<wsdl:operation name="SendPurchase">
<wsdl:input message="tns:POMessage"/>
<wsdl:output message="tns:InvMessage"/>
</wsdl:operation>
</wsdl:portType>
27
Notification operation
• A notification operation is an operation in which the service endpoint
sends a message to a client, but it does not expect to receive a
response.
• This type of messaging is used by services that need to notify clients
of events.
• Notification is when a <portType> element contains an <output> tag but no
<input> message definitions.
• Heer the client (subscriber) has registered with the web service to
receive messages (notifications) about an event.
• An example of this could be a service model in which events are reported to
the service and where the endpoint periodically reports its status.
• No response is required in this case, as most likely the status data is assembled and
logged and not acted upon immediately
28
Solicit/response operation
• A solicit/response operation is an operation in which the service
endpoint sends a message and expects to receive an answering
message in response.
• This is the opposite of the request/response operation since the
service endpoint is initiating the operation (soliciting the client),
rather than responding to a request.
• Solicit/response is similar to notification messaging, except that
the client is expected to respond to the Web service.
• With this type of messaging the <portType> element first declares
an <output> tag and then a <input> message definition – exactly
the reverse of a request/response operation.
• An example of this operation might be a service that sends out order status
to a client and receives back a receipt.
29
WSDL document has six major elements
<definitions>: Root WSDL Element
<types>: What data types will be transmitted?
<message>: What messages will be transmitted?
<portType>: What operations will be supported?
<binding>: How will the messages be transmitted on the wire?
<service>: Where is the service located?
30
WSDL essential
• definitions
• Must be the root element
• Define the name of the service
• Declare the namespaces used in the document
• types
• Describe all the data type used by the Client and Server
• Can be omitted of only simple data types are used
• message
• Define the name of the request/response messages
• Define also the message part elements
• portType
• Define the combination of message elements to form a complete one-way
or round-trip operation
31
WSDL essential (cont.)
• binding
• Provide specific details on how a portType operation will actually be
transmitted over the wire
• SOAP specific information can be defined here. WSDL includes built-in
extensions for defining SOAP services
• service
• Define the address for invoking the specified service
• documentation
• Provide human-readable documentation
• Similar to making comments in a program
• import
• Allow importing other WSDL documents into a WSDL document
• Enable a more modular WSDL document
32
WSDL skeleton
<?xml version="1.0" encoding="UTF-8" ?>
<wsdl:definitions … >
<wsdl:types … >
:
</wsdl:types>
<wsdl:message … >
:
</wsdl:message>
<wsdl:portType … >
:
</wsdl:portType>
<wsdl:binding … >
:
</wsdl:binding>
<wsdl:service … >
:
</wsdl:service>
</wsdl:definitions>
33
Example
NameAndAge.wsdl
34
<definitions>: NameAndAge
<types>: JavaBean Record
– two variables Name and Age
<message>: 1. showRecordResquest
2. showRecordResponse
<portType>:showRecord that consists of
a request/response service
<binding>: Direction to use the SOAP
HTTP transport protocol
<service>: Service available at
http://localhost:8080/axis/services/NameAndAge
35
Definitions
The logical name for information about this service. WSDL documents can
import namespaces from other WSDL documents. Setting targetNamespace
to a unique value ensures that the namespaces do not clash
<?xml version="1.0" encoding="UTF-8" ?>
<wsdl:definitions
targetNamespace=
"http://localhost:8080/axis/services/NameAndAge"
xmlns="http://schemas.xmlsoap.org/wsdl/"
:
:
Default namespace. All the WSDL elements, such as
>
<definitions>, <types> and <message> reside in this
namespace.
36
Definitions (cont.)
Define the namespaces that will be used in the later part of the
document
xmlns:apachesoap="http://xml.apache.org/xml-soap"
xmlns:impl=
"http://localhost:8080/axis/services/NameAndAge"
xmlns:intf=
"http://localhost:8080/axis/services/NameAndAge"
xmlns:soapenc=
"http://schemas.xmlsoap.org/soap/encoding/"
xmlns:tns1="enpklun:polyu.edu.hk:soap"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:wsdlsoap=
"http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
37
Types
Default namespace, apply to unspecified tags, e.g.
schema, sequence, complexType, element
The qName of our JavaBean, its namespace
<wsdl:types>
<schema targetNamespace="enpklun:polyu.edu.hk:soap”
xmlns="http://www.w3.org/2001/XMLSchema">
<complexType name="Record">
can be a null string
<sequence>
<element name="age" type="xsd:int" />
<element name="name" nillable="true"
type="xsd:string" />
</sequence>
</complexType>
</schema>
</wsdl:types>
Two parameters of Record to be sent. The
element names are derived from the get/set
functions of the JavaBean
38
Data types
• Different programming languages have different ways to declare data
types, e.g. int, double, String
• One of the greatest challenges in building Web services is to create a
common data type system that every programming language can
understand
• E.g. a JavaBean cannot be understood by C++ program
• WSDL by default follows the data typing system defined by W3C XML
Schema Specification
<schema targetNamespace="enpklun:polyu.edu.hk:soap”
xmlns="http://www.w3.org/2001/XMLSchema">
:
</schema>
39
Data types (cont.)
• XML Schema specification includes a basic type system for encoding
most simple data types
• Include a long list of built-in simple types, e.g. string, float, double ….
Details can be found in
http://www.w3.org/TR/2000/WD=xmlschema=0=20000407/
• If only these data types are used in a Web service, the WSDL
document does not have the “types” section to further explain them
• When converting from a service or a request to XML messages, the
implementation platform, e.g. AXIS, should know how to encode
these simple type data based on the specifications as defined in XML
Schema
40
Data types (cont.)
• For complex data types, e.g. JavaBean, XML Schema does not have
their specifications
• If a Web service wants to use them, need to be explained in the
“types” section of its WSDL file
<complexType name="Record">
<sequence>
<element name="age" type="xsd:int" />
<element name="name" nillable="true"
type="xsd:string" />
</sequence>
</complexType> • Define that the Record type in fact comprises only two
variables in sequence
• Quite different from the original JavaBean specification
• But can be understood by most languages
41
Message
• When the data type is defined, specify the kind of messages that
make use of that data type
• The message element defines two kinds of messages in this example
• showRecordRequest
• showRecordResponse
• The showRecordRequest message only uses one kind of data type:
Record
• The showRecordResponse message uses the same kind of data type:
Record
42
Message (cont.)
• The namespace of tns1 as defined in “definition” is
enpklun:polyu.edu.hk:soap
• The same as the targetNameSpace in “types”
• Hence we are talking about the "Record” described in
“types”
<wsdl:message name="showRecordRequest">
<wsdl:part name="in0" type="tns1:Record" />
</wsdl:message>
<wsdl:message name="showRecordResponse">
<wsdl:part name="showRecordReturn"
type="tns1:Record" />
</wsdl:message>
The name of the parameter used in these two
messages. Only one in each message
43
portType
• Define how the messages are transmitted for the method:
showRecord
<wsdl:portType name="RecordService">
<wsdl:operation name="showRecord"
parameterOrder="in0">
<wsdl:input message="impl:showRecordRequest"
name="showRecordRequest" />
<wsdl:output message="impl:showRecordResponse"
name="showRecordResponse" />
</wsdl:operation>
The sequence of the input/output message
</wsdl:portType>
DOES matter.
The example above means that the input
message should go first and followed by the
output message
44
Remember!
45
Messages
<wsdl:operation name="showRecord"
parameterOrder="in0">
• A message can have more than one “parts”
• E.g. if showRecord() requires three input parameters, then the input message
for calling the service will have three parts
• For message that has more than one “parts”, need to indicate their
order, e.g. which part is the first parameter and which part is the
second
• Assume the input message of showRecord() has three “parts” – in0,
in1 and in2, and in0 is the first, in1 is the second and in2 is the third,
then
<wsdl:operation name="showRecord"
parameterOrder="in0 in1 in2">
46
binding
• The binding element provides specific details on how a portType
operation will actually be transmitted over the wire
• A single portType can have multiple bindings using different
transports e.g. HTTP or SMTP
• Contain the following parts:
• binding type
• soap operation
• function name to be called
• details about the input parameters
• details about the return parameters
47
Binding (cont.)
Talking about the showRecord() of RecordService
<wsdl:binding name="NameAndAgeSoapBinding"
type="impl:RecordService">
<wsdlsoap:binding style="rpc"
transport="http://schemas.xmlsoap.org/soap/http" />
<wsdl:operation name="showRecord">
<wsdlsoap:operation soapAction="" />
using HTTP
<wsdl:input name="showRecordRequest">
:
</wsdl:input>
<wsdl:output name="showRecordResponse">
:
</wsdl:output>
Referring to the same operation as in the
</wsdl:operation>
portType, since same namespace
</wsdl:binding>
48
Binding (cont.)
Provide more specific details to the input and output messages with
respect to the kind of messaging protocol (soap in this case) used
<wsdl:input name="showRecordRequest">
<wsdlsoap:body encodingStyle=
"http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://HelloBean" use="encoded" />
</wsdl:input>
<wsdl:output name="showRecordResponse">
<wsdlsoap:body encodingStyle=
"http://schemas.xmlsoap.org/soap/encoding/"
namespace=
"http://localhost:8080/axis/services/NameAndAge"
use="encoded" />
</wsdl:output>
49
service
<wsdl:service name="RecordServiceService">
<wsdl:port binding="impl:NameAndAgeSoapBinding“
name="NameAndAge">
<wsdlsoap:address location=
"http://localhost:8080/axis/services/NameAndAge" />
</wsdl:port>
</wsdl:service>
Specify the location of the service
50
WSDL Invocation Tools
• WSDL gives a full description of a Web service
•
•
•
•
•
Define the namespaces (in definition)
Define the data type (in types)
Define the messages format (in message)
Define the sequence of sending messages (in portType)
Define the kind of the messaging system to be used, e.g. Soap, and its
implementation details (in binding)
• Define the location of the service (in service)
• By having the WSDL document of a Web service, we have obtained all
information required to invoke this service
51
WSDL consequences
• Since WSDL is developed based on standardized rules (XML Schema),
service providers can automatically generate the WSDL document of
a Web service
• Since a WSDL document is a full description of a Web service,
requestors can automatically generate requests based on WSDL
• Hence no need for client to develop the request program, e.g. RecordClient
(see SOAP Implementation)
• Different software vendors have developed tools to facilitate the
above objectives
• WebMethods ‘s GLUE
• IBM’s WSIF (included in its ETTK package)
• SOAP:Lite for Perl
52
Main Objectives of the Tools
• To hide away the complication of invoking the Web service from the
client as much as possible
• To standardize as much as possible the procedure to client to invoke
different kind of services
53
Example: AXIS & GLUE
GLUE CLIENT
AXIS SERVER
Result
Input
Call 11 GLUE
Invoker
4
10
9
Transport
Dispatcher
5
6
3
1
WSDL2JAVA
2
WSDL
document
7
8
Web
Service
54
54
Example: AXIS & GLUE (cont.)
1. AXIS automatically generates the WSDL document of a Web
service
2. GLUE client uses the GLUE’s WSDL2JAVA tool to retrieve the WSDL
document. It obtains the required info of the Web service and
generates a set of Java files
3. The Info is applied to a relatively standard Web service calling
program
4. A GLUE service invoker is generated to handle the problems for
invoking a SOAP service
5. AXIS calls the method in the service and sends the result back to
the GLUE service invoker
10. GLUE client finally gets the result
55
Example: AXIS & GLUE – Simple data types
Java Interface
of the service
Java helper class
for invoking the
service
GLUE
WSDL2JAVA
WSDL
document
56
Example: AXIS & GLUE – Complex data types
Java helper class
for invoking the
service
Java Interface
of the service
GLUE
WSDL2JAVA
Java class for
representing the
complex the data
type
GLUE mapping file
to indicate how to
translate the
complex Java data
type and XML
schema type
WSDL
document
57
Invoking Services using Simple Data Types
For each of the deployed service, a
WSDL file is automatically generated
by AXIS
Location of the wsdl file of HelloName:
http://localhost:8080/axis/services/HelloName?wsdl
Michael P. Papazoglou Web Services: Principles &
Technology Prentice-Hall, October 2007 ©
58
Command:
wsdl2java http://localhost:8080/axis/services/HelloName?wsdl –p Hello
Location of the wsdl file
The files generated should be
placed in the Hello package
File generated:
IHelloService.java – exposes the method interface
HelloServiceServiceHelper.java – dynamically bind to the service
specified by the WSDL file
59
59
Generated by GLUE’s
wsdl2java
• Mirror the interface of the method
sayHello of the service
• Based on this interface, a calling program
should know the method to be called, the
input and output parameters
60
Generated by GLUE’s wsdl2java
Registry.bind() returns an interface to the service (described
by the specified path) that implements the specified interface
61
Automation
• By using the helper files, a relatively standard service calling file can
be used
• Need no knowledge about SOAP
• enables automatic service invocation
• To enable full automated Web service, need an automatic process to
• extract the method name and the class type of the input and output
• provide the input parameter and
• interpret the semantic meaning of the return result
62
public class Invoke_Hello {
Can be extracted from the interface
public String say (String name)
throws Exception {
IHelloService Service =
HelloServiceServiceHelper.bind();
return Service.sayHello(name);
}
public static void main (String[] args)
throws Exception {
Invoke_Hello invoker = new Invoke_Hello();
String result = invoker.say("Dr Lun");
System.out.println(result);
}
}
Only need to provide the required input and
interpret the return result
63
63
Result received from the remote service
64
Invoking Services using Complex Data Types
Location of the wsdl file of NameAndAge:
http://localhost:8080/axis/services/NameAndAge?wsdl
The Web service NameAndAge has a
method showRecord() that requires a
JavaBean as the input and return a
JavaBean
65
File generated:
IRecordService.java – exposes the method interface
RecordServiceServiceHelper.java – dynamically bind to the service
specified by the WSDL file
Record.java – specify the structure of the class that can represent the
complex data type used in the service
RecordServiceService.map – specify how to map between the data
types in Record.java and the complex data type
66
Generated by GLUE’s wsdl2java
• Mirror the interface of the method
showRecord of the service
• Based on this interface, a calling program
should know the method to be called, the
input and output parameters
• Note the complex data type required by
this method
67
Generated by GLUE’s wsdl2java
Similar as in the simple data type case
68
Generated by GLUE’s wsdl2java
• Class suggests to represent the complex data
type used in this service
• Note JavaBean is not used. Only a simple class
• Hence can be more easily handled by a general
invocation program
69
<?xml version='1.0' encoding='UTF-8'?>
<map:mappings
xmlns:map='http://www.themindelectric.com/schema/'
xmlns:xsd='http://www.w3.org/2001/XMLSchema'>
<xsd:schema targetNamespace=
'enpklun:polyu.edu.hk:soap'>
<xsd:complexType name='Record'
map:class='RecordBean.Record'>
<xsd:sequence>
<xsd:element name='age' map:field='age'
type='xsd:int'/>
<xsd:element name='name' nillable='true'
map:field='name' type='xsd:string'/>
</xsd:sequence>
</xsd:complexType>
</xsd:schema>
</map:mappings>
RecordServiceService.map generated by GLUE’s wsdl2java
70
<xsd:complexType name='Record'
map:class='RecordBean.Record'>
<xsd:sequence>
<xsd:element name='age' map:field='age'
type='xsd:int'/>
<xsd:element name='name' nillable='true'
map:field='name' type='xsd:string'/>
</xsd:sequence>
</xsd:complexType>
• Map the element age to the age variable in
RecordBean.Record class and it is of type integer
defined in XML Schema
• Map the element name to the name variable in
RecordBean.Record class and it is of type string
defined in XML Schema
71
package RecordBean;
public class Invoke_RecordBean {
public Record check (Record userRecord)
throws Exception {
Mappings.readMappings("RecordServiceService.map");
IRecordService Service =
RecordServiceServiceHelper.bind();
Record updatedRecord =
Service.showRecord(userRecord); The only difference
as compared with
return updatedRecord;
the simple data type
}
case
public static void main (String[] args)
throws Exception {
:
}
}
72
public static void main (String[] args)
throws Exception {
Invoke_RecordBean invoker = new Invoke_RecordBean();
Record currRecord = new Record();
// This Record is not JavaBean, but the
//
class generated by wsdl2java()
currRecord.name = new String("Chan Tai Man");
currRecord.age = 30;
// Again need to pass the required parameters
Record result = invoker.check(currRecord);
// When result is received, need to interpret the
//
the result
System.out.println("The user is
"+result.name+".\n");
System.out.println("Next year he will be”+
result.age+"years old.");
}
The only part that is application specific
73
Result received from the remote service
74
Summary
• To both the case of simple or complex data types, a very similar
procedure is required to invoke the service
• No knowledge is required in the specific messaging system, e.g. SOAP
• However, the invoker program needs to know
• the location where the wsdl file can be found (can be solved by UDDI)
• where to get the parameters to be sent to the service (require the invoker
program to have some intelligence, very often application dependent)
• how to handle the returned results from the service (require the invoker
program to have some intelligence, very often application dependent)
75