| February 28, 2007 11:59 AM PST | |
By Jim Geier
Read how middleware and traditional connectivity options make it possible for mobile devices to maintain communications with server-based applications.
It is difficult to install wireless networks in a way that provides complete coverage where users operate their mobile client devices. Obstacles such as buildings, walls and even people offer varying amounts of attenuation to the propagation of radio waves. The result is often spotty coverage that periodically interrupts network connectivity as users roam.
I recently tried to remotely utilize a Java*-based Web site publishing application from over a wireless LAN in a hotel lobby, and I found that poor signal strength was interrupting my session. This required me to keep logging back into the system and restarting the application – not fun when you desperately need to be somewhere else!
Likewise, interference from microwave ovens and cordless phones occasionally causes a decrease in wireless LAN performance and sometimes a loss of connectivity for an indefinite period of time. This erratic disturbance makes communications over the network sluggish and even unavailable if the interference is severe enough.
Because wireless systems allow users to roam, mobile software also runs into problems when crossing subnets and other non-compatible types of wireless networks. A client device using a wireless LAN card for network connectivity, for instance, cannot roam to another subnet within the same facility without special provisions. Nor can the client natively roam from the wireless LAN to a 3G cellular system.
Some wireless mobile applications must interface directly with application screens running on a host computer, such as an IBM* AS/400, a Unix platform or a 3270 mainframe. In this case, terminal emulation software runs on the client device, which communicates with application software running on the host. As examples, VT220 terminal emulation corresponds with applications running on Unix, and 5250 terminal emulation works with AS/400-based systems.
An advantage of terminal emulation is that it has low initial cost and is somewhat of a plug-and-play solution. Keep in mind, however, that wireless systems using terminal emulation may not maintain adequate connections with legacy applications, which have timeouts entrenched throughout the application software that relate better with the more reliable wired networks. The timeouts automatically disconnect a communications session if user activity doesn’t occur within a given time period—not exactly a pleasant experience for users!
Consequently, corporate IT people spend a lot of time responding to end-user complaints of dropped connections and the associated issues of incomplete data transactions. The implementation of terminal emulation can have a significant deleterious effect on long-term support costs. This eats away fast at the benefits that the mobile applications offer.
In addition, terminal emulation applications tend to push unnecessary data over the wireless network, which consumes valuable throughput. Because the application is actually running on the host, all input screens, print streams and other correspondence with the application must traverse the wireless network. As a result, uninformed compa nies that start out with wireless terminal emulation eventually search for better solutions in order to reduce support issues.
Terminal emulation is slowly fading away as companies continue to deploy mobile applications following the client/server model. In this case, the developer designs the client software to communicate with the database using proprietary database commands or Open Database Connectivity (ODBC) protocols. The software on the client device with this configuration provides nearly all user functionality.
This approach provides flexibility when developing mobile applications, mainly because the programmer has complete control over the functions that are implemented and is not constrained by applications running on a host system. The problem with client/server connectivity is that it operates over TCP/IP, which is cumbersome over the limited bandwidth of wireless networks. TCP/IP uses relatively large headers and adds significant delays when re-establishing connections while the user traverses coverage holes.
Many Web server applications can tolerate wireless impairments, but be careful when implementing applications requiring immediate responses between the client and the server. In some cases, your application may not be able to recover from loss of connectivity in the transactions that have dependencies on other transactions.
Wireless middleware software resides between client software and the application software or databases located on a server and offers intermediate communications that elevate wireless issues, such as coverage holes. The middleware, which generally runs on a dedicated gateway platform attached to the wired network, processes the packets that pass between the wireless client and the server. As a result, middleware offers efficient and reliable communications over the wireless network while maintaining appropriate connections to application software and databases on the server via the more reliable wired network.
Wireless middleware has store-and-forward messaging that queues traffic to ensure delivery to client devices that lose connections with the network. The middleware is able to act as a proxy of the client. In fact, most applications have no idea that the middleware server is maintaining the connection with the host. Once the client gains wireless connectivity again, the middleware lets the client resume communications. This is especially beneficial when servers and applications can’t tolerate the loss of connectivity.
If transmissions are unexpectedly cut at midstream, “intelligent restart” is a middleware recovery mechanism that detects the premature end of a transmission. When the connection is reestablished, the middleware resumes transmission from the break point instead of at the beginning. This not only enables wireless clients to easily reestablish connectivity, it also helps with improving performance and reducing battery drain due to fewer packet retransmissions.
Some middleware products include data compression at the transport layer to help minimize the number of bits sent over the wireless link. Some implementations of middleware use header compression, where mechanisms replace traditional packet headers with a much shorter bit sequence before transmission. Of course this helps free up needed throughput for supporting higher performance applications, such as video streaming, and large numbers of active users.
Middleware packages are often capable of combining smaller data packets into a single larger packet for transmission over the wireless network, which can improve performance and help lower transmission service costs of wide area networks. Since most wireless data services charge users by the packet, data bundling results in a lower aggregate cost.
Middleware products sometimes offer a development environment that allows developers to use visual tools to “scrape” and “reshape” portions of existing application screens to more effectively fit on the smaller displays of mobile devices, such as PDAs and cell phones. This is a good alternative versus using existing larger screens offered by legacy terminal/host connections, which would generally require users having small screens to spend most of their time scrolling. Developers can pick and choose parts of several legacy screens in order to make the user interface more efficient and streamlined for traversing the wireless network.
To facilitate roaming, a few middleware products offer home and foreign agent functions to support the use of Mobile IP protocols, which seamlessly handle changes in a client’s point of attachment to the Internet. This enables wireless users to roam across different subnets. This is crucial when deploying mobile applications that span a large company.
In addition, some middleware offers proprietary solutions for roaming across different wireless network types, which generally requires special client software installed on the client device. This makes it possible for users to roam from a wireless LAN to a cellular system, assuming the client device has both network adapters. Mobile phone manufacturers are making this a reality, however, with built-in wireless LAN interfaces.
Middleware may also provide multi-host support, which is invaluable when integrating mobile applications into complex end system environments. For example, I remember a mobile application a couple of years ago that required wireless client devices to retrieve pricing data from an IBM mainframe (using 3270 terminal emulation) and record data entered by the user into a database located on a Windows* 2000 server (through ODBC). This would have been difficult to integrate with terminal emulation and direct database connectivity.
Middleware provided a centralized component that molded together both the terminal/host and client/server worlds. This was especially useful knowing that the pricing data was eventually going to be moved to the Windows 2000 server. Middleware makes it possible to develop a common interface that didn’t need to change after moving the pricing data to the server.
A strong advantage from a development perspective is the consistent API that many wireless middleware tools offer. Developers can use the wireless middleware as a development environment for integrating their applications to various types of end systems, regardless of the underlying network.
Developers can also centrally implement and manage the wireless connections through the middleware platform. For example changes made to the solution can easily be made available to all clients because of the centralized nature of the middleware server. The server also sees all client traffic, making it possible to identify the presence of users, track user activity and detect r ogue users and potential denial of service attacks.
Before engaging in the development of wireless mobile software, at least think about how wireless impairments, such as loss of connectivity and RF interference, will impact the operation of your application. That may steer you away from the pitfalls of using terminal emulation. At least with the client/server approach, you have flexibility in developing your client software to include the error recovery mechanisms necessary to combat the wireless impairments. In order to reduce error recovery coding, though, strongly consider the use of wireless middleware.
The following are some of the Wireless Middleware Vendors:
-
Read about a leading supplier of wireless network and process control integration tools striving to set the standard of performance at: www.connectrf.com*
-
Learn about the different integration products of Iona at: www.iona.com*
-
Discover how to enhance productivity and improve customer service through a wireless solution, quickly and easily: www.netmotionwireless.com*
-
Wavelink provides mission-critical wireless applications and the management of wireless LAN networks and mobile devices, read more at: www.wavelink.com*
For more complete information about compiler optimizations, see our Optimization Notice.
alex