As the title suggests, the Web Services Workshop last week (April 11th and 12th) in San Jose, California was quite a grand gathering of some very intelligent minds, all focused on the future of this new emerging paradigm that we call "Web services." I happened to have the good fortune of not only serving on the program committee for the workshop -- that's the group that reviews the submitted position papers and selects who gets to present at the workshop -- but also chairing one of the sessions. As this was my first official W3C event, it was definitely an eye-opening experience into how the W3C accomplishes what it does. In this installment of the "Web services insider," I want to share with you some of the highlights of the presentations and discussions that followed.

Understanding the W3C process

First of all, for those of you who are not familiar with the W3C process as I was not prior to my involvement with this workshop, a quick overview. Before the W3C begins work on any standardization process, they first take some time to solicit feedback and input from the W3C member companies as to what and how exactly the W3C should proceed. These workshops are a part of this process.

The purpose of a W3C Workshop is to do nothing more than brainstorm topics that might eventually evolve into a full-fledged W3C Working Group or Interest Group. It is the Working Groups that produce the actual specifications that we fondly refer to as W3C Recommendations. So, to answer the simple question as to whether or not any actual decisions were made at the workshop to move forward on standardizing such things as WSDL or UDDI, the answer is no, although we discussed in great detail how, when and why we might want to do just those things.

Back to top

How we spent our two days

To begin there was, of course, the obligatory schmoozing normally expected at such functions, and partaking of the excellent lunches prepared by the hotel hosting the event -- kudos to IBM for sponsoring the whole thing, by the way. The two days consisted pretty much of listening to and discussing presentations submitted by the various W3C member companies keenly interested in Web services. Then came the arguing... I mean brainstorming about what we all wanted to do first, who should do what, and what other work from other organizations (such as OASIS) we could leverage as we move forward. In order to get a clearer picture of how things went (and in order to read the excellent position papers that were presented), you'll want to check out the workshop's official Web site (see Resources) and follow the links to the workshop program.

Back to top

What we talked about

The whole of the workshop was centered around several distinct themes that, by now, should be fairly familiar to those of us who have been following the development of this emerging Web services architecture.

We discussed and identified the three distinct conceptual components of the Web services architecture and began the process of defining the stack of requirements and technologies that fit into each of those components. Led by presentations given by IBM's Rod Smith, VP of Emerging Technologies and Microsoft's XML-guru Andrew Layman, a picture of the "Web Services Stack" began to emerge (see Figure 1).

We discussed what exactly it means to "describe" a Web Service and talked about the Web Services Description Language (WSDL) in great detail in terms of whether or not the W3C should begin work to standardize WSDL or more generally, should the W3C begin work to standardize Web Service Description as a whole. The general consensus of the group was that a W3C Working Group for standardizing Web Service Description should be launched in the short term. The exact details of what that working groups charter will be has yet to be determined. However, WSDL is sure to be a core part of that process in much the same way that SOAP has become a core part of the W3C's XML Protocol process.

As you can see from Figure 2, WSDL addresses the bottom two layers of what IBM has identified as the Web Services Description Stack. There was a great deal of focus and attention on the higher levels of this stack as well. That is, having the ability to describe the characteristics of a Web Service in terms of reliability, capabilities, sequencing of messages, orchestration of who sends what messages, and when, etc. are all things that were identified as "describable" components of a Web service. The consensus was that we needed a single, defined, extensible framework upon which to layer each of these into the Service Description Stack. Although there was some disagreement about exactly how this would shape up in the end, WSDL was at the center of the discussion and a very good argument was made as to why WSDL could and should form the basis of that work.

Tim Berbers Lee kicked off the workshop by detailing his vision as to how Web services are, in fact, an actualization of the "Semantic Web." This discussion ranged from such topics as being able to categorize, classify, and discover Web services based on various ontologies, to demonstrating how WSDL and RDF can be combined to leverage already existing RDF-based infrastructure.

Back to top

When worlds collide

One of the most interesting discussions that we had, in my opinion, involved the convergence of this emerging Web services architecture with the work that is being done in the OASIS group with ebXML. For those of you unfamiliar with ebXML, I'll offer this very brief, very watered-down summary: ebXML is an end-to-end stack of protocols and specifications for conducting electronic business over the Internet using XML and other open standard technologies. When I say "end-to-end" I mean that ebXML essentially has a specification to handle every aspect of the electronic-business transaction, from describing simple service endpoint definition (using WSDL or some other mechanism), to describing the entire Business Process Workflow for the transaction. ebXML's range of specifications (due to be completed in mid-May 2001) covers a broad range of aspects relating to reliable messaging, security, transactions, message packaging, description of services, description of service capabilities, sequencing of messages, message workflow and orchestration, agreements between various trading partners, and the list goes on and on.

