Webservices

Web services Architecture:

Web services technology is changing the Internet rapidly, Fully equipped with capabilities to produce the transactional web. Earlier the web is dominated by program-to-user business-to-consumer (B2C) transitions. The transactional web will be limited to program-to-program business-to-business (B2B) exchanges. This transformation is being fueled by the program-to-program communication model of Web services built on existing and emerging standards such as Hypertext Transfer Protocol (HTTP), Extensible Markup Language (XML), Simple Object Access Protocol (SOAP),Web Services Description Language (WSDL), and the Universal Description, Discovery, and Integration (UDDI) project. Web services technologies provide a language-independent, environment-independent programming model that accelerates application integration inside and outside of the enterprise. Application integration through Web services yields flexible loosely coupled business systems. Because Web services are easily applied as
a wrapper technology around existing applications and information technology assets, new solutions can be deployed quickly and recomposed to address new opportunities. As adoption of Web services accelerates, the pool of services will grow, fostering development of more dynamic models of just-in-time application and business integration over the Internet.

http://www.w3.org/TR/ws-arch/


Web services overview

A Web service is an interface that describes a collection of operations that are network-accessible through standardized XML messaging. A Web service performs a specific task or a set of tasks. Web service is described using a standard, formal XML notation, called its service description, that provides all of the details necessary to interact with the service, including message formats (that detail the operations), transport protocols, and location. Web service descriptions are expressed in WSDL. This paper describes Web services in terms of a service-
oriented architecture. As depicted in Figure 1, this architecture sets forth three roles and three operations.

The three roles are the service provider the service requester, and the service registry. The objects acted upon are the service and the service description, and the operations performed by the actors on these objects are publish, find, and bind.















A service provider creates a Web service and its service definition and then publishes the service with a service registry based on a standard called the Universal Description, Discovery, and Integration (UDDI) specification. Once a Web service is published, a service requester may find the service via the UDDI interface. The UDDI registry provides the service requester with a WSDL
service description and a URL (uniform resource locator) pointing to the service itself. The service requester may then use this information to directly bind to the service and invoke it.


Based on the above architecture here is 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.

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 webservices 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 method (not only GET and POST as in version 1.1) so it enables a better implementation of Restful webservices. However support for this specification is still poor.

Criticisms

Critics of non-RESTful Web services often complain that they are too complex and based upon 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, C# or VB 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.




Cited references
1. The document Web Services Conceptual Architecture is located at http://www.ibm.com/software/solutions/webservices/documentation.html.
2. For more information on HTTP from the World Wide Web Consortium, see http://www.w3.org/Protocols/.
3. For more information on SOAP from the World Wide Web Consortium, see http://www.w3.org/TR/SOAP/.
4. For more information on WSDL from the World Wide Web Consortium, see http://www.w3.org/TR/wsdl.
5. The UDDI project is a cross-industry initiative to create an open framework for describing, discovering, and integrating Web services across the Internet. For more information on UDDI, see http://www.uddi.org.
6. For more information on WSFL, see the document titled Web Services Flow Language Guide at http://www.ibm.com/software/solutions/webservices/documentation.html.