It turns out that humans are pretty darned smart. We can figure out a variety of interactions such as:
- How to enter usernames and passwords into different pages
- When to stop waiting for a page to return and resubmit the request
- When timed out of a site, how to reenter data and get to the right pages
- How to enter an e-mail address in a Web form, and then switch over to the e-mail client to view the resulting e-mail message
- What ordering (or flow) of Web pages to go through to achieve a task
Computers, when talking amongst themselves, aren't nearly as smart as this. Things that people deal with naturally - such as security, reliability, sessions, or asynchrony - have to be explicitly programmed into computers. This is why there are so many "WS-*" specifications; computers require a formal specification to fully explain each of the things that we can do naturally.
For Web services to be successful and cost-effective, we need a single standard in each of these areas. It's okay for each Web site to require a username/password combination (as well as different methods of entering them) because people can figure this out very quickly. But imagine if each Web service used a different mechanism for authentication; the job of writing software to deal with each service's different mechanism would be enormous. Standards are all about achieving economies of scale so that vendors can provide the same functionality in the same way. Then, developers can more easily write software to offer or consume Web services.
This article describes the set of Web services standards that BEA believes are important to customers and developers. We classify them by three criteria: the type of problem they address, the readiness of the specification for real-world use, and how fundamental the functionality of the specification is to the Web services stack.
The Web Services Standards Stack
In any discussion of technology, a diagram must inevitably be provided. Figure 1 shows the Web services specifications addressed in this article, their types, and their relationship to what we call the "core" set of Web services specifications.
Classification Methodology
We've chosen two different axes for classifying Web services specifications. The first describes the functionality of the specification according to the "3-Ds" of Web services; delivery, description, and discovery. Delivery is about how a message is sent between services; description specifications describe the message(s) that are exchanged; discovery is how the services or descriptions are found.
The second axis is the preeminence and timing of the specification. There is a set of specifications that are core to Web services; we anticipate that most Web services will use them. For example, SOAP and WSDL are obvious core specifications. Some core specifications are available now; others will be available in the future. Specifications that are useful for some Web services, but will probably not be integral to most, are considered extensions.
Core Standards
I won't go into the details of the current stable specifications, as most people have heard of SOAP, WSDL, and UDDI by now. In short, the current core consists of XML 1.0, XML Schema 1.0, SOAP 1.1, WSDL 1.1, HTTP 1.1, SSL, and TLS. It should be no surprise that many of these are also specifications in the WS-I Basic Profile.
Emerging Core
We can already see the form the next generation of core Web services will take. Delivery will be expanded to include more robust asynchronous messaging, clearer standards for addressing messages, a full-fledged Web service layer message routing system, and more advanced security facilities. Description will be enhanced by the addition of sophisticated policy description capabilities. And discovery will be enhanced with facilities to allow Web services to be dynamically queried for a description of their capabilities. The addition of asynchrony, security, reliability and addressing information into delivery, WS-Policy into description, and URI-based metadata exchange into discovery rounds out what BEA considers to be the next level of core Web service specifications.
Delivery: Asynchrony, Addressing, and Routing
One of the promising aspects of Web services is asynchrony; that is, the ability to deliver responses and messages without an existing connection, so that a service consumer's and provider's execution is decoupled. WS-Addressing defines basic mechanisms for asynchronous messaging; in particular, the Reply-To header allows a "callback" to be performed.
WS-Addressing also specifies how addressing information (typically used for routing) should be conveyed in a SOAP message, by defining common headers such as message identifiers and to and from fields.
Finally, WS-Addressing provides an EndpointReference structure that can contain information about Web service endpoints. An endpoint, which is defined in WSDL 1.2 and is renamed from WSDL 1.1 Port, is an access point of a Web service. It can contain information that is required to access or reference the service, such as a conversation ID. It is often necessary to exchange endpoint references, particularly for callbacks and long-running conversations. In the future, there will be a WS-EndpointResolution specification that will enable two parties to negotiate or refine EndpointReferences.
Delivery: Reliability
Reliable messaging protocols define mechanisms for ensuring that the sending and receiving parties know whether or not a message was delivered. Typically there is an acknowledgement message with a retry algorithm. WS-ReliableMessaging specifies a reliable messaging protocol for Web services using a number of different SOAP headers as well as configuration information. These SOAP headers allow communication of a sequence number, acknowledgment of a sequence of messages, and the ability to request acknowledgement of a sequence of messages. There is an OASIS Committee, WS-Reliability, which is looking at a similar work - WS-Reliability - from Fujitsu, Sun, Oracle, Sonic, and others.
It is worthwhile to note that BEA has published and implemented a number of individual specifications in this area: WS-Acknowledgement, WS-MessageData, WS-Callback, and SOAP-Conversation. This has been done to allow others to interoperate with BEA, to deliver early functionality to our customers, and to provide useful implementation experience. We anticipate our experience and implementation will be helpful in making the specifications above into stable, full-featured standards.
Delivery: Security
WS-Security is composed of a specification at the OASIS Web Service Security technical committee and a roadmap of related specifications. The WS-Security (WSS) specification has three main functions:
- Message integrity/authentication: Guaranteeing that the message was not modified since it left a known person
- Message confidentiality: Guaranteeing that only the right people can look at the message
- Message authorization: Providing the information needed to decide if a request should be granted
The WSS specification uses the XML Digital Signatures specification and the XML Encryption specification, and introduces new authorization elements. All of these WSS features are expressed as SOAP header blocks. A number of vendors have implemented WS-Security, and many more will be involved in WSS interoperability testing.
The WS-Security roadmap contains three other recently published specifications. WS-SecurityPolicy defines how policies for WS-Security are expressed in the WS-Policy language (see below). WS-Trust provides a protocol for requesting and receiving WS-Security tokens, including a challenge response protocol. WS-SecureConversation defines a security context that can be shared during a long-running conversation between two parties, and a refinement of WS-Trust for setting up the context.
Description: Policy
An emerging problem in Web services is describing the capabilities and requirements of endpoints. For example, WS-Security describes a number of security mechanisms but doesn't force services to use any particular one. Likewise, there are several configuration options in WS-ReliableMessaging that allow services and their consumers to fine-tune the nature of their message exchange. Currently, these and many other aspects of a Web service's operation must be done by private negotiation because WSDL isn't up to the task.
While all of these things could be specified and negotiated on a point-by-point basis, it's sensible to define a common framework for configuration, requirements, and capabilities - together referred to as Policy - in Web services. WS-Policy aims to fill this gap with three related specifications.
WS-PolicyFramework describes an overall approach to expressing policy assertions (e.g., "I support the DES encryption algorithm," "That message is required to be SOAP 1.2") and combining them (e.g., requiring one out of a list of values, or requiring all members of a set).
WS-PolicyAssertions defines some specific assertions - like a document's encoding, or support for a particular specification - to demonstrate the use of the framework, as well as allow for reuse of common components. Finally, WS-PolicyAttachment specifies how to associate policy assertions with XML elements, WSDL-type definitions, and UDDI entries.
Discovery: URI-Based Discovery
There is one more item that Web services needs for the core, which is how to discover WSDL and WS-Policy statements about a particular Web service or service provider, given a URI. We expect that a WS-MetadataExchange specification will fill the role of UR-based discovery.
Extensions
Extensions are specifications that are very useful, but in more of a refined area than what we have called core.
WS-Transaction defines coordination of a variety of atomic transactions - two-phase commit and four other types - and compensating transactions. It uses WS-Coordination as a pattern for clients and coordinators to register and exchange coordination messages. WS-Transaction and WS-Coordination involve one or more coordinators that are involved in completing the interaction.
WSBPEL (Web Services Business Process Execution Language) is an OASIS technical committee that is chartered with producing a platform-independent, XML-based programming language for writing Web service control logic. The W3C Choreography Working Group is working on similar technologies but at the time of this writing it was too early to tell if the groups will be complementary.
Conclusion
The set of specifications described here is expected to provide a solid foundation for meeting our customer's application and business-process needs. They are gradually making their way toward becoming standards, starting with SOAP, WSDL, and UDDI, and more recently followed by WS-Security and BPEL4WS. We expect that all of these specifications will be standardized.
Given that you are BEA WebLogic developers, I'll tie these specifications back to BEA and BEA's leadership role. BEA is a coauthor of most of the WS-* specifications. BEA is also an aggressive implementer of the specifications in WebLogic products. For example, BEA WebLogic Platform 8.1 implements a very useful portion of the WS-Security specification, even though the WS-Security TC has not yet held formal interop tests.
In summary, developers can expect to build interoperable Web services using these specifications in current and upcoming WebLogic releases.
Figure 1
All Rights Reserved
Copyright © 2003 SYS-CON Media
