Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Web services


Published on

Published in: Technology
  • Be the first to comment

Web services

  2. 2. LEARNING OUTCOMES  At the end of this class, YOU should be able to : Describe the role of web services  List component of web services  List the specifications used to make web services platform independent
  3. 3. DISTRIBUTED COMPUTING ISSUE  Software application written in various languages  Running on multiple platform  Data exchange problem  Issue : To exchange data over the internet using similar manner to inter process communication in a single computer.
  4. 4. WHAT IS A WEB SERVICE?  Can be defined as : software functionality that can be invoked through the internet using common protocols  A remote component resides in remote web server  Something like a remote function that can be called by a program through a web server  Accept parameters and produce results (service output)  Service output often not HTML rather XML, text or other contents type  Allow application developed using different languages to exchange information
  7. 7. ROLE OF WEB SERVICE  Expose a remote service or executable procedure to a client application  Service requestor  Web services are designed to be platform independent  No CPU, OS or programming language specific is required for web services  Leverage existing technology  Extensive use of HTTP and XML  Interoperable across disparate programming language  It is possible a client written in one programming language communicating with server written in different language
  8. 8. WHERE WEB SERVICES ARE USED?  Within an enterprise (Enterprise Application Integration)  Accelerate and reduce cost of integration  Cost saving on infrastructure deployment and management  Reduce skill requirements  Improve reuse  Between enterprises (E-business integration, B2B)  Providing service to company’s customers  Accessing services from company partners and suppliers  Reduce standard barriers
  9. 9. WEB SERVICE CONTEXT World Wide Web Components Web Service Distributed Objects Standards
  10. 10. WEB SERVICE CONCEPTUAL ARCHITECTURE Service Registry Find Service Requestor Service Description Publish Bind Service Provider Servic e Service Description
  11. 11. WEB SERVICES CORE XML SPECIFICATION  Web Services Definition Language (WSDL)  Simple Object Access Protocol (SOAP)  Universal Description, Discovery and Integration (UDDI)
  12. 12. WEB SERVICE COMPONENT - ARCHITECTURE MAPPING Service Service Registry Find Description In UDDI Publish Using SOAP Service Requestor Bind In Your Language Service Provider Servic e Service Description In WSDL
  13. 13. RELATIONSHIP BETWEEN STANDARDS Searching for a service (UDDI) UDDI Link to WSDL document Web Service Contract Agreement (WSDL) Client Web Service WSDL Web Service Contract Communication (SOAP) XML/SOAP Body
  14. 14. INTERACTION BETWEEN WEB SERVER AND CLIENT UDDI Directory Registered Web Service Web Service Provider white 1. Declare service to UDDI yellow Web Server WSDL WSDL Description Description Web Servic e 2. Client look for a service in UDDI register 3. Download WSDL service to generate proxy or stub for the web service Web Servic e WSDL Description Busines s Object Generated Stub Web Service Client 3. Client invoke web service through proxy sending/receiving SOAP message Application Server Busines s Object Busines s Object Busines s Object EAI & Connector yellow Back Office and Enterpris e System
  15. 15. WEB SERVICE DEFINITION LANGUAGE (WSDL)  Web service need to be defined in order to be discovered by and interfaced with other services and application  WSDL : defined a web service and how to access them  Define the location of the service  The operations the service exposes  Communicates using open protocols  Can be discovered using UDDI
  16. 16. WSDL DOCUMENT STRUCTURE  Abstract Part : describes  The message it sends and receives  The operation associates a message exchange pattern with one or more message  Concrete Part: specifies WSDL Specification Abstract Part types messages operations port types  Transport and wire format details for one or more interfaces  A port (end point) associates a network address with a binding  A service which groups together end points that implement a common interface Concrete Part bindings services and ports
  17. 17. WSDL DOCUMENT STRUCTURE <definitions> <types>Define data types used by the web service</types> <message>A group of related input/output </message> <portType> The operation performed by the web services </portType> <binding> The element defines the message format and protocol details for each port </binding> <service>Define operation expose by each port</service> </definition>
  18. 18. <message>  A group of related input and output messages  <message> define parts and its associated type <message name = “OrderMsg”> <part name=“productName” type=“xs:string” /> <part name=“quantity” type=“xs:integer” /> </message> <message name = “OrderResponseMsg”> <part name=“orderId” type=“xs:integer” /> </message>
  19. 19. <portType>  Elements that defines operations which are made up of messages  The operation performed by the web services  Comparable to a library in traditional programming <portType name=“procurementPortType”> <operation name=“orderGoods”> <input message=“OrderMsg” /> <output message=“OrderResponseMsg” /> </operation> </portType>
  20. 20. COMPARABLE TO TRADITIONAL PROGRAMMING  “procurementPortType” is comparable to function library  “orderGoods” is comparable to a function with “OrderMsg” as input parameter and “OrderResponseMsg” as return type
  21. 21. OPERATION TYPE Type Definition One-way The operation can receive a message but will not return a response The operation can receive a request and will return a response The operation can send a request and will wait for a response The operation can send a message but will not wait for a response Request-response Solicit-response Notification
  22. 22. REQUEST-RESPONSE <message name = “OrderMsg”> <part name=“productName” type=“xs:string” /> <part name=“quantity” type=“xs:integer” /> </message> <message name = “OrderResponseMsg”> <part name=“orderId” type=“xs:integer” /> </message> <portType name=“procurementPortType”> <operation name=“orderGoods”> <input message=“OrderMsg” /> </operation> </portType>
  23. 23. ONE WAY OPERATION <message name = “OrderMsg”> <part name=“productName” type=“xs:string” /> <part name=“quantity” type=“xs:integer” /> </message> <portType name=“procurementPortType”> <operation name=“orderGoods”> <input message=“OrderMsg” /> <output message=“OrderResponseMsg” /> </operation> </portType>
  24. 24. <binding>  This element defines the message format and protocol details for each port  Attributes in <bindings>  type : name of port type  name : bindings name  Sub Element of <bindings>  soap:binding  style: “rpc” / “document”  transport (Communication protocol: SOAP, Transport protocol : HTTP/SMTP)  operation:  Define operation that the port exposes  Must specify how input and output encoded
  25. 25. <binding> <binding name=“ProcurementSoapBinding” type=“tns:procurementPortType”> <soap:binding style=“document” transport=“” /> <operation name=“orderGoods” > <soap:operation soapAction=“” /> <input> <soap:body use=“literal” /> </input> <output> <soap:body use=“literal” /> </output> </operation> </binding>
  26. 26. <service>  A service may have more than one end point, with each one defined by its own port  The port elements corresponds to a particular binding and includes information on how to access it. <service name=“ProcurementService”> <port name=“ProcurementPort” binding=“tns:ProcurementSoapBinding”> <soap:address location=“” /> </port> </service>
  27. 27. <?xml version="1.0"?> <definitions name="Procurement" targetNamespace="" xmlns:tns="" xmlns:xs="" xmlns:soap="" xmlns="" > <message name="OrderMsg"> <part name="productName" type="xs:string"/> <part name="quantity" type="xs:integer"/> </message> <binding name="ProcurementSoapBinding" type="tns:procurementPortType"> <soap:binding style="document" transport=""/> <operation name="orderGoods"> <soap:operation soapAction=""/> <input> <soap:body use="literal"/> </input> <output> <soap:body use="literal"/> </output> </operation> </binding> <service name="ProcurementService"> <port name="ProcurementPort" binding="tns:ProcurementSoapBinding"> <soap:address location=""/> </port> </service> </definitions> messages operation and port type concrete part binding port and service Copyright Springer Verlag Berlin Heidelberg 2004 <portType name="procurementPortType"> <operation name="orderGoods"> <input message = "OrderMsg"/> </operation> </portType> abstract part
  28. 28. UNIVERSAL DESCRIPTION, DISCOVERY AND INTEGRATION (UDDI)  UDDI – platform independent framework to  describe services,  discover businesses,  integrate business services by using the Internet  Directory for storing information about web services  Directory of web service interfaces described by WSDL  Communicates via SOAP
  29. 29. SIMPLE OBJECT ACCESS PROTOCOL (SOAP)  SOAP is a protocol for accessing a Web Service  Communication protocol  For communication between applications  Format for sending messages
  30. 30. WHY SOAP?  RPC is used to communicate between objects like CORBA and DCOM  HTTP is not designed for this  RPC represents a compatibility but with drawbacks.  Security problem -firewalls and proxy servers will normally block this kind of traffic  SOAP is a better way to communicate between application using HTTP  HTTP is supported by all web browsers
  31. 31. SOAP DOCUMENT STRUCTURE  Envelope SOAP ENVELOPE  element that identifies the XML document as a SOAP message  Header  element that contains header information  Body  element that contains call and response information  Fault  element containing errors and status information Header Body Fault
  32. 32. SOAP DOCUMENT STRUCTURE <?xml version="1.0"?> <soap:Envelope xmlns:soap="" soap:encodingStyle=""> <soap:Header> Contains application-specific information about the SOAP message </soap:Header> <soap:Body> Contains the actual SOAP message <soap:Fault> Used to indicate error messages </soap:Fault> </soap:Body> </soap:Envelope>
  33. 33. <soap:Envelope>  Root element of a SOAP message  Defines the XML document as a SOAP message defines the Envelope as a SOAP Envelope <?xml version="1.0"?> <soap:Envelope xmlns:soap="" soap:encodingStyle= > • </soap:Envelope> • • Used to define the data types used in the document May appear on any SOAP element, and applies to the element's contents and all child elements A SOAP message has no default encoding
  34. 34. <soap:Header>  Contains application-specific information (like authentication, payment, etc) about the SOAP message  Attributes of <soap:Header>  mustUnderstand  actor  encodingStyle defines how a recipient should process the SOAP message
  35. 35. mustUnderstand  Indicate whether a header entry is mandatory or optional for the recipient to process  Syntax = soap:mustUnderstand="0|1"  1 : the SOAP server and the node that receives the message containing the header block must be able to process it correctly or issue an appropriate fault messsage <soap:Header> <m:Trans xmlns:m="" soap:mustUnderstand="1">234 </m:Trans> </soap:Header>
  36. 36. actor  Used to address the Header element to a specific endpoint <soap:Header> <m:Trans xmlns:m="" soap:actor="">234 </m:Trans> </soap:Header>
  37. 37. <soap:Body>  Contains the actual SOAP message requests the price of apples <soap:Body> applicationspecific elements <m:GetPrice xmlns:m=""> <m:Item>Apples</m:Item> </m:GetPrice> </soap:Body>
  38. 38. <soap:Body>  Contains the actual SOAP message <soap:Body> applicationspecific elements <m:GetPrice xmlns:m=""> <m:Item>Apples</m:Item> </m:GetPrice> </soap:Body>
  39. 39. A RESPONSE COULD LOOK LIKE <?xml version="1.0"?> <soap:Envelope xmlns:soap="" soap:encodingStyle=""> <soap:Body> <m:GetPriceResponse xmlns:m=""> <m:Price>1.90</m:Price> </m:GetPriceResponse> </soap:Body> </soap:Envelope>
  40. 40. <soap:Fault>  To indicate error messages  Must appear as a child element of the Body element.  A Fault element can only appear once in a SOAP message
  41. 41. <soap:Fault> SUB ELEMENTS Sub Element Description <faultcode> A code for identifying the fault <faultstring> A human readable explanation of the fault <faultactor> Information about who caused the fault to happen <detail> Holds application specific error information related to the Body element
  42. 42. <soap:Fault> <faultcode>SOAP-ENV:Client</faultcode> <faultstring>Message does not have necessary info</faultstring> <faultactor></faultactor> <detail> <PO:order xmlns:PO=""> Quantity element does not have a value</PO:order> <PO:confirmation xmlns:PO=""> Incomplete address: no zip code</PO:confirmation> </detail>
  43. 43. <soap:Fault> CODES Error Description VersionMismatch Found an invalid namespace for the SOAP Envelope element MustUnderstand An immediate child element of the Header element, with the mustUnderstand attribute set to "1", was not understood The message was incorrectly formed or contained incorrect information There was a problem with the server so the message could not proceed Client Server
  44. 44. BINDING SOAP WITH A TRANSFER PROTOCOL  SOAP binding describes how a SOAP message is carried in a transport protocol (eg., HTTP, SMTP or FTP).  For example, to bind SOAP to HTTP:  A SOAP request is wrapped inside an HTTP POST  The HTTP POST request species at least two HTTP headers:  Content-Type and  Content-Length.  Content-Type: defines the MIME type for the SOAP message and the character encoding (optional) used  Content-Length: specifies the number of bytes in the body of the SOAP request or response.  Example POST /stockquote HTTP/1.1 Content-Type: text/xml; charset=utf-8 Content-Length: 482
  45. 45. BINDING SOAP WITH A TRANSFER PROTOCOL Service Provider HTTP Post Request SOA P Engin e HTTP Engin e HTTP Response SOAP Envelope SOAP Envelope SOAP Header SOAP Header SOAP Body SOAP Body Method Request Name Method Return param1 Return param param2 Service Requestor SOA P Engin e HTTP Engin e
  46. 46. Host: Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAPAction: "Some-URI“ <?xml version="1.0"?> <soap:Envelope xmlns:soap="" soap:encodingStyle= > <soap:Header> <m:Trans xmlns:m="" soap:mustUnderstand="1">234 </m:Trans> </soap:Header> <soap:Body> <m:GetPrice xmlns:m=""> <m:Item>Apples</m:Item> </m:GetPrice> </soap:Body> </soap:Envelope> BINDING SOAP TO HTTP REQUEST POST /StockQuote HTTP/1.1
  47. 47. Content-Type: text/xml; charset="utf-8" Content-Length: nnnn <?xml version="1.0"?> <soap:Envelope xmlns:soap="" soap:encodingStyle=""> <soap:Body> <m:GetPriceResponse xmlns:m=""> <m:Price>1.90</m:Price> </m:GetPriceResponse> </soap:Body> </soap:Envelope> BINDING SOAP TO HTTP RESPONSE HTTP/1.1 200 OK