1 / 20

Web Services Basics

This resource explores the foundational concepts of web services, focusing on the integration of HTTP and CGI, and the limitations of using CGI alone for complex data types. It discusses advanced mechanisms such as SOAP for request handling and XML for data representation, as well as the role of WSDL for interface description and UDDI for service discovery. Additionally, it outlines important submission deadlines and milestones for papers related to these topics, aiming to provide a comprehensive overview of web application development in a J2EE environment.

zelda-turner
Télécharger la présentation

Web Services Basics

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 Basics EECS600 Internet Applications Michael Rabinovich

  2. HTTP + CGI = Web Services? • URLs allow to encode arguments to a program • Web servers can specify that a URL invokes an executable • Exposes API for the executable to communicate with the Web server • Standard ways to pass arguments from HTTP request to executable • Standard ways to pass results from executable to HTTP response

  3. CGI is not Enough • Hard to pass complex data types as arguments • Hard to use between executables • Involves extensive human interaction • Involves manual integration and ad-hoc implementation of caller

  4. Web Services Main Building Blocks • XML as data format • SOAP as invocation mechanism • WSDL as interface description • UDDI for service discovery • Web applications server • Servlet API (alternative to CGI) • J2EE environment

  5. Why XML?

  6. <H2> Important Dates </H2> Note: all deadlines are firm! <UL> <LI>Abstracts due: January 5, 2004</LI> <LI>Full papers due: January 12, 2004</LI> <LI>Decisions due: March 12, 2004</LI> <LI>Final version due: April 12, 2004</LI> <UL> HTML: Syntactic Tags Tags reflect document structure and appearance <I>Milestones</I> <BR><HR> <TABLE> <TR><TD> Submission deadline</TD> <TD>7.2.04.</TD> </TR> <TR><TD> Decision notification</TD> <TD>7.3.04</TD> </TR> <TR><TD> Camera copy due</TD> <TD>12.5.04</TD></TR> </TABLE> www.acm.org/sigmod.html www.computer.org/icde/cpf.html

  7. XML: Semi-Structured Data <deadlines> <preamble> <H2> Important Dates </H2> Note: all deadlines are firm! </preamble> <interest text=“Abstracts due:”> <date>January 5, 2004 </date> </interest> <submission text=“Full papers due:”> <date>January 12, 2004 <date/> </submission> </deadlines> • Self-expressive tags • Content (can be) separated from appearance • Structural restrictions • Suitable for both humans and applications <deadlines> <preamble> Milestones </preamble> <submission text=“Submission deadline:”> <date>7.2.04<date/> </submission> </deadlines>

  8. deadlines preamble interest submission date date PCDATA PCDATA PCDATA XML Trees <deadlines> <preamble> <H2> Important Dates </H2> Note: all deadlines are firm! </preamble> <interest text=“Abstracts due:”> <date>January 5, 2004 </date> </interest> <submission text=“Full papers due:”> <date>January 12, 2004 <date/> </submission> </deadlines>

  9. XML Namespaces . . . <n:passenger xmlns:n="http://mycompany.example.com/employees"> <n:name>Åke Jógvan Øyvind</n:name> </n:passenger> <c:payment xmlns:c="http://creditcompany.com/credit"> <c:name> <c:employee> Åke Jógvan Øyvind</c:employee> <c:company> Mycompany </c:company> </c:name> </c:payment> . . . • Avoiding tag name conflicts

  10. It’s Easier with XML! • Easier to find documents of interest • Keyword queries as before • Structural queries • Easier to extract data from documents • Easier to reformat and construct new documents • Easier to process document in an application

  11. Typical Web Application Scenario (2) Query for service (Obtain UDDI/WSDL files) (1) Register service (UDDI file, WSDLpointers) Middleware Client Server (3) Use WSDL file to write apps (4) SOAP calls

  12. SOAP • XML dialect for specifying Web service requests and responses • Typically, it is XML encoding for RPC • Typically, it is carried over HTTP (“HTTP Binding”) • Web service is identified by a URL • Node providing service • Resource on the node (e.g., service name) • Additional information in request: • Procedure (method) name • Input parameters • Information in response: • (Responding procedure name) • Output parameters • Return code

  13. SOAP Request POST /Reservations HTTP/1.1 Host: travelcompany.com Content-Type: application/soap+xml; charset="utf-8" Content-Length: nnnn <?xml version='1.0' ?> <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" > <env:Header> <t:transaction xmlns:t="http://thirdparty.com/transaction" env:mustUnderstand="true" > 5 </t:transaction> </env:Header> <env:Body> <m:chargeReservation env:encodingStyle="http://www.w3.org/2003/05/soap-encoding" xmlns:m="http://travelcompany.com> <m:reservation <m:code>FT35ZBQ</m:code> </m:reservation> <o:creditCard xmlns:o="http://mycompany.com/financial"> <n:name xmlns:n="http://mycompany.com/employees"> Åke Jógvan Øyvind </n:name> <o:number>123456789099999</o:number> <o:expiration>2005-02</o:expiration> </o:creditCard> </m:chargeReservation> </env:Body> </env:Envelope>

  14. SOAP Response HTTP/1.1 200 OK Content-Type: application/soap+xml; charset="utf-8” Content-Length: nnnn <?xml version='1.0' ?> <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" > <env:Header> <t:transaction xmlns:t="http://thirdparty.com/transaction” env:mustUnderstand="true"> 5 </t:transaction> </env:Header> <env:Body> <m:chargeReservationResponse env:encodingStyle="http://www.w3.org/2003/05/soap-encoding" xmlns:rpc="http://www.w3.org/2003/05/soap-rpc" xmlns:m="http://travelcompany.com/"> <rpc:result>m:status</rpc:result> <m:status>confirmed</m:status> <m:code>FT35ZBQ</m:code> <m:viewAt> http://travelcompany.example.org/reservations?code=FT35ZBQ </m:viewAt> </m:chargeReservationResponse> </env:Body> </env:Envelope>

  15. Options • Message exchange patterns • Request-response • Using HTTP POST method • Both request and response are SOAP messages • Response • For idempotent method invocations • Using HTTP GET • Parameters encoded in a URL • Only response is SOAP • HTTP-based request/response matching

  16. WSDL • Supports automation of SOAP programming • Specifies a Web service: • Abstract message interaction scenarios • “Binding” of abstract messages to physical formats • Service end-point (whom to invoke)

  17. WSDL File Sections • Description attributes • Define namespaces • System namespaces (WSDL, SOAP, WSDL Extensions) • Service-specific namespaces • Documentation • Human-readable description • Types • XML schemas of every message • Interface • Lists operations, and for each operation the in/out messages • Binding • Specifies underlying protocol (HTTP), SOAP message exchange pattern, encoding style (message serialization) • Service • Service URL

  18. <?xml version="1.0" encoding="utf-8" ?> <description xmlns="http://www.w3.org/2005/08/wsdl" targetNamespace= "http://greath.example.com/2004/wsdl/resSvc" xmlns:tns= "http://greath.example.com/2004/wsdl/resSvc"> <documentation>This document describes the GreatH Web service. </documentation> <types> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://greath.example.com/2004/schemas/resSvc" xmlns:ghns ="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:schema> </types> <interface name = "reservationInterface" > <operation name="opCheckAvailability" pattern="http://www.w3.org/2005/08/wsdl/in-out" style="http://www.w3.org/2005/08/wsdl/style/iri"> <input messageLabel="In" element="ghns:checkAvailability" /> <output messageLabel="Out" element="ghns:checkAvailabilityResponse" /> </operation> </interface> <binding name="reservationSOAPBinding" interface="tns:reservationInterface" type="http://www.w3.org/2005/08/wsdl/soap" wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP"> <operation ref="tns:opCheckAvailability" wsoap:mep="http://www.w3.org/2003/05/soap/mep/soap-response"/> </binding> <service name="reservationService" interface="tns:reservationInterface"> <endpoint name="reservationEndpoint" binding="tns:reservationSOAPBinding" address ="http://greath.example.com/2004/reservation"/> </service> </description>

  19. UDDI • Registry for Web services • Human readable contact information • Business categorization • WSDL file or file pointer • Itself uses SOAP to interact with registry

  20. Web Services Readings • Web Services Description Language (WSDL) Version 2.0 Part 0: Primer http://www.w3.org/TR/2005/WD-wsdl20-primer-20050803/ • SOAP Version 1.2 Part 0: Primer http://www.w3.org/TR/2003/REC-soap12-part0-20030624/ • OASIS UDDI Specifications http://www.oasis-open.org/committees/uddi-spec/doc/tcspecs.htm

More Related