Referred to by some as the fourth wave of computing, Web services intend to standardize the way business applications communicate with each other, whether they are within an enterprise or communicating with external partners, customers, and suppliers. In this article we explore the key standards behind Web services, as well as the various tools and technologies that the upcoming Microsoft .NET provides for developing and deploying dynamic Web services.

What is a Web Service?
I like MSDN's (Microsoft Developer Network) definition of a Web service. A Web service is a unit of application logic providing data and services to other applications. Applications access Web services via ubiquitous Web protocols and data formats, such as HTTP, XML, and SOAP, with no need to worry about how each Web service is implemented.

Why Web Services?
In a typical large enterprise, many application delivery models and frameworks exist today. For instance, a number of departments may use the Microsoft ASP/COM-based frameworks, another group may utilize one of the powerful application server environments, and another group may have developed their own proprietary application framework. Of course, there is a need to standardize architectures and frameworks across an organization, but getting there is a challenging and in some ways impossible task. What is needed is a mechanism where a number of systems, both internal and external, can be integrated in a loosely coupled fashion. Because Web services are based on open protocols and standards, the participating systems can be implemented in different technologies but still be available under a single coherent space. Change is also inevitable in corporate IT, where a popular application framework today will soon be outdated and a better framework will be available tomorrow. Web services can be effectively utilized in this scenario: while going through the migration a company may choose to expose a number of core features of their ASP/COM-based application using Web services and then slowly migrate their user interface, interaction, and eventually the complete application into the .NET flavor.

Web Services Standards
Web services builds on top of the development of the Internet. Figure 1 shows one view of the various connected standards around their development and deployment.

We have TCP/IP as the basic foundation of the Internet, which uses HTTP/HTTPS as ubiquitous communication protocols. With the definition of XML, a ubiquitous markup language has been created to describe and tag data. XML Schemas have recently surfaced as a rich alternative mechanism to DTDs, to define in XML data about data (metadata). SOAP is the first entry into the world of Web services by defining a communication protocol using XML Messages for disparate systems to utilize the Web to communicate with each other. WSDL (Web Services Definition Language) provides metadata and a description of SOAP-based Web services; UDDI (Universal Directory, Description, and Integration) provides a standard registry and discovery mechanism to register, locate, and consume Web services.

SOAP
SOAP (Simple Object Access Protocol) is a standard which defines a collection of XML messages that can be used for intrasystem communications. It expands the World Wide Web, which has traditionally been used for information discovery and dissemination. SOAP allows the Web to be used as a common vehicle by systems to communicate with each other. These systems can be within a department or a corporate intranet, and communicated within corporate boundaries using the HTTP protocol, or can encompass B2B communications by providing the basic communication protocol for extended enterprise-based integrations.

Because the message format is based on the XML standard, SOAP can be used to communicate among multiple computer architectures, languages, and operating systems. SOAP enables a new class of applications called Web services, which expose services in a standard way so that application developers can create new applications by putting together services from many different sources on the Web.

SOAP defines an XML Schema-based Object Model for three main objects - SOAP Envelope, SOAP Header, and SOAP Body. Let's examine the various XML objects by looking at what happens behind the scenes when a client invokes the simple SOAP-based Web service, HelloService (see Listing 1).

WSDL
SOAP provides a standard way for systems to communicate with each other using the ubiquitous Internet protocols HTTP/HTTPS. No service consumer would be able to use Web services seamlessly unless they knew the exact specification or metadata about the SOAP service. WSDL, a specification developed by the UDDI group and also submitted to the W3C, provides such a way through an open XML-based syntax. WSDL allows service providers to expose the various Web services through an XML specification. Technically speaking, a WSDL document represents the description of a Web service as a collection of ports (or endpoints). The document is typically composed of two sections: one which describes the abstract data types of the messages and the operations, and the second a binding section which associates a service address (typically a URL) with the type definitions.

Typically, if you are a developer/architect creating Web services, then apart from providing the URI/URL of your SOAP service, you want to publish its specification (types/ parameters) using WSDL. However, the Microsoft .NET toolset allows the WSDL-based service description to be almost prebuilt for you. Web services developed using ASP. NET (through .asmx files) provide an auto-generated and customizable WSDL structure.

UDDI
Where there is a description or metadata about a collection of objects, a natural extension to that philosophy would be to have a registry. UDDI provides both private and public registries of SOAP-based services defined using WSDL. UDDI is then, of course, a Yellow Pages to the world of dynamic Web services. The aim is to provide true B2B and Enterprise Integration. Potentially, a scenario like this can be conceived and developed where a computer manufacturing company wants to order some raw materials from B. It queries the public UDDI registry, hosted by a vertical exchange and through that is able to locate a company which provides the appropriate raw materials. Through well-defined services, an integration workflow is then able to call an order entry system of that supplier and order goods. This can be done in an automated, seamless fashion. If this scenario looks a little difficult to achieve, try simplifying some aspects of it and you would realize that the individual components themselves can prove to be very useful as well.

Types of UDDI Registries
Three major UDDI registry providers can be conceived:

