Core concepts

SOAP vs.REST

A NordicAPIs infographic

rest vs soap

originORIGIN

origin REST

REST

REST (Representational State Transfer) was Created in 2000 by Roy Fielding in UC, Irvine. Developed in an academic environment, this protocol embraces the philosophy of the open Web.

origin SOAP

SOAP

SOAP (Simple Object Access Protocol), was created in 1998 by Dave Winer et al in collaboration with Microsoft. Developed by a large software company, this protocol addresses the goal of addressing the needs of the enterprise market.

concept_titleBASIC CONCEPT

concept1

REST

Makes data available as resources (nouns), for example “user” or “invoice””

concept2

SOAP

Makes data available as services (verb + noun), for example “getUser” or “PayInvoice”

concept_titlePROS

pros REST

REST

  • Follows the philosophy of the Open Web
  • Relatively easy to implement and maintain
  • Clearly separates client and server implementations
  • Communication isn’t controlled by a single entity
  • Information can be stored by the client to prevent multiple calls
  • Can return data in multiple formats (JSON, XML etc)
pros SOAP

SOAP

  • Follows a formal enterprise approach
  • Works on top of any communication protocol, even asynchronously
  • Information about objects is communicated to clients
  • Security and authorization are part of the protocol
  • Can be fully described using WSDL

cons_titleCONS

cons REST

REST

  • only works on top of the HTTP protocol
  • Hard to enforce authorization and security on top of it
cons SOAP

SOAP

  • Spends a lot of bandwidth communicating metadata
  • Hard to implement and is unpopular among Web and mobile developers
  • Uses only XML

cons_titleWHEN TO USE

concept1

REST

  • When clients and servers operate on a Web environment
  • When information about objects doesn’t need to be communicated to the client
concept1

SOAP

  • When clients need to have access to objects available on servers
  • When you want to enforce a formal contract between client and server

SOAP vs REST when not to useWHEN NOT TO USE

when not to use REST

REST

  • When you need to enforce a strict contract between client and server
  • When performing transactions that involve multiple calls
when not to use SOAP

SOAP

  • When you want the majority of developers to easily use your API
  • When your bandwidth is very limited

REST vs SOAP use casesCOMMON USE CASES

REST use cases

REST

  • Social Media services
  • Social Networks
  • Web Chat services
  • Mobile Services
SOAP use cases

SOAP

  • Financial services
  • Payment gateways
  • Telecommunication services

Reference: http://nordicapis.com/rest-vs-soap-nordic-apis-infographic-comparison/

Why SOAP?

Here are a few reasons you may want to use SOAP.

WS-Security

While SOAP supports SSL (just like REST) it also supports WS-Security which adds some enterprise security features. Supports identity through intermediaries, not just point to point (SSL). It also provides a standard implementation of data integrity and data privacy. Calling it “Enterprise” isn’t to say it’s more secure, it simply supports some security tools that typical internet services have no need for, in fact they are really only needed in a few “enterprise” scenarios.

WS-AtomicTransaction

Need ACID Transactions over a service, you’re going to need SOAP. While REST supports transactions, it isn’t as comprehensive and isn’t ACID compliant. Fortunately ACID transactions almost never make sense over the internet. REST is limited by HTTP itself which can’t provide two-phase commit across distributed transactional resources, but SOAP can. Internet apps generally don’t need this level of transactional reliability, enterprise apps sometimes do.

WS-ReliableMessaging

Rest doesn’t have a standard messaging system and expects clients to deal with communication failures by retrying. SOAP has successful/retry logic built in and provides end-to-end reliability even through SOAP intermediaries.

WS-AtomicTransaction Explained

The following figure shows two instances of WebLogic Server interacting within the context of a Web services atomic transaction. For simplicity, two WebLogic Web service applications are shown.

Figure 3-2 Web Services Atomic Transactions in WebLogic Server Environment

Description of Figure 3-2 follows
Description of “Figure 3-2 Web Services Atomic Transactions in WebLogic Server Environment”

