ArcIMS Java Client Supplies Mapping to Phones
By Martin Brehovsky and Tomas Brandalik, Sun Microsystems, Inc.
Editor's note: The total number of mobile phone users worldwide is expected to reach 1.4 billion in 2004, according to Alex Slawsby, an analyst for IDC's mobile devices division, and sales show no sign of slowing. The functionality of these omnipresent devices has been expanded to include digital cameras, games, e-mail and, increasingly, mapping. The authors describe how they have implemented an ArcIMS client for mobile phones that takes advantage of Java 2, Micro Edition (J2ME), the edition of the Java 2 platform targeted for consumer and embedded devices.
Amid news of soaring mobile phone sales, the sale of more than one hundred million J2ME-enabled mobile phones worldwide is still noteworthy. The increase in J2ME-enabled devices provides an opportunity for the expansion of services for mobile phones supplied by cellular network operators or application developers. Users only stand to benefit from this situation. They will be able to choose from many applications furnished by sources that are independent of cellular network operators.
Because people typically carry mobile phones with them at all times, these devices are well positioned to supply spatial information through a mapping server client. Although many map services are currently available for mobile phones, these services are most often based on the Subscriber Identification Module (SIM) toolkit or Wireless Application Protocol (WAP). Neither standard allows for the use of rich and responsive user interfaces. On the other hand, J2ME-enabled devices support highly interactive applications that can be customized somewhat for a particular device. A wireless map browser for ArcIMS is a good candidate for this type of interactive application.
Limitations of J2ME Devices
Unfortunately, a majority of J2ME devices are rather limited when compared to a typical personal computer. The most obvious limitations are
- Small display (as low as monochrome 96 x 56, but often color 128 x 128).
- Low processing power.
- Limited available memory. Applications are usually allowed up to 64 KB of memory for code and an additional 200 KB for the run-time heap.
- Small network bandwidth, often with high latency.
- Limited user interface (UI) and input devices (i.e., mobile phones and other wireless devices do not have regular keyboards and pointing devices such as mice).
These limitations require that a J2ME client for ArcIMS be carefully designed so the application is complete and error proof and operates within this framework while providing the user with multiple features.
Communication Between ArcIMS Server and J2ME Client
Communication between the wireless client and server is one of the most important aspects of a J2ME ArcIMS client. ArcIMS has a very powerful XML-based communication protocol called ArcXML. Unfortunately, this power is an obstacle when implementing the J2ME client because a J2ME device typically does not have enough power or memory to process XML communications. Current XML parser implementations for J2ME devices take a lot of available memory—memory could be otherwise used by the application itself. Furthermore, the large size of XML messages is a significant drawback.
To overcome these challenges, the authors designed a proprietary binary protocol called MultiProtocol. It is used to communicate between the map browser and the map server. The protocol allows the client and server to communicate through a set of defined messages that can be sent from either side. The protocol includes the following messages:
MapMessage—Used to request a map for the given extent and image size and the response that contains the map image
IdentifyMessage—Used to request identification of a feature at the given coordinates and the response that contains the identified features
MetadataServiceMessage—Used to get information about available services running on a map server
MultiProtocol can include many other defined messages. The current implementation also includes FeatureMessage for getting features for a given extent and CrossStreetMessage for obtaining a location identified by an intersection of two streets. Messages can also be composed together (e.g., CrossStreetMessage can include MapMessage).
To optimally utilize the communication channel, the authors also designed the protocol so that it could send one or more messages in a single request or response-hence the name MultiProtocol. For example, a client can send both MapMessage and FeatureMessage in a single request. The map server processes both messages and sends back a map image in the MapMessage and information about available features in the FeatureMessage—all in a single response.
ArcIMS as a Server for J2ME Clients
ArcIMS does not understand this binary protocol so some sort of middleware is necessary to translate MultiProtocol's requests into ArcXML and server responses from ArcXML back to MultiProtocol. Fortunately, ArcIMS includes the JavaConnector library, which enables this functionality through custom Java classes (i.e., middleware). The middleware also augments standard ArcIMS functionality by adding further services designed specifically for J2ME wireless clients. The middleware was designed so that each MultiProtocol message type is handled by its own service. For example, when a mobile phone sends a request for a map by sending MapMessage, the middleware calls MapMessage Service, which calls the appropriate objects and methods from JavaConnector, creates a map image, and sends it back to the mobile phone through MapMessage. The architecture of this solution is shown below in Figure 1.
Figure 1: Application architecture
Continued on page 2
|
