A Web service is a set of related application functions that can be programmatically invoked over the Internet. Web services allow buyers and sellers all over the world to discover each other, connect dynamically, and execute transactions in real time with minimal human interaction.
Web services are self-contained, self-describing modular applications that can be published, located, and invoked across the Web.
Web services are self-contained. On the client side, no additional software is required. A programming language with XML and HTTP client support is enough to get you started. On the server side, a Web server and servlet engine are required. The client and server can be implemented in different environments. It is possible to Web service enable an existing application without writing a single line of code.
Web services are self-describing. The client and server need to recognize only the format and content of request and response messages. The definition of the message format travels with the message; no external metadata repositories or code generation tools are required.
Web services are modular. Simple Web services can be aggregated to form more complex Web services either by using workflow techniques or by calling lower layer Web services from a Web service implementation.
Web Services are platform independent. Web services are based on a concise set of open, XML-based standards designed to promote interoperability between a Web service and clients across a variety of computing platforms and programming languages.
Service roles and interactions
A network component in a Web Services architecture can play one or more fundamental roles: service provider, service broker, and service client.
- Service providers create and deploy their Web services and can publish the availability of their WSDL-described services through a service registry, such as a UDDI Business Registry.
- Service brokers register and categorize published services and provide search services. For example, UDDI acts as a service broker for WSDL-described Web services.
- Service clients use broker services such as the UDDI Business Registry to discover a needed WSDL-described service and then bind to and call the service provider.
Binding involves establishing all environmental prerequisites that are necessary to successfully complete the services. Examples of environmental prerequisites include security, transaction monitoring, and HTTP availability. The relationships between these roles are described in Figure 1.
Figure 1. Service roles and interactions.
http://127.0.0.1:1043/help/topic/org.eclipse.jst.ws.doc.user/concepts/cws.html (eclipse help)
Web services standards
The following standards play key roles in Web services: Universal Description, Discovery and Integration (UDDI), Web Services Description Language (WSDL), Web Services Inspection Language (WSIL), SOAP, and Web Services Interoperability (WS-I). The relationship between these standards is described in Figure 2.
The UDDI specification defines open, platform-independent standards that enable businesses to share information in a global business registry, discover services on the registry, and define how they interact over the Internet. For more information on UDDI, refer to www.uddi.org
WSIL is an XML-based open specification that defines a distributed service discovery method that supplies references to service descriptions at the service provider’s point-of-offering, by specifying how to inspect a Web site for available Web services. A WSIL document defines the locations on a Web site where you can look for Web service descriptions. Since WSIL focuses on distributed service discovery, the WSIL specification complements UDDI by facilitating the discovery of services that are available on Web sites that may not be listed yet in a UDDI registry. A separate topic in this documentation discusses the Relationship between UDDI and WSIL. For more information on WSIL, refer to www.ibm.com/developerworks/webservices/library/ws-wsilspec.html
WSDL is an XML-based open specification that describes the interfaces to and instances of Web services on the network. It is extensible, so endpoints can be described regardless of the message formats or network protocols that are used to communicate. Businesses can make the WSDL documents for their Web services available though UDDI, WSIL, or by broadcasting the URLs to their WSDL via email or Web sites. WSDL is described as a separate topic in this documentation. For more information on WSDL, refer to www.w3.org/TR/wsdl
SOAP is an XML-based standard for messaging over HTTP and other Internet protocols. It is a lightweight protocol for the exchange of information in a decentralized, distributed environment. It is based on XML and consists of three parts:
- An envelope that defines a framework for describing what is in a message and how to process it.
- A set of encoding rules for expressing instances of application-defined data types.
- A convention for representing remote procedure calls and responses.
SOAP enables the binding and usage of discovered Web services by defining a message path for routing messages. SOAP may be used to query UDDI for Web services
Figure 2. Relationships between SOAP, UDDI, WSIL and WSDL.
A service provider hosts a Web service and makes it accessible using protocols such as SOAP/HTTP or SOAP/JMS. The Web service is described by a WSDL document that is stored on the provider’s server or in a special repository. The WSDL document may be referenced by the UDDI business registry and WSIL documents. These contain pointers to the Web service’s WSDL files.
WS-I is an organization designed to promote Web service interoperability across platforms, operating systems, and programming languages. The WS-I Simple SOAP Binding Profile and WS-I Attachments Profile are outlines of requirements to which WSDL and Web service protocol (SOAP/HTTP) traffic must comply in order to claim WS-I conformance. The Web services WS-I validation tools currently support WS-I Simple SOAP Binding Profile 1.0 and the Attachment Profile 1.0. To view the specifications, refer to the WS-I Web site, and under Resources select Documentation: http://www.ws-i.org
Several new Web services standards are also supported by this development environment. These include:
JAX-RPC stands for Java™ API for XML-based RPC, also known as JSR 101. It is a specification that describes Java Application Programming Interfaces (APIs) and conventions for building Web services and Web service clients that use remote procedure calls (RPC) and XML. It standardizes the Java to WSDL and WSDL to Java mappings, and provides the core APIs for developing and deploying Web services and Web service clients on the Java platform. For more information refer to the official specifications.
JSR-109 (Implementing Enterprise Web Services) defines the programming model and run-time architecture to deploy and look up Web services in the Java EE environment; more specifically, in the Web, EJB, and Client Application containers. One of its main goals is to ensure vendors’ implementations interoperate.
http://127.0.0.1:1043/help/topic/org.eclipse.jst.ws.doc.user/concepts/cwsstandards.html (eclipse help)
SOAP vs. REST
There are currently two schools of thought in developing web services: the traditional, standards-based approach (SOAP) and conceptually simpler and the trendier new kid on the block (REST).
Together with WSDL and XML Schema, SOAP has become the standard for exchanging XML-based messages. SOAP was also designed from the ground up to be extensible, so that other standards could be integrated into it–and there have been many, often collectively referred to as WS-*: WS-Addressing, WS-Policy, WS-Security, WS-Federation, WS-ReliableMessaging, WS-Coordination, WS-AtomicTransaction, WS-RemotePortlets, and the list goes on. Hence much of the perceived complexity of SOAP, as in Java, comes from the multitude of standards which have evolved around it. This should not be reason to be too concerned: as with other things, you only have to use what you actually need.
The emergence of the RESTful style of web services was a reaction to the more heavy-weight SOAP-based standards. In RESTful web services, the emphasis is on simple point-to-point communication over HTTP using plain old XML (POX).
Representative State Transfer (REST). REST is an architectural style that can be summed up as four verbs (GET, POST, PUT, and DELETE from HTTP 1.1) and the nouns, which are the resources available on the network (referenced in the URI). The verbs have the following operational equivalents:
HTTP CRUD Equivalent
A service to get the details of a user called ‘dsmith’, for example, would be handled using an HTTP GET to
http://example.org/users/dsmith. Deleting the user would use an HTTP DELETE, and creating a new one would mostly likely be done with a POST. The need to reference other resources would be handled using hyperlinks (the XML equivalent of HTTP’s href, which is XLinks’
xlink:href) and separate HTTP request-responses.
Summary and Pros/Cons
SOAP and RESTful web services have a very different philosophy from each other. SOAP is really a protocol for XML-based distributed computing, whereas REST adheres much more closely to a bare metal, web-based design. SOAP by itself is not that complex; it can get complex, however, when it is used with its numerous extensions (guilt by association).
To summarize their strengths and weaknesses:
*** SOAP ***
· Langauge, platform, and transport agnostic
· Designed to handle distributed computing environments
· Is the prevailing standard for web services, and hence has better support from other standards (WSDL, WS-*) and tooling from vendors
· Built-in error handling (faults)
· Conceptually more difficult, more "heavy-weight" than REST
· More verbose
· Harder to develop, requires tools
*** REST ***
· Language and platform agnostic
· Much simpler to develop than SOAP
· Small learning curve, less reliance on tools
· Concise, no need for additional messaging layer
· Closer in design and philosophy to the Web
· Assumes a point-to-point communication model–not usable for distributed computing environment where message may go through one or more intermediaries
· Lack of standards support for security, policy, reliable messaging, etc., so services that have more sophisticated requirements are harder to develop ("roll your own")
· Tied to the HTTP transport model
Web Services Description Language (WSDL)
WSDL allows a service provider to specify the following characteristics of a Web service:
- The name of the Web service and addressing information
- The protocol and encoding style to be used when accessing the public operations of the Web service
- The type information such as operations, parameters, and data types comprising the interface of the Web service
Web Services Description Language (WSDL) reference
A WSDL document defines services as collections of network endpoints, or ports. In WSDL, the abstract definition of endpoints and messages is separated from their concrete network deployment or data format bindings. This allows the reuse of abstract definitions: messages, which are abstract descriptions of the data being exchanged, and port types which are abstract collections of operations.
The concrete protocol and data format specifications for a particular port type constitutes a reusable binding. A port is defined by associating a network address with a reusable binding, and a collection of ports define a service. Hence, a WSDL document uses the following elements in the definition of network services:
- Types: a container for data type definitions using some type system (such as XSD).
- Message: an abstract, typed definition of the data being communicated.
- Operation: an abstract description of an action supported by the service.
- Port Type: an abstract set of operations supported by one or more endpoints.
- Binding: a concrete protocol and data format specification for a particular port type. The binding is usually SOAP and the encoding and data formatting regulations used (also known as the style) is usually literal (this includes document/literal, and sometimes rpc/literal).
- Port: a single endpoint defined as a combination of a binding and a network address.
- Service: a collection of related endpoints.
- Services: used to aggregate a set of related ports. These are the root elements of all WSDL files.
- Ports: specify an address for a binding, thus defining a single communication endpoint.
- Bindings: specify concrete protocol and data format specifications for the operations and messages defined by a particular port type.
- Port types: a set of abstract operations that each refer to an input message and output messages.
- Operations: input and output messages.
- Messages: represent an abstract definition of the data being transmitted. A message consists of logical parts, each of which is associated with a definition within some type system.
- Parts: a flexible mechanism for describing the logical abstract content of a message.
- Types: describe all the data types used between the client and server. WSDL is not tied exclusively to a specific typing system, but it uses the W3C XML Schema specification as its default choice.
- Import statements: used to associate a namespace with a document location.