Information AboutWeb Service |
| CATEGORIES ABOUT WEB SERVICE | |
| web 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: ;-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. ; 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.
; and XML Signature in SOAP to secure message exchanges, as an alternative or extension to using HTTPS to secure the channel. ; standard protocol for reliable messaging between two Web services. ;, BEA and IBM it is currently being standardized by the OASIS organization {Link without Title} . ; 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.
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 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, REST ful 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 complexhttp://www.tbray.org/ongoing/When/200x/2004/09/21/WS-Research 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. SEE ALSO
NOTES EXTERNAL LINKS
|
|
|