Rhody: Let's start with a high-level overview of WS-I and, if you can, highlight key members, new members, and what your broad mission statement is.
Glover: As far as key members are concerned, I'd have to say every member is a key member.

The mission statement is really easy. As emerging standards, particularly Web services standards, are adopted by the marketplace, and as it is discovered that there are interoperability issues related to the use of those standards, WS-I will produce profiles and supporting materials that address those interoperability issues and resolve them. That is, in a nutshell, what we do.

We started in February 2002 and have been under way for about a year and a half. We started by focusing on what was commonly perceived to be the bedrock for Web services - SOAP for transport, WSDL for definition of Web services, and UDDI for discovery. Those three documents - we can call them specifications or standards; I leave the distinction up to braver hearts than mine - have been available for some time from a variety of sources. Of course they are all in either W3C or OASIS. They have been adopted by a number of platform, tool, and application vendors, and there were well-understood interoperability issues related to using them, singly or together, to produce Web services.

WS-I's first job was to look at those three standards, identify the interoperability issues, and come up with recommendations on how to resolve them. That is, in fact, what we are preparing to do. We have the Basic Profile version 1.0 in working group approval draft status now [Note: the Basic Profile has since been released], and that document is the WS-I position on how to address the interoperability issues related to the use of those standards in Web services. That's what we've focused on for the past year. It's the first profile we've produced, so we've been learning as we go. In addition to producing the profile, we've produced a number of pieces of supporting material.

First, we've been producing testing tools that help people analyze services and artifacts related to them, such as UDDI descriptions and WSDL documents, to verify that those services and supporting documents conform with the Basic Profile. Those tools will be rolled out, we hope, this year. They are going into their approval cycles now.

In addition, we've produced a set of sample applications that developers can look at to help them understand what a conformant set of Web services looks like. In fact, we have a showcase of close to 12 companies that have implemented part or all of the sample application and put it out on the Internet on servers, together with an interface that lets you exercise those Web services and prove to yourself that when someone has, in fact, implemented interoperable Web services they can be mixed and matched. You can, for instance, one day start using the Microsoft implementation service, and the next day shift to the BEA or the Sun or the IBM implementation of that service, and because their interfaces were developed using a common standard and all adhere to the Basic Pofile, it doesn't matter which one you use; they will all work in the application. So we've got the profile, we've got the tools, we've got the sample applications, and there are a few more documents that wrap around them that help describe them a bit more, but that's the root of what WS-I does.

Looking ahead a bit, what's next? There is, I believe, consensus in the trade press and among the Web services community that security is the next thing we need to solve. We now have the Basic Security Working Group under way, and that group is developing a profile that addresses security. It hopes to have a preliminary draft available this summer but beyond that, of course, these things take as long as they take. We hope to have a draft profile before the end of the year; that's the goal of the working group. Once that's available, we'll be better able to estimate when the profile will be final. That's the next big deal for WS-I, dealing with security.

There's also an effort under way now to take the Basic Profile and figure out how we can add attachment support to it because a number of our members have indicated that that is something they want. It's not as close to completion as Basic Profile 1.0, but the working group has a draft that they're kicking around internally. They're not satisfied that they've solved all of the technical issues yet, which is why it has not yet entered the public eye.

Anything past security becomes more speculative. There are a couple of things that we look at before we start work. We look to see that a standard had been accepted by the industry - that's a very nebulous term, but in general it means that a standard has been implemented by the vendors; it's being used; it's demonstrably something that the industry thinks is important.

The second hurdle we have to go over is that there need to be interoperability issues related to the use of the standard. SOAP was widely implemented in the middleware that most of us rely on. It was being used by people who develop Web services. There were obviously interoperability problems with it, so that's an example of a model. We expect to go through the same cycle when we look at what the next set of issues we deal with is. We can conjecture, and we did in fact in the roadmap we used when we launched WS-I. We pointed to things like reliable messaging, workflow, choreography, business rules, as things that some of us thought would probably come up as the next sets of issues for the Web services community to deal with. And we pretty much still think those are things we'll need to address down the road. However, we're not there yet. Until there are accepted standards that address those topical areas, and until it's clear that interoperability issues exist, those simply aren't topics that WS-I is going to take up and start developing profiles to deal with.