In many ways, ebXML sounds like exactly what the Web services architecture is building up to. Well, that is exactly correct, which is why we are starting to see collisions and convergence between what the two architectures are trying to accomplish and how they are trying to accomplish it. For example, ebXML needed a method of transporting XML-based messages back and forth over the wire. At first, they looked at SOAP (version 1.0) and decided against using it so they developed their own XML messaging protocol based primarily on stuffing XML-documents into individual multipart-MIME parts. Then, along came the SOAP Messages With Attachments specification that accomplished the exact same thing using SOAP as the primary protocol. The ebXML Working Group was left with a choice -- either continue with their own XML-messaging specification or make the switch over to use the SOAP With Attachments specification. A little over two months ago they wisely decided to adopt SOAP With Attachments as their messaging standard.

As developers continue along this path of evolving the Web services architecture, similar collisions that will need to be resolved. So the obvious question is this: why not just use ebXML if it already does all of this stuff? Why go through the trouble of defining a brand new architecture?

This question was raised many times at the Web Services Workshop and the answer was simple: where there are areas of overlap, such as in the area of XML Messaging or Service Discovery, we will need to take a strong, hard look at whether or not the ebXML stuff (or perhaps specifications designed elsewhere) fit the requirements of what we are wanting to do and if so, how do we best leverage those items into the Web services architecture. The important thing to keep in mind that this is an evolving architecture that does not quite yet have all of the puzzle pieces defined. We intend to re-invent the wheel as little as we possibly can.

Another important thing to remember about the difference between ebXML and Web Services is that they are both approaching the same problem from two different vantage points. ebXML is starting from the top and working down -- identifying the full range of requirements necessary for successfully conducting electronic-business over the Internet and then working to implement specifications that meet those requirements. The Web services architecture, however, is starting from the bottom and working its way up -- implementing specifications that meet individual core requirements (such as simple XML messaging and service description) and building up from there.

Do ebXML and Web services compete? To some extent yes, to some extent no. In many ways, ebXML can be viewed as being a complex implementation of the Web services architecture using a specialized set of specifications to answer some very difficult questions. The fact that these specifications differ from the specifications generally viewed as core to the Web services architecture (WSDL, UDDI, etc) is irrelevant if you recognize that this entire architecture is still in flux. What is important is the fact that work is being done to make sure that these two architectures can coexist, and actually serve to add additional layers of value to each other. For example, ebXML's Service Repository is being designed in such a way that allows it to coexist and even integrate with a UDDI Service Registry.

Back to top

The bottom line

The bottom line of the Web Services Workshop was this: the evolution of Web services is very important and the W3C should begin work to standardize various components of that architecture. We all pretty much agreed that standardizing service description should be one of the top priorities in this effort, which means you should start to see some activity around WSDL in the very near future. If you're a company implementing WSDL-based tools, I'd recommend that you pay special attention to how things progress.

In terms of what the W3C Workshop means for developers actually in the field wanting to use this stuff to implement real applications in the short term, the one thing that I can recommend is that you begin to familiarize yourself the core components of the Web services architecture. If you haven't already, start learning about SOAP, WSDL and UDDI. If you're a Java developer, I recommend that you download the IBM Web Services Toolkit to begin experimenting with the Web services architecture.

Resources

• See Part 1 of this series.
  
  
• Read the SOAP Version 1.1 Specification
  
  
• Familiarize yourself with the WSDL Version 1.1 Specification
  
  
• Information about UDDI can be found at the UDDI Web Site.
  
  
• The IBM Web Services Toolkit is available through IBM's alphaWorks Web Site.
  
  
• The IBM Web Services Development Environment preview is also available through alphaWorks.
  
  
• IBM also offers the WSDL Toolkit for download.
  
  
• Information about Microsoft's SOAP Toolkit and .NET can be found at http://msdn.microsoft.com.
  
  
• Download Paul Kulchenko's SOAP::Lite for Perl module.
  
  
• Get an overview of the Web services architecture with this article.
  
  
• Review the IBM UDDI4J release, an open-source Java implementation of the Universal Discovery, Description, and Integration protocol.
  
  
• Learn about XML messaging with SOAP with this tutorial.
  
  
• You can learn more about the W3C and the W3C standardization process by visiting http://www.w3.org.
  
  
• The program, position papers, presentation slides and minutes for the W3C Web Services Workshop are available at the Workshop's homepage.
  
  
• The OASIS group is responsible for creating the ebXML specification.
  
  

About the author

James Snell is both an author and a developer and is one of the newest members of the IBM Web Services development team. He comes to IBM with an extensive background in custom enterprise application development and business-to-business integration, and a passion for the cutting edge of Web technology. You can reach him at jasnell@us.ibm.com.

Rate this article

Comments

Back to top

Table of contents

• Understanding the W3C process
• How we spent our two days
• What we talked about
• When worlds collide
• The bottom line
• Resources
• About the author
• Comments

Next steps from IBM

Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.

---

• Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
• Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
• Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
• Buy: Rational Service Tester for SOA Quality

Dig deeper into SOA and Web services on developerWorks

Try IBM PureSystems. No charge.

Experience today!

---

Get started with the cloud-based trial and pattern development kit.

Special offers