|
Have the limitations of wireless technology restricted its applicability to specific niche markets? Wireless applications traditionally have been developed for vertical markets. Deployment of these projects typically has required large development efforts and, therefore, a robust wireless development platform that supports the development's specific needs.
But has this model changed? Wireless technology has come a long way and the middleware to support it is following close behind. Can we design applications
that seamlessly function in bo
th LAN- and wireless-based environments? Has the technology progressed to a point where it enables any application to run in a wireless environment. Can we simply ignore mobile middleware and think of it only as a transport-layer issue?
The short answer is "No." In fact, most wireless technologists contend that the products designed to make wireless networks transparent simply aren't good enough, and state that the applications themselves must be aware of the wireless environment.
We examined application programming interface (API)-based and agent-based tools and found that although these approaches are moving in that direction, they aren't there yet. We tested wireless middleware tools at AT&T's Wireless Services laboratory
using Cellular Digital Packet Data (CDPD) as our wireless service. We chose CDPD because of its bandwidth and its ability to pass IP packets (it's not transport-layer specific--any TCP/IP stack can be used).
Current Wireless Installa
tions
The most common model fo
r wireless environments is the client/agent/server setup originally popularized by Oracle Corp.'s Oracle Mobile Agents. This configuration uses an agent application to access server-based resources in the LAN environment and communicate the results over a wireless medium to the mobile client.
In this setup, the wireless agent server must be connected directly to the wireless service provider. To understand this, consider that the common method for enabling IP applications over wireless connections is via TCP/IP header reduction. Once the header has been reduced, it will no longer route over a conventional TCP/IP network. It must be delivered directly to the wireless network where the client wireless device can receive the transmission with its specific device identifier.
Different wireless networks approach this constraint differently. For example, Mobitex and Ardis networks use X.25 and leased lines as their most common connection type. AT&T Wireless Service's CDPD network supports frame relay but it also can route directly to the Internet.
Wireless APIs
Most network managers don't have the resources for large or even moderate-sized development projects and the majority of wireless-centric middleware products have been proprietary APIs. Understanding how these APIs are used can aid in understanding how to set up wireless-based services successfully.
We investigated Nettech Systems' InstantRF Workbench and found that it may be one of the simplest libraries for which to develop. InstantRF Workbench is comprised of
three components: RFMlib, RFgate and RFlink. RFMlib is the mobile-side library and includes drivers for most wireless devices. Nettech's libraries
support major wireless networks as well as wireline a
nd LAN connections, providing a great deal of network transparency.
RFgate is the equivalent to RFMlib on the host gateway. RFgate's primary function is to launch independent agents, or processes, written by the RFgate developer that act on behalf of the mobile client in the LAN-based environment. It does this by associating the mobile unit ID from an incoming request with a specific application ID. However, you must first define mobile run-time parameters for the application.
|
REPORTS
ANALYTICS
Follow 
