At Your Service, On the Web

At Your Service, On the Web

Dino Esposito

InstantDoc #20927

April 24, 2001

.NET includes three programming models: WinForms, WebForms, and Web Services. Whatever your model of choice, the classes you use for non-user interface (UI) tasks—data access and manipulation, media access, system programming—are always the same. In other words, your approach is similar whether you抮e writing a desktop application (WinForms) or a Web page (WebForms). And your approach shouldn抰 change when you decide to build a new breed of applications using Web Services.

A Web service, simply, is a piece software that provides certain functionalities over the Web. As such, Web Services are similar to DLLs, but DLLs differ in two significant ways. First, DLLs are in-process modules that are specific to the Windows platform. In other words, to use a DLL, you must inject it into the memory context of the calling process. Second, DLLs rely on written documentation to expose their programming interface. To take advantage of a DLL, you must either statically import the signatures of all its public functions or, if you know the signatures, arrange a dynamic call. In the former scenario, the compiler checks the accuracy of your code before it runs; in the latter, you must code defensively to avoid—or at least limit—runtime errors. To call a DLL, you must make it available on the same local network (and, more often than not, on the same machine) where the caller is running.

Web Services take DLLs to the next level of usability. Web Services is a library of functions that relies on Internet standards to let you identify it, call it, and receive results from it. The Web service抯 interaction model also differs from the DLL抯 model. A Web service works like a standalone server that receives requests, precesses data, and returns responses. You don抰 have to inject a Web Service into the caller抯 memory context, and you don抰 have to download it to a local network.

Architecturally, a Web service is any application that you can access through a URL. Web Services support HTTP, which lets clients issue calls and receive results by providing the underlying network transportation between clients and services. Web Services typically use XML to package method names, input parameters, and return values. In principle, you can define your own XML-based protocol to invoke a particular service. In practice, you might want to use the Simple Object Access Protocol (SOAP) for this task. SOAP is the real-world standard for describing a remote method call; it抯 an XML vocabulary whose tags and attributes let you describe the method you want to invoke on the service, and with which arguments. What travels over the network is simply a XML string. Because of SOAP, Web Services are an excellent alternative to other techniques for performing remote procedure calls (RPCs).

XML, in fact, easily penetrates corporate firewalls, which don抰 always let Distributed COM (DCOM) code pass. In addition, HTTP and XML are widely accepted standards that every hardware platform fully supports. You can write a Web service on any platform, and modules running on different platforms can call it. SOAP serves to define a specific standard that Web-Service requests and responses must adhere to. SOAP is a verbose protocol, but if you want to serve different applications across the Internet, using standard and specific protocols and vocabularies is a must.

To users, Web Services looks like an application that抯 integrated with the Web server, so you can invoke it over the Web. The application must be able to parse the XML payload it receives and extract the information about the method and the arguments. After such a method runs, the return value generates another XML-SOAP packet to send back over HTTP.

In Windows, you have two ways to write SOAP-based Web services: with and without .NET抯 built-in services. If you can take advantage of the .NET Framework, then you can write a Web service as an ordinary class. Using WebMethod, a special attribute, you mark a method as a remotely callable function:

<%@ WebService Language="VB" Class="CurrentTime" %>

Imports System

Imports System.Web.Services

Class CurrentTime
 
public Function <WebMethod()> Show() As String
 
 Show = DateTime.Now.ToString()
 
End Function

End Class

If you can抰 afford the .NET Framework, the SOAP Toolkit 2.0, in conjunction with Visual Studio 6.0, gives you another way to achieve similar results. However, the immediacy that the .NET Framework gives you and the unprecedented support that you get from the tools (specifically, Visual Studio.NET) should prompt you to use .NET wherever possible.

Thanks to the open Internet standards that they support, Web Services can communicate with any module running on any platform. A benefit of such flexibility is that you can extend existing distributed systems to expose functionality as Web Services. You can connect a new server to the network, run the .NET runtime on it, and then write and install Web Services. Thanks to HTTP, XML, and SOAP, such services are immediately ready for the hosting system and any client that accesses the network to use.

Because of its association with .NET, Web Services have generated a lot of talk, but the feature is anything but .NET-specific. Web Services is a cross-platform module that interacts with the rest of the world through HTTP and XML. In .NET, you get special support for writing SOAP-based services. Similar infrastructures are, or will be, available from other vendors, including Oracle and Sun. Regardless of platform, internal implementation, and vendor, all Web Services share an unprecedented ability to work together as pieces of one system.