Building Cross-Platform Applications Using Web Services

Thousands of distributed applications have been implemented using these legacy mechanisms. However, each of these mechanisms presents one or more serious obstacles in the areas of platform- or language-dependence, ease of configuration, ease of implementation, or cost. No mechanism meets the need for a truly platform- and language-independent mechanism that is easily deployable on top of existing infrastructures and transport protocols, with either no or few trivial configurations required of participating systems. No mechanism met those needs; that is, before Web Services.

Table 11-1 Comparison of Distributed Application Infrastructures

Type	OS/Platform	Language Support	Configuration Complexity	Cost
Sockets	UNIX (variants available)	C	High	None
DCE	UNIX	C, C++	High	High
CORBA	UNIX, Windows	Any	Medium	Medium
Java RMI	Java (Java Virtual Machine)	Java only	Low	None
DCOM	Windows	Many	Low	None

Building Servers

Let's discuss some of the issues around building Web Services on the most popular computing platforms, including Microsoft Windows NT, Microsoft Windows 2000, UNIX, and Linux. We will divide our discussion between building Web Service servers and Web Service clients.

Simplistically speaking, the only requirement for providing a Web Service server is the ability to present that service as a URL. The URL must accept incoming service requests over HTTP as POST or GET methods or XML SOAP documents, must marshal the data within the request appropriately for its OS, must invoke appropriate methods on the data, repackage the data into an XML result document, and return the document via HTTP to the client.

If you want to advertise your Web Service and make it available to clients throughout the Internet, you must create a Web Services Description Language (WSDL) document that describes your Web Service to clients. The WSDL document is an XML document that provides information about the Web Service's exposed methods, arguments to those methods, and return values. You would typically register your WSDL document with a Web Service registration service, such as UDDI.org, which we mentioned in Chapter 8.

Web Services present clear advantages when compared to other cross-platform application development solutions. Because Web Services are built on existing, open technologies such as HTTP and XML, developers must implement little, if any, new infrastructure. Virtually all modern operating systems and platforms are supported. The Web Service server is still based on a Web server running a Web application server. Language support is broad. Complexity is low; the Web Service designer need only make the paradigm shift that the Web server is providing services, not Web pages, via a URL.

Visual Studio .NET

You can, theoretically, create your own HTTP GET or POST methods or build your own SOAP files for transmitting Web Services requests between client and server. Why bother doing so, however, when a development environment can support you by doing many of these tasks automatically? If you are developing on a Windows server platform, you can draw on the powerful capabilities of the Microsoft Visual Studio .NET environment for building XML Web service applications.

Visual Studio .NET handles many of the mundane tasks associated with developing Web applications, such as creating SOAP documents appropriate for your XML Web service methods, marshaling and unmarshaling data, creating WSDL contracts for your Web Service methods, and ensuring that these methods are stateless by encapsulating all application state data within the SOAP document. With Visual Studio .NET you can quickly build XML Web service applications that are reliable and easily scalable.

Visual Studio .NET provides support for most modern Web development languages, including VBScript, JScript, Visual Basic, C, C++, Visual C++, C#, Perl, Python, COBOL, PASCAL, and Scheme. It also provides an integrated environment for XML Web service development appropriate for developers from different development backgrounds.

Finally Visual Studio .NET provides rapid prototyping capabilities for client user interfaces. For debugging and testing, Visual Studio .NET provides the ability to view and trace SOAP messages between client and server.

UNIX and Linux

Other operating systems and language vendors provide toolkits and development environments for creating Web Service servers on other platforms, including UNIX and Linux operating systems. Options include IBM's Web Services Toolkit and the Java 2 Enterprise Edition (J2EE).

J2EE provides several APIs to specifically support the needs of Web Service application developers. Table 11-2 presents each of these API groups.

Table 11-2 Java APIs for Web Services

API	Description
JAXP: Java API for XML processing	Provides the capability for both tree-based processing (DOM) or event-based processing (SAX) of XML data. The API also provides support for XMLTs should you want to transform your XML documents into another XML vocabulary. You might want to do this to, for example, transform XML data to HTML for display in a Web browser, or extract components of an XML document and apply WML wrappers for display on the screen of a wireless device.
JAXB: Java API for mapping XML documents to Java classes	Provides the capability for creating Java classes from XML data and an XML DTD or Schema. These classes automatically provide the capability to validate, marshal, and unmarshal the XML data from an XML document instance. From an XML document you can create a Java object tree for processing by your Web Service server.
JAXM: Java API for messaging	Provides the capability to create SOAP documents for passing messages between systems in SOAP format. The API handles details like SOAP syntax and message identification.
JAXR: Java API for XML registries	Supports accessing standard Internet-based business registries. The JAXR API provides the capability to register a Web Service with registries such as UDDI.org, as well as the capability to search registries such as UDDI.org for specific Web Services.
JAX-RPC: Java API for issuing RPCs via XML documents	Supports issuing RPCs as request and result SOAP documents. JAX-RPC handles the details of marshaling and unmarshaling the data into the SOAP document JAX-RPC provides. JAX-RPC is a less-general API than JAXM. It does not provide all the capabilities of JAXM, including asynchronous messaging, multiparty message routing, and delivery verification.

Other Platforms

Theoretically, any computing device that can accept incoming HTTP requests, manipulate incoming data by a method, marshal results into an XML document, and deliver the result XML document to the client via HTTP can serve as a Web Service server. Variables in choosing to perform these tasks on a non-Windows or non-UNIX platform include the nature of the Web Service and the availability of tools to support providing the Web Service infrastructure. For example, at a minimum the platform should support an XML parser for creating the XML result file.

