1 / 115

Web Services

Web Services. Vagelis Hristidis FIU. What is the “Transactional Web”. Today: “The eye-ball Web” - the architecture of the Web is geared towards delivering information visually.

chavezjohn
Download Presentation

Web Services

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. Web Services Vagelis Hristidis FIU

  2. What is the “Transactional Web” • Today: “The eye-ball Web” - the architecture of the Web is geared towards delivering information visually. • Tomorrow: “The transactional Web” – the architecture of the Web geared towards intelligently exchanging information between applications.

  3. What is the “Transactional Web” • “Web Services” (plural) is a blanket term representing all of the technologies that enable the “transactional web” to exist. • “Web Service” (singular) is a term referring to a collection of application operations accessible over a network using Web Services technologies.

  4. Why do we need Web Services? • Standard way to export functionality • To implement the Semantic Web • Allow agents • Allow communication between applications • Allow searching for available applications • Examples: stock quotes, retail, b2b, libraries,…

  5. WSAH(Web Services Acronym Hell) DIME ebXML XSD XML WSDL JABBER XML-ENC SOAP-SEC SOAP XML-RPC SAML DISCO SOAP-RP XMLP XLANG CPP-CPA DSML UDDI WSFL WSEL P3P DAML-S X-KISS BPEL XKMS PKI XML-DIGSIG DISCO

  6. Roadmap • Web Services Stack • SOAP • WSDL • UDDI • Web Services Composition - BPEL • Issues

  7. The Web Services Stack Wire Protocols Description Discovery SOAP Blocks Agreements SOAP/XMLP Process XML WSDL Extensions HTTP/SMTP/BEEP WSDL Registry (UDDI) TCP/IP XML Inspection The Web Services Stack helps us understand how each of the various pieces fit into the “Big Picture”

  8. The Web Services Stack • Wire Protocols • Primary Role: provide a standard, flexible communications channel • Secondary Role: provide a standard, flexible wire-level data representation • Advantage: interoperability at the lowest level

  9. The Web Services Stack • Description • Primary Role: provide a standard, flexible way to describe what and how a Web service does what it does. • Advantage: interoperability

  10. The Web Services Stack • Discovery • Primary Role: provide a standard, flexible way to discover where a Web service is located and where to find more information about what the Web service does (the description) • Advantage: interoperability, dynamic integration

  11. Choreography - CDL4WS Orchestration - BPEL4WS Web Services Stack BusinessProcesses Transactions Quality ofService Coordination WS-Security WS-Reliability Context Management Discovery UDDI Description Description WSDL SOAP Message XML Transport HTTP,IIOP, JMS, SMTP

  12. Roadmap • Web Services Stack • SOAP • WSDL • UDDI • Web Services Composition - BPEL • Issues

  13. SOAP • SOAP stands for Simple Object Access Protocol • Made up of three major parts • A messaging framework • An encoding standard • An RPC (remote procedure call) framework • It is possible to use just the messaging framework or messaging framework/encoding standard without using the RPC mechanism (though latter is where much of power lies). • SOAP is based entirely on XML

  14. SOAP: Messaging framework • Just defines a generic document type using XML • This document type represents the abstraction of a message • Virtually any type of message you can think of can be packaged as a SOAP message. • However, doing so without RPC mechanisms takes only very small advantage of the features defined in the SOAP standard

  15. General (Basic) Structure SOAP Message SOAP Envelope • Envelope • Defines the content of the message • Header (optional) • Contains destination information, versioning, extensions • Good place for security • Body • Contains payload SOAP Header SOAP Body Payload Document(s) SOAP Fault

  16. General (Basic) Structure SOAP Message <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/encoding/" soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" > <soap:Header> ... ... </soap:Header> <soap:Body> <!-- User request code here --> <soap:Fault> ... ... </soap:Fault> </soap:Body> </soap:Envelope>

  17. SOAP encoding • The second component of SOAP is a standard for how to represent common datatypes as SOAP types. This is knows as the encoding style. • SOAP does this in a language agnostic way, much like CORBA (but not in binary form) • For example, SOAP stipulates that an array of three integers be represented as: SOAP-ENC:Array SOAP-ENC:arrayType="xsd:int[3]"><SOAP-ENC:int>8</SOAP-ENC:int><SOAP-ENC:int>5</SOAP-ENC:int><SOAP-ENC:int>9</SOAP-ENC:int></SOAP-ENC:Array>

  18. SOAP RPC • The third part of SOAP is an RPC mechanism that turns messages into method calls • We have a generic message structure + data. It requires just a little more work to turn the message into a function call. • Must be a way to represent parameters and return values, exceptions, etc.

  19. SOAP RPC cartoon VB application Java application InvoiceVB-Structure InvoiceJava-Structure SOAP client SOAP Server SOAP Message The client application thinks its making a procedure call to a remote module

  20. SOAP protocol bindings • Question:how are SOAP messages transmitted? • Answer: using existing protocols (http, SMTP, etc.) • This has some obvious advantages vs. defining its own protocol • Piggybacks on security model, general robustness • SOAP defines bindings to different protocols that specify how SOAP is used with that protocol to send messages. • http is most popular

  21. Roadmap • Web Services Stack • SOAP • WSDL • UDDI • Web Services Composition - BPEL • Issues

  22. Source • WSDL 1.1 specification • http://www.w3.org/TR/wsdl • WSDL 2.0 working draft, 26 June 2007 • http://www.w3.org/TR/wsdl20/ • W3C School Tutorial • http://www.w3schools.com/wsdl/wsdl_intro.asp

  23. What is WSDL • Web Service Description Language. • An XML language used to describe and locate web services. • Written in XML. • Describe functionality of a web service • Specify how to access the service (binding protocol, message format, and etc.) • Not a W3C standard yet. • Version 1.1 released March 2001 • W3C Recommendation of Version 2.0 released June 2007

  24. Related Standards • Type System: XML Schema • Name space: XML namespaces • Binding: SOAP, HTTP, MIME and etc.

  25. The Main Structure of WSDL <definition namespace = “http/… “> <type> xschema types </type> <message> … </message> <port> a set of operations </port> <binding> communication protocols </binding> <service> a list of binding and ports </service> <definition>

  26. WSDL - Overview <definitions> <types> <!-- XML Schema --> </types> <message name=“getQuote_In” /> <message name=“getQuote_Out” /> <portType name=“StockQuoteServiceInterface”> <operation name=“getQuote”> <input message=“getQuote_In” /> <output message=“getQuote_Out” /> </operation> </portType> <binding name=“StockQuoteServiceBinding” type=“StockQuoteServiceInterface”> <soap:binding transport=“http://schemas.xmlsoap.org/soap/http” /> … </binding> <service name=“StockQuoteService”> <port name=“StockQuoteServicePort” binding=“StockQuoteServiceBinding”> <soap:address location=“http://www.acme.com/services/stockquote” /> </port> </service> </definitions> Definition of data types Definition of messages Definition of port type Definition of the bindings Definition of the service

  27. Types • <types> define types used in message declaration • XML Schema, DTD, and etc. • XML Schema must be supported by any vendor of WSDL conformant products.

  28. <types> <schema targetNamespace="http://example.com/stockquote.xsd" xmlns="http://www.w3.org/2000/10/XMLSchema"> <element name="TradePriceRequest"> <complexType> <all> <element name="tickerSymbol" type="string“ minOccur = “1” maxOccur=“10”/> <element name = “payment”> <complexType> <choice> <element name = “account” type=“string”> <element name = “creditcard” type=“string”> </choice> </complexType> </element> </all> </complexType> </element> </schema> </types>

  29. WSDL Messages • The <message> element defines the data elements of an operation. • Each messages can consist of one or more parts. The parts can be compared to the parameters of a function call in a traditional programming language.

  30. <message name="GetLastTradePriceInput"> <part name="body" element="TradePriceRequest"/> </message> <message name="GetLastTradePriceOutput"> <part name="body" element="TradePrice"/> </message>

  31. WSDL Ports • The <portType> element is the most important WSDL element. • It defines a web service, the operations that can be performed, and the messages that are involved. • The <port> defines the connection point to a web service, an instance of <portType>. • It can be compared to a function library (or a module, or a class) in a traditional programming language. Each operation can be compared to a function in a traditional programming language.

  32. <portType name="StockQuotePortType"> <operation name="GetLastTradePrice"> <input message="tns:GetLastTradePriceInput"/> <output message="tns:GetLastTradePriceOutput"/> </operation> </portType>

  33. Operation Types • The request-response type is the most common operation type, but WSDL defines four types: • One-way: The operation can receive a message but will not return a response • Request-response:The operation can receive a request and will return a response • Solicit-response:The operation can send a request and will wait for a response • Notification:The operation can send a message but will not wait for a response • -- v 1.2 addition • request – multiple response …

  34. One way and Notification Example <portType name=“RegisterPort"> <operation name=“register"> <input name=“customerInfo" message=“RegInfo"/> </operation> <operation name = “register Response”> <output name = “response” message=“ResponseInfo”/> </operation> </portType >

  35. Binding • Binding defines how message are transmitted, and the location of the service.

  36. <binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="GetLastTradePrice"> <soap:operation soapAction="http://example.com/GetLastTradePrice"/> <input> <soap:body use="literal"/> </input> <output> <soap:body use="literal"/> </output> </operation> </binding>

  37. <service name="StockQuoteService"> <documentation>My first service</documentation> <port name="StockQuotePort" binding="tns:StockQuoteBinding"> <soap:address location="http://example.com/stockquote"/> </port> </service>

  38. Roadmap • Web Services Stack • SOAP • WSDL • UDDI • Web Services Composition - BPEL • Issues

  39. WSDL and UDDI • Description of web service. • Discovery of web service? • UDDI – yellow page.

  40. What is UDDI • UDDI is a platform-independent framework for describing services, discovering businesses, and integrating business services by using the Internet. • UDDI stands for Universal Description, Discovery and Integration • UDDI is a directory for storing information about web services • UDDI is a directory of web service interfaces described by WSDL or another description language

  41. UDDI Overview • UDDI is: • A Web Services API for publishing and discovering the existence of Web services • A registry for managing information about Web services • A coalition of organizations working together to manage UDDI registries and to further develop the Web Services API for accessing those registries.

  42. UDDI Overview • UDDI is built around a “Yellow-pages” like data model: Business Entity Identities Business Services Categories Service Bindings TModels

  43. UDDI Overview • TModel = “Technology Model” TModel TModel Instance Abstract metadata definition relating to some aspect of the UDDI registration Implementation specific metadata conforming to a given TModel. TModel = Abstract Class

  44. UDDI Overview • TModels • Categories & Identifiers • Categorization and Identification taxonomies are TModels • Categories and Identifiers are TModel Instances • Keyed Referenced • Name + Value + TModel • Examples: NAICS, UNSPSC, D&B # • WSDL Port Types • WSDL Port Types are TModels • WSDL Services that are bound to a Port Type are TModel Instances • WSFL Business Processes • WSFL Flow Models are TModels • WSFL Global Models are TModel instances TModels represent the extent of UDDI’s semantic description capabilities.

  45. UDDI Overview • UDDI has only limited extensibility through TModels • UDDI was created by IBM, Microsoft and Ariba (many companies have joined the effort) • The intent was to put something together that worked.

  46. UDDI Overview • UDDI Version 1.0 – September 2000 (in production) • UDDI Version 2.0 – June 2001 • UDDI Version 3.0 - In development • UDDI will be presented to a standards body after Version 3.0

  47. How can UDDI be Used • If the industry published an UDDI standard for flight rate checking and reservation, airlines could register their services into an UDDI directory. • Travel agencies could then search the UDDI directory to find the airline's reservation interface. • When the interface is found, the travel agency can communicate with the service immediately because it uses a well-defined reservation interface. (by WSDL)

  48. WSDL in UDDI WSDL UDDI

  49. WSDL in UDDI • Since the service interface represents a reusable definition of a service, it is published in a UDDI registry as a tModel

  50. WSDL in UDDI

More Related