For many information technologists, Web services involve a confusing mix of existing and new technologies. You have a variety of open standards, such as XML and SOAP, which were hammered out in public standards committees. You have licensed technologies such as Java, which work on all platforms but are privately controlled. And you have proprietary standards, such as C#, which were created to ease technology implementation regardless of who sets the standards, but only work in Microsoft development environments.

The conventional wisdom is as follows. Because Microsoft has set itself apart from all other major Web services players with tools that only work in its Visual Studio .NET environment, the stakes of Web services implementations are higher than they should be. If you choose a largely open standards approach, you can mix and match vendors such as IBM, BEA, Oracle, and Sun. If one doesn't work out, you can shift to another without needing to scrap your basic philosophy, though you may need to do some minor retraining and retooling. If you choose the Microsoft approach, you cannot change vendors without major retraining and retooling. Because of the costs involved, Microsoft's approach locks you in for all intents and purposes. It works both ways, of course--it locks you out if your initial choice doesn't favor Microsoft.

Against this backdrop, I spoke with the directors of Web services technologies for Microsoft and IBM, the latter being the early leader in the open-standards approach. Neil Charney is the director of the .Net connected strategy group for Microsoft. Bob Sutor is director of IBM Web services. Both discussions were cordial and lively, providing more common ground than you might expect after having read the above, and challenging conventional wisdom in a variety of ways. I'll start with the Neil Charney interview and follow with the Bob Sutor Q&A.

Microsoft's take: Neil Charney

Recently published reports quote IBM representatives claiming that Microsoft's Web services approach is "proprietary." For example, John Swainson, general manager of IBM's Application and Integration Middleware division, told eWeek, "Microsoft sort of lives in the world of proprietary standards. They argue they are open standards, but the reality is the implementations are mostly proprietary." How do you respond to these comments?

Wow. You don't beat around the bush, do you? (Laughs.) I think most of this talk is rhetoric and hyperbole. One of the most beneficial things about Web services is that we can move beyond a blanket approach and into more of a customer-centric approach. We can go to a client site and recommend what's best for their business. As long as their choices support Web services, they allow for interoperability and integration with what they've already invested in.

The need for this approach is felt on a grass-roots level. Customers that I've talked to are tired of needing to choose between monolithic solutions. They ask me, "Can't we all just get along?" The days of actually walking into a customer scenario and saying, "Here's the deal. Everything has to run on Windows...," are over. It's not customer-centric enough. These days, customers don't want to rip out stuff they've paid for just for the latest and greatest. They want to take advantage of what they already have. Calling technology "Legacy" is a pejorative way of referring to stuff that still works. Why not build technologies that make the legacy stuff better? That's the value of Web services.

What about Java? Microsoft has a history of not supporting Sun's version of Java in Windows clients and developing alternatives to Java, such as J++ or C#, in its development tools. Doesn't that hinder interoperability with existing Java applications?

