1 ws technologies ii wsdl roberto bruni dipartimento di informatica università di pisa models and...

1

WS Technologies IIWSDL

Roberto BruniDipartimento di Informatica Università di Pisa

Models and Languages for Coordination and Orchestration

IMT- Institutions Markets Technologies - Alti Studi Lucca

2

Roberto Bruni @ IMT Lucca 16 March 2005


InstitutionsMarketsTechnologies

IMT

Contents WSDL Some Java tools

3




IMT

Contents WSDL Some Java tools

4




IMT

What is the Story so Far? With UDDI (and SOAP) we know how to find and

discover new services as if we looked at the yellow pages

What can we do with discovered services? should we contact the service provider and ask for

technical support in programming the right SOAP calls?

No, this would be a waste of time for both us and the provider!

Instead, the provider should prepare a unambiguous description of the WS to be exposed

automatically downloadable, understandable, and usable for connecting to the specific WS

WSDL fixes the standard for such description

5




IMT

Web Services Description Language (WSDL)

WSDL is an XML-based language for the description of Web Services (and the methods to access them)

A WSDL document is just a particular XML document it resides in a file with suffix .wsdl it can be checked for validity against the WSDL

Schema it describes how to "interface with" and use WS … and also the binding protocol to access WS it is a bit complex for human beings but it is unambiguous for a machine

6




IMT

The Seven Elements of WSDL

Essentially, WSDL documents consist of 7 key elements message types (data structures) messages

basic units of communication between WS and clients typed data to be communicated as a single logical transmission

operations sequences of messages related to a single action

interfaces (called port types in WSDL v1) logical groups of operations representing abstract services

bindings associations between interfaces and concrete protocols / data

formats endpoints (called ports in WSDL v1)

associations between interface bindings and network addresses services (collections of endpoints)

7




IMT

A View at WSDL Hierarchical Structure

<definitions> <types> <message> <interface>

<operation> <input> <output>

<binding> <service>

<endpoint>

8




IMT

Types A type is the most basic WSDL element

completely analogous to a Schema document (.xsd) XML Schema are in fact used for defining message

types a type can correspond to

a struct, in C a class with variables but without methods, in Java

types are necessary to describe the main elements and parameters in a method call

9




IMT

Example:the Class Address.java

public class Address { public String name; public String address1; public String address2; public String city; public String state; public String zip;}

