|
Results for Web service
|
On this page:
|
(computer science) A collection of SML-based standards that enable electronic communication and interaction independently of the computer platforms or specific technologies used by the communication parties.
An interface for a service oriented architecture (SOA), in which Web-based applications dynamically interact with other Web applications using open standards that include XML running over HTTP, UDDI and SOAP. Such applications typically run behind the scenes, one program "talking to" another (server to server). Microsoft's .NET and Sun's Java System (J2EE) are the major development platforms that natively support these standards. See SOA.
Private Implementations
Web services have been initially successful in private environments where large enterprises need to exchange data with their divisions and subsidiaries or with partners and clients. In such controlled situations, agreement on the data being passed between Web service components is more easily obtained. In addition, since Web services use open standards, vendors can supply customers with client side software to add to their applications no matter what the platform.
Public Use
Web services over the public Internet are expected to materialize slowly. Using discovery systems such as UDDI, the goal is to register a service on the Internet, allow an application to search for and find the service and then to seamlessly exchange data with it. If the service is fee based, payment processing could be included. Before global Web services can be put into operation, there must be industry agreement on the functions each service component must provide.
CORBA and DCOM
Web services enable software components to interact with each other around the world. In the past, this has only occasionally been realized within private networks using the industry standard CORBA and Microsoft's DCOM distributed component platforms. However, because Web services use protocols that are open and easier to implement, they have a better chance of being widely implemented.
The Buzzword
Although the term became the hot buzzword at the turn of the century, Web services still require cooperation and agreement among people to define business transactions and processes. Web services define only the format, transport and interface standards, not the meaning of the data to be exchanged (see ebXML). See SOA, SOAP, UDDI and XML.
 |
| UDDI is used to register and discover Web services, typically described in WSDL. The UDDI transactions use SOAP to talk to the UDDI server, and then the application uses SOAP to request the Web service. SOAP messages are actually delivered by HTTP and TCP/IP. |
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.
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:
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.
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.
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.
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.
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.
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.
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.
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 enables a better implementation of RESTful Web services[1] . However support for this specification is still poor in software development kits, which often offer tools only for WSDL 1.1.
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.
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.
This entry is from Wikipedia, the leading user-contributed encyclopedia. It may not have been reviewed by professional editors (see full disclaimer)
Join the WikiAnswers Q&A community. Post a question or answer questions about "WEBSERVICES" at WikiAnswers.
Copyrights:
 |
 | Sci-Tech Dictionary. McGraw-Hill Dictionary of Scientific and Technical Terms. Copyright © 2003, 1994, 1989, 1984, 1978, 1976, 1974 by McGraw-Hill Companies, Inc. All rights reserved. Read more |
 |
| Computer Desktop Encyclopedia. THIS COPYRIGHTED DEFINITION IS FOR PERSONAL USE ONLY. All other reproduction is strictly prohibited without permission from the publisher. © 1981-2008 Computer Language Company Inc. All rights reserved. Read more |
 |
| Wikipedia. This article is licensed under the GNU Free Documentation License. It uses material from the Wikipedia article "Web service". Read more |
Be the first to tackle these...
...or improve one of these:
