Advisor recently spoke with IBM director of e-business standards strategy Bob Sutor about current trends in Web services adoption, and the standards integration work being done by the Web Services Interoperability Organization (WS-I).

Advisor: What is the Web Services Interoperability Organization?

Bob Sutor: Let me start by giving you a context for Web services and how it motivates the need for interoperability. The primary purpose for what we've been doing with Web services technologies over the last 18 to 24 months is to make it easier for businesses to communicate with each other electronically, without having to know which specific technologies each one is using. If I want to conduct a business transaction with you, I don't want to have to know if you're using Windows, Linux, Java, or C#. I'm only interested in the transaction.

Web services is a collection of XML-based standards that enable interoperability by making things independent of platforms. Now, I specifically said these standards "enable" interoperability. The set of standards we're developing for Web services, while we have a few now with basic connectivity, will become more sophisticated over the next couple of years as we start addressing the standardization around security, reliable message delivery, transactions, and workflow. So, it'll become more difficult for software developers to understand if they're using all these technologies correctly. Even if they're trying to develop using open standards, are they sure the way they're using the standards conforms to current industry practices or best practices?

If I'm a CIO or CTO, I have to make the investment decisions about Web services. I have 20 to 25 standards, all of which are necessary and all of which plug together, and all at different version levels. Now, I need to make sense out of which ones of these work with the products I have, the ones I want to purchase, or the Web services I want to use. It becomes a real nightmare trying to understand which Web services really interoperate.

So, the Web Services Interoperability Organization (WS-I) is based on providing guidance and clarity both for the developers and the people making investment decisions. They need to know that the products, such as the tools, the runtime, and the Web services themselves are based on open standards. They also need to know which open standards the developers used, and if they used common industry practices to put them together. We want our customers to have the confidence to say, "Alright, I can use that Web service. I know that will be compliant with what I already have." We think that confidence will really speed up the adoption of Web services. We all agree Web services is a good idea -- it's hard to argue against it. Therefore, we want to get this technology into our customers' systems as quickly as possible, but they want the reassurance it'll do the job. They want to know that all these promises of interoperability are more than just marketing hype -- that this notion of interoperability is something they can concretely see and measure.

How far away from that level of interoperability do you think we are?

We've started doing some preliminary work over the last year around the basic standards such as SOAP and WSDL, which are the basic ways for describing Web services. This organization's timing is very important. We think we're about to enter a period where there will be many more technologies coming into the standardization process. I mentioned some before -- security, reliability, and transactions -- but there are several more.

So, we're at the point where the foundation for Web services, in terms of the basic connectivity, has been laid. We've clearly been talking about Web services a lot, and people at least have a vague idea of what Web services are. We want to make sure now that when we move off the basic platform for all the future standardization efforts that will take place in the different organizations, that interoperability is built in -- that it's a requirement from now on to make sure the standard coming from one place will work with the standard coming from another place.

There are just too many different specifications to be handling them all in one place. The W3C will not do them all; OASIS will not do them all; same with the OMG, or any of the other big organizations. So, it's assumed that this standardization work will be done in a distributed way. So, we need a central organization, like WS-I, that's neutral and isn't affiliated with any of these organizations, and therefore isn't involved in any of the existing cross-organization politics. We're also neutral regarding programming languages; we don't say you have to do Web services with Java or C# or .NET. So, WS-I is an appropriately neutral industry body that can drive forward the roadmap for Web services to work in a complementary fashion with the standards organizations and finally make this notion of interoperability real.

To what extent are the W3C, OASIS, and similar organizations participating in WS-I?

They're going to have to figure that out, just as WS-I is. There are different ways of answering that question because you have to define who the W3C is. The W3C has its own staff, but what's more important is the W3C has 500-plus companies involved -- it's the companies that ultimately do most of the work of the W3C. They actually create the standards or the recommendations that come out of the W3C.

When we announced WS-I in early February 2002, we named about 55 participating companies, and among them were many of the biggest names in Web services, and we fully expect more companies to come on board. The companies that are really focused on interoperability with WS-I are frequently the same ones that populate the W3C or OASIS working groups. In this way, we can really segment the work. For example, when IBM works within WS-I, we'll focus on the interoperability issues and how to thread all these things together. When we work in the W3C, we're concentrating on the scope of the work to be done in the W3C: actually creating the standards. We may be working with the requirements that come from WS-I because of its studies or the requirements coming from other places, but when we're working at the W3C, we're doing the W3C's work. We think this is going to greatly improve the level of cooperation between the groups.

Microsoft and IBM announced the Web Services Inspection specification back in November 2001. How does this fit into WS-I, if at all?

I'd guess this specification will come into play in a few months. There are several specifications out there beyond the basic few. Microsoft published a few by itself. We [IBM] published a few by ourselves. Some of them are out there simply for industry comment, and some are in an advanced standardization state. Sometimes you just have to publish something by saying, "Hey, we're putting this out there because we think this is really good. What do you think?" You try to get industry support around these notions.

I expect Inspection to be wrapped up and submitted to a standards organization within the next few months. When that happens, we'll discuss it with the other people in the WS-I and see how they'd like to use it.

So, when you say you'd be submitting it to a standards organization, you'd be submitting it to a body like the W3C or OASIS?

Yes.

