|
The W3C defines a Web service (many
sources also capitalize the second word, as in
Web Services) as "a software system designed
to support interoperable Machine to Machine interaction
over a network." Web services are frequently
just Web APIs that can be accessed over a network,
such as the Internet, and executed on a remote
system hosting the requested services.
The W3C Web service definition encompasses
many different systems, but in common usage the
term refers to clients and servers that communicate
using XML messages that follow the SOAP standard.
Common in both the field and the terminology is
the assumption that there is also a machine readable
description of the operations supported by the
server written in the Web Services Description
Language (WSDL). The latter is not a requirement
of a SOAP endpoint, but it is a prerequisite for
automated client-side code generation in the mainstream
Java and .NET SOAP frameworks. Some industry organizations,
such as the WS-I, mandate both SOAP and WSDL in
their definition of a Web service..
Web
Services Architecture
Web Services Tutorial
Java
Web Services : At a glance
Specifications
Core specifications
The specifications that define Web services are
intentionally modular, and as a result there is
no one document that contains them all. Additionally,
there is neither a single, nor a stable set of
specifications. There are a few "core"
specifications that are supplemented by others
as the circumstances and choice of technology
dictate, including:
SOAP
An XML-based, extensible message envelope format
with "bindings" to underlying protocols.
The primary protocols are HTTP and HTTPS, although
bindings for others, including SMTP and XMPP,
have been written.
Web Services Description Language (WSDL)
An XML format that allows service interfaces to
be described along with the details of their bindings
to specific protocols. Typically used to generate
server and client code, and for configuration.
Universal Description, Discovery, and Integration
(UDDI)
A protocol for publishing and discovering metadata
about Web services that enables applications to
find them, either at design time or runtime.
Most of these core specifications have come from
W3C, including XML, SOAP, and WSDL; UDDI comes
from OASIS.
See List
of Web service specifications for a more complete
listing.
Profiles
To improve interoperability of Web Services, the
WS-I publishes profiles. A profile is a set of
core specifications (SOAP, WSDL, ...) in a specific
version (SOAP 1.1, UDDI 2, ...) with some additional
requirements to restrict the use of the core specifications.
The WS-I also publishes use cases and test tools
to help deploying profile compliant Web Service.
Additional specifications, WS-*
Some specifications have been developed or are
currently being developed to extend Web Services
capabilities. These specifications are generally
referred to as WS-*. Here is a non exhaustive
list of these WS-* specifications.
WS-Security
Defines how to use XML Encryption and XML Signature
in SOAP to secure message exchanges, as an alternative
or extension to using HTTPS to secure the channel.
WS-Reliability
An OASIS standard protocol for reliable messaging
between two Web services.
WS-ReliableMessaging
A protocol for reliable messaging between two
Web services, issued by Microsoft, BEA and IBM
it is currently being standardized by the OASIS
organization.
WS-Addressing
A way of describing the address of the recipient
(and sender) of a message, inside the SOAP message
itself.
WS-Transaction
A way of handling transactions.
Some of these additional specifications have come
from the W3C. There is much discussion around
the organization's participation, as the general
Web and the Semantic Web story appear to be at
odds with much of the Web Services vision. This
has surfaced most recently in February 2007, at
the Web of Services for the Enterprise workshop.
Some of the participants advocated a withdrawal
of the W3C from further WS-* related work, and
a focus on the core Web.
In contrast, OASIS has standardized many Web service
extensions, including Web Services Resource Framework
and WSDM.
Styles of use
Web services are a set of tools that can be used
in a number of ways. The three most common styles
of use are RPC, SOA and REST.
Remote procedure calls
Architectural elements involved in the XML-RPC.RPC
Web services present a distributed function (or
method) call interface that is familiar to many
developers. Typically, the basic unit of RPC Web
services is the WSDL operation.
The first Web services tools were focused on RPC,
and as a result this style is widely deployed
and supported. However, it is sometimes criticised
for not being loosely coupled, because it was
often implemented by mapping services directly
to language-specific function or method calls...
Many vendors felt this approach to be a dead end,
and pushed for RPC to be disallowed in the WS-I
Basic Profile.
Service-oriented architecture
Web services can also be used to implement an
architecture according to Service-oriented architecture
(SOA) concepts, where the basic unit of communication
is a message, rather than an operation. This is
often referred to as "message-oriented"
services.
SOA Web services are supported by most major software
vendors and industry analysts. Unlike RPC Web
services, loose coupling is more likely, because
the focus is on the "contract" that
WSDL provides, rather than the underlying implementation
details.
Representational state transfer
Finally, RESTful Web services attempt to emulate
HTTP and similar protocols by constraining the
interface to a set of well-known, standard operations
(e.g., GET, PUT, DELETE). Here, the focus is on
interacting with stateful resources, rather than
messages or operations.
RESTful Web services can use WSDL to describe
SOAP messaging over HTTP, which defines the operations,
or can be implemented as an abstraction purely
on top of SOAP (e.g., WS-Transfer).
WSDL version 2.0 offers support for binding to
all the HTTP request methods (not only GET and
POST as in version 1.1) so it enable a better
implementation of RESTful Web services[1] . However
support for this specification is still poor in
software development kits for which often offer
tools only for WSDL 1.1.
Criticisms
Critics of non-RESTful Web services often complain
that they are too complex[2] and biased towards
large software vendors or integrators, rather
than open source implementations.
One big concern of the REST Web Service developers
is that the SOAP WS toolkits make it easy to define
new interfaces for remote interaction, often relying
on introspection[clarify] to extract the WSDL
and service API from Java or C# code. This is
viewed as a feature by the SOAP stack authors
(and many users) but it is feared that it can
increase the brittleness of the systems, since
a minor change on the server (even an upgrade
of the SOAP stack) can result in different WSDL
and a different service interface. The client-side
classes that can be generated from WSDL and XSD
descriptions of the service are often similarly
tied to a particular version of the SOAP endpoint
and can break if the endpoint changes or the client-side
SOAP stack is upgraded. Well designed SOAP endpoints
(with handwritten XSD and WSDL) do not suffer
from this but there is still the problem that
a custom interface for every service requires
a custom client for every service.
There are also concerns about performance due
to Web services' use of XML as a message format
and SOAP and HTTP in enveloping and transport.
At the same time there are emerging XML parsing/indexing
technologies, such as VTD-XML, that promise to
address those XML-related performance issues.
Similar efforts
There are several other approaches to the set
of problems that Web services attempts to address,
both preceding and contemporary to it. RMI was
one of many middleware systems that have seen
wide deployment. More ambitious efforts like CORBA
and DCOM attempted to effect distributed objects,
which Web services implementations sometimes try
to mimic.
More basic efforts include XML-RPC, a precursor
to SOAP that was only capable of RPC, and various
forms of HTTP usage without SOAP.
|