Rhody: Obviously SOAP, UDDI, and WSDL have seen a lot of attention. Will you continue on those, like the attachments, or are more coming up?
Glover: Where the Basic Profile is concerned, we're going to get 1.0 out the door and then we're going to deal with attachments. I'm fairly confident that that is something we'll focus on this year. Again, speculating for a minute, you can look at what's going on with the basic definition of Web services. Inside W3C right now there is work going on on SOAP 1.2, there's work going on on WSDL 1.2. Within OASIS, there's work going on on UDDI 3.0, and all those are follow-on standards to the standards that are in the Basic Profile. It's reasonable to suggest that as those standards are rolled out by various owning organizations, there will be industry uptake. Once we see that SOAP 1.2 is supported by platform and tools vendors, and incorporated into Web services, it's reasonable to expect, again, that despite the wonderful job that standards developers have done, there will be interoperability issues. If that's the case, it's reasonable to think that that may be a set of work that WS-I takes on somewhere down the road. But again, we're going to wait. SOAP 1.2, WSDL 1.2, aren't out in "rec" form from W3C yet, and OASIS hasn't released UDDI 3 as a recognized standard yet. We'll wait for that first. We'll also wait to see the various vendors incorporate those standards into their products, and we'll wait to see WS-I members come back and say, "I've tried to build Web services incorporating SOAP 1.2, or WSDL 1.2, or UDDI 3.0, or all of the above, and here are the interoperability problems I need help with." Once we get a growing set of interoperability problems identified by our members, that's what will prompt us to say it's time to write a profile.

Rhody:That makes sense. Do you see pretty much all of your work as front loaded by other standards bodies, or is anything coming directly from WS-I?
Glover: No, WS-I's job primarily is to do follow-up work. There is some work we do that is not initiated solely by the standards groups. We've discussed what prompts us to make a profile. Stepping away from that for a moment, we're spending an increasing amount of time with the WS-I membership to identify the Web services usage patterns they're seeing in their applications. And of course we're trying to cultivate the membership so we get a representative cross-section of the industry. We'll sit down with our membership and say, "How are you using Web services? What are the usage patterns you see emerging, the interoperability problems that you're seeing?" That is totally WS-I driven. We're trying to get a better sense, within the organization, of how the technology is being employed, what the problems are, so we can be proactive and go out from the WS-I to say, "Here are the issues we see that need to be resolved." Not simply as a response to analyzing existing standards, but at some point down the road, "Here are the usage patterns that users might like to implement; here are the reasons they can't."

I think the two concepts that describe the work the WS-I is doing are 1) implementers forum, and (2) standards integrator. One of the things we've been doing is developing effective relationships with W3C, OASIS, and IETF. Our primary focus has been on the organizations that own the standards that represent our profiles, and I think that will continue. But we're also working with industry vertical groups and other groups that are trying to be consumers of our work, or are trying to contribute their requirements and shape what we do. Focusing for a minute on feedback, however, obviously the first and clearest feedback mechanism is as we release draft and final versions of our profile. We're encouraging the organizations that own the standards we're referencing to review the profile, look at the interoperability issues we found, and insofar as it's possible, incorporate our recommendations in whatever form they feel is appropriate into follow-on versions of their standard.

This gets a little convoluted because we're working the other way as well. If you look at the clauses and basic profile that deal with SOAP, you'll find that many of our clauses are closely aligned with the work that went into SOAP 1.2 within W3C. We attempted, as we developed the profile, to minimize the costs associated with moving from a Web service that was built based on SOAP 1.1 and the Basic Profile into SOAP 1.2. The differences between the two technical definitions are as small as we can make them, but at the same time there are some differences. We're sending the profile back to W3C and encouraging them to read it, and if they see comments in it they think are good ones, we're encouraging them to weave our recommendations into future versions of the SOAP stack, or the WSDL stack, or the UDDI stack, or down the road into WS-Security. There's going to be some stuff in the profile that they simply can't find a home for because in addition to commenting directly on the standards, we also comment on how two or more standards should be used together. Because we're taking a view that's different from a single standards developer view, some of this will just be hard to incorporate directly into a standard. It's probably down the road that you'll see the majority of the content of our profile. It will be, "How do you deal with boundary conditions between SOAP and WSDL; between SOAP, WSDL, and UDDI?"

