Introduction to Web Services Technologies: SOA, SOAP, WSDL and UDDI

This chapter is from the book 

• 3.1 Web services and the service-oriented architecture (SOA) page 48

• 3.2 Web Services Description Language (WSDL) page 66

• 3.3 Simple Object Access Protocol (SOAP) page 71

• 3.4 Universal Description, Discovery, and Integration (UDDI) page 80

Before we delve into the concepts and technology behind Web services, let's complete the timeline we began at the beginning of the previous chapter. In 2000, the W3C accepted a submission for the Simple Object Access Protocol (SOAP). This XML-based messaging format established a transmission framework for inter-application (or inter-service) communication via HTTP. As a vendor-neutral technology, SOAP provided an attractive alternative to traditional proprietary protocols, such as CORBA and DCOM.

During the following year, the W3C published the WSDL specification. Another implementation of XML, this standard supplied a language for describing the interface of Web services. Further supplemented by the Universal Description, Discovery, and Integration (UDDI) specification that provided a standard mechanism for the dynamic discovery of service descriptions, the first generation of the Web services platform had been established. Figure 3.1 illustrates, on a high level, the relationship between these standards.

Figure 3.1 The relationship between first-generation specifications.

Since then, Web services have been adopted by vendors and manufacturers at a remarkable pace. Industry-wide support furthered the popularity and importance of this platform and of service-oriented design principles. This led to the creation of a second generation of Web services specifications (discussed in Chapter 4).

3.1 Web services and the service-oriented architecture (SOA)

3.1.1 Understanding services

The concept of services within an application has been around for a while. Services, much like components, are intended to be independent building blocks that collectively represent an application environment. Unlike traditional components, though, services have a number of unique characteristics that allow them to participate as part of a service-oriented architecture.

One of these qualities is complete autonomy from other services. This means that each service is responsible for its own domain, which typically translates into limiting its scope to a specific business function (or a group of related functions).

This design approach results in the creation of isolated units of business functionality loosely bound together by a common compliance to a standard communications framework. Due to the independence that services enjoy within this framework, the programming logic they encapsulate does not need to comply to any one platform or technology set.

3.1.2 XML Web services

The most widely accepted and successful type of service is the XML Web service (from hereon referred to as Web service or, simply, service).

This type of service has two fundamental requirements:

• it communicates via Internet protocols (most commonly HTTP)

• it sends and receives data formatted as XML documents

That's pretty much it. You can write a simple ASP or JSP script that resides on a Web server sending and receiving XML formatted messages via HTTP, and you can go out and get yourself an "I'm Service-Oriented" T-shirt.

Broad acceptance of the Web service design model has resulted in the emergence of a set of supplementary technologies that have become de facto standards. An industry standard Web service, therefore, generally is expected to:

• provide a service description that, at minimum, consists of a WSDL document

• be capable of transporting XML documents using SOAP over HTTP

These technologies do not alter the core functionality of a Web service as much as they do its ability to represent itself and communicate in a standard way. Many of the architectural conventions expressed in this chapter assume that SOAP and WSDL are part of the described Web services framework.

Additionally, it is common for Web services to:

• be able to act as both the requestor and provider of a service

• be registered with a discovery agent through which they can be located

In a typical conversation with a Web service, the client initiating the request is a Web service as well. As shown in Figure 3.2, any interface exposed by this "client service" also qualifies it as a service from which other services can request information. Therefore, Web services do not fit into the classic client-server model. Instead, they tend to establish a peer-to-peer system, where each service can play the role of client or server.

Figure 3.2 Web services swapping roles during a conversation.

3.1.3 Service-oriented architecture (SOA)

As previously mentioned, it is not too much trouble to append an application with a few Web services. This limited integration may be appropriate as a learning experience, or to supplement an existing application architecture with a service-based piece of functionality that meets a specific project requirement. It does not, however, establish a service-oriented architecture.

There is a distinct difference between:

• an application that uses Web services

• an application based on a service-oriented architecture

An SOA is a design model with a deeply rooted concept of encapsulating application logic within services that interact via a common communications protocol. When Web services are used to establish this communications framework, they basically represent a Web-based implementation of an SOA.

The resulting architecture essentially establishes a design paradigm within which Web services are a key building block. This means that when migrating your application architecture to an SOA, you are committing yourself to Web services design principles and the accompanying technologies as core parts of your technical environment.

