After a spectacular birth and early development, the Internet is blossoming into a medium for users to interact with businesses and services in new, exciting, and complex ways. By necessity, dynamic Web content will increasingly be driven by more than one provider, whether that provider is a remote corporate office or a major Web portal. These providers will need tools to allow smooth interoperation between hosts and platforms. The focus of Microsofts latest all-encompassing technology initiative, Microsoft .NET (pronounced dot net), are Web servicesapplications built to a universal platform for information exchange. Announced last June, Microsoft .NET is a major evolution of the DNA (Distributed interNet Applications) architecture, which promoted multitiered, component-based programming. The Microsoft .NET Web services architecture seeks to extend the distribution of components and applications across the Internet via the Simple Object Access Protocol (SOAP). In the Microsoft .NET vision, future dynamic Web content will be driven by multiple Web services hosted by various providers throughout the intranet and Internet.
A loose definition of a Web service is simply server-based functionality available over the World Wide Web via standard URL addressing. A search engine is a common Web service. To the user, a search engine appears to be a single, simple interface: enter a query and click Search to retrieve the results. However, think about all the functionality going on behind the scenes. The query is performed against large-scale indexing databases, employing various Web techniques to trawl for pages. The users mouse clicks are often recorded and analyzed to provide profiling and performance feedback. The targeted advertising displayed on the results page is also somehow generated. Customized results are often tailored for registered users. To provide quick results, search engine sites must distribute these functions among several services running on multiple servers unseen by the user. Major portal sites must currently build custom solutions such as these to enhance their users visits. The Web services paradigm intends to simplify this level of scalability and integration for all content providers. You are probably not considering architecting the next great search engine site. You may want to consider leveraging the Web infrastructure for your next distributed application, however, unless you don't anticipate Web application requirements or the need for long-term scalability. SOAP is the messaging system providing the high level of integration for Web services. On the Windows platform, SOAP
is a vehicle for deploying Component Object Model (COM) objects on the Web and for integrating with non-Microsoft systems.
Casting a Wide .NET
The Microsoft .NET developer initiative seeks to simplify Web programming on many fronts. On the Windows platform, a Common Language Runtime (CLR) with significant features such as garbage collection is provided for all Microsoft .NET-compliant languages to share. Creating components housing business logic will be simplified by true language interoperability and major object-oriented enhancements. Most Microsoft .NET languages will also operate in the next-generation Active Server Pages (ASP) environment. Microsoft released a beta version of Visual Studio.NET, which is the development environment for creating Windows-based Web services on Microsoft.NET. The goal is to make the programming and use of Web services as simple as writing and calling a subroutine.
On the network, Microsoft .NET specifies SOAP. The SOAP protocol is a World Wide Web Consortium (W3C) standard in progress, allowing all internet-capable platforms, including Java-based platforms, to provide and consume SOAP-based Web services. IBM is actively participating in the SOAP standard effort as well. In the past, Microsoft had offered its proprietary Distributed Component Object Model (DCOM) as the primary distributed programming protocol for components, effectively shutting out non- Windows server platforms. The shift to the open SOAP standard is perhaps the most exciting aspect of Microsoft .NET.
SOAP employs existing Internet standards to help broaden its appeal. In particular, HTTP and XML are the major building blocks of SOAP. XML, the lingua franca of Web services, is used to write SOAP messages. SOAP messages can be sent over a variety of client/server-based network protocols, including the Web standard HTTP, to provide the same accessibility Web servers and browsers enjoy.
SOAP messages carry typed data that can be universally interpreted. XML describes both the data and its structural representation in a SOAP message. Remote Procedure Call (RPC) systems such as Web services can thus pass parameters and return results in a platform-agnostic manner. The current draft protocol consists of three major parts. First, the envelope defines how a message is to be described and the steps for processing it. Second, the encoding rules describe how application-specific data types are exchanged. Third, SOAP provides conventions for implementing RPC calls and responses.
Figures 1 and 2 show very basic SOAP request and response message examples, respectively. The request message shows how a Web services client (which could be another Web server or a client application) might query for customer information using a customer ID. The required SOAP-ENV:Envelope XML element identifies the envelope for the message. The SOAP-ENV:Body element contains an element defined by the Web service to denote the search function FindSubscriber, which, in turn, contains the customer ID data for the query. It contains an element defined by the Web service to denote the search function FindSubscriber. The subid element contains the parameter data passed to this function.
The response message (Figure 2) shows the same envelope element structure, with results being returned in the mc:FindSubscriberResponse element. Many details are missing from these examples. In particular, the encoding rules describing the data passed as the subid parameter and returned in the subdescription structure are not explicitly carried in the envelope. They are referred to, however, in the XML schema document named by the xmlns:mc attributes of the mc:FindSubscriber and mc:FindSubscriberResponse elements. The data contained in the messages are name and value pairs expressed in terms of XML elements and values. The schema comprises the set of encoding rules. It contains descriptions of the allowable data type elements and how to interpret their values. This
schema can be hand-coded, but is more likely to be machine-generated by SOAP tools based on application-domain specifics.
Visual Studio SOAP Toolkit
At the Microsoft Professional Developers Conference last July, developers were treated to a sneak preview of the features targeted for the forthcoming release of Visual Studio.NET (VS.NET). VS.NET promises to make the construction of Web services no more difficult than creating a Windows form-based application. Built-in wizard tools will generate and maintain a lot of the SOAP details for you. In the meantime, however, Microsoft offers a free toolkit that allows you to quickly prototype your own Web services using currently available software.
The SOAP toolkit for Visual Studio 6.0 contains a wizard that generates SOAP- based Web services wrapper code for COM components running on the Windows Internet Information Server (IIS) Web server. This tool takes the type library information for a specific Windows component Dynamic Link Library (DLL) and generates the XML-based contract language containing the SOAP encoding specifics. The contract language, called Web Services Description Language (WSDL), describes the method signatures of the interface methods of the components exposed as Web services.
The wizard can also generate the ASP scripts that, along with the toolkits listener.asp script, comprise the listener function of a Web service. Basically, a VBScript function is generated for each method and property of the component DLL. The listener.asp script and some underlying toolkit components interpret the incoming SOAP requests using the WSDL for the service. This results in a call to the generated VBScript wrapper method, which calls the components method.
Heres a quick review. The SOAP toolkit wizard creates an ASP-based Web service based on a COM component DLL containing your business logic. With the WSDL and ASP scripts the wizard generates, you configure IIS to permit Web address access to the scripts. Presto! You have a Web service.
Using Web Services
The SOAP toolkit provides helper functionality for accessing Web services too. Generally, to access a particular Web service, a client program must know the following:
Where the service is located (i.e., a URL)
How to get and interpret the description of the service
How to use the SOAP to invoke the service
These steps are usually referred to as Web service discovery and are mostly implemented by the toolkit components known as the Remote Object Proxy Engine (ROPE). ROPE is used by a Web service user as a proxy for the component being accessed on the remote site. Once located and its description successfully parsed, a Web service modeled as a COM component may be accessed as if the Web service were a local instance, as in the following Visual Basic fragment:
Dim bRes As Boolean
Dim oProxy As New ROPE.Proxy
bRes = oProxy.LoadServicesDescription icURI, _
If bRes False Then
The URL http://webhost/myserv/soapserv.xml is the address of the description of the service, and soapserv.xml is WSDL, as generated by the wizard for wrapping a COM object. The ROPE.Proxy components LoadServicesDescription method is used to load the
description. Based on the contents of the description, the Proxy instance can invoke the remote MyWebserviceMethod in a natural way. The assumption made by this code is that MyWebserviceMethod exists as a Web service endpoint function. The Proxy object also provides methods for checking this and other description details at runtime.
The SOAP toolkit is just one software development kit (SDK) for implementing SOAP solutions. IBM s SOAP4J implementation (written in Java) is now the base for the Apache XML Projects Apache SOAP project. These early-adopter toolkits expose some of the nuts and bolts of SOAP that the programmer will be shielded from in the eventual release of Visual Studio.NET. Even more sophisticated tools will probably follow.
As the tools rollout, more and more SOAP-based Web services will be coming online. According to the Microsoft plan, eventually Web service providers will emerge that will want to widely distribute their software using this model. A working example of the Web services model is already online at the Microsoft Office eServices Web page at officeupdate.microsoft.com/services/default.asp. Any large-scale distribution effort will likely require a centralized registry for posting and finding Web services over the Internet. The Universal Description, Discovery, and Integration (UDDI) specification has been proposed and supported by Microsoft and IBM as a standard for such a registry.
At its most basic, UDDI is an initiative to provide businesses with a way to publish their methods of conducting business over the Internet. Thus far, the focus of the technical effort has been on XML, SOAP, and the established Web standards. The goal is to make the discovery of Web services a ubiquitous Internet service, much like the Domain Name System (DNS) for mapping host names to IP addresses. The UDDI group has pledged to make any resulting registry open to all businesses and is currently accepting registrants on its site at www.uddi.org.
Not Done Yet
SOAP-based Web services are a very exciting new way for distributing business objects over the Internet. There are problems to work out, however. As of this writing, the standard for XML Schema, a critical part of the SOAP standard, has not been finalized. Other standards, including the SOAP Contract Language and the precise discovery algorithm are yet to be drafted. How these will evolve as Microsoft rolls out its Microsoft
.NET technology releases will determine their acceptance.
REFERENCES AND RELATED MATERIALS
"A Young Person's Guide to the Simple Object Access Protocol: SOAP Increases Interoperability Across Platforms and Languages, " Don Box, MSDN Magazine Online, March 2000 (http://msdn.microsoft.com/msdnmag/issues/0300/soap/ soap.asp)
Apache SOAP Project: http://xml.apache.org/soap/index.html
Cleaning Up the Web with SOAP, Don Denoncourt, MC, September 2000
"Develop a Web Service: Up and Running with the SOAP Toolkit for Visual Studio," Rob Caron, MSDN Magazine Online, August 2000 (http://msdn.microsoft. com/msdnmag/issues/0800/webservice/webservice.asp)
Doing E-Business with XML Schemas and SOAP, Eduardo Ross, MC, July 2000
Microsoft .NET Developer Center: http://msdn.microsoft.com/net/default.asp
Microsoft SOAP Technology page: http://msdn.microsoft.com/soap/default.asp
"Simple Object Access Protocol (SOAP) 1.1," W3C (www.w3c.org/TR/SOAP/)
SOAP Toolkit for Visual Studio 6: http://msdn.microsoft.com/xml/general/ toolkit_intro.asp
UDDI group home page: www.uddi.org
Figure 1: The request for a Midrange Computing subscribers information includes the subscriber ID.
Figure 2: A response to the request of Figure 1 contains some customer detail data.