Rhody: I think I understand the deliverables process. What about the organization itself? Can you speak about the recent board of directors election, and any formal relationships you have with other standards bodies?
Astor: The WS-I was created about a year and a half ago and there was a lot of inertia that I think had to be gotten over by the people who created the organization. Once momentum was established, it was important to start looking around and ask, "Okay, now that we have something here, is it the right something and what might need to be changed? What do our members think; what does the public think?" There have been several changes, and my presence on this call is certainly one of them. Back in late 2002, due to interest from the rest of the community in participating on the board of directors, which was previously open only to founding members, an election was held and two additional board members were elected, Sun Microsystems and webMethods. It was in that process that I got onto the board, and I now chair the WS-I marketing committee.

In terms of other organizations, it became clear some time ago that, aside from the original nine founding and contributing members, there was another category of people that are important to our organization as well. Those are other standards organizations, not just the W3C and OASIS, but also many of the vertical standards groups like RosettaNet, Cydex, UCCNet, and others, such as ACORD in insurance. Assuming that the membership agrees, there will be a new category of associate membership established that will be for organizational-type members to join the group as well.

Rhody: That would be like system integrators, consultancies, etc.?
Astor: No, more like RosettaNet, ACORD, and groups like that. We're talking primarily about non-profit organizations that don't have much money.

Glover: We have an established mechanism for bringing companies in. It doesn't matter if they are a services company like Accenture or a middleware company like BEA. This new provision will allow industry verticals or standards organizations such as W3C and OASIS to participate without paying dues. Primarily, these organizations are not accustomed to paying dues and are not set up for that sort of financial exchange. Many of them run on very small budgets. It's also a mechanism that we could use to bring academics in if there were specific cases where we felt that was necessary.

Rhody: That makes a lot of sense.
Astor: Another change is that the board has created several subgroups - we call them board committees - to deal with various issues. For example, the marketing committee, or the liaison committee. There was a lot of interest from the membership in participating in those committees so we've created a policy where whenever possible we open up those committees. The marketing committee is the first one that is open not just to board members but to contributing members as well. We are now in the process of bringing new members into the marketing committee.

The theme that I noticed about WS-I that I think is evident is that it has always been an inclusive organization. Certainly, I have found it so since I joined and got involved. But its policies are being broadened to be even more inviting to nonboard companies to participate in new and interesting ways.

Another interesting thing that happened recently that got an enormous amount of energy is that a special interest group for Japan was created. There are 15 participating member companies now in Japan who are actively translating all of the WS-I deliverables and evangelizing and promoting WS-I there. And many of the things that Tom alluded to, such as SOAP with Attachments and security, are all driven by the membership. So the changes going on at WS-I are extraordinarily member driven. That is why we can't tell now what we will be working on in six months. As Tom said, if SOAP 1.2 makes it in the marketplace, terrific, and in all likelihood it will be a candidate for a profile, but it's really driven by the members and their concerns.

Rhody: That all makes sense to me, but this is the first chance we've had to talk with anyone from the WS-I in depth. I'd like to get an idea of the "state of the union." Where do you think the next big things will be in Web services, not necessarily things WS-I will focus on immediately, but what is driving the industry.
Glover: First, I think you want to talk to the various vendors because you're asking about a space where I believe there will be a difference of opinion. And the difference won't be so much over the technical areas where we have work to do. It will be over timing, over prioritizing, and of course at this point there will be a difference of opinion over which standard - or which effort that might produce standards - will prevail in certain areas. If you look at reliable messaging, there's more than one effort underway right now to produce an RM spec. If you look at workflow, there's no consensus on a standard for workflow. If you look at business rules, same thing. These areas are still, to some extent, hotbeds of research and discovery and discussion, which is really good news. Some people look at the fact that there is more than one effort to produce a reliable messaging spec and shake their heads and say, "This is a bad thing; why can't we settle on one?"