Please note the following:

  • Using the local JTA transaction manager, a transaction can be imported to or exported from the local JTA environment as a subordinate transaction, all within the context of a Web service request.
  • Creation and management of the coordination context is handled by the local JTA transaction manager.
  • All transaction integrity management and recovery processing is done by the local JTA transaction manager.

For more information about JTA, see Programming JTA for Oracle WebLogic Server.

The following describes a sample end-to-end Web services atomic transaction interaction, illustrated in Figure 3-2:

  1. Application A begins a transaction on the current thread of control using the JTA transaction manager on Server A.
  2. Application A calls a Web service method in Application B on Server B.
  3. Server A updates its transaction information and creates a SOAP header that contains the coordination context, and identifies the transaction and local coordinator.
  4. Server B receives the request for Application B, detects that the header contains a transaction coordination context and determines whether it has already registered as a participant in this transaction. If it has, that transaction is resumed and if not, a new transaction is started.

    Application B executes within the context of the imported transaction. All transactional resources with which the application interacts are enlisted with this imported transaction.

  5. Server B enlists itself as a participant in the WS-AtomicTransaction transaction by registering with the registration service indicated in the transaction coordination context.
  6. Server A resumes the transaction.
  7. Application A resumes processing and commits the transaction.

 


Spring Framework Overview

Spring was built on top of the idea of dependency injection and inversion of control. In normal words – instead of having a bunch of classes creating each other and passing each other from one place to another you have a bag of beans. Each bean declares its dependencies (what services do I need to work?) and Spring container resolves this requirements by automatically and automagically wiring everything together.

You have a Service that says (through XML, annotations, constructor signature…) I need DAO interface to work! and Spring is kind enough to find some bean that implements that interface, create it first and pass where it is required.

On that foundation multiple other services were provided (mostly in terms of data access and AOP), but the injection is the core concept.


Spring Framework – Dependency Injection

Any application is composed of many objects that collaborate with each other to perform some useful stuff. Traditionally each object is responsible for obtaining its own references to the dependent objects (dependencies) it collaborate with. This leads to highly coupled classes and hard-to-test code.

For example,consider a Car object.

A Car depends on Wheels, Engine, Fuel, Battery, etc to run. Traditionally we define the brand of such dependent objects along with the definition of the Car object.

Without Dependency Injection (DI) :

class Car{
  private Wheel wh= new NepaliRubberWheel();
  private Battery bt= new ExcideBattery();
  //rest
}

Here, the Car object is responsible for creating the dependent objects.

What if we want to change the type of its dependent object – say Wheel – after the initial NepaliRubberWheel() punctures? We need to recreate the Car object with its new dependency sayChineseRubberWheel(), but only the Car manufacturer can do that.

Then what the Dependency Injection does us for …?

When using Dependency Injection, objects are given their dependencies at run time rather than compile time (car manufacturing time). So that we can now change the Wheel whenever we want. Here, the Dependency (Wheel) can be injected into Car at run time.

After using DI:

class Car{
  private Wheel wh= [Inject an Instance of Wheel at runtime]
  private Battery bt= [Inject an Instance of Battery at runtime]
}

Source: understanding-dependency-injection


Spring Framework – Aspect Oriented Programming (AOP)

Laymans terms so let me give you an example. Let’s say you have a web application, and you need to add error logging / auditing. One implementation would be to go into every public method and add your try catch blocks etc…

Well Aspect oriented says hogwash with that, let me inject my method around your method so for example instead of calling YourClass.UpdateModel(), the system might call,

LoggingHandler.CallMethod() this method might then redirect the call to UpdateModel but wraps it in a try catch block to handle logging errors.

Now the trick is that this redirection happens automagically, through configuration or by applying attributes to methods.

This works for as you said cross cutting things which are very common programing elements that exist in every domain, such as: Logging, Auditing, Transaction Mgmt, Authorization.

The idea behind it is to remove all this common plumbing code out of your business / app tier so you can focus on solving the problem not worrying about logging this method call or that method call.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s