As Published In September/October 2004

Giving Legs to Web Services
By Caroline Kvitka

WS-I supports Web services working together.

Interoperability is crucial for the adoption of Web services—and a key reason that the Web Services Interoperability Organization (WS-I) was created in February 2002. The WS-I's goal is to deliver clear and consistent recommendations to ensure interoperability between Web services standards, specifications, and technologies, such as XML, SOAP, and WSDL. WS-I's support for Web services interoperability does not create new Web services standards or specifications—it makes them easier to use. Founding board members include Oracle, IBM, Microsoft, Accenture, BEA Systems, Fujitsu, HP, Intel, and SAP (Sun Microsystems was elected to the board in October 2002).

Interoperability Needed

Many Web services specifications are open to interpretation, which results in Web services that can't interoperate.

"When people started implementing SOAP 1.1 and WSDL 1.1, which are just W3C Notes, there were lots of problems, because two people could read the same specification and come to very different conclusions, especially with WSDL 1.1," says Anish Karmarkar, an active member of the WS-I Basic Profile Working Group and a principal member of the technical staff for Oracle's Java products. "In a lot of places, WSDL doesn't really say what you must and must not do; instead, it provides an example, and you have to guess what it's trying to do."

The WS-I attempts to resolve conflicts by providing interoperability recommendations among Web services implementations across platforms, applications, and programming languages.

"Having lots of options makes it difficult to get interoperability," adds Jeff Mischkinsky, a WS-I board member and director of Web Services Standards for Oracle.

The WS-I carries out its mission by creating four types of deliverables: profiles, usage scenarios and use cases, sample applications, and testing tools.

Profiles

A profile is a named group of Web services specifications at specific version levels, along with conventions about how they work together. Profiles make it easier to discuss Web services interoperability at a level of granularity that makes sense for developers, users, and executives making decisions about Web services. Essentially, profiles are a set of best practices for implementing the specifications in an interoperable way.

By profiling a group of specifications, a WS-I working group sets out to clear up ambiguities in the original specifications. For example, a specification might say, "If you want to achieve x, you can do it in the following ways: a, b, and c." The working group looks at the three options and settles on just one, and the profile will state that x must be done in that particular way.

Basic Profile 1.0

The first profile released by the WS-I is the Basic Profile 1.0 (BP 1.0), which consists of guidelines recommending how a set of core Web services specifications should be used together to develop interoperable Web services. These guidelines cover the following areas:

• Messaging: the exchange of protocol elements, usually over a network, to affect a Web service
• Description: the enumeration of the messages associated with a Web service, along with implementation details
• Discovery: metadata that enables the advertisement of a Web service's capabilities
• Security: mechanisms that provide integrity and privacy

The goal of BP 1.0 is to provide recommendations to simplify the task of implementing interoperable Web services within and across enterprises. BP 1.0 also aims to simplify purchasing decisions for customers concerned about interoperability with partners, customers, and suppliers.

BP 1.0 deals with SOAP 1.1, WSDL 1.1, UDDI 2.0, XML 1.0, and several Web services standards and specifications. These include XML Schema Part 1: Structures; XML Schema Part 2: Data Types; RFC2246: the Transport Layer Security Protocol 1.0; RFC2459: Internet X.509 Public Key Infrastructure Certificate and CRL Profile; RFC2616: HyperText Transfer Protocol 1.1; RFC2818: HTTP over TLS Transport Layer Security; RFC2965: HTTP State Management Mechanism; and the Secure Sockets Layer Protocol Version 3.0.

BP 1.0 resolves more than 200 interoperability issues associated with using the core Web services specifications together. "The majority of these clarifications and conventions are not so much technical improvements, in that there's not always a significant technical reason for doing something one particular way," says Rob Cheng, product marketing director of Oracle Application Server 10g. "The value comes not from the fact that choice A is necessarily superior but from the fact that everyone makes the same choice. It's a significant advantage in terms of development, speed, support, and ease of use to have everyone on the same page."

