Web Services in a Pervasive Computing Environment

Oct. 21, 2002 12:00 AM

Pervasive computing is taking the world by storm. Industry analysts are predicting that mobile is the "next paradigm shift," and vendors (including IBM) are investing heavily in producing the best toolset for building applications for pervasive computing.

Pervasive devices like mobile phones, PDAs, and pagers far outnumber computers, and the trend is accelerating. Add to that the fact that all sorts of equipment, such as air conditioning units, oil tanks, car surveillance systems, and so on, are being built with serious computing power and a communication link, and you begin to understand the large investment in new computing environments for building applications on devices other than PCs and workstations.

Mobile and pervasive applications aren't new. The explosion of pervasive technology isn't a result of a new business need but rather a result of maturing technology. Users have always been mobile. Because of lack of technology (or lack of reasonably priced technology), mobile users have had to make do with manual processes and paper-based data management.

This isn't to say that there are no mobile systems out there - there are industries in which mobile systems have been a way of life for more than 10 years. One of the best examples is the utilities vertical - companies that are responsible for the distribution of power, such as electric utilities and gas utilities. These companies have been using pervasive computing for many years, including mobile terminals used by field personnel for receiving and completing work orders as well as remote telemetry units (RTUs) that monitor the energy distribution network for faults and provide a constant data feed to the central monitoring stations.

Let's look at an example from the world of field service. In this world, technicians and engineers are deployed in the field and make use of mobile data terminals to receive work notifications. They then use these terminals to see what work needs to be done where and receive additional information such as circuit diagrams, product catalogs, and so on. Traditionally, most of these data terminals have been rugged laptops and/or alphanumeric pagers. Client software running on such a laptop is shown in Figure 1. With the proliferation of lower-cost, high-quality pervasive devices, the field force can now be equipped with a myriad of devices.

These mobile data terminals access the central server using wireline and wireless networks. This is another area in which technology has made much progress. Five years ago a company would almost always have to set up a private radio network in order to deploy such a system. Today, the availability of lower-cost public data networks makes the use of private radio frequencies (RF) a legacy as companies move away from expensive infrastructure. Some geographies fare better than others; for example, carriers in Europe have deployed almost ubiquitous access over GSM and are now rolling out GPRS. The U.S. lags far behind with a combination of different technologies with spotty coverage, causing a reality in which a national deployment will probably need to use a combination of networks such as CDPD, Mobitex, cellular, and possibly private RF and even satellite. In this reality, the system architecture is complex and the total cost of ownership (TCO) high.

Total Cost of Ownership
TCO is what it's all about (at least from a business perspective). The goal of any organization that wants to deploy a mobile data system has to do with achieving the efficiencies and ROI provided by the application while maintaining a low TCO. If you look at a rollout of a mobile data solution you see that there are at least four important categories to consider when assessing TCO:

Devices
Networks
Applications
Mobile infrastructure

In each of these categories, technology is making rapid progress in reducing the TCO. In terms of devices, operating systems like Win32, Pocket PC, Palm OS, EPOC, and more allow a variety of data terminals with very good tools and applications. In terms of networks, gone are the days of expensive private RF networks. In terms of applications, environments such as J2EE and J2ME are now being applied, allowing highly maintainable and low-cost applications. But in this article I focus on the mobile infrastructure, specifically the use of Web services within these environments and on the components provided by IBM within the WebSphere family of products that can help you roll out a complete mobile infrastructure.

Web Services in the Field
You're probably a bit surprised that Web services can be used in mobile environments, and I don't blame you. After all, Web services are, by definition, closely related to the Web and the Internet, which are all about online connections. Yet mobile environments must function flawlessly in a disconnected or offline mode. This is because no matter how good coverage becomes, it's still spotty. This is especially true if you live and work in the U.S. Unless you live in the middle of a highly populated metropolitan area, you probably frown (as I do) on the "Can you hear me now? Good" commercial.

Even if coverage is perfect, it will not be complete because some people need to work while in the basement, within radio-free areas (like hospitals), etc. Also, wireless networks today are slow. 3G may solve these issues, but right now you really don't want to wait for an end-to-end transaction all the way back to the server with every button press. What you really need is an environment with a store-and-forward capability, which will allow you to do your work, cache all your transaction submissions, and send them up when the network allows.