An SOA based on XML Web services builds upon established XML technology layers, with a focus on exposing existing application logic as loosely coupled services. In support of this model, an SOA promotes the use of a discovery mechanism for services via a service broker or discovery agent.

Figure 3.3 shows how an SOA alters the existing multi-tier architecture by introducing a logical layer that, through the use of standard programmatic interfaces (provided by Web services), establishes a common point of integration.

Figure 3.3 A logical representation of a service-oriented architecture (for a single multi-tier application).

This service integration layer forms the basis of a new model that can extend beyond the scope of a single application to unify disparate legacy platforms into an openly interoperable environment. When Web services are used for cross-application integration (as in Figure 3.4's logical service-oriented integration architecture), they establish themselves as part of the enterprise infrastructure.

Figure 3.4A logical representation of a service-oriented integration architecture.

It is important to understand the increased design complexities introduced by enterprise SOAs. Even more so than in n-tier environments, application designers need to appreciate fully how the introduction of services will affect existing data and business models, especially if current or future EAI initiatives need to comply to a service-oriented model.

As the utilization of services diversifies, the significance of security and scalability requirements are amplified. Well-designed service-oriented environments will attempt to address these challenges with adequate infrastructure, rather than custom, application-specific solutions.

For detailed information about service-oriented architecture design principles, and how SOAs can lead to the evolution of a service-oriented enterprise, see Chapter 14.

3.1.4 Web service roles

Services can assume different roles when involved in various interaction scenarios. Depending on the context with which it's viewed, as well as the state of the currently running task, the same Web service can change roles or be assigned multiple roles at the same time.

Service provider

When acting as a service provider, a Web service exposes a public interface through which it can be invoked by requestors of the service. A service provider promotes this interface by publishing a service description. In a client-server model, the service provider is comparable to the server (Figure 3.5).

Figure 3.5 A service provider receiving a request from a service requestor.

A service provider can also act as a service requestor. For example, a Web service can play the role of service provider when a service requestor asks it to perform a function. It can then act as a service requestor when it later contacts the original service requestor (now acting as a service provider) to ask for status information.

Service requestor

A service requestor is the sender of a Web service message or the software program requesting a specific Web service. As shown in Figure 3.6, the service requestor is comparable to the client within the standard client-server model.

Figure 3.6 A service requestor initiating a request to a service provider.

A service requestor can also be a service provider. For instance, in a request and response pattern, the initiating Web service first acts as a service requestor when initially requesting information from the service provider. The same Web service then plays the role of a service provider when responding to the original request.

Intermediary

The role of intermediary is assumed by the Web service when it receives a message from a service requestor, and then forwards the message to a service provider. Figure 3.7 explains how, during the time that an intermediary processes a message, it too can act as a service provider (receiving the message) and as a service requestor (sending the message forward).

Figure 3.7 An intermediary service transitioning through two roles while relaying a message.

Intermediaries can exist in many different forms. Some are passive, and simply relay or route messages, whereas others actively process a message before passing it on. Typically, intermediaries are allowed only to process and modify the message header. To preserve the integrity of a message, its data should not be altered. (Intermediaries are discussed in more detail in Chapter 9.)

Initial sender

As the Web services responsible for initiating the transmission of a message, initial senders also can be considered service requestors (Figure 3.8). This term exists to help differentiate the first Web service to send a message, from intermediaries also classified as service requestors.

Figure 3.8 The first Web service is identified as the initial sender.

Ultimate receiver

The last Web service to receive a message is the ultimate receiver. As shown in Figure 3.9, these services represent the final destination of a message, and also can be considered service providers.

Figure 3.9 A service acting as the ultimate receiver.

3.1.5 Web service interaction

When messages are passed between two or more Web services, a variety of interaction scenarios can be played out. Following are common terms used to identify and label these scenarios.

Message path

The route along which a message travels is the message path. It must consist of one initial sender, one ultimate receiver, and can contain zero or more intermediaries. Figure 3.10 illustrates a simple message path.

Figure 3.10 A message path consisting of three Web services.

The actual transmission path traveled by a message can be dynamically determined by routing intermediaries. Routing logic may be invoked in response to load balancing requirements, or it can be based on message characteristics and other variables read and processed by the intermediary at runtime. Figure 3.11 explains how a message is sent via one of two possible message paths, as determined by a routing intermediary.

Figure 3.11 A message determined dynamically by a routing intermediary.

Message exchange pattern

Services that interact within a service-oriented environment typically participate in one of a number of predefined message exchange patterns.

Typical patterns include:

• request and response (see Figure 3.12)

  Figure 3.12 Example of a request and response message exchange pattern.

• publish and subscribe

• fire and forget (one-to-one)

• fire and forget (one-to-many or broadcast)

The request and response pattern is more common when simulating synchronous data exchange. The remaining patterns are used primarily to facilitate asynchronous data transfer.

Correlation

Correlation is a technique used to match messages sent along different message paths. As illustrated in Figure 3.13, it is commonly employed in a request and response message exchange pattern, where the response message needs to be associated to the original message initiating the request.

Figure 3.13 Correlation used in a request and response message exchange pattern.

Embedding synchronized ID values within the related messages is a frequently used technique to achieve correlation.

Choreography

Rules that govern behavioral characteristics relating to how a group of Web services interact can be applied as a choreography. These rules include the sequence in which Web services can be invoked, conditions that apply to this sequence being carried out, and a usage pattern that further defines allowed interaction scenarios. The scope of a choreography is typically tied to that of an activity or task (see Figure 3.14 for an example).

Figure 3.14 The interaction sequence of a group of services being governed by a choreography.

Activity

Message exchange patterns form the basis for service activities (also known as tasks). An activity consists of a group of Web services that interact and collaborate to perform a function or a logical group of functions. Figure 3.15 shows a simple service activity.

Figure 3.15 A service activity involving three services.

The difference between a choreography and an activity is that the activity is generally associated with a specific application function, such as the execution of a business task.

3.1.6 Service models

Depending on the extent to which they are utilized, Web services can introduce a great deal of standardization on a number of levels, including:

• application architecture

• enterprise infrastructure

• global data exchange

Despite their contribution to establishing a consistent framework for information interchange, Web services themselves do not come in standard shapes or sizes. A service can be based on one of a number of design models, each with its own role and function.

This book documents a number of the common XWIF design models for Web services (listed in Table 3.1). Consider these a starting point, and feel free to customize them to whatever extent they assist in meeting your requirements. As the overall acceptance of service-oriented designs increases, and as Web services and their associated technology set become more integrated into the IT mainstream, this list is sure to evolve.

Table 3.1. Service models and the locations of their respective descriptions within this book

XWIF Service Model	Location
utility service	Chapter 6
business service	Chapter 6
controller service	Chapter 6
proxy service	Chapter 9
wrapper service	Chapter 9
coordination service (for atomic transactions)	Chapter 9
process service	Chapter 10
coordination service (for business activities)	Chapter 10

3.1.7 Web service description structure

An XML Web service is described through a stack of definition documents that constitute a service description. Figure 3.16 illustrates the relationship between these documents, each of which is described individually, thereafter.

Figure 3.16 Contents of a service description.

Definition documents acts as building blocks for a service description:

• Abstract + Concrete = Service Definition

• Service Definition + Supplementary Definitions = Service Description

Abstract

The description of a Web service interface, independent of implementation details, is referred to as the abstract. Within a WSDL document, this abstract interface definition is primarily made up of the interface and message constructs. It is further supported by the types construct, which is often classified separately. (Descriptions of these elements are provided later in this chapter, as part of the WSDL tutorial.) In a component-based architecture, the service interface is often compared to the Interface Definition Language (IDL) file used to describe a component interface.

Concrete

Specific location and implementation information about a Web service are the concrete parts of a WSDL document, as represented by the binding, service, and endpoint (or port) elements.

Service definition

Generally, the contents of a WSDL document constitute a service definition, which includes the interface (abstract) and implementation (concrete) definitions.

Service description

Often a service description consists of only a WSDL document providing a service definition; however, it can include a number of additional definition documents that can provide supplemental information (such as how this service relates to others).

3.1.8 Introduction to first-generation Web services

The W3C framework for Web services consists of a foundation built on top of three core XML specifications:

• Web Services Description Language (WSDL)

• Simple Object Access Protocol (SOAP)

• Universal Description, Discovery, and Integration (UDDI)

These technology standards, coupled with service-oriented design principles, form a basic XML-driven SOA. This first-generation Web services architecture allows for the creation of independent Web services capable of encapsulating isolated units of business functionality. It also has a number of limitations, which have been addressed in a second generation of specifications. (Key second-generation Web services specifications are introduced through a series of tutorials in Chapter 4.).

The next three sections provide introductory tutorials to each of the first-generation Web services technologies.