In-Depth

How legacy can meet wireless

• By Richard Adhikari
• December 1, 2001

The facts do not bear out the predictions. Corporations are not rushing pell-mell into setting up wireless applications because there really are no mission-critical applications for the wireless environment. "Numbers don't make a market, business values and capabilities do," said Ram Menon, chief strategist at business integration solutions provider Tibco Software Inc., Palo Alto, Calif.

Corporations are adopting wireless technology when it makes sense. For most, that means providing better access to, and communications with, mobile sales forces and field technicians to speed up order entry or work-order reporting, and even rescheduling them on the fly—the kind of bread-and-butter stuff that keeps businesses going.

However, integrating wireless applications into the corporate back end to leverage data is not simply a matter of writing the code and plugging it in. Wayne Fleming, professional services manager at Optimus Solutions LLC, Norcross, Ga., which implements mobile and wireless solutions in enterprises, recommends that developers first conduct a mini-profile of the types of users in the firm who will use wireless applications. Then they should decide which apps should be wireless-enabled. "Not every app is a candidate for wireless," Fleming said. "Think from the perspective of 'I just need another view of my data' instead of [thinking about] building an entire system." Leverage any existing business logic instead of rewriting it, he said. Then figure out what types of devices will be used and what kind of performance can be expected on those devices.

Next, work out how the wireless devices will connect to the enterprise. Decide, for example, whether users should access information over a WAP browser or a Palm Pilot, and whether they need periodic snapshots of data or always-on connectivity like HiddenMind provides. The next step is to look for the middleware that will extend enterprise information to the devices selected. Keep your options open. "Just because you choose one device as a standard doesn't mean other devices are excluded," Fleming said. Finally, use the user mini-profiles as the basis for a framework that will support those profiles and build the apps based on that framework, he added.

For example, Optimus Solutions builds apps on IBM platforms with MQSeries middleware using JDBC and ODBC connectivity. It leverages existing business logic whenever possible, so it calls stored procedures and existing business logic and extends them to users' handheld devices.

According to Gregory Brown, vice president of product strategy at FreeRein Corp., Bellevue, Wash., organizations must know where users will be: close to the corporate campus—which implies a finite geographic area—in a metropolitan area where they won't know their exact location, or anywhere in the world. Each of these assumptions implies "a lot about the type of network you want, the amount of data you can send to the user, the types of devices appropriate for the user, and how much offline data you want to prepare users with," Brown said. Making the wrong assumptions in these areas is "setting yourself up for failure," he added.

Then there is the problem of outputting data to client devices. It is the Wild West out there, with multiple devices, multiple standards and even different implementations of the same standard. "The problems with mobile computing devices are not just with their OSs; even the same OSs have different chips," said John McMullen. McMullen is director of product management for Web and wireless solutions at m-business and e-business application builder Teoco Corp., Fairfax, Va. "There are lots of other tricks you need to know; for example, some devices do not support certain types of display objects." These are the types of issues that must be considered when implementing wireless applications into the corporate back end.

One solution is to use transcoders—software that takes data and reformats it to the specific requirements of different output devices. But "you can't have satisfactory operation out of a transcoder that has to deal with multiple devices because it's a generalized piece of software; it only has value for most generic applications and front ends," said Frank Prince, an analyst at Forrester Research Inc., Cambridge, Mass. In some cases, the application and the device have to be specialized to work together, he added. However, developers should do the math first to determine whether or not the cost of customization will be too high to get a good return on investment. Prince has written a report for Forrester, "The real cost of mobility," which includes an interactive spreadsheet that lets readers try out cost estimates.

Another option is to leverage Java. Kada Systems Inc., Burlington, Mass., offers the Kada Mobile Platform for Java, which puts full-featured Java on handheld devices. This lets users download complete Java apps, access and work with those apps offline, then synchronize data updates to the back-end databases wirelessly. Kada supports JNI on the Palm Pilot and enables light-footprint databases on Java and C++ from Oracle Corp., Redwood Shores, Calif., and iAnywhere Solutions Inc., Emeryville, Calif., for the Palm Pilot and PocketPC.

