A web service (also webservice) is defined by the
W3C as "a software system designed to support
interoperable machine-to-machine interaction over a
network. It has an interface described in a machine-processable format (specifically Web Services Description Language
WSDL). Other systems interact with the web service in a manner prescribed by its description using
SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other web-related standards." Web services are frequently just
Internet Application Programming Interfaces (API) that can be accessed over a network, such as the
Internet, and executed on a remote system hosting the requested services. Other approaches with nearly the same functionality as web services are
Object Management Group's (OMG) Common Object Request Broker Architecture (
CORBA),
Microsoft's Distributed Component Object Model (
DCOM) or
Sun Microsystems's Java/Remote Method Invocation (
RMI).
In common usage the term refers to
clients and
servers that communicate over the
Hypertext Transfer Protocol (HTTP) protocol used on the web. Such services tend to fall into one of two camps: Big Web Services and RESTful Web Services. Such services are also referred to as
web APIs.
"Big Web Services" use
Extensible Markup Language (XML) messages that follow the
Simple Object Access Protocol (SOAP) standard and have been popular with traditional enterprise. In such systems, there is often a machine-readable description of the operations offered by the service 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 many
Java and
.NET SOAP frameworks (frameworks such as
Spring,
Apache Axis2 and
Apache CXF being notable exceptions). Some industry organizations, such as the
WS-I, mandate both SOAP and WSDL in their definition of a web service.
More recently,
REpresentational State Transfer web services have been regaining popularity, particularly with Internet companies. By using the PUT, GET and DELETE HTTP methods, alongside POST, these are often better integrated with HTTP and web browsers than SOAP-based services. They do not require XML messages or
WSDL service-API definitions.
A highly dynamic and loosely coupled environment increases not only the probability of deviation situations that occur during the execution of composite services, but also the complexity in exception handling. Due to the distributed nature of SOA, loosely coupled feature of web services, the monitoring and exception handling issues about web services in SOA context is still an open research issue.
When running composite web services, each sub service can be considered autonomous. The user has no control over these services. Also the web services themselves are not reliable; the service provider may remove, change or update their services without giving notice to users. The reliability and fault tolerance is not well supported; faults may happen during the execution. Exception handling in the context of web services is still an open research issue.
Specifications
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 the deployment of profile compliant web services. The WS is the editing
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-Transaction: A way of handling transactions.
- WS-Addressing: Is a standard way to insert address in the SOAP header.
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 paradigms 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.Web Services is a software systems that could published, located and binding in the web using XML protocols.
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
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 functions 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.
Middleware Analysts use
Enterprise Service Buses which combine
message-oriented processing and
Web Services to create an
Event-driven SOA. One example of an open-source
ESB is
Mule.
Representational state transfer
Finally,
Representational State Transfer (REST) attempts to describe architectures which use HTTP or similar protocols by constraining the interface to a set of well-known, standard operations (like GET, POST, PUT, DELETE for HTTP). Here, the focus is on interacting with
stateful resources, rather than messages or operations.An architecture based on REST (one that is 'RESTful') can use WSDL to describe SOAP messaging over HTTP, which defines the operations, can be implemented as an abstraction purely on top of SOAP (e.g., WS-Transfer), or can be created without using SOAP at all.
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 enables a better implementation of
RESTful Web services.However, support for this specification is still poor in
software development kits, which often offer tools only for WSDL 1.1.
Design methodologies
Web services can be written in two ways:
- Developer using bottom up method first writes the implementing class in a programming language and then uses WDSL generating tool to expose its methods as web service[1]. This is often simpler way.
- Developer using top down method first writes the WSDL document and then uses code generating tool to produce the class skeleton that she later completes. This way is more difficult but produces cleaner designs[2].
Criticisms
Critics of non-RESTful Web services often complain that they are too complex
ongoing · WS-Pagecount and based upon large software vendors or integrators, rather than typical
open source implementations. There are open source implementations like
Apache Axis and
Apache CXF.
One key 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, C# or VB code. This is viewed as a feature by the SOAP stack authors (and many users) but it is argued 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
Rethinking the Java SOAP Stack. 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, however emerging XML parsing/indexing technologies, such as
VTD-XML, promise to address those XML-related performance issues.
Similar efforts
Several other approaches exist to solve the set of problems that Web services 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.
See also
References
External links
)============================== --
This entry is from Wikipedia,the leading user-contributed encyclopedia. It may not have been reviewed by professional editors (See full disclaimer)