public class MyClass{ public void myMethod(Address myAddress){ //do something }}

10




IMT

the elements must appearin the specified order

The Schema address.xsdURI of the Schema

current namespace

<xsd:schema targetNamespace="…/address.xsd" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:addr="…/address.xsd"> <xsd:element name="address" type="addr:addressType" /> <xsd:complexType name="addressType"> <xsd:sequence> <xsd:element name="name" type="xsd:string"/> <xsd:element name="address1" type="xsd:string"/> <xsd:element name="address2" type="xsd:string"/> <xsd:element name="city" type="xsd:string"/> <xsd:element name="state" type="xsd:string"/> <xsd:element name="zip" type="xsd:string"/> </xsd:sequence> </xsd:complexType></xsd:schema>

11




IMT

Example: address.xsd with Anonymous Types

URI of Schema

Only if addressType is notused elsewhere

<xsd:schema targetNamespace="…/address.xsd" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:element name="address"> <xsd:complexType> <xsd:sequence> <xsd:element name="name" type="xsd:string"/> <xsd:element name="address1" type="xsd:string"/> <xsd:element name="address2" type="xsd:string"/> <xsd:element name="city" type="xsd:string"/> <xsd:element name="state" type="xsd:string"/> <xsd:element name="zip" type="xsd:string"/> </xsd:sequence> </xsd:complexType> </xsd:element></xsd:schema>

12




IMT

Example: valid XML document for address.xsd

<address>

<name>Arthur Fonzarelli</name>

<address1>123 W. Wisconsin</address1>

<address2>Apt. 4</address2>

<city>Milwaukee</city>

<state>WI</state>

<zip>53222</zip>

</address>

13




IMT

<all> disregards the order of elements

The Type address in WSDL I

<?xml version="1.0"?><wsdl:definitions name=“AddressType” targetNamespace=“…/addressType.wsdl” xmlns:tns=“…/addressType.wsdl” xmlns:wsdl=“http://schemas.xmlsoap.org/wsdl/”> <wsdl:types> <xsd:schema targetNamespace=“…/addressType.wsdl” xmlns:xsd=“http://www.w3.org/2001/XMLSchema”> <xsd:element name="Address"> <xsd:complexType> <xsd:all> <xsd:element name="name" type="xsd:string"/> <xsd:element name="address1" type="xsd:string"/> <xsd:element name="address2" type="xsd:string"/> <xsd:element name="city" type="xsd:string"/> <xsd:element name="state" type="xsd:string"/>

14




IMT

The Type address in WSDL II



<xsd:element name="zip" type="xsd:string"/>

</xsd:all>

</xsd:complexType>

</xsd:element>

</xsd:schema>

</wsdl:types>

</wsdl:definitions>

15




IMT

Messages On the contrary of types, messages do not

have an immediate analogy with Java... so we will push it...

Imagine a setting where any method can have three parameters at most WSDL relies on such assumption

(input, output and a third one, fault, for exception handling)

Thus we must group the parameters of methods this is what messages are for!

they have a sub-component part for each parameter

16




IMT

Example: a Messagepublic void order(Address shipTo, Address billTO){ //do something}<?xml version="1.0"?><wsdl:definitions …>

+ <wsdl:types>

 <wsdl:message name="purchase"> <wsdl:part name="billTo" element="tns:address"/> <wsdl:part name="shipTo" element="tns:address"/> </wsdl:message></wsdl:definitions>

type="tns:addressType"type="tns:addressType"

alternatively

17




IMT

Operations wsdl:operation is probably the simplest WSDL element

it correspond to an abstract method in Java but, as said, it has some limitation

three parameters at most: input, output, fault

essentially there are four main different kinds of operations

one-way (from the client to the service)

request/response (request from the client and response back from the service)

notification (from the service to the client)

solicit/response (message from the service and response from the client)

18




IMT

One-way Operations In general, operations are described by the element

wsdl:operation that can contain one or more messages (wsdl:input, wsdl:output, wsdl:fault)

In one-way operations, only the input element is allowed ex.

<?xml version="1.0"?><wsdl:definitions …> + <wsdl:types> <wsdl:message name="purchase"> … </wsdl:message> <wsdl:operation name="submitPurchase"> <wsdl:input message="tns:purchase" /> </wsdl:operation></wsdl:definitions>

19




IMT

Request/Response Operations

Both input and output are defined optionally, an additional fault element ex.

<?xml version="1.0"?><wsdl:definitions …> <wsdl:types> … </wsdl:types> <wsdl:message name="purchase"> … </wsdl:message> <wsdl:operation name="submitPurchase"> <wsdl:input message="tns:purchase" /> <wsdl:output message="tns:confirmation" /> <wsdl:fault message="tns:faultMessage" /> </wsdl:operation></wsdl:definitions>

20




IMT

<?xml version="1.0"?><wsdl:definitions …> <wsdl:types> … </wsdl:types> <wsdl:message name="trackingInformation"> … </wsdl:message> <wsdl:operation name="deliveryStatus"> <wsdl:output message="tns:trackingInformation" /> </wsdl:operation></wsdl:definitions>

Notification Operations Converse of one-way operations only output message is allowed

example: for notifying the client about the current status of the

order

21




IMT

<?xml version="1.0"?><wsdl:definitions …> <wsdl:types> … </wsdl:types> <wsdl:message name="bandwidthRequest"> …

</wsdl:message> <wsdl:operation name="clientQuery"> <wsdl:output message="tns:bandwidthRequest" /> <wsdl:input message="tns:bandwidthInfo" /> <wsdl:fault message="tns:faultMessage" /> </wsdl:operation></wsdl:definitions>

Solicit/Response Operations

Useful when a service needs some information from the client example:

construction of a site with variable bandwidth

22




IMT

Interfaces (Port Types) For the moment we have only surveyed

standalone operations but all the operations make sense only

when considered within a port type What is a “port type”?

W3C: “it defines a group of abstract operations and their corresponding abstract messages”

it is equivalent to a Java interface (in WSDL v2, port types are called interfaces)

Syntactically, it is defined by an element wsdl:interface (wsdl:portType in WSDL v1)

which contains one or more wsdl:operation elements

23




IMT

Example: Interface

<?xml version="1.0"?><wsdl:definitions …> <wsdl:types> … </wsdl:types> <wsdl:message name="purchase"> … </wsdl:message> <wsdl:portType name="submitPurchaseType"> <wsdl:operation name="submitPurchase"> <wsdl:input message="tns:purchase" /> </wsdl:operation> </wsdl:portType></wsdl:definitions>

24




IMT

Binding For the moment we have just considered

"abstract" elements upon receiving a <wsdl:interface> we have all the

information on how to use it but we cannot create a direct instance

To instantiate the interface we must provide the information that are necessary to interact with it in particular:

which transport method will the interface use? which communication format are we going to use?

The binding defines all details that are needed

25




IMT

SOAP Binding on HTTP I<?xml version="1.0"?><wsdl:definitions name="purchaseExample" targetNamespace="…/purchaseExample.wsdl" xmlns:tns="…/purchaseExample.wsdl" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"> <wsdl:types> … </wsdl:types> <wsdl:message name="purchaseMessage"> … </wsdl:message><!– PORT TYPES --> <wsdl:portType name="purchaseType"> <wsdl:operation name="purchaseOperation"> <wsdl:input message=“tns:purchaseMessage” /> </wsdl:operation> </wsdl:portType>

26




IMT

They are different!

SOAP Binding on HTTP II

HTTP

ex. SOAP, HTTP e SMTP





<wsdl:binding name="purchaseBinding"

type="tns:purchaseType">

<soap:binding style="document"

transport="http://schemas.xmlsoap.org/soap/http" />

<wsdl:operation name="tns:purchaseOperation">

<wsdl:input>

<soap:body use="literal" />

</wsdl:input>

</wsdl:operation>

</wsdl:binding>

</wsdl:definitions>

27




IMT

Endpoints (Ports) Once defined the binding to the transport

protocol we can link the method call to a specific IP address the binding defined the communication protocol, but

not the address of the machine hosting the service sych information is given by the element

wsdl:endpoint (called wsdl:port in WSDL v1)

An endpoint contains a name a binding a network address

28




IMT





<wsdl:binding name=“purchaseBinding” type=“tns:purchaseType”>

<soap:binding style=“document” transport=“…/http” />

<wsdl:operation name=“tns:purchaseOperation”>

<wsdl:input> <soap:body use=“literal” /> </wsdl:input>

</wsdl:operation>

</wsdl:binding>



<wsdl:port name=“Purchase_ServicePort”

binding=“tns:purchaseBinding”>

<soap:address

location=“http://www.fluidimagination.com:8080/soap/servlet/rpcrouter” />

</wsdl:port>

</wsdl:definitions>

Example: Going Further on Previous Example

29




IMT

Services Now we have all ingredients

the only thing left is to combine them in a single offert

analogous to a whole Java class

The element wsdl:service is the very first element exposed to the interest of users who get the .wsdl document it groups all endpoints it allows the server to check if the services really

supports all the required operations

30




IMT





<wsdl:binding name=“purchaseBinding” type=“tns:purchaseType”>

…

</wsdl:binding>



<wsdl:service name=“Purchase_Service”>

<documentation>blah blah blah</documentation>

<wsdl:port binding=“tns:purchaseBinding”

name=“Purchase_ServicePort”>

<soap:address location=“…” />

</wsdl:port>

</wsdl:service>

</wsdl:definitions>

Example: for the Last Time

full example

31




IMT

Summary

WSDL v1 Java

types classes without methods

messages parameters, return value, errors

port types and operations interfaces

bindings remote communication protocol

services and ports remote classes

32




IMT

A WSDL v2 Example:GreatH Hotel Reservation I

Hotel GreatH is located in a remote island for years it has been relying on fax/phone

reservations now, even though the facilities and prices at

GreatH are better than what its competitor offers, GreatH notices that its competitor is getting more customers than GreatH

after research, GreatH realizes that this is because the competitor offers a Web service that permits travel agent reservation systems to reserve rooms directly over the Internet

33




IMT

A WSDL v2 Example:GreatH Hotel Reservation II

GreatH then wants to build a reservation Web service with the following functionalities:

CheckAvailability the client must specify a check-in date, a check-out date, and room type the Web service will provide the room rate if such a room is available If any input data is invalid, the service should return an error The service will accept a checkAvailability message and return a

checkAvailabilityResponse or invalidDataFault message MakeReservation

the client must provide a name, address, and credit card information the service will return a confirmation number if the reservation is

successful the service will return an error message if the credit card number or any

other data field is invalid The service will accept a makeReservation message and return a

makeReservationResponse or invalidCreditCardFault message.

34




IMT

A WSDL v2 Example:GreatH Hotel Reservation III

GreatH knows that later the WS will need to support transactions and secured transmission

but initially we consider the implementation of only minimal functionality to simplify the example, we will consider

only the CheckAvailability operation GreatH.wsdl

35




IMT

Using WSDL in a UDDI Registry

WSDL complements the UDDI standard by providing a uniform way of describing

the abstract interface and protocol bindings

of arbitrary network services Next, we try to clarify the relationship between the two

describe how WSDL can be used in UDDI business service descriptions

WSDL service descriptions can be structured in multiple ways

if the reusable information is separated from the information that is specific to a given service instance, the use of WSDL and UDDI together becomes particularly simple

36




IMT

Authoring UDDI Service Descriptions I

The first step is to create the WSDL service interface definition

Typically, industry groups will define a set of service types, and describe them with one or more service interface definition WSDL documents

The service interface definition will include service interfaces and protocol bindings, and will be made publicly available

The WSDL service interface definitions are then registered as a special kind of UDDI tModels, called “wsdlSpec tModels”

the overviewDoc field in each new tModel will point to the corresponding WSDL document

37




IMT

Authoring UDDI Service Descriptions II

Next, programmers will build services that conform to the industry standard service definitions either manually or using appropriate UDDI-aware

tooling, programmers will retrieve the tModel description of the industry standard definition

following the overviewDoc link they will obtain the corresponding WSDL document

WSDL-aware tooling, in turn, can help generate an implementation

(that supports the standard interfaces and bindings)

38




IMT

Authoring UDDI Service Descriptions III

Finally, the new service must be deployed and registered in the UDDI repository either manually or using WSDL/UDDI-aware tooling,

a UDDI businessService data structure is created, and then registered

Typically when using WSDL/UDDI-aware tools, some type of “deployment descriptor” document will be generated at that same time

39




IMT

Import Element The <import location="..."> element in WSDL allows the

separation of elements of service description into two parts service interface definition (SInt) service implementation definition (SImp)

Typically, information common to a certain category of business services, such as

message formats, portTypes (abstract interfaces), and protocol bindings,

are included in the reusable portion (SInt), while information pertaining to a particular service endpoint

(i.e., port definition) is included in the other portion (SImp) Within the context of UDDI,

we will be concerned only with the reusable portion

40




IMT

WSDL and UDDI:Monolithic Approach

Relevant UDDI Structures: businessService

bindingTemplate how and where the service is accessed it specifies a network endpoint address (in the accessPoint

element) and a stack of tModels describing the service one tModelInstanceInfo inside the tModelInstanceDetails

element for each relevant tModel tModel, aka service type definition

one for each interface/portType classified using uddi-org:types taxonomy, as being of type

"wsdlSpec" must have an overviewDoc whose overviewURL points to

the WSDL document defining the interface/portType

41




IMT

Sketch of businessService Structure<businessService> (...) <bindingTemplates> <bindingTemplate> (...) <accessPoint urlType="http"> http://www.etc.com/ </accessPoint> <tModelnstanceDetails> <tModelnstanceInfo tModelKey="..."> </tModelnstanceInfo> (...) </tModelnstanceDetails> </bindingTemplate> (...) </bindingTemplates></businessService>

42




IMT

WSDL document containing the definition of the interface

classified with type "wsdlSpec" according to the uddi-org:types taxonomy

Example: tModel <tModel authorizedName="..." operator="..." tModelKey="...">

<name>StockQuote Service</name>

<description xml:lang="en">

WSDL description of a standard stock quote service interface

</description>

<overviewDoc>

<description xml:lang="en">WSDL source document.</description>

<overviewURL>http://stockquote-definitions/stq.wsdl</overviewURL>

</overviewDoc>

<categoryBag>

<keyedReference tModelKey="uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4"

keyName="uddi-org:types"

keyValue="wsdlSpec"/>

</categoryBag>

</tModel>

43




IMT

network endpoint address

reference to the tModelin the previous slide

Example: businessService <businessService businessKey="..." serviceKey="..."> <name>StockQuoteService</name> <description> (...) </description> <bindingTemplates> <bindingTemplate> (...) <accessPoint urlType="http"> http://example.com/stockquote </accessPoint> <tModelnstanceDetails> <tModelnstanceInfo tModelKey="..."> </tModelnstanceInfo> <tModelnstanceDetails> </bindingTemplate> </bindingTemplates></businessService>

44




IMT

WSDL and UDDI:Modular Approach

The Monolithic approach can be replaced by an expanded modelling that encompasses the flexibility and reusability

of WSDL fine grain "taxonomy-zation" of WSDL artefacts

portType/interface binding service

port/endpoint

45




IMT

Modular Mapping: Overview


IMT

1 ws technologies ii wsdl roberto bruni dipartimento di informatica università di pisa models and...

Documents

imt lucca

elements of wsdl

orchestration contents

wsdl documents

ws technologies

specific ws wsdl

orchestration types

wsdl v1 associations