Programming Web Services: RPC via SOAP and REST. 2Service-Oriented Computing RPC via SOAP A Web service is typically invoked by sending a SOAP message.

Programming Web Services:RPC via SOAP and REST

2Service-Oriented Computing

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

3Service-Oriented Computing

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

4Service-Oriented Computing

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

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

5Service-Oriented Computing

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 6Service-Oriented Computing

WADL Example

7Service-Oriented Computing

Flickr RESTful Documentation

8Service-Oriented Computing

9Service-Oriented Computing

JSON, and in XML

JSON as Text

10Service-Oriented Computing

JSON in XML

11Service-Oriented Computing

RESTful Atom Publishing Protocol

12Service-Oriented Computing

13Service-Oriented Computing

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

14Service-Oriented Computing

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

Simple B2C Web Service Example

InternetSellCameraWeb Service

Shipping Database

Sales Database

Inventory Database

User

15Service-Oriented Computing

“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?

16Service-Oriented Computing

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!

17Service-Oriented Computing

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!

18Service-Oriented Computing

Requirements

Cross-enterprise processes Exception handling Conversations and long-lived

transactions Contracts among parties involved

REST Principles

19Service-Oriented Computing

SOAP RPC vs. REST

Sample SOAP code to retrieve an employee’s benefits:<SOAP-ENV:Envelope xmlns: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

20Service-Oriented Computing

21Service-Oriented Computing

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