Articles : Developing Real World Web Services-based Applications :

Write Once, Run Anywhere Web Services

The Java programming language gave developers a real ability to write a program once to run on many platforms. Yet, portability is more complicated than just program execution. It involves making an application available across a wide range of platforms and devices.

In this second installment of the three-part series we continue our discussion on developing real world Web Services-based applications with an emphasis on mobile and pervasive environments. This article will also describe how the Web Services Mediator (WSM) middleware layer I introduced in last week�s article facilitates the development of Web Services-based mobile and pervasive applications in which an application is written once, and then is later automatically optimized for a particular device. Finally, next week, in the third installment in this series, I will take an in-depth, code-level view of building a real world taxicab reservation system that involves a variety of Web Services and leverages the capabilities of the WSM.

Introduction

Looking around our homes and offices it is not uncommon to find a large number of devices that allow us to do different things. The telephone has the ergonomics to support making phone calls - buttons for dialing a phone number, a microphone located close to our mouths to transmit our voices to the other party, and a speaker located close to our ears to deliver to us the voices of the other party. Since the telephone is primarily for voice-based communications, the device has limited resources that are optimized for transmitting voice. These limited resources are sufficient for the device�s intended purpose and do not needlessly increase its cost.

The next-generation computing and communications environment - oftentimes referred to as the pervasive Internet - will be littered with the digital equivalents of the devices and appliances commonly found around our homes and offices today. Digital versions of picture frames, televisions, children�s toys, radios, alarm clocks, and VCRs will join personal computers (PCs) and mobile devices as the on- and off-ramps to the Internet, corporate intranets, and other information networks.

We are already starting to see this with network-enabled video game machines, digital picture frames, and interactive television set-top boxes. Not only are the ergonomics of each device different, but each device also has different system resources. The system resources are usually limited so that they are sufficient for their intended purpose. Some devices have limited computational processing resources, while others have a vast amount . Some devices have high bandwidth network connections, while others have low bandwidth, "sometimes connected" wireless connections. Some devices have large, full-color viewing screens, while others have small, black-and-white screens.

Within this next-generation environment the role of software developers will not be to target any one platform for their applications, but instead to structure and write programs so that they can easily be run on all devices on which running them make sense - both current and future devices. Consider an MP3 audio decoding and playback application. Initially, these applications were run on PCs. Then, as newer multimedia PDAs with audio speakers emerged, the MP3 applications were run on these mobile devices. Next, manufacturers introduced high-quality digital entertainment centers for home living rooms, which are also targets for MP3 applications. Each of these different devices have the ergonomics that are appropriate for their intended purpose and domain-of-use, and effectively extend the reach of information - in this case, MP3 audio files - to that domain.

An Adaptable Web Services-based Application Architecture for Pervasive Devices

Since a single application can be run on many devices, each with different system resources, an adaptable application architecture is necessary. Not only must the application be adaptable statically, but also dynamically, at runtime, since the environment in which the device operates may vary over time. Essentially, to cost-effectively develop and maintain applications for a large variety of devices, an application architecture that supports "write once, run everywhere optimally" is necessary. Optimality is key as all devices have limited system resources, and adapting applications so that they run efficiently and optimally on each platform is imperative.

A Web Services-based application comprises a set of Web Services that are consumed by that application as well as integration logic for coordinating together the set of Web Services, and, perhaps, a graphical user interface (GUI). As more Web Services are consumed by an application, the Web Services contribute increasingly to the runtime characteristic of the application. This is because each implementation of a Web Service has unique characteristics. Starting from its exported interface and the exact capabilities the service provides, to the runtime cost, reliability of the implementation and the power consumed by the application as it interacts with the Web Service, each Web Service has unique traits that combine together with those of other utilized Web Services to create the overall runtime characteristic or performance of a Web Services-based application.

Since each Web Service, even Web Services that provide the same or similar capabilities, have unique implementations and thus, unique characteristics, the selection of Web Services contribute to the runtime characteristics of the application. In order to allow the runtime characteristics of a Web Services-based application to be dynamically changed, a decoupling between the application and the Web Services being consumed is necessary. This decoupling can then be used to dynamically select at runtime Web Services that have the characteristics that will achieve the desired performance for that particular application, running on that particular device, within the current environment.

The Web Services Mediator (WSM) middleware layer that I introduced in last week�s article provides exactly the necessary decoupling. With the WSM, applications are developed based on a client proxy programming model (exactly identical to the standard programming model of Web Services). But, instead of using the client proxy for a particular Web Service, a Service Type Group (STG) client proxy is used that abstracts away the details (e.g., interface specification, method names and semantics, message format and encoding, transport mechanism, etc.) of each Web Service and allows the application to utilize any Web Service within the STG.

Once a WSM application has been written, its runtime characteristics can be modified by simply configuring the WSM. The WSM can be configured to use a specified Web Service within a STG for the endpoint of a client proxy. Or, more interestingly, desired runtime characteristics or metrics of the application can be specified, with the WSM responsible for selecting Web Services within each STG that provide best performance along those metrics.

About the Author

Dr. Sandeep Chatterjee joined HP in 2001 as a member of its Mobile Middleware Labs. He is responsible for architecting and developing a next-generation Web Services platform for enterprise as well as mobile environments. Web Services Mediator (WSM) introduces a "mediation" layer between Web Services and the applications that consume them, brokers communications, and bridges multiple standards, messaging formats, and services. More information on the WSM can be found at HP�s Mobile Middleware Labs site http://mml.hpl.hp.com.

Prior to his employment at HP, Dr. Chatterjee was Entrepreneur-in-Residence at FidelityCAPITAL, the venture capital arm of Fidelity Investments. He later founded and was President & CTO of Satora Networks, which developed tools and technologies for building appliances and services for the mobile and pervasive Internet.

Dr. Chatterjee holds a B.S. in Electrical Engineering and Computer Science from the University of California at Berkeley, and a M.S. and Ph.D. in Computer Science from the Massachusetts Institute of Technology (MIT). His doctoral thesis in networked client architectures was selected as one of the top thirty-five inventions in the thirty-five year history of MIT�s Laboratory for Computer Science, and his invention is preserved and showcased in a time capsule at the Museum of Science in Boston, Massachusetts.

Applet Index
(sorted alphabetically)
A B C D E F G H I J K
L M N O P Q R S T U
V W X Y Z #s

The Java Source
(applets w/source code)
A B C D E F G H I J K
L M N O P Q R S T U
V W X Y Z

How to Add Java Applets to Your Site

New on the Java Boutique:

New Review:

Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling API boasts simplicity, ease-of-integration, a well-rounded feature set, and it's free!

New Applet:

Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA sequences into three useful formats.