Why Web services? The reason goes back to TCO. In the same way that the devices and networks have migrated away from proprietary environments, the messaging platforms and formats are converging. From a data format perspective, it's attractive to use SOAP messages and envelopes to carry information that needs to be sent from the client to the server or from the server to the client. By sticking with a standard, which is the claim to fame of Web services, companies can take another step toward lowering the TCO. And while Web services are mostly used in online environments today, they were designed to work in asynchronous environments, so they're actually quite appropriate when it comes to store-and-forward environments.

WebSphere Components for Mobile Infrastructure
Are we there yet? Almost. Most mobile environments today don't make use of Web services, perhaps because they're just too new. But the WebSphere family of products actually has all the components you need to develop and deploy a mobile data solution using Web services. It's based on a combination of the WebSphere Application Server, WebSphere Everyplace Wireless Gateway, and MQSeries Everyplace.

The IBM WebSphere Everyplace Server is a software platform for extending the reach of new and existing applications to the mobile e-business space. The components include:

IBM Everyplace Wireless Gateway

Tivoli SecureWay Policy Director

IBM WebSphere Edge Server

IBM WebSphere Transcoding Publisher

IBM MQSeries Everyplace

Location-based Services

Intelligent Notification Services

IBM Everyplace Synchronization Manager

Tivoli Personalized Services Manager

Everyplace Suite Manager

IBM SecureWay Directory

The beauty of the Wireless Gateway is that it makes any network, or combination of networks, look like a simple IP network (a virtual LAN/WAN, if you will). It supports a variety of wireless and dial-up network technologies. All data traffic that flows through the Wireless Gateway uses a mobile network connection (MNC), a resource assigned to a Wireless Gateway that defines a specific type of network connection. Existing applications that use a TCP/IP interface may use either wireless or wireline networks - it's completely transparent. In fact, a data transmission can start over one network, lose coverage, and be completed over another network, all without the application even knowing about it. Using the Wireless Gateway shields network-specific details from the user application and provides network-specific enhancements, such as data compression, data encryption, data optimization, and authentication. Supported IP-based and non-IP-based networks include:

Packet networks
-CDPD
-DataTAC
-Mobitex

GPRS

Cellular networks
-AMPS
-CDMA
-GSM
-iDEN
-PCS 1900
-PDC
-PHS
-SMS

Private RF networks
-Dataradio
-Motorola Private

Dial-up telephone
-PSTN

WAP

The Wireless Gateway removes the complexity of the underlying network(s) and makes everything as simple as opening a TCP/IP socket and moving data around. However, for the store-and-forward capabilities, you need MQSeries Everyplace (MQe). MQe integrates many of the functions available in MQSeries and supports both reliable and unreliable communications as well as:

Industrial-strength messaging

Reliable communications

Assured, once-only delivery of messages

Powerful encryption

Optimized data streams

Immediate server or mainframe interaction when a link is available (queues messages when it is not)

MQSeries Everyplace is supported on the following platforms:

EPOC

Palm OS

Pocket PC (Windows CE)

Win32

OK, enough with the marketing fluff, let's put this all together (see Figure 2). The application typically has two components: a server that is running within a WebSphere application server and a client that may be running over pJava, J2ME, or even a non-Java application making use of the MQe C DLLs. These application components communicate by sending SOAP messages to Web service endpoints. The actual SOAP payload is delivered using a set of MQe queues (for example, the MA0R SupportPac for MQ can be used). The delivery of messages from one queue to another is made easy by using the Wireless Gateway. No matter which network is needed, it all looks like TCP/IP when used by MQ.

So, go out there, download ~1GB of WebSphere "stuff," and have a ball. And if you need to justify all this great technology, remember: it's all about the total cost of ownership.

About Ron Ben-Natan
Ron Ben-Natan is Chief Technology Officer at ViryaNet Inc. Prior to that he worked for companies such as Intel, AT&T Bell Laboratories, Merrill Lynch and as a consultant at J.P. Morgan. He has a Ph.D. in Computer Science in the field of distributed computing and has been architecting and developing distributed applications for over 15 years. His hobby is writing about how technology is used to solve real problems and he has authored numerous books including “IBM WebSphere Application Server: The Complete Reference” published by Osborne/McGraw. He can be reached at

About Doron Sherman
Doron Sherman is the CTO of Collaxa, Inc., a Web Service Orchestration Server vendor and a BEA Partner located in Redwood Shores, California. He has been involved with Java since its early days and pioneered application server technology while being a founder and chief scientist at NetDynamics.