- Web services are
application components
- Web services
communicate using open protocols
- Web services are
self-contained and self-describing
- Web services can
be discovered using UDDI
- Web services can
be used by other applications
- HTTP and XML is
the basis for Web services
·
Web services can be published, found, and used on the Web.
·
Web services use XML to code and to decode data, and SOAP to
transport it (using open protocols)
·
WSDL
- WSDL stands for
Web Services Description Language
- WSDL is an
XML-based language for describing Web services.
- WSDL is a W3C
recommendation
SOAP?
- SOAP stands for
Simple Object Access Protocol
- SOAP is a
communication protocol
- SOAP is for
communication between applications
- SOAP is a format
for sending messages
- SOAP
communicates via Internet
- SOAP is platform
independent
- SOAP is language
independent
- SOAP is based on
XML
- SOAP is simple
and extensible
- SOAP allows you
to get around firewalls
- SOAP is a W3C
recommendation
Why SOAP?
It is important for application development to allow Internet
communication between programs.
Today's applications communicate using Remote Procedure Calls
(RPC) between objects like DCOM and CORBA, but HTTP was not designed for this.
RPC represents a compatibility and security problem; firewalls and proxy
servers will normally block this kind of traffic.
A better way to communicate between applications is over HTTP,
because HTTP is supported by all Internet browsers and servers. SOAP was
created to accomplish this.
SOAP provides a way to communicate between applications running
on different operating systems, with different technologies and programming
languages.
Syntax
Rules
Here are some important syntax rules:
- A SOAP message
MUST be encoded using XML
- A SOAP message
MUST use the SOAP Envelope namespace
- A SOAP message
MUST use the SOAP Encoding namespace
- A SOAP message
must NOT contain a DTD reference
- A SOAP message
must NOT contain XML Processing Instructions
UDDI
- UDDI stands for
Universal Description, Discovery and Integration
- UDDI is a
directory service where companies can search for Web services.
- UDDI is
described in WSDL
- UDDI
communicates via SOAP
1. What is differences between RESTful web services and SOAP
web services ?
Ans:Though both RESTful web service and SOAP web service can operate cross platform they are architecturally different to each other, here is some of differences between REST and SOAP:
1) REST is more simple and easy to use than SOAP. REST language is based on use of nouns and verbs (better readability)
2) REST uses HTTP protocol for producing or consuming web services while SOAP uses XML.
Ans:Though both RESTful web service and SOAP web service can operate cross platform they are architecturally different to each other, here is some of differences between REST and SOAP:
1) REST is more simple and easy to use than SOAP. REST language is based on use of nouns and verbs (better readability)
2) REST uses HTTP protocol for producing or consuming web services while SOAP uses XML.
- The SOAP WS is transport protocol neutral.
Supports multiple protocols like HTTP(S), Messaging, TCP, UDP SMTP,
etc.
- The REST is transport protocol specific. Supports only
HTTP or HTTPS protocols.
3) REST is lightweight as compared to SOAP and preferred choice in
mobile devices and PDA's. REST does not need XML parsing, no message header (to
and from), hence less bandwidth
4) REST supports different format like text, JSON and XML while SOAP only support XML.
4) REST supports different format like text, JSON and XML while SOAP only support XML.
- The SOAP WS permits only XML data
format.You define operations, which tunnels through the POST. The focus is
on accessing the named operations and exposing the application logic as a
service.
- The REST permits multiple data formats like XML, JSON
data, text, HTML, etc. Any browser can be used because the REST approach
uses the standard GET, PUT, POST, and DELETE Web operations. The focus is
on accessing the named resources and exposing the data as a service. REST
has AJAX support. It can use the XMLHttpRequest object. Good for stateless
CRUD (Create, Read, Update, and Delete) operations.
GET - represent()
POST - acceptRepresention()
PUT - storeRepresention()
DELETE - removeRepresention()
5) SOAP based reads cannot be cached. REST based reads can be cached. Performs and scales better.
6) Different error handling:
REST: requires HTTP error handling
SOAP: can have user defined error
7) REST only supports synchronous message because of its reliance of HTTP and HTTPS
8) SOAP WS supports both SSL security and WS-security, which adds some enterprise security features like maintaining security right up to the point where it is needed, maintaining identities through intermediaries and not just point to point SSL only, securing different parts of the message with different security algorithms, etc.
The REST supports only point-to-point SSL security. The SSL encrypts the whole message, whether all of it is sensitive or not.
9) The SOAP has comprehensive support for both ACID based transaction management for short-lived transactions and compensation based transaction management for long-running transactions. It also supports two-phase commit across distributed resources.
The REST supports transactions, but it is neither ACID compliant nor can provide two phase commit across distributed transactional resources as it is limited by its HTTP protocol.
10) The SOAP has success or retry logic built in and provides end-to-end reliability even through SOAP intermediaries. REST does not have a standard messaging system, and expects clients invoking the service to deal with communication failures by retrying.
POST - acceptRepresention()
PUT - storeRepresention()
DELETE - removeRepresention()
5) SOAP based reads cannot be cached. REST based reads can be cached. Performs and scales better.
6) Different error handling:
REST: requires HTTP error handling
SOAP: can have user defined error
7) REST only supports synchronous message because of its reliance of HTTP and HTTPS
8) SOAP WS supports both SSL security and WS-security, which adds some enterprise security features like maintaining security right up to the point where it is needed, maintaining identities through intermediaries and not just point to point SSL only, securing different parts of the message with different security algorithms, etc.
The REST supports only point-to-point SSL security. The SSL encrypts the whole message, whether all of it is sensitive or not.
9) The SOAP has comprehensive support for both ACID based transaction management for short-lived transactions and compensation based transaction management for long-running transactions. It also supports two-phase commit across distributed resources.
The REST supports transactions, but it is neither ACID compliant nor can provide two phase commit across distributed transactional resources as it is limited by its HTTP protocol.
10) The SOAP has success or retry logic built in and provides end-to-end reliability even through SOAP intermediaries. REST does not have a standard messaging system, and expects clients invoking the service to deal with communication failures by retrying.
No comments:
Post a Comment