Creating distributed applications for the enterprise has always been the thorniest of problems. With several competing implementations of distributed object invocation such as CORBA, RMI, and DCOM, the choices for system architects were never clear. Worse still, your choice of infrastructure could potentially limit your choice of business partners. Integration between these disparate systems could be accomplished, but the skill set required is rare and the cost is extravagant.

Microsoft has changed all of this with their .NET initiative and the concept of Web Services. Web Services are remote services exposed through universally accepted and open standards such as HTTP and XML. This new paradigm shift has removed the barriers of remote object invocation and communication between organizations large and small. You are no longer limited by the tools that you use or the operating system that you choose.

Here are the simple steps in creating and using a Web Service:

1. Create the Web Service
2. Describe the service
3. Publish the service

Creating the Web Service

The first thing that must be done is to build your Web Service. Visual Studio .NET has been built from the ground up around this concept and makes it really simple to expose methods or objects that you have already built or ones that you will build in the future. All you must do is place special headers on the methods that you want to make publicly available via your service. The service itself will be accessed through your web server using HTTP and XML.

Describing the Service

The second thing that you must do is describe your service. No, we are not talking about marketing. You must supply a human and computer readable document that will describe exactly what methods are available, what data must be sent, and what will be returned to the consumer of your service. This document is aptly named a Web Service Description Document. This document is constructed using an XML based syntax called WSDL or Web Service Description Language. More information can be found at the W3C website.

Publishing the Service

The last thing that must be done is to make your service available to customers both internal and external, as well as describe the services that you offer. The proposed solution to this problem is another open standard called UDDI (Universal Description, Discovery and Integration). The current vision is a universal phonebook-like system where businesses list the services that they offer for customers to use. This may happen in the future, but a more immediately effective approach would be publishing your service internal to your organization so that other developers could use code or services that have already been built. This allows for an immediate increase in productivity. More information can be found at the UDDI.ORG website.

Web services are an immature technology and much has to be fleshed out before they can be deployed in mission critical applications that require security, metering, and payment - but the benefits that they offer are very clear:

• Code reuse
• Platform Neutral
• Language Neutral

It really is not a question of IF your organization will use web services; it is a question of WHEN. My advice is to learn your lessons now, within your organization, rather than later when attempting integration with your business partners. Good luck with your journey into XML Web Services: The Future of Computing.