Advancing the Web services stack

A proposed synthesis of IBM's Web services architecture stack and new IBM technologies

IT developers will be interested in Judith M. Myerson's proposed revisions to the IBM Web services architecture stack. In this article, she demonstrates how new standards, particularly Web Services Experience Language (WSXL), Trading Partner Agreement (TPA), WS-Security, and WS-Inspection, can serve as updates to the architecture. Developers could apply these additions to the stack to the development of Web services or even to a plan for Web services life cycle management.


Judith Myerson (, Systems Architect/Engineer

Judith M. Myerson is a systems architect and engineer, and is also a freelance writer. Her areas of interest include middleware technologies, enterprisewide systems, database technologies, application development, network management, distributed systems, component-based technologies, and project management. You can contact her at

developerWorks Contributing author

01 June 2002


In May 2001, IBM's WSCA (Web Services Conceptual Architecture) 1.0 presented the original version of IBM Web Services Stack. To update the stack, in this article I will bring together various standards IBM has been working on and incorporate them into a coherent proposed architecture. They include WS-Security, WS-Inspection, WSXL and TPA (see Resources).

The original IBM Web services architecture stack consisted of the XML, WSDL, SOAP and UDDI standards and which in this article will hereinafter be called the Web services stack. In this article, we will explain how higher-level layers in this Web services stack are built upon the capabilities of the lower levels. I will then propose an update to this stack (hereinafter called the suggested Web services stack), incorporating new and emerging IBM Web services standards for service user interface/presentation, service agreement, and secure messaging layers.

Please note that the stack presented here is merely a suggested architecture; IBM has not endorsed or approved it. However, several IBM staffers gave me excellent suggestions on updating the stack.

Both stacks -- the original IBM stack and the suggested revision -- require three service roles, as shown in Figure 1 below: a service provider, a service client (acting as a service requestor), and a service broker. The service provider publishes a Web service by creating it on an appropriate platform and generating a Web Services Description Language (WSDL) document that describes it. The provider then sends service details to the service broker for storage in a repository. The service client registers with the broker, and searches and finds the appropriate Web service in the broker's repository, retrieving WSDL. It then negotiates with the provider to bind to the provider's Web service.

Figure 1. Web services roles and operations
Web services roles and operations

Current Web services stack

In this section, I will recap the standards and the tools used to implement them at each layer in the Web services stack. We start from the bottommost layer, transport, and work my way up one layer at a time until I reach the final layer, service flow.

Transport layer

As you can see in Figure 2, the transport layer is the foundation of the Web services stack. Web services must be invoked by a service client so they can be accessible to a network. Web services that are publicly available run over the Internet. Only the authorized users within an internal organization can view intranet-available Web services, while unauthorized users in the outside world cannot. It is possible to create extranet-based Web services to allow legitimate users access to them on more than one intranet.

Figure 2. Original Web services stack
Original Web services stack

The Internet protocols that can be supported by this stack are HTTP and, to a lesser extent, SMTP (for electronic mail) and FTP (for file transfer). Intranet domains use middleware call infrastructures, such as IBM's MQSeries, and CORBA (the Common Object Request Broker Architecture). The latter relies on a protocol called the Internet Inter-ORB Protocol (IIOP) for remote objects.

MQSeries name changes

Note that the following MQSeries products have been renamed as part of the consolidation of IBM's middleware product portfolio:

  • MQSeries has been renamed WebSphere MQ.
  • MQSeries Integrator has been renamed WebSphere MQ Integrator.
  • WS BtoBi PAM has been renamed WebSphere Partner Agreement Manager.

XML-based messaging layer

In this layer, SOAP is the messaging protocol for XML. It is built upon the lower layer -- transport -- meaning that SOAP is used singly or in combination with any transport protocols. All SOAP messages support the publish, bind, and find operations in the Web services architecture. SOAP comprises three parts: an envelope to describe the content of a message, a set of encoding rules, and a mechanism for providing remote procedure calls (RPCs) and responses.

IBM, Microsoft, and others submitted SOAP to the W3C as the basis of the XML Protocol Working Group. When the W3C releases a draft standard for the XML protocol, the Web services architecture stack will migrate from SOAP to the XML protocol.

Service description layer

Service description provides the means of invoking Web services. WSDL is the basic standard for defining, in XML format, the implementations and interfaces of services. This means that WSDL divides a service description into two parts: service implementation and service interface. You must create a service interface before you can implement WSDL.

Service publication layer

You need other service description documents to complement WSDL. You can use UDDI data structures to describe business context, for example. You can make a WSDL document available to a service client at any stage of the service client's life cycle. When this happens, the stack moves up to the next layer, service publication. At this layer, the service provider can send a WSDL document directly to a service client via e-mail, for example. This action is known as direct publication. The service provider can also choose to publish the WSDL document to a host-local WSDL registry, or to a public or private UDDI registry. IBM's WSCA specifies how the definitions for two components of WSDL can be derived from the UDDI entries.

Service discovery layer

Service discovery relies on service publication; if a Web service is not or cannot be published, it cannot be found or discovered. The service client can make the service description available to an application at runtime. The service client, for example, can retrieve a WSDL document from a local file obtained through a direct publish. This action is known as static discovery. The service can also be discovered at design or run time using either a local WSDL registry or a public or private UDDI registry.

Service flow layer

Web Services Flow Language (WSFL) is the standard for the service flow layer at the top of the stack. It differs from other standards in the stack in that it looks at business process modeling and workflows. WSFL is used to describe how Web services are to interact in workflows and how they are to perform in service-to-service communications or collaborations. This means that Web services are components of, or can be dynamically orchestrated into, workflows -- between a buyer, a seller, and a shipper, for instance.

For example, WSFL allows a workflow manager to call from a composite Web service each individual Web service with its particular role in a business process; such processes could include managing financial reports, supporting forecasts and budgets in a five-year IT plan, or making a hotel reservation. For instance, in making a hotel reservation, workflow components could include:

  • An enterprise's private Web services collaborating to present a single Web service interface to the public.
  • Different enterprises providing Web services in a collaborative effort to perform business-to-business transactions.

You need a tool, such as IBM MQSeries Workflow (now called WebSphere Process Manager; see the sidebar), to define business processes as a series of activities, and to vary the sequence of these activities as the requirements for business processes change.

Suggested Web services stack

The original Web services stack needs to be updated to incorporate IBM's new standards. This is achieved by the addition of several new layers: a service user interface/presentation layer, a service agreement layer, and a service security layer.Figure 3 illustrates the suggested stack.

Figure 3. Suggested Web services stack
Suggested Web services stack

Let's start with the topmost layer: the service user interface/presentation layer. The standard associated with this layer is called Web Services Experience Language (WSXL), and is used to describe how user experiences should be delivered to end users (for example, through a browser, or a portal, or by embedding into a third party interactive Web application). It is independent of presentation markup.

WSXL logically sits atop the WSFL, as user experiences depend on how Web services are to interact in workflows. The WSFL uses WSDL for the description of service interfaces and their protocol bindings. The service description layer for WSDL consists of two components: the service implementation layer and the service interface layer. The definition for the implementation layer describes how a service provider implements a service interface. You must create a service interface before you can implement WSDL.

WSDL, in turn, relies on the WS-Security specification, which, as the specification itself states, is used to describe "how to attach signature and encryption headers to SOAP messages." (See Resources for the full specification.) Included in the security specifications are other types of message attachments, such as X.509 and Kerberos tickets. IBM's WSCA 1.0 specifies how the WSDL description of the service interface definition and the service implementation definition can be derived from the UDDI entries. This means that UDDI is used as a service registry for WSDL-based services.

When not using UDDI, you may want to use the alternative WS-Inspection as a parallel to the service discovery layer. Both standards provide "directory assistance" via third-party sources. While WS-Inspection primarily supports focused discovery (active search) patterns, along with some unfocused (open-ended browsing) ones, UDDI (static) is limited to focused discovery patterns. Additionally, WS-Inspection has two other characteristics that UDDI does not possess: direct communication (via voice) and simple aggregate token (via business card), both of which are disseminated by the originator.

As you can see in Figure 3, the service agreement layer has been inserted between the service flow and service discovery layers. This new layer, TPA (short for Trading Partner Agreement), describes an agreement between two partners (for example, business IBM Software Group Architecture Overview partners) on how they should interact regarding a service, as specified in the service flow layer. In a procurement/purchase order system, the seller (the service provider), for instance, must have Web services to receive request for quote (RFQ) messages, purchase order (PO) messages, invitation-for-bid (IFB) solicitation query messages, and payment messages. The buyer (the service client) must have Web services to receive RFQ quotes, invoice messages, bid award notification messages, and account summary messages. Between the provider and the client are many steps involved in the workflow of exchanging messages.


In this article, I have suggested an update to IBM's Web services architecture stack that incorporates three new layers: service user interface/presentation (WSEL), service agreement (TPA), and secure messaging (WS-Security). I also have shown how WS-Inspection can be used as an alternative to UDDI's service discovery. The developer should keep these extensions in mind when creating a Web service based on an agreement between two trading partners. This is particularly important when the Web service being created is intended to interface with other Web services that have already been implemented.



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into SOA and web services on developerWorks

Zone=SOA and web services
ArticleTitle=Advancing the Web services stack