WebServices dot org

XML 2004 – Making Gains with Web Services by Setting Limits

The week of the conference generated some heat as debates arose over XML performance and the potential for a binary form of XML to address those performance issues. While the heat of these debates generated a lot of media and Web log attention, several of the XML 2004 conference sessions shed light on emerging standards, illuminated WS-I's role in giving standards more focus, and offered useful guidance on achieving interoperability in Web services implementations.

Hugo Haas, W3C. WSL 2.0 – What's New?

Hugo Haas, the W3C's lead staff member of Web services activities, outlined the emerging version 2.0 of the Web Services Description Language or WSDL that he described as a machine-processable description of Web services. As Haas noted, WSDL “provides a contract between a service and a client.”

The W3C plans to publish the WSDL 2.0 specification as three documents:

• Part 1, Core language

• Part 2, Predefined extensions

• Part 3, Bindings

Haas outlined a number of improvements in version 2.0 compared to the current version (1.1) of WSDL, particularly in the component model that separates descriptions of a service's abstract functionality from the concrete details telling how that service will be offered and where. Version 2.0 defines inheritance features which enables WSDL to reuse definitions of interface operations. This inheritance capability allows adding other operations to this extended description, which Haas says makes it easier to organize and structure your documents.

Haas discussed the Message Exchange Patterns (MEPs) in WSDL2.0 that he said described the sequence, cardinality, and direction of messages between agents. WSDL messages go either in or out of a service, and are thus called input and output messages. Version 2.0 defines eight MEPs:

• In-only, Out-only, Out-In, and In-Out, which are simple stand-alone messages

• Robust In-only and Robust Out-only that add optional fault messages to the In-only and Out-only patterns

• In-Optional-Out and Out-Optional-In, which builds in the capability for a reciprocal response message or a fault if needed

Haas said the WSDL does allow adding MEPs beyond this basic set.

Haas noted that WSDL 2.0 uses the F&P capability to define its Application Data Feature. This feature, a predefined extension, makes possible the adding of application-defined data declarations outside the normal SOAP channels.

WSDL 2.0 allows for marking operations as safe, expressed as an attribute with a value of “true,” which in this case means limiting the obligation to the requesting agent. Haas said this feature is analogous to getting a price list, which incurs no further obligation on the customer, while placing an order normally carries a financial obligation by the purchaser.

The concrete aspects of WSDL 2.0, according to Haas, are found in the Bindings document , which include support for SOAP 1.2 , SOAP attachments, SOAP 1.1 (for backward compatibility), and HTTP over Secure Socket Layer (https). The SOAP 1.2 binding uses the SOAP 1.2 modules and supports the SOAP 1.2 fault description format.

While WSDL 2.0 allows for specifying the underlying protocol to use in an exchange, the new document goes into more detail to describe the HTTP bindings, which Haas said “is more complete than WSDL 1.1”. Haas added WSDL 2.0 supports all HTTP methods (e.g., GET, POST, DELETE), and allows the specification of input, output, and fault serialization, as well as authentication and cookies.

Haas outlined the status of the document and W3C's plans for its publication as a Recommendation, the W3C's name for a completed standard. In August 2004, W3C published what it calls a Last Call Working Draft , which means the WSDL working group addressed all of the known requirements and requested final public comments on the draft documents. The comment period closed in October 2004, and the working group is reviewing and addressing the comments it received.

Haas expected W3C to publish a Candidate Recommendation, the next stage of its process, at the end of 2004 or early in 2005. The Candidate Recommendation calls for test implementations of the document. Haas cautioned that the process is by no means completed and the W3C working group still has a lot of work to do.

Samir Tyagi, Sun Microsystems, Lessons from the Front Line - Building Interoperable Web Services

Samir Tyagi of Sun Microsystems discussed achieving Web services interoperability, in most cases the overriding reason for building a service-oriented architecture (SOA) in an organization. Tyagi, who works for Sun Microsystems' consulting division, said that his position enables him to work directly with clients, and thus offers a perspective to “discuss the realities of application-to-application communications and how they affect Web services.”

Tyagi made a distinction between interconnections using Web services and the tighter, more traditional integration of applications. Web services allow applications to maintain their independence, while they exchange data though loose couplings. Because of Web services' reliance on standards, they can offer customers lower costs and reduced vendor lock-in. With Web services, parts of applications can be orchestrated, to take advantage of their modularity. And organizations can reuse Web services, because of their independence from the applications themselves. This dependency of applications in traditional integration schemes causes what he called “brittleness”.

But to achieve the interoperability that overcomes that brittleness, according to Tyagi, Web services need to overcome some barriers of their own. Despite all the talk of standards with Web services, Tyagi observed said that “not all Web services vendors are created equal,” meaning the implementation of those standards will vary from one vendor to another, which can cause trouble for Web services projects. Other obstacles companies will face include differences in basic operational issues, such as log-in procedures and agreements on how to federate or recognize identity across applications. Other cases, different companies seeking to exchange data through Web services may be using different versions of schemas or transport protocols.

To overcome these obstacles, Tyagi recommended that companies first “standardize on standards” He called agreements among companies on the details of standards the core of making Web services work. In some industries, the major players (e.g., Wal-Mart among retail stores in North America) will dictate the standards to use. In other cases, Tyagi urged taking advantage of the work done by Web Services Interoperability ( WS-I ) on SOAP, WSDL, and UDDI, defining profiles and compliance tests. He recommended using tool kits based on these compliance tests to encourage interoperability.