"We engineered the Java platform to fit the Palm Pilot and provide the same functionality across the Palm Pilot and PocketPC," said Jim Acquaviva, Kada's CEO.

Once the device issue has been resolved, the next step is to make sure users get only the information they need and no more. Handheld devices have limited memory and screen size, so "you want users to be able to take the proper subset of application functionality from what's available on the desktop and the appropriate subset of data that's relevant to them accomplishing their mission on that trip," explained Acquaviva.

There are two realistic ways of doing this, he noted. One is to use mobile application servers and database technologies from Oracle and iAnywhere. The other is to use the Java Messaging Service (JMS) with a local messaging store on the device interacting with messaging-oriented Beans. "In both cases, you have a managed, persistent store in a format that can easily communicate—and be reconciled and synchronized with—a back-end database," Acquaviva said.

In either case, corporations should select a "very open" solution, suggested Martyn Mallick, wireless solutions evangelist at iAnywhere. That is because wireless devices have to connect to "multiple databases, possibly enterprise apps, and you may have Web content, XML content or e-mail you want to bring to wireless devices," he said.

The iAnywhere server integrates to back-end databases from Oracle, Sybase, Microsoft and IBM through JDBC or ODBC. It also has native drivers for Oracle and Sybase. Users can have EJBs running within an iAnywhere server that can access enterprise data and synchronize changes. iAnywhere has a J2EE framework running on its wireless server that lets users develop applications for thin-client devices.

However, synchronization with back-end systems has its dangers. "You must be very careful that the external wireless system does not damage the integrity of the internal data," said Michael Mudditt, president of ThinAir Solutions LLC, Montgomery, Pa., a Palm Pilot-based mobile applications builder. That can happen because wireless transport speeds are much slower than LAN speeds. An office LAN might run on 100Base-T, for instance, while wireless access tends to be at 9.6 Kbps and maxes out at 144 Kbps. Other things that might impact data on the back end, said Mudditt, are transient or bad wireless connections. To handle these problems, ThinAir Solutions has created the Oxygen Server, an intelligent server running an iAnywhere database that establishes an IP connection between users' Palm Pilots and iAnywhere. It also manages external users, connects into the back-end database and makes changes or acquires data, and conducts refreshes at the appropriate speed. That interim step mainly protects internal databases from transient users, Mudditt said.

Security is also of great importance to wireless apps. It should be "a core part of the platform and not just an afterthought," said iAnywhere's Mallick.

Tim Scannell, wireless industry analyst at Mobile Insights Inc., Quincy, Mass., said implementing security and encryption layers on top of wireless applications is inadequate, because "to get something secure, you have to start with security and then worry about the wireless part of it."

Another thing to think about when integrating wireless applications into the corporate back end is manageability—how to deploy applications to wireless devices, and how to manage the devices and applications. Experts say the best way to handle this issue is to bring wireless devices under the wing of the corporate IT department by managing them as IT assets. "It's critical that the IT group has tools in place to manage user accounts, devices, the software on those devices, and be able to control what's being used and make sure they're adequately supported before they roll out those devices," said FreeRein's Brown.

FreeRein offers the M/Gen mobile infrastructure platform, which provides a central interface for administering and maintaining all platform users and functions. Features include hardware inventory management, software inventory control, centralized software installation and upgrades. Based on Windows 2000, the M/Gen Platform is device-, carrier- and platform-agnostic. It provides "a lot of the APIs and SDKs that make it simpler for you to do database synchronization," the company's Brown said. The M/Gen Platform currently provides synchronization for SQL Server and Oracle, and FreeRein is looking at working with Sybase.

Wireless solutions must also enhance user productivity. "People are most productive when they can multitask," noted Kristopher Tyra, chief technology officer at enterprise wireless solutions provider HiddenMind Technology Inc., Cary, N.C. He believes mobile applications should interrupt users when there is something they should know. For example, when a corporation changes its product pricing information, the application should interrupt the sales force and inform them of the change. But what happens if the user is not in wireless contact? That is where persistent applications come in. "The mobile application has to be able to queue up transactions," Tyra said, "and I should be able to work with the device and the application while I'm not connected."

