By Scott Mauvais, MCSD

If you are like most developers, you've been eyeing Microsoft's .NET strategy with quite a bit of interest. XML Web Services is one of the central .NET concepts. I have spoken with many developers about XML Web Services over the past several months. Not surprisingly, everyone is excited about XML Web Services, but they all have some questions. (Sometimes I am surprised by how excited some developers are given the questions they have.) These questions fall into four broad categories:

These are the questions I'll answer in this column. Because the .NET view of XML Web Services is such a huge topic, I will not attempt to address all of it. Rather, throughout the article I will point you to my short list of key resources—mostly books and articles—that will supply the information you are looking for and save you much time scouring the Internet.

I'll start with an overview of XML Web Services, including what XML Web Services are and what Object RPC problems they aim to solve. Next I'll show how you can use the Microsoft® SOAP Toolkit 2.0 to start building XML Web Services today and, better yet, start building interfaces that support XML Web Services to your existing Windows® DNA applications. Finally I'll wrap up with a short discussion of what XML Web Services will look like in a .NET world.

An Overview of XML Web Services

XML Web Services are the linchpin of Microsoft's software as a service strategy. XML Web Services are the way to build distributed applications that are neutral in terms of programming language, object protocol, platform, and location. Just like any good object-oriented approach, XML Web Services provide a public interface (called a contract in Web Services-speak) and hide the actual implementation. This means that you, the developer, are free to change the specifics of your implementation—including the platform on which you've built it—without affecting any of your clients.