Practical Application of BP 1.0

The WS-I provides several tools to help developers create Web services that conform to BP 1.0. Usage scenarios demonstrate how specific message exchange patterns are constrained by BP 1.0, and use cases capture the business requirements for an application. These guidelines provide a framework for the use of BP 1.0-compliant Web services.

Late last year, the WS-I released Sample Application 1.0, a set of use cases, usage scenarios, and a technical architecture intended to help define best practices for using BP 1.0. Sample Application 1.0 implements a real-world supply chain scenario, by modeling the interactions between multiple Web storefronts, retail warehouses, and manufacturers to demonstrate how Web services can connect heterogeneous systems and autonomous organizations. Developers can download Sample Application 1.0 from Oracle and other WS-I members.

"You can actually plug and play the different parts of this application with different vendor packages. You have a Web store, a retailer, and a warehouse, and in real time, you can toggle which product or platform is running each of the pieces," explains Cheng. "I can change the front end from IBM to Oracle and put Microsoft on the middle tier. I can keep changing it, and it will work every time. The application gives confidence to businesses and developers that Web services interoperability isn't just talk."

Testing Tools

The WS-I also provides testing tools that allow developers to gauge the extent to which their Web services and applications conform to the guidelines of BP 1.0. These tools consist of a program that sits on the network and sniffs packets as they go over the wire and analyzes each of the Web services messages to see whether they are conforming. The tool generates a report that tells you whether your message is conformant or not and where the problem is if it's not conformant. If your application is conformant, you should be able to exchange messages.

"You can go to the specific failure and understand what's wrong," says Eric Rajkovic, a principal member of Oracle's technical staff and a member of the WS-I Sample Applications group. "The report doesn't tell you what to do, but it tells you why your application is not conformant."

To make it easier for developers to test the conformance of their applications with BP 1.0, Oracle has integrated the testing tools into Oracle JDeveloper 10g. "It generates the report in the same window, so you don't have to leave your current development environment," says Cheng.

Next Steps DOWNLOAD WSI BP 1.0a Basic Profile Oracle Containers for J2EE (with support for the WS-I Supply Chain Sample Application) WS-I Basic Profile 1.0 Compliance Analyzer demo WS-I Sample Application 1.0 package

What's Next?

WS-I has several new profiles in the works, including the Attachments Profile and the Basic Security Profile.

The Attachments Profile complements BP 1.1 by adding support for interoperable SOAP messages with attachments-based Web services. The use of attachments affects Web services interoperability in terms of packaging, formatting, and serialization.

"Attachments are necessary for several reasons when carrying large amounts of data, either binary or other XML documents," says Karmarkar, an editor of the Attachments Profile. Some advantages are smaller message size, smaller memory requirements, shorter processing time (because there is no need to convert binary data to base-64), and streaming. Attachments allow applications to use appropriate APIs to process data in a streaming fashion.

"Let's say you have an XML file that you want to ship with SOAP, and the encoding of the SOAP message is different from the encoding of your file," says Karmarkar. "You'll have to read the file from your PC, change the encoding to match the encoding of the envelope that's carrying this file, and then send it, which means there is encoding-conversion overhead, which you don't want. That's why attachments are important."

The Basic Security Profile is an interoperability profile that involves transport security, SOAP messaging security, and other security considerations for BP 1.0. The security threats and challenges the profile will address include data integrity, data confidentiality, message uniqueness, message alteration, falsified messages, message replay, and denial-of-service attacks.

"Right now, the security work in BP 1.0 is point-to-point connectivity," says Cheng. "But when we're talking about more-complex Web services, or flows, crossing multiple networks and multiple nodes, you have to start thinking about security that spans the entire communication process."

Benefits

The combination of profiles, sample applications, and testing tools gives BP 1.0 three solid legs to stand on, says Mischkinsky.

"BP 1.0 is a significant achievement," he says. "Users are much better off. When companies go to implement BP 1.0, there will be a much higher degree of probability that they can interoperate."