Web Service Overview
This first section provides the underlying information and concepts required to successfully implement Web Services. Before employing Web Services, you should understand which problems they are designed to solve and the motivation behind them. This should ensure that you apply Web Services in appropriate places in your application.
What Is a Web Service?
A Web Service is essentially an application component that can be accessed using Web protocols and data encoding mechanisms—primarily HTTP and XML. In some cases, this is a third-party service hosted remotely. A Web Service differs from a traditional component in several ways, not only in the protocols used to access it. Under the component model, a currency conversion component could bring with it a file containing a fixed set of currency conversion rates that must be updated regularly. However, it would be up to you (the component user) to ensure that this information is updated. On the other hand, a Web Service is (or should be) a “living” entity, such that it brings with it any data and “back-end” functionality it requires. Unlike the component, a currency conversion Web Service takes responsibility for any updating of data or functionality. Your application simply uses the conversion service and leaves the details of obtaining the latest data and subsidiary services to those who implement and host the service.
Similarly, a Web Service can represent a courier service or a credit-card processing service. Again, you do not need to concern yourself with how the service is implemented, simply the results of using the service. Many types of Web Services are appearing that provide a sliding scale of functionality from low-level infrastructure to high-level business services.
Applications can be built from services in a similar way to building applications from components. You will combine standard services (such as credit-card authorization) with custom code to create your desired application.
As a software developer, you might write Web Services for others to use. In this case you would
Decide what functionality you wish to expose as a service.
Implement the service being offered.
Describe the service being offered.
Publish the description.
Inform direct consumers of your Web Service that it is available (or wait for them to discover it).
Alternatively, you may use Web Services as part of your application as follows:
Discover an interesting service.
Retrieve the description.
Plug it into your application.
Use the service as the application executes.
This all sounds very easy, but you need a ubiquitous framework for Web Services to stop this from sliding into chaos. The key factor in delivering such a framework is the widespread agreement to use common, Web-based protocols. In the first instance, this comes down to the use of the Simple Object Access Protocol (SOAP), under which XML-encoded messages are sent over some form of transport mechanism—usually HTTP. SOAP is the way in which Web Services communicate. Other protocols are also required to deliver the full framework, and you will encounter these protocols over the course of the next two days.
Why Use Web Services?
Web Services bring similar advantages to the use of components. Using a service allows you to take advantage of another organization's expertise in, say, credit-card processing, without you having to become a specialist in it yourself. The service model enables you to use the most powerful and up-to-date functionality by connecting to a remote running service.
Although a service-based approach to application development is not a new concept, it has traditionally presented difficult challenges:
Interoperability between different distribution mechanisms, such as CORBA, RMI, and DCOM.
Application integration, including legacy systems, cross-vendor, and cross-version.
Web-based business requires cross-organization development and high flexibility to accommodate a rapid rate of change, and safe operation through company firewalls.
Web Services can provide a consistent, cross-organization, cross-vendor framework that will speed up the integration of applications and application components. By selecting existing, widely-used standards, the Web Service framework removes many barriers to integration that existed when using other frameworks. The Web Service model is language- and platform-neutral, so developers anywhere can potentially build and consume Web Services.
Probably the most important factor of all is that all the major application, platform, and technology vendors have adopted the Web Service concept and the associated protocols. This means that Web Services will form a large part of application development over the next few years.
Web Service Technologies and Protocols
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.