1. Private Registry: Your own organization may document and describe its internal Web services, which can foster interdepartmental communication and integration. Like any registry, you will also have separate Testing and Production registries as well. As we will discuss later, Microsoft provides a tool called UDDI Developer Edition 1.5 which can be used to create a private UDDI registry.
2. Public UDDI Registries: As part of its commitment to promote the UDDI standard, Microsoft has created its own publicly available secure UDDI registries. The production UDDI Registry is available at http://uddi.microsoft.com; a test version of the registry is available at http://test.uddi.microsoft.com.
3. UDDI Registries hosted by Exchanges: As part of your vertical or horizontal industry, a unification and common access initiative can potentially foster the development of a registry focused on your service offerings. Typically, these exchanges have something in common - either they are focusing on solving a particular business problem or are developed as part of a vertical organization.

Microsoft .NET Framework
Overview
From a developer's perspective, Microsoft .NET Framework is an environment for developing, deploying, and executing applications - both traditional Windows and Web-based applications as well as dynamic Web services. With a rich set of class libraries and the flexibility of multiple languages, .NET framework allows developers to focus on creating application business/ presentation logic and leaving the "plumbing" work to the underlying framework.

.NET Framework was in Beta 2 (this stage is said to be feature-complete) at this writing. More information is available on the .NET homepage at www.microsoft.com/net/.

Components
The core Microsoft .NET Framework includes the common language runtime, class libraries and the bindings for the supporting languages (toolkits, document, etc.), and ASP.NET. In addition, the Visual Studio toolset (Visual Basic, Visual C++, etc.) has emerged under a common next-generation Visual Studio.NET umbrella. Under the .NET umbrella is a group of components, including Windows 2000 as the core operating system, .NET Enterprise Servers such as SQL Server 2000, and a set of Web services provided by Microsoft and collectively called the .NETMyServices (see Table 1).

Tools for Developing
Web Services Using .NET
As part of the .NET umbrella, a number of tools will be available for development and deployment of Web services.

ASP.NET-based Web Services
A key feature of the next generation Active Server Pages (ASP.NET) technology is that it makes creation of Web services as simple as creating dynamic Web applications. ASP.NET-based Web services (written as .asmx files) aim to revolutionize the world of Web services. ASP.NET Web services intend to achieve the same benefits that Active Server Pages (and now ASP.NET) have achieved for creating dynamic Web pages. Developing and deploying a Web service using ASP.NET Web services support is as simple as developing and deploying a Web page.

Listing 2 creates a full-featured SOAP-based service called HelloService with a method SayHello that returns a string message. .NET Framework-based Web services use SOAP for communication and WSDL to represent the description and metadata for a service. An important benefit of this approach is that the various pre-built .NET libraries and the custom libraries that you develop can be used to create dynamic Web services. For instance, we can use the flexibility of ADO.NET-based components to interact with relational databases such as SQL Server. Through .NET and the COM interoperability layer it's possible to interact with any COM-based packaged enterprise application, such as SAP R/3 and Siebel, and make it available as an open Web service.

Simply opening the URL in Internet Explorer provides a basic rendering which lists the various methods and their descriptions (see Figure 2). Executing the Web service with a browser using the URL http://localhost/WebServices/HelloService.asmx/SayHello? returns the following XML response:

<?xml version="1.0" ?>
<string xmlns="http://www.silverline.com/Webservices">Hello World from .NET </string>

Browsing to the URL http://localhost/WebServices/HelloService.asmx?WSDL, returns the description about the Web service in WSDL format (see Figure 3).

The returned XML can then be processed by any application which can communicate using HTTP/HTTPS and has XML processing capability.

It's also possible to invoke the Web service as part of another .NET application after proxy classes have been generated for the appropriate language bindings. This mechanism is a .NET standards-based alternative for remote objects. As we will see below, Visual Studio.NET has built-in integration for discovering and using .NET Web services.

HelloService service = new HelloService();
String msg = service.SayHello();
Console.WriteLine(msg);

Using the Windows XP Professional SOAP Client
The same service can also be invoked through any environment which supports SOAP/WSDL specifications. For instance. the upcoming Windows XP Professional ships with SOAP client software which provides easy access to SOAP/WSDL-based Web services. The following code snippet shows the basic script required to call the Web service:

Dim client
Set client = CreateObject("MSSOAP.SOAPClient")
client.mssoapinit("http://localhost/WebServices/HelloService.asmx?WSDL") wscript.echo client.SayHello()

Visual Studio.NET
Microsoft Visual Studio has been the key de-facto standard for developing Visual Basic-, Visual C++-, and ASP-based applications. Visual Studio.NET (also known as Visual Studio 7.0) is the next revision of Microsoft Visual Studio toolset. Visual Studio.NET supports development in the new Microsoft language C#, Visual Basic.NET, and ASP.NET. Visual Studio.NET provides an integrated development and debugging platform for development of Windows forms-based GUI applications, Windows services, reusable components (or building blocks), Web applications, and services.

From a Web services perspective, Visual Studio.NET supports integrated development of C# and Visual Basic.NET-based ASP.NET development. Web services can be designed as easily as a Web application or even a traditional Windows form. Integration with supported databases (using ADO.NET) is key and enables faster wizard-based development of dynamic applications. These features are provided by Visual Studio.NET from Web services.

