Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More neutral standpoint regarding soap #111

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

More neutral standpoint regarding soap #111

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
42 changes: 28 additions & 14 deletions Week01/SOAP.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,34 +1,46 @@
# SOAP

## What.
## Background

SOAP originally stood for Simple Object Access Protocol but that acronym was later drooped, this protocol is used to exchange structured information in web services.
SOAP originally stood for Simple Object Access Protocol but that acronym was later dropped, this protocol is used to exchange structured information in web services.

One of SOAP characteristics is its heavy use of the Xml information set. Other characteristics are extensibility, neutrality and independence.
SOAP was initialy designed in 1998 by Dave Winer, Don Box, Bob Atkinson, and Mohsen Al-Ghosein at Microsoft as an object-access protocol.

SOAP was initialy designed in 1998 by Dave Winer, Don Box, Bob Atkinson, and Mohsen Al-Ghosein for Microsoft.
One of SOAP characteristics is its heavy use of the XML information set. Other characteristics are extensibility, neutrality and independence. Amidst that, it is stateless

## Why.

SOAP was Created to communicate between applications over HTTP. This is a very smart thing to do since HTTP is supported by all Internet browsers and servers.
### Pros

With this form of communication the operating system your application is running on or the programing language it is written in is no longer apart of the equation. That is, no longer a constraint on your system design.
* Language neutrality. SOAP is not dependant on a specific language for development.
* As a result of its language neutrality, a service following the SOAP principle can be platform independant.
* Human readability. SOAP messages are in very simple XML format.
* Scalability. SOAP, like services following other principles such as Rest, uses HTTP for its communication. And so, can be scaled in the same manner.

## Why not.
### Cons

There is this thing called REST.
* SOAP services come with a larger overhead than say Rest, and as a result, tend to run slower. In the event that SOAP's de-facto content type of XML is less preferrable to the communicating client than say, Json, it needs to be parsed by the client.
* WSDL Dependence. SOAP relis on WSDL (Web Services Description Language) for descriptions of its available resources, and does not have any standardized mechanism for dynamic discovery of its available services.

## REST vs SOAP

It is becoming quite apparent that the RESTful Json APIs are becoming more popular than the SOAP ones. One of the biggest advantages REST has over SOAP is its usage of standard http.

REST uses many different data formats while SOAP only uses the boring old Xml. Rest also has better performance and scalability.
###### Content Type
Whereas Rest is inherently flexible when it comes to returning differing dataformats, such as Json, or XML, the SOAP design is constricted to XML. Depending on desired result, this may yield better performance due to less overhead.

###### Security and Data Integrity
At this rate it sounds a little one-sided argument but SOAP has a few advanteges over REST like WS-Security(identity through intermediaries), WS-AtomicTransaction (ACID compliant transactions) and WS-ReliableMessaging(successful/retry logic).

But in the end it is quite apparent that REST is the future and SOAP is slowely becoming history.
In the event ACID transactions are needed over a service, SOAP tends to be the preferred pick. While Restful supports these transactions, they aren't ACID compliant, nor as comprehensive. REST is limited by the HTTP communication form itself which can’t provide two-phase commits across distributed transactional resources. SOAP can however. Though generally, such transactions over the wire find little logical place in most applications, such as ones applying REST principles, it is often a desired mechanic in Enterprise applications.

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

#### Bottomline
While SOAP's design approach may be slightly more dated than the one applied in REST services, they both come with logical pros and cos, which are more attuned to certain conditions and requirements. And so, arguments can be made for the usage of both depending on the nature of the application.


## Helpful resources
## Sources

What is SOAP?
http://careerride.com/SOAP-What-is-SOAP.aspx

SOAP example Request and Response:
http://www.w3schools.com/webservices/ws_soap_example.asp
Expand All @@ -38,3 +50,5 @@ http://www.tutorialspoint.com/soap/

REST vs SOAP:
http://spf13.com/post/soap-vs-rest