Many far-reaching claims are being made with regards to Web services. Some in the industry suggest that Web services will make dynamic e-business a reality, will be the next distributed programming paradigm, and will enable the "Holy Grail" of fully distributed Web applications. Component and distributed computing evangelists made those claims before (think CORBA), but these goals remain elusive and unrealized.

As industry observers and participants understand, Web services standards are a moving target. This article will use a layered depiction of the Web Services Stack to examine the more accepted standards at the bottom of the stack, as well as the leading contenders in the murkier waters toward the top. It includes a brief look at some of the competing efforts and several peripheral functional areas that require standardization to enable Web services to achieve its goals. I conclude with some strategies for moving forward in this important area of e-business.

The Players
Almost every major technology company is involved in the Web services standardization effort in one form or another. Many are members of one of the organizations, consortiums, and coalitions that have emerged over the last couple of years. Up to this point, Microsoft and IBM have been driving the more established, lower-level standards. The field becomes much broader and more fragmented when we discuss standards and organizations developing solutions for business process management and workflow.

Currently, the World Wide Web Consortium (W3C) is the primary Web services standardization organization. However, a number of other significant efforts include UDDI.org, OASIS, UN/CEFACT, BPMI.org, and ebXML.

Web Services Stack
The Web Services Stack is an emerging set of open specifications that are either existing Internet standards, or widely accepted specifications that are proceeding through normal procedures to become true standards. It is a layered representation, and the upper layers build on the lower layers. Because the Web Services Stack defines how to construct Web-based solutions, it is fundamental to achieving interoperability (see Figure 1).

Network
At the bottom of the Web Services Stack is the network layer. Distributed applications require a network protocol, which defines the communication mechanism between two concurrent processes.

Hypertext Transfer Protocol
While the concept of Web services is designed to be protocol-independent, the predominant protocol used today is Hypertext Transfer Protocol (HTTP). The ubiquity of HTTP, coupled with its innate ability to navigate firewalls, makes it the most common Web services network protocol. Use of such protocols as SMTP, FTP, or even TCP is possible, but there are currently only a few implementations that support these protocols.

Recently, IBM published a proposal for a reliable messaging protocol called HTTPR. HTTPR builds its reliability on HTTP 1.1, so it includes the benefits of HTTP while ensuring that messages are delivered to their destinationsunimpeded. Reliable messaging is a critical facet of Web services and will undoubtedly appear in some form in the near future, although some may argue whether the network layer is the most appropriate position for its implementation.

XML Messaging
The XML messaging layer includes data representation, data format, and a messaging protocol. The XML messaging layer is generally agreed upon; however, with the ongoing work of the XML Protocol group, it is certain that some refinements are forthcoming.

Data Representation
XML
HTTP is a text-based protocol that is payload-agnostic and therefore lacks a mechanism for representing parameter values in Remote Procedure Calls (RPC). This is where XML, Extensible Markup Language, emerges as an important factor in Web services. XML is a platform-neutral, tagged-data representation language. It allows data to be serialized into a message format that is easily decoded on any platform. XML provides the mechanism for exchanging structured data between network applications.

XML Namespaces
Extensibility is a key element in the data representation layer. In order to support extensibility, the Web Services Stack needs a mechanism to prevent name collisions and allow a program to process only those elements it cares about. Namespaces offer a simple, universal way to distinguish among identically named elements or attributes. To support extensibility, every element and attribute in XML has a namespace URI associated with it.

Data Format
XML Schemas
Web services require a method to define the data types used in Web services messages.

The XML Schema specification standardizes a vocabulary for describing XML data types. The XML Schema specification also defines a set of built-in primitive data types and a mechanism for establishing the type of an element in an XML document.

Messaging Protocol
Simple Object Access Protocol
The Simple Object Access Protocol (SOAP) is generally agreed upon as the messaging protocol. SOAP is a simple and lightweight XML-based mechanism for exchanging structured data among network applications. It consists of three parts:

• An envelope that defines a framework for describing what is in a message;
• A set of encoding rules for expressing instances of application-defined data types; and,
• A convention for representing remote procedure calls and responses.

