Issues in Object Development and Multiple-Platform Design

This section provides insights into issues about designing Web Service objects. Web Service objects present some special constraints, such as the requirement that they be passed by value and that Web Service methods tend to present much more course-grained functionality than do other distributed-application paradigms. We also discuss application development issues, such as the application development environment, presented by the major hardware platforms, and review the general issues of security, scalability, and state maintenance.

Object Development

We mentioned limitations of Web Service objects in Chapter 8. All Web Service objects are passed by value through HTTP and SOAP. No mechanism for passing an object by reference exists. Calls to Web Services require some overhead. Objects must be marshaled into (potentially large) XML SOAP documents and return results must be unmarshaled. Web Service calls, because they rely on HTTP, are stateless. Because Web Service connections are closed upon the completion of any call to a Web method, all state information must be provided within the body of the SOAP document.

Because Web Services are designed to provide course-grained application methods and business-level services, as opposed to the fine-grained object sharing that motivated the development of CORBA and RMI, these limitations are rarely burdensome to a Web Service developer. The simplicity of implementing Web Services is largely the result of designing around the limitations of open standards like HTTP. It would be difficult to argue that the popularity of the Web has suffered because HTTP does not provide a mechanism for maintaining state across invocations!

A Simple Example: GolfCourseService

In Chapters 9 and 10 we wrote and deployed a Web Service called GolfCourseService, which allowed Web clients to find information about golf courses and reserve tee times at specific courses. Here we will review the minimum requirements for a client to invoke this service via HTTP GET and POST methods.

The WSDL document GolfCourse.wsdl provides the method signatures presented by the GolfCourseService Web Service. Here we will invoke the GetCourseDetail( ) method, which presents a query interface into the database of golf courses. A client can retrieve information about a specific golf course by passing in the course's ID.

HTTP GET is the simplest way to invoke a Web Service. A client provides arguments to the Web Service methods as addendums to the Web Service URL. The HTTP GET invocation for the GoldCourse Web Services GetCourseDetail( ) method might look like this:

 GET /GolfCourseService/GolfCourseService.amx/GetCourseDetail?id=200  HTTP/1.1 

The Web Service client will return an XML result document in response to this GET request. Likewise, we could perform a POST HTTP request to send HTTP data from a client form. The POST might look like this:

 POST /GolfCourseService/GolfCourseService.amx/GetCourseDetail HTTP/1.1 Host: localhost Content-Type: application/x-www-form-urlencoded Content-Length: <length> id=200 

The HTTP Post response document, saved here as response.xml, is a simple XML document, identical to the HTTP Get response document. The response is formatted in plain XML without any SOAP references. The header for the document returned is:

 HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Content-Length: length 

The body of the document (again saved in response.xml) as seen in Listing 11-1 is:

Listing 11-1 response.xml: Document returned by our Web Service.

 <?xml version="1.0" encoding="utf-8"?> <GolfCourse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns=
"http://tempuri.org/"> <id>20</id> <name>Wildwood Green</name> <description>Wildwood Green</description> <price>50.00</price> <telephone>919-999-3333</telephone> <address> <street>157 Strickland Road</street> <city>Raleigh</city> <state>NC</state> <postalCode>27613</postalCode> <country>usa</country> </address> <tees>  //Tees information omitted for brevity </tees> </GolfCourse>  

Platform Issues and Limitations

Because Web Services are based on open, ubiquitous standards like XML and HTTP, platform issues and limitations are kept to a minimum but are not completely eliminated. This section discusses some of the platform-specific issues around Web Services, including how tightly the development environment is integrated with the execution environment and the capabilities of lightweight platforms (such as PalmOS devices).

Windows

Microsoft Windows NT, Windows 2000, and Windows XP provide the most complete platform for developing and deploying Web Services applications. Visual Studio .NET provides a complete development environment for building, deploying, and testing XML Web services. Microsoft IIS provides a Web server for presenting your Web Service to the Internet and managing issues like security. Windows itself provides an application server environment for running your Web Service.

