450 likes | 537 Views
Models and Languages for Coordination and Orchestration IMT- Institutions Markets Technologies - Alti Studi Lucca. WS Technologies I I WSDL. Roberto Bruni Dipartimento di Informatica Università di Pisa. Contents. WSDL Some Java tools. Contents. WSDL Some Java tools.
E N D
Models and Languages for Coordination and Orchestration IMT- Institutions Markets Technologies - Alti Studi Lucca WS Technologies II WSDL Roberto Bruni Dipartimento di Informatica Università di Pisa
Contents • WSDL • Some Java tools Models and Languages for Coordination and Orchestration
Contents • WSDL • Some Java tools Models and Languages for Coordination and Orchestration
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 unambiguousdescription of the WS to be exposed • automatically downloadable, understandable, and usable for connecting to the specific WS • WSDL fixes the standard for such description Models and Languages for Coordination and Orchestration
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 Models and Languages for Coordination and Orchestration
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 • typeddata to be communicated as a single logical transmission • operations • sequences of messagesrelated 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) Models and Languages for Coordination and Orchestration
A View at WSDL Hierarchical Structure • <definitions> • <types> • <message> • <interface> • <operation> • <input> • <output> • <binding> • <service> • <endpoint> Models and Languages for Coordination and Orchestration
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 classwith variables but without methods, in Java • types are necessary to describe the main elements and parameters in a method call Models and Languages for Coordination and Orchestration
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(AddressmyAddress){ //do something } } Models and Languages for Coordination and Orchestration
URI of the Schema current namespace the elements must appear in the specified order The Schema address.xsd <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> Models and Languages for Coordination and Orchestration
URI of Schema Example: address.xsd with Anonymous Types <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> Only if addressType is not used elsewhere Models and Languages for Coordination and Orchestration
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> Models and Languages for Coordination and Orchestration
<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"/> Models and Languages for Coordination and Orchestration
The Type address in WSDL II <!-- ========================== (segue) ========================== --> <xsd:element name="zip" type="xsd:string"/> </xsd:all> </xsd:complexType> </xsd:element> </xsd:schema> </wsdl:types> </wsdl:definitions> Models and Languages for Coordination and Orchestration
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 partfor each parameter Models and Languages for Coordination and Orchestration
type="tns:addressType" type="tns:addressType" alternatively Example: a Message public void order(Address shipTo, Address billTO){ //do something } <?xml version="1.0"?> <wsdl:definitions …> + <wsdl:types> <!-- =================== Aggiungiamo un messaggio =================== --> <wsdl:message name="purchase"> <wsdl:part name="billTo" element="tns:address"/> <wsdl:part name="shipTo" element="tns:address"/> </wsdl:message> </wsdl:definitions> Models and Languages for Coordination and Orchestration
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) Models and Languages for Coordination and Orchestration
<?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> 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. Models and Languages for Coordination and Orchestration
<?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> Request/Response Operations • Both input and output are defined • optionally, an additional fault element • ex. Models and Languages for Coordination and Orchestration
<?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 Models and Languages for Coordination and Orchestration
<?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 Models and Languages for Coordination and Orchestration
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 Models and Languages for Coordination and Orchestration
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> Models and Languages for Coordination and Orchestration
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 Models and Languages for Coordination and Orchestration
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/"> <!-- Types --> <wsdl:types> … </wsdl:types> <!-- MESSAGES --> <wsdl:message name="purchaseMessage"> … </wsdl:message> <!– PORT TYPES --> <wsdl:portType name="purchaseType"> <!-- == OPERATIONS == --> <wsdl:operation name="purchaseOperation"> <wsdl:input message=“tns:purchaseMessage” /> </wsdl:operation> </wsdl:portType> Models and Languages for Coordination and Orchestration
They are different! SOAP Binding on HTTP II <!-- ========================== (segue) ========================== --> <!-- BINDING --> <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> HTTP ex. SOAP, HTTP e SMTP Models and Languages for Coordination and Orchestration
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 Models and Languages for Coordination and Orchestration
Example: Going Further on Previous Example <!-- ========================== (segue) ========================== --> <!-- BINDING --> <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> <!-- PORTS --> <wsdl:port name=“Purchase_ServicePort” binding=“tns:purchaseBinding”> <soap:address location=“http://www.fluidimagination.com:8080/soap/servlet/rpcrouter” /> </wsdl:port> </wsdl:definitions> Models and Languages for Coordination and Orchestration
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 Models and Languages for Coordination and Orchestration
Example: for the Last Time <!-- ========================== (segue) ========================== --> <!-- BINDING --> <wsdl:binding name=“purchaseBinding” type=“tns:purchaseType”> … </wsdl:binding> <!-- SERVICES --> <wsdl:servicename=“Purchase_Service”> <documentation>blah blah blah</documentation> <wsdl:port binding=“tns:purchaseBinding” name=“Purchase_ServicePort”> <soap:address location=“…” /> </wsdl:port> </wsdl:service> </wsdl:definitions> full example Models and Languages for Coordination and Orchestration
Summary Models and Languages for Coordination and Orchestration
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 Models and Languages for Coordination and Orchestration
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 anerror • 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. Models and Languages for Coordination and Orchestration
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 Models and Languages for Coordination and Orchestration
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 Models and Languages for Coordination and Orchestration
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 Models and Languages for Coordination and Orchestration
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 willobtain the corresponding WSDL document • WSDL-aware tooling, in turn, can help generate an implementation • (that supports the standard interfacesandbindings) Models and Languages for Coordination and Orchestration
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 Models and Languages for Coordination and Orchestration
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 beconcerned only with the reusable portion Models and Languages for Coordination and Orchestration
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 insidethe 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 Models and Languages for Coordination and Orchestration
Sketch of businessService Structure <businessService> (...) <bindingTemplates> <bindingTemplate> (...) <accessPoint urlType="http"> http://www.etc.com/ </accessPoint> <tModelnstanceDetails> <tModelnstanceInfo tModelKey="..."> </tModelnstanceInfo> (...) </tModelnstanceDetails> </bindingTemplate> (...) </bindingTemplates> </businessService> Models and Languages for Coordination and Orchestration
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> Models and Languages for Coordination and Orchestration
network endpoint address reference to the tModel in 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> Models and Languages for Coordination and Orchestration
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 Models and Languages for Coordination and Orchestration
Modular Mapping: Overview Institutions Markets Technologies IMT Models and Languages for Coordination and Orchestration