Service Description
One of the goals of Web services is to allow an application to choose between two or more equivalent services in a standardized manner. The rationale is that, at some point, applications will be built from components implemented as network-enabled services and even be able to dynamically select from these services. The service description layer defines the descriptive mechanism needed to provide enough information for a program to make a decision based on criteria such as quality of service, security, or reliability.

Web Services Description Language
The Web Services Description Language (WSDL) describes what functionality a service provides, where the service is located, and how to invoke the service. The WSDL specification defines seven basic constructs that are intended to be language- and platform-neutral and can be somewhat confusing even though they correspond to more widely known computing nomenclature. Table 1 clarifies these constructs:

WSDL is widely supported although it is not yet a recommendation from the W3C. It is currently under review by the XML Protocol Working Group.

Universal Description, Discovery and Integration
The Universal Description, Discovery and Integration (UDDI) specification defines a data structure standard for representing business service descriptions in XML. UDDI provides higher-level business information that is complementary to the information specified in WSDL. There are four basic structures defined by UDDI:

• Business entity: Information about a business, i.e. name, type, etc.
• Business service: A collection of published Web services.
• Binding template: Access information such as a URL.
• tModel: Technical specifications for the service type, such as interface definitions, message formats, message protocols, and security protocols.

UDDI
UDDI has gained a great deal of momentum in the service publication space. The core component of UDDI is the Business Registry, an XML file used to describe a business entity and its Web services. The UDDI Business Registry is a SOAP-based Web service that provides the interface businesses use to publish their Web services to the registry. The registry is operated as a distributed, replicated service. Currently, IBM and Microsoft operate registry nodes.

Service Discovery
Web services are about machine-to-machine communication. To work effectively, this architecture must have an efficient means of integrating Web-based applications and business processes. The Service Discovery layer addresses these needs by defining the means for accessing and consuming service descriptions.

UDDI
UDDI's considerable momentum in this area is due in large part to the backing of Microsoft, IBM, and Arriba. The UDDI Business Registry contains three types of information - white, yellow, and green pages - that businesses can use to discover a Web service.

• White pages include business name, address, contact, and identifiers, and allow other companies to search the directory by company name.
• Yellow pages include taxonomies of the types of business and provide for the categorization of companies.
• Green pages provide a programmatic description about a service and can include items such as references to specifications for Web services. Green pages also allow companies to interface with other companies in the registry using XML and provide a significant key to automating business processes.

Service Workflow
Business process collaboration and workflow is an essential component for realizing the potential of Web services beyond simple request/response models. This includes the automation and composition of Web services across business boundaries. A critical requirement that will allow inter-enterprise automation and collaboration to succeed is a standardized business protocol for describing these business processes. The service workflow area is very fluid at this time.

Web Services Flow Language
The Web Services Flow Language (WSFL) is a specification for describing business processes. WSFL addresses two types of Web services composition: a business process and a partner interaction. A business process is modeled as a collection of Web services executed in sequence to achieve a particular business goal. A partner interaction describes how the Web services interact with each other. Web services are linked together to indicate the interaction of one Web service with an operation of another Web service's interface.

XLang
XLang is the XML business process language used by Microsoft's BizTalk server. XLang is used to describe the business processes, which are then executed by the BizTalk Orchestration engine at runtime. XLang also allows orchestration of Web services into business processes and composite Web services. One other interesting aspect of XLang is its support for compensating processes - rather than trying to support an expensive two-phase commit protocol, XLang provides a notation for expressing an alternative optimistic model, where actions have explicit compensatory actions that negate the effect of the action.

Microsoft has previously worked with IBM on both the WSDL and UDDI initiatives. And, while they initially created parallel recommendations, it would not be surprising to see IBM and Microsoft jointly agree to submit a proposal to W3C that combines XLang and WSFL in the near future.

Business Process Management Initiative
The Business Process Management Initiative (BPMI) promotes the standardization of common business processes. These processes may span multiple applications, departments, or business partners. The processes may be behind firewalls or accessible via the Internet.

BPMI.org develops open specifications, such as the Business Process Modeling Language (BPML) and the Business Process Query Language (BPQL), that enable standards-based management of e-Business processes with imminent Business Process Management Systems (BPMS).