By developing and deploying your Web Service on a Windows operating system, you can be assured that the system conflicts that inevitably arise in mixed development environments will be kept to a minimum. Visual Studio .NET guarantees that your operating system, Web server, Web application server, and development environment are all up-to-date and compatible.

Using Visual Studio .NET you can develop your XML Web service application server using one of several languages, including C, C++, and C#. You can also easily generate Web Service clients for any platform that supports HTML 3.2-capable Web browsers. Visual Studio .NET allows you to create Web forms that invoke appropriate code on the server side, instead of on the client side, to support the platform-independence of the XML Web service client.

UNIX and Linux

The family of UNIX operating systems has a good track record for supporting mission-critical and enterprise-wide application server deployment. UNIX operating systems offer a high degree of reliability and tend to be stable throughout a system's load curve. UNIX systems have also been easier to scale, and more robust in the face of scaling, than other operating systems.

Many developers and organizations find the greater availability of open source applications for UNIX operating systems intriguing. Given the variety of application server choices on UNIX, an organization can choose to spend more money for off-the-shelf commercial solutions or spend less money and more developer resources configuring open source solutions.

The plethora of UNIX configurations and available application server options presents a double-edged sword. Each development environment is likely to present a different combination of a UNIX kernel, Web server, Web application server, development tool set, and other variables. Application developers are more likely to struggle with compatibility issues in a UNIX environment than in a Windows environment. Such environment and compatibility issues tend to make rapid application development on UNIX platforms less feasible than on Windows platforms.

Portable Devices and Handhelds

Handheld devices present some of the most challenging issues faced by distributed-application developers. The portability and widespread deployment of such devices makes them attractive client targets for distributed-application development.

The issues around building distributed applications for these devices are obvious: these devices present limited UIs with constraints on screen size and user input capabilities (that is, these devices rarely present a full keyboard). Handheld devices also present severe constraints in application support, processing power, and available memory, both in RAM and persistent storage.

Network connectivity might be the biggest challenge. Handheld devices, when they are connected to a larger network, normally present low-bandwidth connections of an intermittent nature. The user of such a device must explicitly connect or dial into a network. This requirement might change soon, however, with the advent of portable, high-speed, local area network connections.

The Java 2 Platform, Micro Edition (J2ME technology) allows you to develop Java-based applications on portable and handheld devices, including PalmOS. Using J2ME you can build PalmOS-compatible versions of lightweight XML parsers like MicroStar's Aelfred.

Other Platform Issues: Security, Scalability, and State

Other particularly important issues in designing distributed applications in a heterogeneous network environment include security, scalability, and state. Security generally requires knowledge of each target OS as well as the intermediary transport protocol. Scalability is a classic software design problem, complicated in a distributed environment by the number of variables present (multiple hardware configurations, operating systems, and network). State is a ramification of building services above the stateless HTTP protocol. Here we take a brief look at each.

Security

Once again, Web Services' use of open standards means that we don't have to invent another mechanism for providing secure transmission of data between client and server. Because the Web Services transport protocol is HTTP, the Web Service application looks just like any other Web application running on your Web server. You will continue to use the same mechanisms for authentication, authorization, and encryption that you use with your existing Web server and Web applications.

If we want to provide secure over-the-wire transmission of our Web Services' HTTP requests between client and server, we can use Secure Sockets Layer (SSL), which provides secure HTTP transmissions via public key encryption. To do this we must be sure that our Web server is configured to provide SSL support. For added authentication security we can register X.509 certificates for client identity verification with Verisign.

Because the client accesses Web Services from a URL, just as the client would access a Web page, we can use any of our Web server's security functionality as part of our Web Services' security component. We can require user authentication to access the Web Service URL, or we can restrict access to specific IP addresses or ranges of IP addresses. We can also authenticate Web Service clients and maintain that authentication between HTTP requests by issuing session cookies. All of this functionality is provided by your Web server.

At the Web Services application level we can implement a variety of security mechanisms, including role-based security. Say we offer a Web Service that performs payroll functions. A client with the role of "clerk" might be able to issue paychecks, but not view salary information. A client with the role of "supervisor" might be able to change salaries. The role of the client, along with authentication information to validate that role, can be passed to the Web Service in the incoming SOAP document as arguments to the appropriate method calls.