I guess I look at it and say, "Obviously this work is important; otherwise there wouldn't be so many people engaged." A little bit of debate early in the cycle is a good thing because it lets us look at various ways of solving reliable messaging, or business rules or security for that matter. It lets us explore different pathways for a while. The reality is that at some point we have to make up our minds and I think that's happening. Five years ago we didn't have SOAP and we do now. Five years ago we didn't have WSDL and we do now. We didn't have UDDI and we do now. WS-Security I'd say, and this is a personal opinion, is emerging as one of the key specs for Web services security and that's happening because the industry is coming to consensus on it. I really believe that in a couple years you're going to see that Web services is the next area where the industry says we have to get this sorted out. Let's come to an agreement on which specification or specifications we're going to base our reliable messaging implementations on. And frankly, this is where WS-I comes into play.

I think people join WS-I for pretty much one reason - they have decided that we need interoperable Web services. It's important to all of us for different reasons, depending on who you're looking at. Some of us are producing middleware; some of us are producing tools; some of us are consuming technology. We have heterogeneous IT environments; we're tired of not being able to integrate applications without a custom solution. We see Web services as a technology that will help us do application integration more quickly and for less money.

These are all good reasons for why people have joined WS-I. We all believe we have to settle on specifications that are deployed industry-wide in a common way. And that's really what WS-I is all about - it's a growing community of companies saying this is important to us; we want Web services to become a viable technology. The only way it will become viable is if we have a common understanding of how to interpret these specifications. That's what we're here to do. That's the really good news, and I think that over the next couple of years you're going to see WS-I members starting to say, "Okay, this is the next nut we have to crack. Now it's security. Let's all sit down and talk about our security problem."

That conversation is ongoing. We have Basic Security going on right now. If you look at what the Basic Security Profile is based on, you'll know a number of things about it. Security tokens are important for the security community. We've listed some token types that we are going to address. There's already a healthy discussion under way on whether that list of token types is sufficient. Maybe it is, maybe it isn't. It may be very possible that even as we defined the Basic Security working group's charter we did so over the types of tokens that should be included. SAML was one that didn't make it into the version 1 charter. It's very possible that we're going to incorporate SAML into a subsequent iteration of that profile and that's just part of the conversation that's going on. When SAML settles down, and we understand whether or not it's important, we'll make a decision on whether we have to do something with it.

One of the challenges we have is in making sure we have this conversation going. It's obvious through the conversation we've had so far that it's really important, so WS-I has to pull into the organization the companies that represent what's going on in terms of the Web services user community. Particularly, we have to pull in the companies that are technology consumers using Web services, not just the companies that are using platforms or writing tools, and this is a real challenge. If you look at W3C, at OASIS, typically the companies that participate in standards development are the hard-core technology companies that produce platforms, that produce middleware, that produce the component solutions that people use. Not the companies that rely on those solutions. In fact, when you look at groups like the Liberty Alliance, one of the things they have said is that unlike many standards efforts, they have a lot of technology consumers in their ranks. The WS-I needs that, and that's a challenge that we've got - trying to grow within our membership an ever-larger percentage of technology consumers that can come in - like United Airlines and a number of others - and say "Right, we don't build the middleware; we don't write the tools; we use this stuff. Let us tell you the problems we're having." We're succeeding, thanks to the work that this group is doing. Of course, the work that the liaison team does is key here too because these companies often participate in organizations such as ACORD, such as OMA; organizations that cater to the problems particular to their industry. We've spent a lot of time talking to the finance community, to health care, to any number of other organizations, saying "Tell us what your particular needs are - what it is you're trying to do that you think is unique to you. Looking down through your industry at your basic infrastructure requirements, what do you need?"

Rhody: I have one last question. If you had to say one thing to our readers about what's going on, the relevance of the work you're doing, what would you tell them?
Glover: Participate. If Web services is going to become a technology that helps us all do what we want to do, namely application integration, it's going to take a lot of us participating in this effort. Whereas there is probably a limited section of the industry that is interested in writing the next SOAP spec, there is a much greater segment of the industry that has something valuable to say about what they need from Web services if the technology is going to go partway toward meeting their needs. And we need to hear from them.