• The Business Process Modeling Language (BPML) is a metalanguage for the modeling of business processes, just as XML is a metalanguage for the modeling of business data.
• The Business Process Query Language (BPQL) is a management interface to a Process Server, which allows business analysts to query the state and control the execution of process instances managed by the Process Server. This interface is based on SOAP. Process models managed by the Process Repository through the BPQL interface can be exposed as UDDI services for process registration, advertising, and discovery purposes. Both BPML and BPQL are open specifications.

ebXML
ebXML, like the Web Services Stack, is an end-to-end stack of protocols and specifications for conducting electronic business over the Internet using standard technologies. ebXML has been discussed as an alternative to Web services and predates the Web services model. However, while there is some overlap between the two models, ebXML focuses more specifically on EDI-style information exchange.

A more likely scenario is the eventual merger of some proportion between the Web services model and ebXML. UN/CEFACT and OASIS, the groups behind ebXML, recently adopted SOAP as the basis of the ebXML-messaging infrastructure. Also, W3C is actively considering the ebXML specification and will incorporate those aspects of the specification that meet their requirements for a standardized Web services architecture.

JAX Pack
JAX Pack is Sun's effort to encapsulate the various standards in the Java space. A collection of Java APIs for XML, the JAX Pack is designed to support the standard APIs for Web services including SOAP, XMLP, WSDL, and UDDI.

The various APIs that comprise JAX Pack are outlined in Table 2.

e-Business
In addition to the specifications described above, there are additional critical areas that span all layers of the Web Services Stack. These include security, management, quality of service, and transactions. Businesses will require these additional features before Web services will have the capability to transform their business relationships. Mechanisms for attachments, security, authentication, contract management, quality control, and more will need to follow. Two of the most important issues are security and transactions.

Security
The W3C XML Signature Working Group is chartered to develop an XML-compliant syntax used for representing the signature of Web resources and portions of protocol messages and procedures for computing and verifying these signatures. This working group does not address broader XML security issues such as XML encryption and authorization.

The XML Key Management System (XKMS) is an effort to integrate PKI (public key infrastructure) and digital certificates with XML applications. XKMS relies on the XML Signature specification and on anticipated work at W3C on an XML encryption specification. Other initiatives in this area include S2ML (Security Services Markup Language) and AuthXML, which are being unified under the backing of the OASIS XML Security Services committee.

Business Transaction Protocol
Transactions in Web services have a particularly unique set of requirements. The transaction protocol must be able to address long-running, inter-enterprise business transactions while ensuring the reliable coordination of interdependent workflows.

Business Transaction Protocol (BTP) is an XML-based specification for representing and managing these complex, multi-step transactions over the Internet. BTP provides an open specification for XML message interfaces to support coordination of Web services from different Internet trading partners. In addition, BTP defines a model for defining and managing the status of these interactions to guarantee reliable messaging and completion of a business process, regardless of how long it takes to execute.

This protocol was originally developed by BEA and has since been submitted to the OASIS Business Transactions Technical Committee. This committee has the challenging task of defining requirements, evaluating this submission as well as other technologies, and producing a recommended specification for a business transaction protocol that complements existing Web services standards, specifically the ebXML initiative.

Where Do I Go From Here?
I think that you can now appreciate the vast complexity and fluid nature of the Web services space. The logical question becomes, "Should I even start down the Web services road and, if so, where should I start?"

The short answer is "Yes," but tread carefully. Start by learning and getting familiar with the Web Services Stack, the various specifications, and some of the main vendors and their successful and unsuccessful implementations. Depending on your risk adversity, begin to incorporate these principles, specifications, and standards into either internal or external development efforts. However, always follow common design principles and architect these efforts carefully to accommodate the facts that these standards are still evolving and that change is inevitable.

Conclusion
Will Web services succeed where others have failed? A primary factor in determining the extent to which Web services will succeed is that, for the first time since distributed computing became a mainstream concept, a solution is evolving based on open standards that have the potential to truly support interoperability. Standards identify and eliminate discrepancies, and provide the specificity and transparency that providers and tool vendors need to create interoperable products. How quickly the various players can arrive at consensus on these standards will play a key role in determining the level of success that Web services will enjoy.

Author Bio:
Greg Heidel is a principal architect and the Web services technical lead for Momentum Software. His responsibilities include architecting and designing systems on both the J2EE and .NET platforms and researching the future directions of Web service technologies. gheidel@momentumsoftware.com