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 what problems they are designed to solve and the motivation behind them. This should ensure that you apply Web Services in appropriate places within your application.

What Is a Web Service?

Web Services can be seen as the next stage in the evolution of software. Procedural programming evolved into object-oriented (OO) programming to improve the modelling of system elements and the encapsulation of data and functionality. Component-based development provides a standardized, service-rich framework in which OO functionality can be delivered and built into applications. Web Services takes advantage of common Web protocols to make component instances easily accessible both within and outside an organization.

A Web Service is essentially an application component that can be accessed using Web protocols and data encoding mechanisms, such as HTTP and XML. In some cases, this will be a third-party component hosted remotely. The difference between a Web Service and a traditional component lies not only in the protocols used to access it, but also in that the service can bring its own “live” data and “back-end” functionality with it. An example of this would be a currency conversion service. 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 to ensure that this information is updated. On the other hand, a currency conversion service takes responsibility for this updating. Your application simply makes use of the conversion service and leaves the details of obtaining the required data and subsidiary services to those who implement and host the service.

Similarly, a Web Service may 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. There are many types of Web Services 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 may write Web Services for others to use. In this case you would

Alternatively, you may use Web Services as part of your application as follows:

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), which is a combination of XML and HTTP. SOAP provides the transport mechanism over 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 allows 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, 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 most important of all is the fact that all the major application, platform, and technology vendors have adopted the Web Service concept. 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 the central 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 document-centric, message-style 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) 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) are concerned with describing the workflow between services so that their relationships can be encapsulated as part of an application. More information on WSFL can be found at http://xml.coverpages.org/wsfl.html.

• 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 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 its location are stored in a registry. The Web Service consumer can then retrieve this information and use it to invoke the Web Service.

Some of this consumer/service interaction takes place at design and development time. The interface and service contract information will can be registered, regardless of whether the service is active or not. This information is required by the application builder to create code that uses the Web Service in their 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.

Similarly, the way in which an application interacts with a Web Service will depend on the service. Some services may provide an RPC-style interface based on request/response operations while others may work in a massaging style by exchanging XML-based documents. In either case, the interaction can be synchronous or asynchronous. There is nothing to stop a Web Service from offering out its services in all four combinations.

Service developers will define an interface for their service 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 of the Service Control Manager (SCM) under DCOM.

The services being invoked can be of varying granularity. Web Service mechanisms can be used as a convenient way to integrate existing, fine-grained components. Alternatively, the Web Service being accessed can represent a whole application, such as an ERP system.

Although there is much about the Web Service paradigm that 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. There will be a need for Service-Level Agreements (SLAs) 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.