There are a number of additional constraints one can apply on SOA in
order to improve its scalability, performance and, reliability. Below are kind of web service:
Stateless Service
Each message that a consumer sends to a provider must contain all
necessary information for the provider to process it. This constraint
makes a service provider more scalable because the provider does not have
to store state information between requests. This is effectively "service
in mass production" since each request can be treated as generic. It is
also claimed that this constraint improves visibility because any
monitoring software can inspect one single request and figure out its
intention. There are no intermediate states to worry about, so recovery
from partial failure is also relatively easy. This makes a service more
reliable.
Stateful Service
Stateful service is difficult to avoid in a number of situations. One
situation is to establish a session
between a consumer and a provider. A session is typically established for
efficiency reasons. For example, sending a security certificate with each
request is a serious burden for both any consumer and provider. It is much
quicker to replace the certificate with a token shared just between the
consumer and provider. Another situation is to provide customized
service.
Stateful services require both the consumer and the provider to share
the same consumer-specific context, which is either included in or
referenced by messages exchanged between the provider and the
consumer. The drawback of this constraint is that it may reduce the
overall scalability of the service provider because it may need to
remember the shared context for each consumer. It also increases the
coupling between a service provider and a consumer and makes switching
service providers more difficult.
Idempotent Request
Duplicate requests received by a software agent have the same effects
as a unique request. This constraint allows providers and consumers to
improve the overall service reliability by simply repeating the request if
faults are encountered.
Deriving Web Services from SOA
Everyone knows roughly what a "web service" is, but there is no
universally accepted definition. The definition of web service has always
been under hot debate within the W3C Web Services Architecture
Working Group. Despite the difficulty of defining web services, it is
generally accepted that a web service is a SOA with at least the following
additional constraints:
-
Interfaces must be based on Internet protocols such as HTTP,
FTP, and SMTP.
-
Except for binary data attachment, messages must be in XML.
There are two main styles of Web services: SOAP
web services and REST
web services.
SOAP Web services
A SOAP web service introduces the following constraints:
-
Except for binary data attachment, messages must be carried by
SOAP.
-
The description of a service must be in WSDL.
A SOAP web service is the most common and marketed form of web service
in the industry. Some people simply collapse "web service" into SOAP and
WSDL services. SOAP provides "a message construct that can be exchanged
over a variety of underlying protocols" according to the SOAP 1.2
Primer. In other words, SOAP acts like an envelope that carries its
contents. One advantage of SOAP is that it allows rich message exchange
patterns ranging from traditional request-and-response to broadcasting and
sophisticated message correlations. There are two flavors of SOAP web
services, SOAP RPC and
document-centric SOAP web service. SOAP RPC web services are not SOA;
document-centric SOAP web services are SOA.
SOAP RPC Web Services
A SOAP RPC web service breaks the second constraint required by an
SOA. A SOAP RPC Web service encodes RPC (remote procedure calls) in SOAP
messages. In other words, SOAP RPC "tunnels" new application-specific RPC
interfaces though an underlying generic interface. Effectively, it
prescribes both system behaviors and application semantics. Because system
behaviors are very difficult to prescribe in a distributed environment,
applications created with SOAP RPC are not interoperable by nature. Many
real life implementations have confirmed this.
Faced with this difficulty, both WS-I
basic profile and SOAP 1.2 have made the support of RPC optional. RPC
also tends to be instructive rather than descriptive, which is against the
spirit of SOA. Ironically, SOAP was originally designed just
for RPC. It won't be long before someone claims that "SOAP" actually
stands for "SOA Protocol".
REST Web Services
The term
REST was first introduced by Roy Fielding to describe the web architecture. A REST web
service is an SOA based on the concept of "resource". A resource is
anything that has a URI. A resource may have zero or more
representations. Usually, people say that a resource does not exist if no
representation is available for that resource. A REST web service requires
the following additional constraints:
-
Interfaces are limited to HTTP. The following semantics are
defined:
- HTTP GET is used for obtaining a representation of
a resource. A consumer uses it to
retrieve a representation from a URI. Services provided
through this interface must not incur any obligation from consumers.
- HTTP DELETE is used for removing representations of a
resource.
- HTTP POST is used for updating or creating the
representations of a resource.
- HTTP PUT is used for creating representations of a resource.
- Most messages are in XML, confined by a schema written in a
schema language such as XML Schema
from W3C or RELAX NG.
- Simple messages can be encoded with URL encoding.
- Service and service providers must be resources while a consumer
can be a resource.
REST web services require little infrastructure support apart from
standard HTTP and XML processing technologies, which are now well
supported by most programming languages and platforms. REST web services
are simple and effective because HTTP is the most widely available
interface, and it is good enough for most applications. In many cases,
the simplicity of HTTP simply outweighs the complexity of introducing an
additional transport layer.