Another source of trouble in achieving interoperability are differences in data models between applications. In his paper, Tyagi gave as an example the goal of offering customers the ability to view data stored in accounts maintained jointly by a bank and investment company. While the two companies may agree on the data they want to share, each company likely uses a different way of organizing the data - i.e., different data models – that would prevent the organizations from achieving their joint business objective. Tyagi recommended in these cases agreeing on a common data model and common XML schema supporting that model.

Tyagi discussed a few security issues that architects need to consider. In his paper, Tyagi noted that trading partners may agree on security at the transport level, but clients will not know if the server uses SSL version 1.0 or 2.0, or if a Web service uses mutual authentication with SSL . He suggested that Web services needing transport level security, standardize on version 1.0 and negotiate certificate requirements separately. At the message level, other issues can develop involving signed or encrypted messages exchanged between SOAP endpoints. Tyagi said exchanging signed or encrypted messages requires processing with common mechanisms, to prevent misinterpretations. Another message-level issue is the extent of enveloping, and use of enveloped or detached messages. He suggested users may find detached messages easier to process than than enveloped messages.

Architects, according to Tyagi, need to build testing into the development project as routine part of the process. This ounce of prevention can pay off many times over, because as Tyagi noted, when things go wrong, “developers are less productive when working under a magnifying glass.” He recommended the use of WS-I's Monitor and Analyzer testing tools written for Java and C# that test for compliance with the WS-I's basic profile.

To back up his recommendations, Tyagi offered an example of Web services interoperability, with a demonstration of data exchanged with a Web service from both a J2EE platform running Java and a Microsoft .Net platform running C#. The business case involved sending a purchase order as a SOAP message and returning a SOAP message with either a purchase-order status or an error message. Tyagi prepared first abstract then concrete WSDL for generating the service endpoint interfaces (SEIs). He also tested the WSDL code using the WS-I basic profile compliance tools mentioned above. The SEIs were used to generate the client-side code in both Java and C#. Tyagi then gave a live demonstration of the data exchanges with the Web service from both clients.

Michael McIntosh and Anthony Nadalin, IBM. Enhanced Interoperability for Security of XML Web Services

The state of Web services security standards received attention at the conference, including a discussion of ways that security impacts interoperability. Despite the recent publication of several new security-related standards, such as WS-Security for SOAP messages and the Username Token Profile, IBM's Michael McIntosh and Anthony Nadalin said that more needs to be done to achieve interoperability while still protecting the systems and transactions involved. McIntosh and Nadalin (and Paula Austel, also of IBM, who co-authored the conference paper but did not take part in the presentation) described the work of the Web Services Interoperability (WS-I) organization to achieve this objective.

Most of WS-I's work up to now has centered around development of profiles – guidelines to enhance interoperability – of the basic Web services specifications: SOAP, WSDL, and UDDI. Because of the importance of security to Web services, a WS-I working group has recently published a draft security profile. The working group wrote the basic security profile for systems architects and developers, which presents several security scenarios.

While not discussed in the session or the accompanying conference paper, an acknowledgment is a simple reply that tells the sender that the recipient's system has received the message. It does not imply a commitment by the recipient to act on the message, while a response normally addresses the content of the sender's message. In all three cases the messages may, if necessary travel through intermediate nodes.

In these scenarios, the threats include message alteration, breach of confidentiality, faked messages, spoofing, falsified claims, and denial of service, among others. In addressing these threats, the presence of intermediaries – a feature supported by SOAP – increases the security challenges. Transport level security (e.g., https) can secure message between adjacent SOAP nodes, while message-level security, such as that defined by the WS-Security specification, is needed when sending through intermediaries.

The authors said that as it now stands, WS-Security is not a specification that lends itself to interoperability. McIntosh and Nadalin pointed out that WS-Security supports a good deal of flexibility and extensibility, that are normally considered good things by architects. But many elements in WS-Security,according to the speakers, allow a wide range of values, which can pose extra challenges when trying to coordinate security among trading partners.

The WS-I Basic Security Profile, say McIntosh and Nadalin, addresses this conundrum. The profile constrains the specifications, and provides what the authors call “clarifications and amplifications” to the original documents. The specifications covered by the profile include:

• HTTP Security (https)

• WS-Security SOAP Message Security v1.0

• WS-Security Username Token Profile v1.0

• WS-Security X.509 Certificate Token Profile v1.0

• WS-Security SOAP With Attachments Profile (draft)

While it may appear that the standards writers and profile groups may be in conflict, McIntosh and Nadalin said that is not necessarily the case. They noted that the participants in the WS-I and OASIS security groups overlap, which means that often the people who write the security standards are the same people who recommend the constraints on the standards in the profile.

Standards are Good, but Understanding Their Limits May Be Better.

These discussions of standards and their limits suggested an increasing sophistication and maturity on the role of standards in Web services. XML and Web services have developed into working tools for systems architects because of standards on which solutions implementers can rely. But like any intellectual product, standards are written by fallible humans, and thus need to be recognized as living documents capable of growth and change.. At XML 2004, these arguments showed that recognizing the limits of Web services standards can bring a healthy dose of realism to a Web services solution.