Web Service Technologies and Protocols - Java

The following are some of the more important protocols, technologies, and standards in Web Services:

• The Simple Object Access Protocol (SOAP)—Combines XML and Multipurpose Internet Mail Extensions (MIME) to create an extensible packaging format. The SOAP envelope can be used to contain either RPC-style or message-style (document-centric) service invocations. A SOAP message can be carried over many transport mechanisms, including HTTP, SMTP, and traditional messaging transports. Although SOAP began its life outside the World Wide Web Consortium (W3C), ongoing work on SOAP can be found at http://www.w3.org/2002/ws/. This includes the latest working drafts of the 1.2 specifications, as well as a link to the version 1.1 specification.

• The Web Services Description Language (WSDL)—It is an XML vocabulary used to describe Web Services. It defines operations, data types, and binding information. The WSDL specification can be found at http://www.w3.org/TR/wsdl.

• Universal Description, Discovery, and Integration (UDDI)—Provides a model for organizing, registering, and accessing information about Web Services. The UDDI specifications can be found at http://www.uddi.org/.

• The Web Service Flow Language (WSFL) and Web Service Collaboration Language (WSCL)—These are concerned with describing the workflow between services so that their relationships can be encapsulated as part of an application. The description of interactions between Web Services is also described as choreography. More information on WSFL can be found at http://xml.coverpages.org/wsfl.html. A W3C working group on choreography has been formed and can be monitored at http://www.w3.org/2002/ws/chor/.

• Electronic Business XML (ebXML)—Provides a framework for e-commerce that includes the inter-application workflow and the description and discovery of services. It uses SOAP as its transport mechanism but does not directly use WSDL, UDDI, or WSFL. ebXML is a joint initiative between OASIS and the United Nations CEFACT group. The set of ebXML specifications can be found at http://www.ebXML.org/.

Web Service Architecture

The idealized interaction between a Web Service–based application and the Web Service itself is shown in Figure 20.1. The overall interaction is very similar to the way that a J2EE client uses an EJB. When a Web Service is created, information about its interface and location are stored in a registry. The Web Service consumer can then retrieve this information and use it to invoke the Web Service.

Figure 20.1
Interaction between Web Service, registry, and service consumer.

Some of this consumer/service interaction takes place at design and development time. The interface and service contract information can be registered, regardless of whether the service is active. This information is required by the application builder to create code that uses the Web Service in his application. At runtime, the application can look up the precise location of the Web Service to locate it, very much like a traditional RPC mechanism, such as RMI.

There are several variations on this interaction. A Web Service can be used entirely dynamically in that the service description is discovered and invoked dynamically. Alternatively, the location information discovered at design time as part of the service description can be bound into the client application so that it has no need of the registry at runtime. Indeed, the information about the Web Service might not even be registered in any form of registry. The creator of a Web Service can easily provide service descriptions to potential clients by attaching the necessary WSDL documents to an email message.

Similarly, the way in which an application interacts with a Web Service depends on the service. Some services might provide an RPC-style interface based on request/response operations. In this case, the interface to the Web Service will look like a traditional Remote Procedure Call (RPC) interface as found in Java's RMI. The interaction of an RPC-style Web Service and its clients still uses SOAP messages "under the covers" but it provides a more familiar model for developers to work with. Conversely, other services might work in a message-oriented style by exchanging XML-based documents. In either case, the interaction can be synchronous or asynchronous. There is nothing to stop a Web Service implementation from offering out its services in all four combinations (synchronous RPC-style, asynchronous RPC-style, synchronous message-oriented, and asynchronous message-oriented).

Service developers will define an interface for their services using a description mechanism such as WSDL. This can be based on an existing service implementation, or the service can be developed after the interface is defined.

Application developers will take the service description and write code based on this. In many cases, a client-side proxy will be created for the services and the application will interact with this proxy. However, the precise details of this are left to the client-side developer.

The service implementations will take a variety of forms. On the server-side, an adapter and router will be required to accept inbound SOAP messages and dispatch them to the appropriate service implementation. This performs the role of the Object Request Broker (ORB) in CORBA and RMI or the Service Control Manager (SCM) under DCOM.

The services being invoked can be of varying granularity. You can use Web Service mechanisms to expose fine-grained services, such as currency conversion. However, Web Service protocols are much more suited to exposing coarse-grained services. In some cases these services can represent a whole application, such as an ERP system.

Although much about the Web Service paradigm will seem familiar to you, the use of Web Services, especially third-party Web Services, does bring some extra considerations for developers:

• The fact that the service is hosted elsewhere will impact testing, security, availability, and scalability. Service-Level Agreements (SLAs) will need to be defined for all services used.

• The providers of an external service will have to be paid somehow. There will be associated authentication requirements so that use of the service can be tracked by the providers.