Wouldn't it be convenient if you could simply drop wired applications into a wireless environment and they would continue to work without any additional effort? Unfortunately, accessing traditionally wired applications on a wireless device isn't quite that easy for two main reasons:
- Many wireless platforms are closed.
- The machine interfaces of wireless devices are diverse.
Many manufacturers produce wireless devices without published low-level interfaces, which makes installing additional applications on the devices difficult. For example, installing a VPN isn't feasible on most of today's wireless platforms. Beyond that difficulty, the wireless platform often imposes a particular type of connectivity and might even require a specific intermediate technology. For example, if a mobile phone supports only the Wireless Application Protocol (WAP), your only choice is to use WAP. In addition, a wireless application's back end needs to present content and receive input from a wide range of client devices, which can be challenging because the number and types of available client devices continually change as new products come onto the market.
Almost every application has the potential to be wireless-enabled. However, some applications have more difficulty than others in achieving that potential. Is Exchange Server a good match for wireless devices? Typically, a primary factor for selecting an application is its data-transfer volume: The lower the total volume, the better because the application can perform faster. Exchange is clearly a high-volume application (daily traffic of several megabytes is common), so you might argue that Exchange isn't a good match for wireless devices. However, Exchange has the advantage of being used by almost everyone with an Internet connection. It's the only personal software application with this wide a reach. Thus, to satisfy Exchange users' demands, you can find many wireless devices that offer email access. The manufacturers have taken into account that users probably won't want to process all their email on a wireless device, so the wireless devices use forms that filter the content down to a scale suitable for wireless access.
You can broadly classify the wireless devices that offer email access by the type of interface they provide (i.e., by their connectivity options). The connectivity options include the native interface, the enhanced interface, the Web interface, the Short Message Service (SMS) interface, the WAP interface, the terminal services interface, and proprietary solutions. Let's look at these options and at considerations for evaluating a wireless email solution.
The Native Interface
The most common connectivity option is the native interface between Exchange and Outlook that uses the Messaging API (MAPI) mail protocol. As Figure 1 shows, this option provides a direct connection to Exchange. Because Outlook is part of Microsoft Office, Outlook is already installed on many mobile devices (e.g., notebooks) that are set up to access email over fixed lines. Making Outlook work over a wireless link requires no additional effort.
However, the native interface has two disadvantages. First, because it's written for Windows platforms, not all wireless devices can use this connectivity option. Second, Outlook's dependency on MAPI remote procedure calls (RPCs) results in poor performance over unreliable and slow network links. MAPI RPCs use bandwidth inefficiently, making the connection vulnerable to high latency. In a high-speed environment, the latency is scarcely noticeable, but over slow dial-up or wireless links (often only 9.6Kbps), the latency can be unacceptable. Furthermore, RPCs are problematic to set up when you have firewalls between the wireless device and the Exchange server.
Some of the other mail protocols that you can use with the native interface include POP3 and IMAP4, which manufacturers usually combine with Lightweight Directory Access Protocol (LDAP) to provide a directory interface. Examples of products that support POP3, IMAP4, and LDAP include Outlook Express and Netscape.
You can use nonMAPI-based clients over a wireless network. NonMAPI-based clients typically offer better performance than MAPI-based clients. However, the nonMAPI-based clients are less capable of supporting nonstandard functions, such as Outlook's Calendar and Contact functions.
The Enhanced Interface
You can optimize the native interface by compressing and securing the wireless connection. This enhanced interface is transparent to the user. As Figure 2 shows, a compression engine compresses and encrypts the data and an optimization engine intercepts the compressed connection and translates the requests to MAPI.
One product that uses an enhanced interface is Infowave's Wireless Business Engine with the Exchange Connector. Together, the Wireless Business Engine and Exchange Connector create a VPN between the wireless device and the Exchange server on a corporate network. Infowave designed this VPN especially for wireless connections. In the VPN, the Wireless Business Engine encrypts and compresses the data, which reduces the transmission size and provides more tolerance in case of link failures. The Exchange Connector decompresses and decrypts the data and translates it into MAPI requests.
Infowave offers functions that further optimize slow and unreliable wireless connections. These functions include
- batch processing of send and receive operations to optimize slow email protocols
- flexible attachment handling, such as not sending large attachments
- asynchronous downloads while the user is processing other mail
The Web Interface
In many situations, a good alternative to the native interface is to use a Web interface (e.g., HTTP, HTML, XML) between Outlook Web Access (OWA) and Exchange. As Figure 3 shows, OWA requires only a Web browser, which is available on almost every wireless device. When you use OWA with Microsoft Internet Explorer (IE) 5.0 or later, you receive the richest UI. However, you can use OWA with virtually any browser (albeit with reduced functionality). You typically don't need to install any additional software or updates, which makes setting up the wireless connection easier for you and makes using the wireless email application easier for end users.
With this type of interface, access speed is certainly tolerable across most networks, especially when users are retrieving or entering small amounts of information. Following an approach similar to the one in "The Enhanced Interface" section, you can optimize the Web interface with products such as Infowave's Wireless Business Engine with the Web Connector. In addition, you can use Wireless Knowledge's Workstyle for Microsoft Exchange to achieve device-dependent rendering of the content—a big plus for small formfactor devices equipped with a browser.
Although access speed is tolerable, the Web interface doesn't support local storage, which means that end users can't work in offline mode. Unless email access is only sporadic, the requirement of a connection is a big drawback in a wireless environment.
The SMS Interface
The SMS interface is well suited for mobile phones because many mobile phones send and receive SMS messages. Phones with SMS capability are especially prevalent in Europe and Asia, and virtually all Global System for Mobile Communication (GSM) phones send and receive SMS messages. In addition, SMS has built-in notification, which alerts users when messages arrive.
Figure 4 shows the typical setup of an SMS solution. The user sends a query in the form of an SMS message. The message passes through the mobile operator's SMS center to an SMS-Exchange interface, such as Fenestrae's Fenestrae Mobile Data Server. Fenestrae Mobile Data Server processes the query, extracts the corresponding information from Exchange, and returns the results to the user in the form of another SMS message, which again passes through the SMS center.
Besides Fenestrae Mobile Data Server, other solutions that take advantage of SMS include Magic E's Xsonic InTouch Lite and Microsoft Mobile Information Server with the Outlook Mobile Manager (OMM) add-on. (For information about this add-on, see the sidebar "Redirecting Email with OMM.") However, no two SMS solutions are alike. The extent to which the solutions use SMS can differ in several respects:
- You can use SMS purely as an alert mechanism (e.g., Microsoft's solution), or you can let a user make simple command-like requests to the server (e.g., Magic E's and Fenestrae's solutions).
- SMS solutions can integrate with the personal information manager (PIM) on the device (e.g., Fenestrae's solution) so that calendar appointments and contacts are automatically sent to the phone without any user action (assuming the phone supports calendar appointments and contacts).
- An SMS solution can take advantage of a direct connection to a mobile operator (e.g., Microsoft's and Fenestrae's solutions), which is useful for a large volume of messages, or an SMS solution can rely on SMS terminals (i.e., phones) to generate SMS messages.
Regardless of the SMS solution that you use, the biggest drawback is the UI. Manual entry of messages and commands through a standard phone keypad is cumbersome, and even reading long messages can be awkward because of the small screen size. Although casual users might be able to adapt to the UI, corporate users who receive numerous email messages every day would likely find the UI unacceptable.
To solve the UI problem, SMS solutions let users filter and often truncate email messages according to personalized rules. The user defines the criteria that determine whether an alert is necessary (e.g., sender, subject, recipients, size) and the elements to include in the alert (e.g., sender, first three lines of text, distribution list—DL). Thus, users might simply have an alert-only solution that informs them when messages have arrived. The users can then find a fixed connection to view those messages.
However, a complete solution might be more desirable. A complete solution provides a means for users to retrieve some information from an email message or retrieve the entire message. The solution doesn't need to be entirely based on SMS. You can combine SMS with a pull mechanism, such as a WAP interface. For example, an SMS message might contain a URL for the full email message, which users can retrieve through a WAP interface.
The WAP Interface
Although WAP is a primitive interface, you can use it as a pull mechanism to let users browse through their mailbox and read mail messages or parts of them, as I just described. In terms of retrieving information, a WAP-based UI is better than an SMS-based UI because the WAP-based UI is menu driven rather than command driven. In other words, users of WAP-based devices don't need to memorize commands.
To use a WAP interface to connect to Exchange, you must secure a WAP connection to the corporate network. In most cases, securing a WAP connection means that you must install a WAP gateway on the company's network, as Figure 5 shows. In Figure 5, the Wireless Markup Language (WML)Exchange interface provides a browser interface to the user's Exchange mailbox. The WML-Exchange interface is similar in concept to OWA, except that it uses WML rather than HTML.
Some of the WAP solutions include Infowave's FirstHand, Xsonic's Mobilize, Fenestrae Mobile Data Server, and Mobile Information Server with the OMM add-on. The performance of WAP solutions is subject to significant variation depending on the underlying network protocol they use. One of WAP's biggest deficiencies is that people commonly implement it on circuit-switched data. This setup means that at least the initial request requires the connection of a dial-up circuit, which often takes 10 seconds or more to establish. However, if you implement WAP on top of a packet data network, such as the General Packet Radio Service (GPRS) network, the response time improves radically.
The Terminal Services Interface
Citrix MetaFrame and Windows XP's Remote Desktop (an extension of Windows 2000 Server Terminal Services) both offer a generic means of accessing server applications from a thin-client device, such as a PDA. With a single piece of software (i.e., MetaFrame or Remote Desktop), you can enable a whole suite of applications, including Exchange, on a wireless device. As Figure 6 shows, you can use a multipurpose terminal services client to access a terminal server on the host network. The terminal server can provide the functionality for any number of applications. In this case, you would use Outlook on the terminal server to connect to Exchange.
Using the terminal services interface is compelling when users need to access a wide range of applications from their wireless devices because it's efficient in bandwidth and requires little local support. However, similar to the Web interface, the terminal services interface requires an active network connection. If Exchange is your only wireless application, this approach might be overkill.
Proprietary Solutions
Although standards for wireless email applications are just now taking hold, some trailblazers have already implemented proprietary solutions. These companies have the advantage of being able to offer specialized hardware that they've tailored for email access.
However, proprietary solutions carry an inherent disadvantage. If the solution uses a closed platform, extending or customizing the functionality to suit end-users' needs is difficult. As a result, although the device might be ideal for email access, you must complement it with an additional mechanism for other wireless applications—in other words, you need yet another device.
Research in Motion's (RIM's) BlackBerry is a good example of a proprietary solution. One important feature is a miniature keyboard. The keyboard is more awkward to use than a full keyboard but certainly much easier to use than a similarly sized phone keypad.
BlackBerry uses packet data networks to deliver email to mobile Exchange users. BlackBerry is popular in North America, but it's not widely used elsewhere mainly because BlackBerry is available only on Mobitex and DataTAC networks. As BlackBerry becomes available on GPRS networks, its popularity might spread to other continents.
Considerations to Keep in Mind
Matching your networks and client devices with the wireless applications you need to make available to users can be a monumental task and isn't something I can cover adequately here. Different users require different levels of functionality, and users access their information under widely varying circumstances. However, when deciding on your wireless email solution, keep in mind
- the trade-off between bandwidth and functionality. Transmitting meaningful information occupies bandwidth. If a solution requires little bandwidth, it will offer little functionality. The only way around this trade-off is to compress transmissions, but even compression has limitations.
- the ease with which you can configure and support wireless devices. The configuration and support of wireless devices can be an enormous, never-ending task. If you're a novice or extremely busy, you'll likely find great value in using applications that are preinstalled on the wireless device or that are already installed for wired usage.
- whether users need local storage. Local storage is an important factor if users will occasionally use the wireless devices without network connectivity. For example, users might be in remote areas that don't have access to a network. Local storage might also be important if users need to occasionally save email messages.
- whether users need alerts. Alerts provide a great mechanism to push information to the user. Pull technologies are sufficient for many applications; however, they rely on the user knowing when to browse, or poll, for information. If new information arrives at random intervals, the task of polling can be frustrating to the user.
Choosing the Right Connectivity Options
As you think about which connectivity option is best for your environment and mull over the considerations, you might find that no one option meets all the users' needs. For example, some users might need alerts delivered immediately to their mobile phones. Other users might need complete email messages delivered to their PDAs. To fully satisfy the needs of a varied set of users, a complete solution might involve several, or conceivably even all, of the connectivity options. After you decide on the right connectivity options, check out the Mobile & Wireless Solutions Web site (http://www.mobile-and-wireless.com) for helpful tips about how to implement them.