Alternative platforms that support the J2EE might be reasonable candidates for Web Service servers. Otherwise, deploying a Web Service server on, for example, a handheld device, might be an exercise in non traditional application development, at least for the near future.

Building Clients

Building clients for distributed applications has never been easier. Because Web Services are based on open standards like HTTP and XML, all that is minimally required of a Web Service client is the ability to create and pass to the server an HTTP GET or POST request or an XML SOAP document. This capability can be implemented in a variety of ways. Most simply, any client that supports an HTML 3.2-compatible Web browser and the HTTP protocol can participate as a Web Services client. Even clients that do not support HTML 3.2-compatible browsers can use their own built-in application support to create the requisite XML files for transmission over HTTP to the Web Services server.

One of the first steps in designing a Web Service client is to inspect the WSDL document for the Web Service you want to run. The WSDL document is an XML document that provides the methods exposed by the Web Service, expected arguments, and return values. You can perform this inspection manually, but a Web Service development environment can make the task easier for you.

Windows Platforms

Visual Studio .NET provides a complete development environment for building, deploying, and testing XML Web services. You can develop both the XML Web service server and client portions directly in the application. Clients that run on Windows NT, Windows 2000, or Windows XP can be HTML or Web forms. On a Windows platform Visual Studio .NET can save the Web form as a DLL.

UNIX and Linux

Again, you can build an HTML 3.2-based Web Service client for UNIX and Linux platforms directly from Visual Studio .NET. Because the client interface to a Web Services server is only an HTTP GET or POST method or an XML file, you can design your own Web Service client. The language that you use and the form of the Web Service client is irrelevant as long as the client can marshal its native data format in an XML file (or arguments to an HTTP method), send the data over the wire via HTTP, receive the result XML document via HTTP, and remarshal the results.

Other Platforms

Again, Visual Studio .NET provides the capability to develop and test XML Web service clients on other devices, including devices running Microsoft Windows CE. These devices include portable hand-held computing devices, "smart" devices such as tablet PCs, portable game consoles, and digital television controllers. As the number and variety of these devices increases, so will the opportunity to take advantage of XML Web services via these devices.

A key point in designing and implementing Web Services is that the Web Service client need not be a Web form driven by a human user. Certainly, any computing device can act as a Web Service client. In fact, Web Service servers can invoke methods that call other Web Services in completing a client request. For example, a digital television controller can invoke a Web Service that provides video-on-demand capabilities. This service might, in turn, invoke a Web Service that performs billing functions. Keep this capability in mind, especially as you develop applications for non-traditional computing devices.

Accessing Objects Across Platforms

Object access and sharing presents some of the major challenges in distributed-application development. All but the most homogeneous environments require that objects be converted from an application's native data format, passed along a wire, and converted back to a different application's (possibly different) native data format. The process must be repeated, in reverse, at the return of data by the server. Many solutions have been developed for this problem, although none have thus far presented a mechanism as open and as widely deployable as that presented by Web Services.

Traditional Methods

Each of the traditional mechanisms for sharing objects across platforms present limitations that have prevented these mechanisms from supporting Internet-wide distributed applications. CORBA objects are fine grained compared to the granularity needed to support business functions. RMI allows sharing of objects and code, but only between Java platforms. DCOM only allows object sharing between Windows platforms. Full-blown DCE is too expensive and too complex, and UNIX sockets require programming at a lower level than many developers are comfortable with, making development and maintenance problematic.

Furthermore, it became apparent that data, not code, was the most precious commodity in Internet applications. The HTTP protocol had existed for years and firewalls had been configured to cope with it. XML proved to be a powerful vehicle for transporting any type of information. There must be some way to combine the two technologies and produce the next big advance in distributed computing.

Web Services

Web Services perfectly fit the reality that data, not code, is the most important commodity in distributed applications. Because Web Services are based on the open standards of HTTP and XML, they offer an infrastructure for distributed-application development free of the barriers that prevented widespread deployment of past systems.

To share objects in a Web Services environment you must convert the instantiated objects from their memory storage to a format that can be transmitted across a network. Because HTTP is a stateless protocol, the serialization process must include all state or property information. The serialized object must provide enough information to be reassembled into an identical object by an application at the other end of the wire.

Both Visual C++ and Java support object serialization. However, each language uses its own data format to store its objects and metadata in a serialized format. This distinction greatly complicates the task of sharing serialized objects between applications written in different languages.

By using XML as a common serialization format, any applications that can parse an XML file can instantiate objects serialized within an XML file. Any application that can parse an XML file and marshal the contents into and out of the application's native object format can share objects in and participate in a Web Services environment. Using XML as a common serialization format ensures that the widest possible set of computing platforms can participate in a Web Services environment.

Writing Objects for Multiple Platforms

Object serialization presents one of the more challenging problems in implementing distributed applications. How can you transform an object from the internal data structures created and maintained by your programming language to a persistent form that can be passed between server and client over the wire?

This problem appears in two locations in Web Service applications. The client must serialize its data to the argument list to an HTTP POST or GET method or to a SOAP document. The Web Service server system must both un-serialize the incoming request and reserialize the result to an XML (possibly XML SOAP) result document.

Fortunately, you don't need to worry about the details of object serialization. Web Service development environments and APIs designed to provide Web Service functionality have this capability built in. Visual Studio .NET allows you to serialize XML Web service arguments within a SOAP document. Other APIs, such as J2EE's JAXM, directly support the creation of SOAP documents.

After an object is serialized within a SOAP document, what do we do to ensure the interoperability of the resulting SOAP document within a distributed application? Nothing. The XML and SOAP specifications ensure that any computing device with any internal data format will interpret the content of the SOAP document in exactly the same way. Any platform that supports an XML parser will appropriately read and marshal any data contained within the SOAP document.