1 / 45

Understanding WSDL: Models and Languages

Learn about Web Services Description Language (WSDL) for coordinating and orchestrating web services. Explore key elements, types, and structure of WSDL documents. Understand how to define message types using XML Schema.

michelle-dillard
Télécharger la présentation

Understanding WSDL: Models and Languages

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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

  2. Contents • WSDL • Some Java tools Models and Languages for Coordination and Orchestration

  3. Contents • WSDL • Some Java tools Models and Languages for Coordination and Orchestration

  4. 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

  5. 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

  6. 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

  7. A View at WSDL Hierarchical Structure • <definitions> • <types> • <message> • <interface> • <operation> • <input> • <output> • <binding> • <service> • <endpoint> Models and Languages for Coordination and Orchestration

  8. 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

  9. 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

  10. 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

  11. 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

  12. 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

  13. <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

  14. 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

  15. 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

  16. 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

  17. 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

  18. <?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

  19. <?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

  20. <?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

  21. <?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

  22. 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

  23. 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

  24. 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

  25. 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

  26. 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

  27. 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

  28. 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

  29. 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

  30. 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

  31. Summary Models and Languages for Coordination and Orchestration

  32. 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

  33. 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

  34. 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

  35. 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

  36. 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

  37. 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

  38. 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

  39. 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

  40. 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

  41. 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

  42. 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

  43. 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

  44. 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

  45. Modular Mapping: Overview Institutions Markets Technologies IMT Models and Languages for Coordination and Orchestration

More Related