To recap, WS-I is an overall organization that helps to implement the standards being developed by standards organizations, such as W3C and OASIS. It's the organization that takes the standards that have come out and shows developers and IT architects how you can implement them to actually create Web services.

Yes, here's how you can put them together to do the type of applications that you want to use Web services for. This is not a standards organization. We think of WS-I as more of a standards integrator that will put the standards together and show what subsets of these standards should be used to maximize the degree to which applications can really talk to each other. Some of these standards, while we think they're great specifications, are quite general, and whenever you have something that's general, it leaves a lot of room for interpretation. For example, if I give you four options for doing something, you're really only going to do one or two. And after a while, the industry settles on one or two. You take some time and see what your partners are doing, and go with them. We're going to use this organization to drive the idea of settling on the commonly used subsets or the common ways of mixing and matching them. So, we're going to help implement them in that way and clear up some of the confusion so the way you use it is the same way someone else might use it.

Is this where profiles come into play?

Yes, profiles are a way of saying these particular standards should be used together in this type of Web services application. We'll give scenarios, almost like a pattern. If you're building a certain kind of application, you'll have some guidance on what standards to use and how they plug together. We'll provide testing materials because our ultimate end-user for these profiles is the developer who's creating the Web services. If I'm sitting in an IT department creating a Web service, I want to have the confidence that the thing I just built uses industry standards correctly according to common conventions. That gives me a lot of confidence that I can extend the way I use Web services in my enterprise.

To what extent will Web services eliminate the need for traditional, application-to-application integration?

Web services will be a technology that can be used for application-to-application integration. But if you're asking specifically about enterprise integration through a firewall, it won't replace it. A lot of Web services is above the level of transport. So, I could send a SOAP message, which is one of the most primitive notions of Web services, across the Internet on HTTP, but I can also send it across MQSeries. That's the advantage of MQSeries: It's highly optimized, secure, and reliable. So if you're using MQSeries, you can actually employ Web services inside your enterprise software.

How aware do you think the average IT manager is of Web services?

I think they're becoming increasingly more aware. When you get to the point of Web services being talked about in the New York Times and the Wall Street Journal, it means you're talking to business people. There was an article in the October 2001 Harvard Business Review about Web services called "Your Next IT Strategy." So, the message is starting to get through to the business people that Web services is an effective way of building the applications you're going to put out on the Internet.

Now they have to start considering the traditional things like return on investment. They have to think about what they're doing in their enterprise and if they should outsource some processes. And if they outsource something like billing, how would they talk to this billing company or billing application across the Internet? Of course, we say that answer is Web services. What's getting through to the IT managers is that they have limited resources, especially given this economy. So, the question is where do they want to put those resources, especially the software engineers. They want to devote those people to the higher aspects of the application that make their businesses more efficient or differentiate them from the competition. They don't want to spend their software resources way down in the weeds of the application saying, "Well, I have to talk to this partner this way and that partner that way. And gee, maybe that library is buggy." They want that infrastructure standardized and the tools support to make it easier to handle this development. Web services gives you that standardization and so you can devote your resources to the important things in your company.

This also works in times when you have a good economy. In that situation, you're worried more about growth and scaling up your infrastructure to handle more partners, customers, and suppliers. In that case, the more you're using these common interfaces and infrastructure, the faster you can tie people into whatever it is you're doing with your business.

What is your feel for the percentage of IT managers looking at Web services as a potential solution?

I couldn't give you a percentage, but I can tell you it's a healthy number. We know quite a few companies are starting to experiment with Web services inside their enterprises. Quite a few starting to use them in production as well.

So, if you're a Java developer working with the WebSphere platform and you want to start developing Web services, which standards bodies and specifications do you need to pay attention to?

If you're a Java developer working with WebSphere, several things you need are already built into the product. You have libraries within WebSphere and IBM development tools that let you work with SOAP and WSDL, which are describing Web services, and UDDI. The four basic standards -- XML Schema (Schema is new as of last May, but support for XML has been in WebSphere Application Server for years), SOAP, WSDL, and UDDI, which is being standardized by UDDI.org -- are all supported in the WebSphere platform.

If you care about the standards, want to read the specifications, and want to see how the standardization process is going today, pay attention to the W3C and UDDI.org. That's where most of the standardization work is being done.

There's some work going on in OASIS around how Web services relate to user interactions. A lot of times when we think of Web services, we think of software talking to software. But, at least one end of the software is a browser and possibly a user talking to that browser. So, how does a user interact with a browser, which then communicates with servers via Web services technologies? How do you develop a portal that may be Web services-based so there's some intelligence in the portal? Say you fill in your name and address in one window in the portal. How can you move that information into another window of the portal intelligently? How can these things vary based on whether I'm looking at this in a browser or on some sort of wireless device? So, there are many ways of using Web services that will come about. We think OASIS will be very important.

We're hoping WS-I adds some central guidance. As these technologies and standards become more mature, IBM will continue to use alphaWorks as a way to get early code releases out to developers as quickly as possible. We'll continue to use the open source communities to develop the appropriate libraries, the software. This, as we've talked about before, speeds up the process by which we can actually get the hardened libraries into WebSphere Application Server. And as it does appear, we know our customers will have much more confidence in it because it's been used by thousands of developers before the final product was released.