A lot of customers are happy with what they have and are not interested in changing what they have. If they have a lot of J2EE [Sun's Java 2 Enterprise Edition] applications, they have historically not talked with a Microsoft representative. If they had, they would know that they could use Visual Studio .NET to create applications that work with Java applications.

Wait. They won't be J2EE applications, but C# or some other standard, right?

Yes, but the result is the same. It's easy to expose the application as a Web service, which should work with a J2EE app or any other Web service-enabled application. Our approach is to assume that customers may at some point want to make their applications work with what's already there; so we make it easy to do so. With Web services, the approach can be much less monolithic. So, customers' task is to evaluate what is the best platform for developing these applications from a performance, ease of use, and cost perspective.

Last summer, Microsoft spokesman Jim Cullinan said Microsoft will no longer support Java, in response to Sun's suit forcing Microsoft into bundling Java Support into Windows XP. How does this decision affect your ability to help customers build on their existing Java applications and libraries?

As a language, it's something that we've supported and will continue to support. But it's a myth that there is some standard way of treating Java. There's no J2EE-compliant Web service. IBM has its own take. BEA has its own model. Whatever the platform, Web services allow you to bridge these different worlds. The interoperability of Web services enable collaboration and cooperation in the industry for the first time.

How do you make a C# application on Visual Studio .NET work with a J2EE application that was built on some other development platform?

It takes either a couple of lines of XML code or two clicks of the mouse to make it into a Web service. This makes it callable as a Web service for any application via SOAP or XML. In a sense, Visual Studio .NET makes it as easy to develop Web services as it is to develop applications with Visual Basic.

When you say it's just a couple of lines of code or two clicks of the mouse to make an application available as a Web service, that's on paper, right? In practice it has to be more complicated than that or everyone would be jumping on the bandwagon.

Yes, you're right. There's a lot more to integrating with Web services than simply making an application available as a Web service. But even now it's an order of magnitude easier than the current crop of integration technologies. In terms of the work that needs to be done to make Web services deliver on its promise, we're working with over 100 vendors to improve the interoperation of the specification.

I remember when VB Script viruses first made their appearance in the mid-to-late '90s. Because Visual Basic is so easy to write programs in, a script kiddie could write a virus that infected any application in which VB Script was the scripting language--pretty much any Office application--pretty easily. If creating Web services on Visual Studio .NET is as easy as Visual Basic, doesn't that make it less secure also?

Security is something you need to pay attention to no matter what the underlying interoperability standard is (whether it be COMM, CORBA, or Web services). In the last two years, more so than ever. There are lots of existing ways of ensuring security on the Web, from as simple as Secure Sockets Layer to as complicated as private leased networks. Our customers are pushing for Web services security standards to layer on top of these. IBM and Microsoft are working together to form the WS-Security standard. The standard separates the description of the security from the security itself. WS-security is a way of pointing to the security model you want to use. What you want is flexibility. You want to give customers the ability to shift their security model or change it on the fly. The standard allows for this flexibility.

If the results of the Web service are the same regardless of the development platform, why would customers prefer one vendor over another?

The results aren't the same; the communication is the same. Customers can now say, "I will choose based on performance, productivity, value, time to market." The results are the applications they're building. We need to move beyond the platform wars and get down to evaluating the technology on the basis of what customers care about--the easiest, quickest, and most economical. Interoperability is the key requirement.

In theory, Java gives you interoperability. Why would you need Web services if Java delivered on its promise?

What Java had promised was to make everything work with Java. This is another monolithic approach. What they were saying was, "If it doesn't work with Java, it can't interoperate."

So how do you respond to the charge that Microsoft's approach is proprietary?

Calling something proprietary is flag waving that means different things for different people. We optimize our languages for our development platform. Everybody does that. But from a customers' perspective, that's the way to improve developer productivity, speed time to market, and generally make it easier and cheaper for the customer.

IBM's take: Bob Sutor

IBM has shifted course towards open standards and open source technologies such as Linux and Apache a lot faster than analysts expected. How did this shift come about?

It all came out of IBM Global Services. We have more than 150,000 service professionals talking with customers every day. It's a huge part of our business. We get paid to deliver customer solutions. That means bringing value to the customer however the customer wants it done. Customers are asking for integration technologies, both internally with the variety of systems that customers have on site and externally with partners and customers.

Once you get this input in, you could respond in a variety of ways. You could say, "We've developed technology that lets you integrate everything," or you could say, "There's a lot of stuff out there that will help you integrate what you have." For the most part, IBM chose the second way. Why?

Our job is to help solve customer problems. We will use any technology that lets customers move data and applications around while keeping their underlying architecture intact. In that context, we'd love to sell them IBM hardware and software, but we don't make it a requirement that they use our stuff to solve their problems. That's why Web services fits what we do so well. Web services are built on top of existing architectures and are platform neutral.

Even though you have adopted open source and standards like J2EE, you have to develop tools like WebSphere Studio that involve elements of your own unique approach. Can you explain what WebSphere is (for the layman) and why you think it's the best approach?

WebSphere is an application server based on J2EE [Sun's current standard for Java] and it also runs on Linux. WebSphere Studio is a platform on which you develop high-level applications that fit behind your back-end systems. Think of WebSphere as a bridge between the outside world and your enterprise, which consists of a Web site, perhaps some software-to-software communication with other customers or suppliers, and perhaps wireless communications. WebSphere Studio makes it much easier to develop new applications on demand. It's how you get information to flow between your company and the outside world.

Clearly Web services hold great promise. But we see slower than expected adoption primarily because of immature standards. Do you see standards as a key issue in Web services adoption?

Analysts say this all the time--people are waiting for all the standards to fall into place before they adopt the technology. In practice, people don't wait for all the standards. For example, people didn't wait to use the Internet when all we had were early versions of HTML. People adopted Internet technologies in their infancy. In this way, Web services are like other emerging technologies behind it, such as XML and Java. The early adopters implement solutions with the technology before the standards are all in place.

Certain standards emerge early, depending on their priority. The first priority Web services standards developed the means to get conversations going between the players. "Hi, I'm a Web services application. This is how you talk to me. This is how I talk to you." That part's in XML. After that, standards deal with how we can create a message envelope to standardize ways of exchanging information. That part's in SOAP. These are the basics and are close to being finalized. Incidentally, WebSphere is up to date on all these standards.

The second priority is security. Customers have all told us that they're not going to send their business information on the Web without better security. There are security standards in place--for example, encryption--that can be perfectly applied to Web services. What needs to be better, and what we're working on with WS-security standards, is evaluating parts of the message and giving special security to them. For example, if something is a medical document, there would be special security requirements for it. We are developing systems management products based on WS-security that should be released in 2003.

How does IBM view Web services going forward?

We see it as part of the plumbing. In two or three years, it's not going to have that much special significance, it's just going to be how we do things. Web services take a heterogeneous collection of things and make them look homogeneous. They will be the way to standardize partnerships and internal technologies.

One big push right now is in the mobile arena. We are building a tool kit for mobile devices to make all these different things very consistent with each other and with what they're connected to.

Our other main push is in grid computing. We're developing an advanced resource manager to take best advantage of all available processing power for Web services, especially in database systems. It allows customers to really use processing resources as efficiently as possible.

Finally, we're working on automating as much of the systems management as possible. Customers ask us, "Why do I need a person to maintain these systems? Why can't I just switch it on and let it work and have it back up automatically?" Automating systems management is part of the promise of Web services, across different servers from different vendors. All these things threaded together is what we call On Demand computing. It's just part of what we do.