Scalability

Few scalability issues are specific to Web Services. Developers of Web Service clients should attempt to minimize the required amount of object state information that must be serialized into an XML file and also minimize the size of data objects that must be serialized. Overhead of serializing, un-serializing, and re-serializing object data presents one of the most obvious potential bottlenecks in a distributed Web Service application. Any savings by the client in serialization time is also likely to save un-serialization and re-serialization time on the server.

Because the Web Services server presents its services to the outside world as a URL or set of URLs, the issues surrounding the scaling of Web Services servers is similar to the issues around scaling conventional Web servers. The developer of a Web Service server should minimize object state information required by the service and minimize the size of objects likely to be passed to the service. For large Web Service applications a multitier architecture is feasible, just as one might deploy a multitier architecture for serving conventional Web sites and applications.

State

Because Web Services rely on the stateless HTTP protocol, they must be designed so that all necessary state information is included in the client request for the Web Service. Some work-arounds for HTTP's stateless nature exist, such as using session cookies to maintain authentication state between HTTP invocations. In general, however, the Web application must be designed to work under conditions of a nonpersistent, stateless connection with potentially high latency and (depending on the system environment) unknown or low bandwidth.

Why Not Use Web Services?

Given the ease of implementing Web Services, why would we want to use any other mechanism for creating client/server applications? Despite the many advantages presented by Web Services, they are not the right solution for many situations. Situations where a Web Service solution might not be appropriate include environments in which the following situations are present.

Speed is a Priority

Several areas present possible speed bottlenecks to Web Service applications. Marshaling object data to an XML file on the client can be resource intensive. Distributed applications that maintain an object's native format for over-the-wire transmission have an advantage here.

The same bottleneck appears four times: when the client creates a SOAP XML file for transmission to the Web Service server, when the Web Service server receives the SOAP file and unmarshals the data, when the Web Service server marshals the result of its Web method(s) into a SOAP result file, and when the client unpacks the SOAP result file. The time and computing resources taken up by these operations can be significant, especially if large data structures are passed around. (Because HTTP requires that data be passed by value, all input and result data must be passed over the wire.)

The HTTP protocol presents another potential speed bottleneck. HTTP provides an effective protocol for general Internet traffic. However, lack of control of and access to the underlying transportation mechanism means that the Web Service HTTP requests and responses are at the mercy of current network conditions at all levels (LAN, WAN, and Internet).

State is Important

The stateless nature of Web Services, mandated by the stateless HTTP protocol, is not appropriate for all distributed applications. Applications that must maintain an open database connection, for example, cannot operate effectively in a stateless environment. Applications in which data should be passed by reference instead of by value are not appropriate for Web Services either.

Imagine a Web Service that performs an insert operation on an address field component of a 20-MB data file. A Web Service that provides this capability would need to pass 20 MB of data from the client to the server (after marshaling that data to an XML file). The client would have to receive 20 MB of data, parse the SOAP file, unmarshal the data, perform the insert operation, remarshal the data, and pass the 20-MB SOAP file back to the client, which needs to parse and unpack the result file. All to change a single record! A pass-by-reference mechanism would be more appropriate here.

Through the judicious use of offsets to manage changes to large data files, you can minimize the number of times a large data file is passed back and forth between Web Services clients and servers. Visual Studio .NET provides an abstraction called Data Sets to support working with large XML documents. The Data Set automatically handles update issues when a client application is finished modifying a large data file. Another set of classes called Data Adapters handle all the low-level database interactions. Other APIs for building Web Services will typically provide APIs to perform the same role.

Homogeneous Deployment Environment

Marshaling and unmarshaling your Web method arguments with each Web Service invocation will probably require some overhead. Instead of marshaling your data with every Web Service call, you can save significant computing resources by maintaining objects in the native serialization format of your language and operating system. If you are deploying distributed applications in a homogeneous computing environment, you might want to use more traditional methods for implementing them.

Security Is Critical

Although Web servers can provide a high degree of security with SSL and its underlying public key encryption mechanism, other transport protocols are likely to provide a better solution within corporate firewalls or other closed environments.