Geeks With Blogs
Rajeev Ranjan

1.     SOAP

 

SOAP stands for Simple Object Access Protocol. Here the messages are exchanged based based on Xml format. It’s the format of the data which is sent over the wire in communication.

SOAP message typically looks like:

<?xml version="1.0"?>

<soap:Envelope xmlns:soap="http://www.w3.org/2003/12/soap-envelope">

<soap:Header></soap:Header>

<soap:Body>

                <GetOrders  xmlns: “http://tempuri.org/” >

                                <OrderBY>CustomerId</ OrderBY >

                </GetOrders>

                <soap:Fault> </soap:Fault>

</soap:Body>

</soap:Envelope>

 

 

SOAP has been standard protocol for exchanging message across the systems, technologies and operating systems.

1.1Downside of SOAP:

It is quite verbose to send as simple message as getting Orders for a given person. It uses POST operation for things as simple as getting orders by customer Id. This could be done with GET operation with REST which takes less traffic and is faster.

2.     REST

 

 It stands for Representational State Transfer. This was the term by Roy Thomas in his Phd dissertation. REST is essentially client server architecture with following constraints.

In understand REST we need to first understand the following terms:

Resource:  Resource is anything that can be represented, called from or to by computer. Essentially the request, response of interaction of client and server machine is the resources.

Representation: The way the resources are presented. It can be HTML, XML, JSON or any other serialized format.

State:  All the information which goes back and forth between client and server.

Transfer: Movement of State from client and server and vice versa.

2.1Fundamentals of REST

2.1.1       Separation of Concern

Clients and server can be developed and evolve independent of each other and they need not be dependent on internal structure of the system. This means client and server can be replaced by other. Server is more scalable because it can be designed independent of Client state and interface.

2.1.2       Uniform Interfaces

REST uses the HTTP verbs for the communication between client and server.

HTTP Verb

Purpose

GET

Used to fetch the representation from a resource. The Example showed in section # 1 uses SOAP which is verbose. Using REST and GET verb we can simplify this. See below table.

HEAD

Does not return the representation of resource but the headers like content length, date modified.

PUT

Creates or update an existing resource like upload of a file to server.

POST

Similar to PUT when creating the data on server but here server is in control of creating the data. It is also used in scenario where server needs to initiate any action.

DELETE

It can be used for deleting a resource from the server.

 

Normally with RPC or SOAP style of programming we stress more on methods or services which can be consumed by the client like GetOrdersForCustomer(string customerId), GetCustomers()

But if the same URL is with different HTTP verb, it implies different operations with the server.

 

If we leverage HTTP verbs the interfaces can be simplified using:

SOAP/RPC Style method

REST style Method

HTTP Verb used

Comment

PlaceOrder

Order/768

PUT

New order with # 768

GetOrders

Order/768

GET

Fetch order with # 768

GetOrdersForCustomer

Order/Customer/27

GET

Fetch order for customer # 27

GetCustomers

Customer

GET

Fetch all the customers

CancelOrder

Order/767

DELETE

Removes order # 767

 

Here we can see that variety of operations could be simplified and made less verbose using REST.

2.1.3       Stateless

Interaction between client and server is stateless that means the interaction is highly scalable. Any session specific data is stored in client which is responsible for passing the data to server on required request.

2.1.4       Cacheable

HTTP by design supports the cacheability for all the GET operations. This can also be explicitly or implicitly set on different browsers using the “Cache-control” header in the response for a given request. This cacheability helps in reducing the traffic between client and server.

2.1.5       Indempotent

This behavior of the system in which an operation is called for one or more time, the state of the system does not change.

Let us go with examples:

 

2.1.5.1GET:

If we call GET operation for the URL: http://localhost/ Order/768 more than 1 time it does not change the state of server.

2.1.5.2PUT:

Though PUT may not look idempotent, but it is also idempotent.  Say we upload a file with PUT many a times. The state will remain the same as if we had uploaded the file only once.

2.1.5.3DELETE:

 This is similar to PUT behavior.  Say we deleted some resource using DELETE verb and call it again. On repeated call server may give an error but the state of system do not change after repeated calls.

2.1.5.4POST:

By design POST is not Idempotent. Here some extra plumbing work is required on the server side to make sure repeated calls do not affect the system.

3.     Resource Oriented Architecture

What next? The Service Oriented Architecture (SOA) has been doing good job but its own limitations. Once we apply REST principles to SOA we essentially solve many of the problems of SOA.  SOA created with REST principles lead to Resource oriented architecture.

 

As discussed above we get improvement in terms of interoperability, scalability, greater availability of bandwidth with less traffic.

Posted on Monday, December 30, 2013 11:02 AM SOA , ROA | Back to top


Comments on this post: SOA to ROA

No comments posted yet.
Your comment:
 (will show your gravatar)


Copyright © rajeevr | Powered by: GeeksWithBlogs.net