Because XML Web Services is cross-platform and live on the Internet, users can access your application whenever they want and from whatever machine they're using. What's important is that your app is more service than application. While most people focus on the various business models of software as a service, what I find most intriguing about XML Web Services are the hosting and delivery models. (Obviously I'm a software geek and not a marketing exec.)  Sure, software as a service does provide some interesting annuity-based models, but those already exist as software that I can subscribe to, buy outright, or simply use on a one-off basis every now and then for a marginal fee. You see, hosting and delivery allow you to meter usage and then adjust the pricing accordingly. And because your application is hosted as a Web Service rather than being installed on every client, you can ensure that everyone always has the latest version.

Microsoft has built XML Web Services on top of Internet standards such as HTTP and XML. This means that any application that can listen and respond to HTTP requests and send and receive XML (and XML is nothing but a text stream) can become an XML Web Service. The same is true for client applications: if they can use HTTP and XML, they can utilize any XML Web Service regardless of platform or location. If you are new to XML, your best resource is Jake Sturm's book, Developing XML Solutions. With this book, you will get an in-depth look at building XML applications with lots of samples. To get a feel for what is in the book and to make sure it is right for you, you can check out the table of contents and even read a sample chapter, titled “XML Namespace, XPath, XPointer, and XLink.”

This reflexive aspect of XML Web Services leads to an important point: every XML Web Service is a potential client, meaning that you can easily integrate multiple XML Web Services—all from different companies and on different platforms—into a single XML Web Service.

What About COM?

If you have been working in a Microsoft development environment for long, you probably recognize some of these points, and you might think that the Microsoft Component Object Model (COM) already provides many of the benefits attributed to XML Web Services. To a certain extent, you are right. COM certainly does provide language independence, because most modern tools allow you to develop COM components regardless of your development language. The Microsoft Windows Scripting Host even lets you put COM wrappers around any language that supports the Microsoft Active Scripting standard.

With the release of Windows NT® 4.0, COM gained some location independence with the advent of Distributed COM (DCOM), formerly known as Network OLE. One of the main problems with DCOM is that it is not particularly firewall-friendly. For example, let's say you've just finished a DCOM-based application called SuperWidget that will solve all of your company's time-reporting and expense-reporting issues. To give your remote employees access to SuperWidget, you have to convince your network administrators to open up some ports on the firewall, as these ports are often blocked. Good luck! When you've convinced them to see the light, configuring Microsoft Windows to use the selected ports takes some effort. You will probably want to refer them to a couple of helpful Knowledge Base articles: Q193230-HOWTO: Configure RPC Dynamic Port Allocation to Work with Firewall and Q248809-DCOM Does Not Work over Network Address Translation-Based Firewall.

Note: Although almost completely unrelated to this article, I must share one of the most useful tips I have picked up in a long time: If you're using Microsoft Internet Explorer and you know the Q number of a KB article, just enter MSKB and the Q number on the address line of your browser. IE will take you directly to the article you want, allowing you to bypass that search page. For example, to bring up the Dynamic Port Allocation article, just enter MSKB Q248809. Don't forget the space.

Finally, there is the issue of platform independence. While you can find COM implementations on other platforms, including HP and SGI, COM has gained real traction only on the Microsoft Windows Platform. As a result, DCOM is a great solution for intra-company applications, but often presents problems for inter-company solutions.

Lest you think I'm picking on COM, the same issues apply to all Object RPC protocols. In fact, the situation is even more complicated for CORBA's Internet Inter-ORB Protocol (IIOP). The big problem with CORBA and IIOP is that each platform implements the protocol somewhat differently. Therefore, trying to access a CORBA-based app running on IBM's AIX from a HPUX machine is nearly as difficult as using any of the COM/CORBA bridge products. When you consider the fragmentation of the UNIX market, this approach becomes unusable. For an excellent article discussing the various Object RPCs (and their limitations) see Don Box's MSDN article entitled “A Young Person's Guide to The Simple Object Access Protocol: SOAP Increases Interoperability Across Platforms and Languages.”

SOAP to the Rescue

SOAP and XML Web Services solve all these problems. The Simple Object Access Protocol 1.1 (SOAP) is a W3C Note that describes how you can access services and objects in a platform-independent manner. It defines a simple, lightweight XML protocol for exchanging structured and typed information on the Web. Microsoft, IBM, Lotus, DevelopMentor, and UserLand Software wrote the initial specification and submitted as a note to the W3C in May 2000; it's expected to become a recommendation later this year. To learn more about SOAP, pick up Brian E. Travis's book XML and SOAP Programming for BizTalk Servers. While focused on BizTalk, it is full of good information on SOAP. To learn more, you can look over the Table of Contents or read a sample chapter, entitled “The XML Application.”

When you use SOAP (or any messaging-based or RPC-based protocol), the client and the server must agree on a calling convention before a client can instantiate a remote object and invoke its methods. To accomplish this, SOAP has defined the Web Services Description Language (WSDL). WSDL is an XML-based format that describes the services offered by your application and the format a client must use when requesting these services. In SOAP, this is called the contract. If you are familiar with COM, you can look at this as the Interface Definition Language (IDL) of SOAP. A big benefit of SOAP over COM and CORBA is that the interface is written in the same language—XML—as the message itself. This means that you can use the same tools and procedures to create and query the metadata that you use on the message itself.

The best part of SOAP is that you can start using it today and turn your existing Windows DNA COM-based applications into Web Services. To create an XML Web Service, the first thing you need is an application. (Just making sure you're awake.) Let's assume your application is a COM component. Next you'll need a WSDL file that describes the services your component offers. Then you need to publish this file so that client applications can learn how to interface with your application. Now you need to create a Web Services Meta Language (WSML) file that maps the services described in the WSDL to the specific methods in the COM object. (If you have been following the evolution of the SOAP specification, you will recognize WSSDL as what used to be known as Service Contract Language (SCL), SOAP Description Language (SDL), and IBM's Network-Accessible Service Specification Language (NASSL).) If you don't want to expose all your methods to the Internet, just omit them from the WSDL and WSML files. Finally, you need a listener service that acts as a proxy. It will respond to incoming SOAP messages, pass them along to your component as specified by the WSML, and then return the results to the calling application.

Although writing the WSDL, WSML, and listener service can be tedious, you can certainly do it yourself: all the information you need is in the SOAP 1.1 specification. But why bother? Microsoft just published the Microsoft SOAP Toolkit 2.0, which is fully supported by PSS (unlike Version 1.0, which was just an MSDN sample). The Microsoft SOAP Toolkit automates the process of turning your COM components into Web Services via a simple wizard interface.

The Microsoft SOAP Toolkit contains a number of components:

• WSDL Generator. Generates WSDL and WSML documents that describe COM servers
• SOAP Messaging Objects.  Generates objects for use with SOAP Messaging Object framework
• ISAPI Listener.  ISAPI module that dispatches SOAP requests to the COM components
• Debugging Utilities. Includes a trace utility to watch the SOAP Messages
• C++ Support Files.
• Documentation.  SOAP SDK documentation

To create an XML Web Service with the Microsoft SOAP Toolkit, simply point the WSDL Generator at your DLL after you have registered it.. The Generator will inspect the DLL and create all the files you need for your Web Service, including the WSDL, WSML, and a listener service.

As you go through the WSDL Generator, the wizard will ask whether you want to use ASP or ISAPI as a listener. When you start building your Web Service, you probably want to start with ASP. If you select ASP, the WSDL Generator will build an ASP file to act as your listener. The benefit of ASP over ISAPI is that you can easily add pre-processing and post-processing instructions to help fine-tune your XML Web Service during the development process. Besides, ASP is much easier to debug than ISAPI. The trade-off, of course, is performance. This is easy to overcome: As soon as you finalize your Web Service, simply rerun the WSDL Generator and select ISAPI instead of ASP. The wizard will update all the files to utilize the ISAPI filter. If you still need the pre-processing and post-processing after you've moved to ISAPI, you will need to write a COM wrapper around your original COM object.

With the Microsoft SOAP Toolkit you can start developing .NET applications today.

Preparing for .NET

If you are starting a new application today, which framework should you use? Clearly you want to migrate your existing Windows DNA applications over to Web Services, but should you build these XML Web Services with the SOAP Toolkit or around the .NET Framework with a tool like Visual Studio® .NET? Fortunately, Microsoft has given us some clear advice: If you have existing Windows DNA applications, you should be making enhancements to them with the Toolkit so that you can start developing XML Web Service Interfaces now. What about new projects? If you expect them to ship in the next four months or so, you also want to use the Toolkit. Finally, for apps that will release more than four months out, you should plan to use the .NET Frameworks.

XML Web Services in a .NET World

The best part about XML Web Services is you don't have to wait for .NET to start using them. You can use the SOAP Toolkit to architect your current applications around XML Web Services.

If you think working with the Microsoft SOAP Toolkit sounds easy, wait until you take a look at .NET. A great deal of this ease is attributable to .NET's metadata. When you compile your application, all the metadata is compiled right into it. Think of it as a typelib on steroids. Because the app has the metadata, you don't need to register it. This is what enables the XCOPY deployment, as well as the ability to have multiple versions of the same app installed side by side. On top of this, you get all the benefits of ASP.NET, including improved session management, automatic restarting of apps, and the separation of the user interface from the application code. The best way to prepare your apps to take advantage of .NET is to start working with the SOAP Toolkit today.

Conclusion

This month I started off by explaining one of the key components of the .NET vision: XML Web Services. After covering the vision behind XML Web Services and software as a service, I discussed some of the problems with traditional Object RPC protocols and how XML Web Services and SOAP in particular address them. I then drilled down into the specifics of SOAP and showed you how you can use the new Microsoft SOAP Toolkit 2.0 both to build XML Web Services today and to migrate your existing Windows DNA applications to the XML Web Services model. Finally I talked about how you can start planning for the .NET frameworks and some of the changes you can expect.

Microsoft Press provides in-depth documentation for these and all the other issues related to developing for .NET. For a complete list of .NET titles from Microsoft Press, see the Inside Information on Microsoft .NET section.

The best place to start is with Jake Sturm's book, Developing XML Solutions, which provides a comprehensive developer's guide that examines XML-related technologies for data exchange and shows how XML fits in the Microsoft Windows architecture.

As I mentioned earlier, you also should check out Brian E. Travis's book XML and SOAP Programming for BizTalk Servers. It has a great deal of work-ready information and tools for building business-to-business e-commerce solutions using eXtensible Markup Language (XML), the Simple Object Access Protocol (SOAP), and the BizTalk Framework.

Another good book is XML Step by Step by Michael Young. It is a practical, hands-on learning title that clearly explains the basics of XML and shows both nonprogrammers and Web developers alike how to create effective XML documents and display them on the Web.

For detailed information on all Microsoft Press Windows 2000 titles for developers, visit the Windows 2000 for Developers page. For a complete list of all the developer titles, see the Developer Tools section.

For some great links and the latest information on XML Web Services, see the MSDN Web Services home page. A good troubleshooting resource is Keith Ballinger's article on Web Services Interoperability and SOAP.

For more information on Microsoft Visual Studio.NET, see the Visual Studio Next Generation Home Page. To get started right away, you can download the Microsoft .NET Framework SDK Beta 1.

One great way to learn more about the .NET SDK is to review the slides from last summer's Microsoft Professional Developers Conference.