The HiddenMind Platform supports "always available" applications on wireless devices, even if they are disconnected from the wireless network. It supports browser-based devices such as Internet-enabled wireless phones and the HiddenMind Wireless Desktop, a native client that runs on programmable devices. The HiddenMind Platform consists of the HiddenMind Mobile Server, the HiddenMind Voice Server, the HiddenMind Wireless Desktop and the HiddenMind Studio, a user-friendly graphical IDE that allows users to create mobile and voice applications in an XML-based language once and deploy them to a variety of devices. HiddenMind Studio works with most low-level data sources, including XML, SQL, HTML, LDAP, IMAP, SMTP and other database connections.

Once a firm has worked out the details of what its wireless application requires, it can then consider the architecture. Planners should keep things simple. "Look hard at trying to build as few architectures as possible—preferably one—for integration with your enterprise apps," said Rowland Archer, chief technology officer at Haht Commerce Inc., Raleigh, N.C. The wireless application architecture should consist of a business objects layer, a command layer on top of that and a presentation layer to top everything off, he said.

Haht, which provides B2B e-commerce applications to customers, builds server and architectural stacks that integrate enterprise applications in real time. Enterprise applications are at the bottom of Haht stacks; on top of them is the integration layer—an EAI stack or one of Haht's adapters. Above that are business objects, followed by presentation services. Haht plugs wireless applications into the presentation layer as a presentation service, said Archer, and, to Haht applications, wireless devices look like another type of browser. There is no need to replace existing EAI and the business objects layer "just because your device happens to be a wireless device instead of a browser," Archer said. This approach lets the Haht Commerce Wireless Solution reuse more than 90% of users' existing Haht e-commerce systems and requires only relatively minor modifications to the user interface.

Separating the presentation layer from the business logic and application layers is the right way to go, said David Leichner, vice president of worldwide marketing at Magic Software Enterprises, Irvine, Calif. "If you're not separating out your presentation layer, you'll probably need to go in and develop—from scratch—to connect between the new device and back-end systems. That will mean some pretty heavy coding. You might need to change the underlying application logic on the back end," he said.

Technical details
Talbot Harty, vice president of marketing at wireless application server vendor Mobileum Inc., Pleasanton, Calif., warns developers not to scrape the screens of Web applications to wireless-enable them. This creates a hardbound link, so every time the Web page that has been scraped changes, the wireless presentation could break, or could need to be redone or checked, he said. Some screen-scraping tools inject their compilation code back into the original code at the Web site they scraped. The result is that "you can't alter the original code with the tool you used to create it; you have to use the tool that comes with the wireless platform instead, and that's a proprietary tool," Harty said.

Some design studios—proprietary development environments offered by some vendors—create separate output in different markup languages so the application can output to different devices, but they create and save the same source in multiple files, Harty said. This "is problematic when you're trying to figure out where a problem is occurring with a particular set of presentations," he said; it forces the developer to go through multiple presentations because the presentation is a compilation process.

Corporations should leverage existing skill sets when integrating wireless apps into the back end. The Mobileum 2.0 platform offers a tool-independent approach that lets developers use standard tools like Macromedia DreamWeaver, Adobe GoLive, Microsoft FrontPage or text editors to build mobile commerce applications by creating generic presentations around their data, Harty said. This allows developers to focus on writing for a family of devices, such as cell phones. In this situation, developers would just draw on XHTML tags for voice or telephony enablement in the application, he explained. This approach also lets Web developers leverage integration they have done previously, such as CGI scripting.

"There's been a lot of work during the past five years to create integration strategies, libraries, and routines around CGI scripts and JDBC and ODBC that need to be leveraged in wireless applications instead of being replaced," Harty said.

Yes, there is a lot of hype about wireless applications. But careful planning and proper implementations will help forward-thinking corporations leverage wireless technology to beat out the competition.