![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
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
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.
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
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.
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 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.
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 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.
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.
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
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.
- This paper was based on "Web Services Conceptual Architecture (WSCA) 1.0" by Heather Kreger, IBM Software Group (May 2001); it extends on the ideas presented by there. (Paper is in PDF format).
- Read "Understanding quality of service for Web services" by Anbazhagan Mani and Arun Nagarajan (developerWorks, January 2002) to improve the performance of your Web services.
- "Security in a Web services world: A proposed architecture and roadmap," a joint whitepaper by IBM and Microsoft (developerWorks, April 2002), has information on various security specifications, particularly WS-Security.
- Read "(WSXL) Web Service Experience Language Version 2" (developerWorks, April 2002) to understand how this specification is used to describe user experiences.
- Read "The WS-Inspection and UDDI Relationship" by Microsoft's Keith Ballinger and IBM's William A. Nagy (developerWorks, November 2001) to understand how these two standards are related to one another.
- Check out the WebSphere MQ Family page to learn about Websphere MQ, WebSphere MQ Integrator, MQSeries Everywhere, and Websphere Partner Agreement Manager.
- Read The Complete Book of Middleware, which focuses on the essential principles and priorities of system design and emphasizes the new requirements brought forward by the rise of e-commerce and distributed integrated systems.
- Read Enterprise Systems Integration, Second Edition, to provide yourself with the business insight and the technical know-how that ensures successful systems integration.
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 jmyerson@bellatlantic.net.
Table of contents
Next steps from IBM
WebSphere Portal can help your small and midsize business achieve better website security, along with faster time to value with easily deployable and customizable example Web sites.
- Try: Download a free trial version of IBM WebSphere Portal Express V6.1, which offers collaboration, document management, and secure Web content management.
- Article: This article provides an overview of the WebSphere Portal security architecture, including internet security, and secure connections between clients.
- Tutorial: This tutorial take you through the steps to develop and test your first portlet WebSphere Portal Test Environment.
- Demo: These demos show Web 2.0 features available today within WebSphere Portal, as well as several features planned for the future.
- Buy: IBM WebSphere Portal Express
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