One key feature provided by Visual Studio.NET is that of adding a remote Web reference. This allows Visual Studio to be a service consumer and use the intended Web service within its own project. From an application perspective, it's possible for your business partner to establish a set of core SOAP/WSDL-based Web services and these services, including their complex parameters, can then be automatically called. This capability is provided by a wizard called "Add Web Reference" and is similar to adding a reference to a local DLL or .NET Component. The wizard can bind to either a remote/local WSDL service contract or a discovery page URL (.disco or .vsdisco files). The wizard also allows querying the Microsoft UDDI Registry (Test and Production) to find services for a given business name as well. For instance, our Web service, http://localhost/WebServices/HelloService.asmx can be linked through its WSDL contract, http://localhost/WebServices/HelloService.asmx?WSDL, as shown in Figure 4.

The reference then shows up next to all of the component references and the Web service can be used within the project like any other class library. For instance, here's a code snippet using our previously defined Web service.

using System;
namespace DemoApp
 {
    public class Main
    {
     public Main()
     {
   localhost.HelloService hello = new localhost.HelloService();
Console.WriteLine(hello.SayHello());
    }
   }
}

Microsoft UDDI SDK
As part of Microsoft's public UDDI Registry implementation (both production and test registries) at http://uddi.microsoft.com, Microsoft has released a toolkit called Microsoft UDDI SDK which provides object mappings of the various UDDI functions. These objects can then be used as part of any software program/ component; a basic UDDI Explorer application is available as part of the SDK. The current release (1.5.2) of the UDDI SDK contains two versions of the SDK, one to use from within the existing production-quality Visual Studio 6 toolset and another which targets the upcoming Visual Studio.NET Beta. It also contains a beta version of an implementation of a private UDDI registry, known as the UDDI Developer Edition 1.5. which requires a Windows 2000 operating system and Microsoft SQL Server (Personal, Standard or Enterprise; MSDE can be used as well).

Microsoft BizTalk Server 2000
One of the components of .NET Enterprise Servers, BizTalk Server is an integration platform for connecting internal enterprise systems with external customers, partners, and suppliers. BizTalk Server leverages XML in multiple fashions: XSLT for transformation of data as it flows from one system to another; XML-based Schemas to define the documents. It implements the XML/SOAP-based BizTalk Framework, which provides a core set of reliable messaging specifications for B2B communications. BizTalk Server supports multiple pluggable transport protocols, such as HTTP/HTTPS, SMTP, and Message Queuing, and may be used to extend Web services for asynchronous communications.

Microsoft SOAP Toolkit 2.0
A number of technologies that we've explored here, particularly ASP.NET, are part of the .NET framework which is in beta release at this writing.

However, you can start developing Web services using ASP/COM+ technologies. Microsoft has released Microsoft SOAP Toolkit, which will provide a bridge between the world of Web services (SOAP, WSDL, etc.) and the world of COM/DCOM components. Using a wizard-based approach, SOAP Toolkit allows Web services wrappers to be defined on top of existing COM-based components and then deployed using Internet Information Server via Active Server Pages (ASP) scripts or an ISAPI Listener. SOAP Toolkit also generates stub asp scripts which expose the WSDL interface of the Web services created.

Conclusion
With the underlying standards and the toolsets that software vendors are developing, Web services is ready for a challenging task. Microsoft .NET framework takes Web services forward by providing a number of integrated tools for building and deploying perspective. One important thing to note is that even though key components of the .NET framework are in beta stage, there exist key components such as Microsoft SOAP Toolkit and BizTalk Server that can help in Web services-enabling existing applications in preparation for .NET.

References

1. Web Services Description Language (WSDL) 1.1: www.w3.org/TR/wsdl
2. Simple Object Access Protocol (SOAP) 1.1: www.w3.org/ TR/SOAP/
3. Universal Description, Discovery and Integration (UDDI): www.uddi.org/specification.html
4. Microsoft UDDI SDK v1.5.2: www. micro soft.com/downloads/release.asp? Release ID=30880
5. UDDI Technical Overview http://uddi. microsoft.com/developer/techOverview. aspx
6. Microsoft .NET: www.microsoft.com/net
7. MSDN Online .NET Section: http://msdn. microsoft.com/net/
8. Microsoft Visual Studio.NET: http://msdn. microsoft.com/vstudio/nextgen/default.asp
9. MSDN Online Web Services Section: http: //msdn.microsoft.com/webservices
10. Microsoft SOAP Toolkit 2.0 SP2: http:// msdn.microsoft.com/downloads/ default.asp?URL=/code/sample.asp ?url=/msdn-files/027/001/580/msdn compositedoc.xml
11. Microsoft BizTalk Server: www.microsoft .com/biztalk/
12. Microsoft BizTalk Framework 2.0: www. microsoft.com/biztalk/techinfo/framwork 20.asp

• Figure 2
• Figure 3
• Figure 4
• Figure 5
• Figure 1
• Source Code
• Figure 6