1 / 21

Programming Web Services: RPC via SOAP and REST

Programming Web Services: RPC via SOAP and REST. RPC via SOAP. A Web service is typically invoked by sending a SOAP message to it and receiving a response in the form of another SOAP message The SOAP messages and their contents are not themselves stored anywhere on the Web or accessible

brendy
Download Presentation

Programming Web Services: RPC via SOAP and REST

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. Programming Web Services: RPC via SOAP and REST

  2. RPC via SOAP • A Web service is typically invoked by sending a SOAP message to it and receiving a response in the form of another SOAP message • The SOAP messages and their contents are not themselves stored anywhere on the Web or accessible • Invoking a Web service is like a remote procedure call (RPC) or a database query • Hiding content inside SOAP messages means Web machinery for caching and security checks cannot be used Service-Oriented Computing

  3. Representational State Transfer • REST is an architectural style for networked systems that constrains the connector semantics (not the component semantics) • The Web is a network of hyperlinked resources, which are things identified by a Uniform Resource Identifier (URI) • A URI can be either a Uniform Resource Name (URN) or a Uniform Resource Locator (URL) • A Web application works as a state machine • A client selecting a link is causing a state transition, resulting in receiving the next page (next state) of the application • A RESTful service is a collection of resources identified by baseURI/ID, e.g., hotel rooms accessed by http://rest.com/resources/hotel/123 Service-Oriented Computing

  4. Characteristics of REST • Client-Server • Statelessness: requests cannot take advantage of stored contexts on a server • Great for load balancing • Caching: responses can be labeled as cacheable • Uniform interface – URIs, hypermedia • Layered components • Focus on resources as opposed to methods: • Read, construct, update a resource representation using the http verbs GET, POST, PUT, and DELETE • Well-suited to hypermedia applications Service-Oriented Computing

  5. HTTP Verbs • Popular verbs • Get: query or read a resource (idempotent) • Post: create or update a resource • Put: creates a new resource (idempotent) • Delete: removes a resource • Idempotent operations: no side effects • Multiple executions = one execution • Challenge: the specification imposes requirements but with no way to judge compliance Especially, can use Get and Post instead of much of SOAP Service-Oriented Computing

  6. Web Application Description Language (WADL) A WADL document has the following elements: • Application – overall description, with location of WADL document and other namespaces • Grammars – definitions of XML structures exchanged • Resources – a container for a Resource, which is ID’d by a URI and can have associated Methods • Methods – descriptions of the inputs/outputs applied to HTTP actions on a Resource, often in the form of a request subelement and a response subelement Service-Oriented Computing

  7. WADL Example Service-Oriented Computing

  8. Flickr RESTful Documentation Service-Oriented Computing

  9. JSON, and in XML Service-Oriented Computing

  10. JSON as Text Service-Oriented Computing

  11. JSON in XML Service-Oriented Computing

  12. RESTful Atom Publishing Protocol Service-Oriented Computing

  13. Software for Open Environments • Tempting to simply lift current database and programming techniques for open environments • Popular pitfall encouraged by the tools: • Think of objects (get and set methods) • Invoke them as before even though they are Web services • Poor performance • Tight coupling Service-Oriented Computing

  14. Simple B2C Web Service Example Suppose you want to sell cameras over the Web, debit a credit card, and guarantee next-day delivery • Your application must • update sales database • debit the credit card • send an order to the shipping department • receive an OK from the shipping department for next-day delivery • update an inventory database • Problems: Some steps complete but not all Service-Oriented Computing

  15. “Traditional” B2C Problems • What if the order is shipped, but the debit fails? • What if the debit succeeds, but the order was never entered or shipped? Service-Oriented Computing

  16. Database Approach A traditional database approach works only for a closed environment: • Transaction processing (TP) monitors (such as IBM’s CICS, Transarc’s Encina, BEA System’s Tuxedo) can ensure that all or none of the steps are completed, and that systems eventually reach a consistent state • But what if the user’s modem is disconnected right after he clicks on OK? Did the order succeed? What if the line went dead before the acknowledgement arrives? Will the user order again? The TP monitor cannot get the user into a consistent state! Service-Oriented Computing

  17. Approach for Open Environment • Server application could send email about credit problems, or detect duplicate transactions • Downloaded applet could synchronize with server after broken connection was restored, and recover transaction; applet could communicate using http, or directly with server objects via CORBA/IIOP or RMI • If there are too many orders to process synchronously, they could be put in a message queue, managed by a Message Oriented Middleware server (which guarantees message delivery or failure notification), and customers would be notified by email when the transaction is complete The server behaves like an agent! Service-Oriented Computing

  18. Requirements • Cross-enterprise processes • Exception handling • Conversations and long-lived transactions • Contracts among parties involved Service-Oriented Computing

  19. REST Principles Service-Oriented Computing

  20. SOAP RPC vs. REST Sample SOAP code to retrieve an employee’s benefits: <SOAP-ENV:Envelopexmlns:SOAP ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Header> some data here... </SOAP-ENV:Header> <SOAP-ENV:Body> <GetBenefits> <user>123-45-6789</user> <type>full_time_employee</type> </GetBenefits> </SOAP-ENV:Body> </SOAP-ENV:Envelope> REST equivalent: http://humanresources.com/benefits?user=<USER_SSID>&type=full_time_employee Service-Oriented Computing

  21. Summary • Tools help with low-level details • Agreeing on standards is more important than the standards themselves • Should conceptualize interactions in a manner compatible with the Web architecture • Can simplify from SOAP in many cases • The above is a small point anyway • Bigger challenges are in ensuring larger-scale interactions, ensuring integrity, handling exceptions, … • Sophisticated programming models are emerging Service-Oriented Computing

More Related