Web service
Web Design & Development Guide
Web service
Home | Up | Enterprise application integration | Instant messaging | Internet search | Web service specifications | List of web service protocols
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, a description 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.
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.
-
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.
- UDDI
- A protocol for publishing and discovering metadata about Web services,
to enable applications to find Web services, 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
[1].
-
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).
Criticisms
Critics of non-RESTful Web services often complain that they are too complex[1]
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
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, in which a minor change on the server
(even an upgrade of the SOAP stack) can result in different WSDL and a different
service interface. Similarly, the client-side classes that can be generated from
WSDL and XSD descriptions of the service are often 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, because of Web services' use of
XML as a message format and SOAP and HTTP in enveloping and transport. At the
same time, there are also 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 both 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
using HTTP without SOAP.
Notes
External links
Home | Up | Web analytics | Web application | Web service | FastCGI | .htaccess | Hypervideo | Mirror | Website monitoring
Web Design & Development Guide, made by MultiMedia | Websites for sale
This guide is licensed under the GNU
Free Documentation License. It uses material from the Wikipedia.
|
3.144.16.40
User Stats:
Today: 0
Yesterday: 0
This Month: 0
This Year: 0
Total Users: 117
New Members:
3.145.xxx.xx
Server Time:
