18.1 Location-Based Services

LBS include all applications that make use of location and geographic data. It is touted as the killer app for mobile commerce because it enables brand new applications not possible in the desktop world. There are several types of LBS applications:

• Pull-based applications: The user actively sends out her location information to a server and pulls in location information such as driving maps and nearby stores.

• Push-based applications: Service providers detect users in their proximity and push out services such as coupons and advertisements. A central issue in push-based applications is how to protect user privacy. Location information can be highly sensitive. It is extremely important vendors get information from and push services to only opt-in users.

• A combination of pull and push: For example, a user can first pull nearby coffee shop locations and make a mobile reservation. Then he can send meeting alerts to peers within certain distances from the shop. The peers will be able to accept or reject the invitation.

Although LBS offers appealing business values, its implementation technologies are sophisticated. The core technology for any LBS solution is Geographic Information System (GIS), which performs important functions such as determining street addresses from coordinates and vice versa; look up yellow pages and landmarks; calculate optimal routes and render custom maps. It is the integration point of many heterogeneous components in the LBS application. This makes XML Web Services a perfect fit here. In the next section, we discuss a leading commercial GIS Web service: Microsoft MapPoint. 

18.2 Microsoft MapPoint Web Services

Standalone GIS servers (e.g., Oracle GIS server) that are capable of geocoding, map rendering, and other complex geographic algorithms have been commercially available for a long time. However, running a GIS server by yourself is probably too expensive for most small to mid-sized businesses. The costs include:

• Hiring GIS experts to set up and maintain the system.

• Licensing high-resolution digital maps and business yellow page listings. This could be very expensive if your users roam across many metropolitan areas.

• Aggregating geographic information updates from many sources (e.g., road construction and business address changes) and updating them frequently to the database.

• Ongoing server administration for secure and high availability services.

• Licensing cost of the GIS server software itself.

For most companies, it makes sense to outsource the entire GIS operation to specialized providers. Microsoft's MapPoint Web Service is a managed GIS solution accessible via a set of platform-independent SOAP Web Services APIs. MapPoint also allows users to import their own geocoding data and points-of-interest listings for customized services.

18.2.1 The MapPoint v3.0 SOAP API

MapPoint Web Services expose a very rich set of SOAP APIs. Important remote methods in MapPoint v3.0 are divided into four categories.

• Common Service contains utility functions that are common to other services.

• Find Service allows the user to do generic geocoding tasks, including finding addresses from latitudes and longitudes, and vice versa. It also allows searching for nearby points of interests.

• Route Service calculates routes and directions based on locations and waypoints. It also generates map view representations of the calculated routes. The map view can be used to highlight routes on a map.

• Render Service renders the map for the locations or routes. It highlights routes, places pushpins and icons, and supports zoom.

Table 18.1 lists the methods from all categories. The first 5 methods in that table belong to the common service; the next 5 methods belong to the find service; the next 2 methods belong to the route service; and the last 4 methods belong to the render service. The API also defines many composite data types (e.g., Address, MapView, and RouteSpecification) to pass data to or from those service methods. Detailed discussions on how use the MapPoint API is beyond the scope of this book. For interested readers, the Axis gateway example in Section 18.2.3 demonstrates the use of many basic API functions from a Java client.

 

18.2.2 The Aggregated API

Through the SOAP API, MapPoint Web Service offers fine-grained access to its GIS back end, allowing us to design flexible applications without arbitrary limitations imposed by preset scripts. However, the trade-off is that we have to make separate method calls for each small step to complete a task. For example, in order to retrieve driving directions between two addresses, we have to go through the following steps.

The last two steps need to be performed repeatedly for a long route with many segments. Since all those method calls are remote SOAP calls, those excessive round trips cause long delays over slow wireless networks. To minimize the data transfer over wireless networks, we can place a remote facade between the mobile client and MapPoint. The facade takes in two human-readable addresses in a single SOAP call, queries MapPoint via many API calls over the wired Internet, constructs the resultant driving directions, and returns the results. It provides a coarse-grained, simple interface that aggregates functions of the fine-grained MapPoint API methods for specific applications. Figure 18.1 illustrates the facade architecture.

 

18.2.3 The Axis Facade

In this section, we introduce a Java-based SOAP facade (gateway) that aggregates generic MapPoint APIs into convenient remote methods for specific tasks to minimize round trips for mobile clients. The gateway is built using Apache Axis (v1.0). It is developed as follows:

1. Generate Java SOAP stub classes for the MapPoint SOAP API using the WSDL2Java tool in Axis.

2. Use those Java stub classes to develop a Java object, MPClient, that contains convenience aggregated methods.

3. Publish the MPClient object as a SOAP Web Service via Axis's server interface. This is the RPC interface for mobile devices. The steps are as follows.

   1. Configure and run Axis server inside a Tomcat server.

   2. Copy the JAR file containing the MPClient class to Axis library directory.

   3. Specify the scope of the service object, methods to expose, and other options via a .wsdd file.

   4. Deploy the .wsdd file to Axis through its server administration utility.

Detailed tutorials on how to configure and use Axis are beyond the scope of this book. Please refer to Axis documentations in the "Resources" section. Due to the limited space, I show only the public interfaces of remote methods in the MPClient class here (Listing 18.1). The API usage is embedded in the code comments. The complete code is available in the AxisFacade project, downloadable from this book's Web site. The project archive also contains generated stub classes, Axis libraries, sample .wsdd files, and ANT script to build and deploy the facade gateway.

Listing 18.1. The Axis facade MPClient class

public class MPClient {



  // Authentication credentials obtained from

  // MapPoint Web site

  private static String userName = "userid";

  private static String password = "password";



  // other variables



  // The cached route segments

  private Segment[] segments;



  // Get the driving directions between

  // two human-ready addresses. This method

  // also caches the route in the segments array

  //

  // You have to run this method before you can

  // retrieve maps for the entire route or for

  // each route segment.

  public String [] getDirections (

   String fromStreet, String fromCity,

   String fromState, String fromZip,

   String toStreet, String toCity,

   String toState, String toZip

                       ) throws Exception {

    // method body

  }



  // Return the number of segments of the current

  // cached route. The number is available after

  // you call the getDirections() method.

  public int getSegmentNum () throws Exception {

    // Method body

  }



  // Get a map from the current cached route.

  // The return value is a byte array for

  // the GIF image.

  //

  // index == 0 for the overview map

  // index <= segmentNum for a segment map

  public byte [] getMap (int index,

          int width, int height) throws Exception {

    // Method body

  }

}

Note

You have to call the getDirections() method to obtain the route before you can retrieve any map.

The MPClient facade class aggregates driving direction services for illustration purposes only. In real-world, location-based applications that require more functionalities, you should design and implement facade gateways that fit your own application needs.

18.3 MapPoint J2ME Clients

With the Axis facade gateway, we have transformed the MapPoint Web Service to a wireless-friendly service while still preserving the benefits of SOAP Web Services. In fact, we can use any Web Services-compatible client to access MapPoint services through the Axis gateway. Those clients can be developed on almost all Microsoft platforms, all Java editions, script languages such as Perl and AppleScript, as well as many native C/C++ SOAP frameworks. In this section, we demonstrate two simple J2ME clients for driving directions.

18.3.1 CDC/PP and PersonalJava Clients

Figure 18.2 demonstrates the driving directions client in action on a PocketPC device running Jeode PersonalJava VM. Thanks to the standard AWT library, the same client runs on CDC/FP/PP devices (e.g., IBM WebSphere Micro Edition's Personal Profile runtime) and standard J2SE desktops (e.g., Windows, Linux, and Mac OS) without modification.

 

Key code snippet that queries the Axis gateway service for directions and maps is shown in Listing 18.2.

Listing 18.2. The CDC/PP driving directions client

public class AWTMap extends Frame

    implements WindowListener, ActionListener {



  private String endPointURL;



  private TextField fromStreet;

  private TextField fromCity;

  private TextField fromState;

  private TextField fromZip;

  private TextField toStreet;

  private TextField toCity;

  private TextField toState;

  private TextField toZip;

  private java.awt.List directionsList;



  private ClassMap cm;

  private Marshal md;



  // Other variables



  // Lists the driving directions

  private void listScreen (boolean newSearch) {

    try {

      if (newSearch) {

        SoapObject method =

            new SoapObject("", "getDirections");

        // Use the SE version for standard JDK

        // Http methods

        HttpTransportSE rpc =

          new HttpTransportSE(endPointURL, "\"\"");

        rpc.setClassMap(cm);

        method.addProperty("in0", fromStreet.getText());

        method.addProperty("in1", fromCity.getText());

        method.addProperty("in2", fromState.getText());

        method.addProperty("in3", fromZip.getText());

        method.addProperty("in4", toStreet.getText());

        method.addProperty("in5", toCity.getText());

        method.addProperty("in6", toState.getText());

        method.addProperty("in7", toZip.getText());

        Vector v = (Vector) rpc.call (method);



        directionsList = new java.awt.List(10, false);

        directionsList.add("Overview Map");

        for (int i = 0; i < v.size(); i++) {

          directionsList.add((String) v.elementAt(i));

        }

        directionsList.setSize(200, 200);

      }

      Panel top = new Panel ();

      top.setLayout(new FlowLayout(FlowLayout.LEFT));

      top.add(directionsList);

      Panel bottom = new Panel ();

      bottom.setLayout(new FlowLayout(FlowLayout.LEFT));

      bottom.add(startOver);

      bottom.add(showMap);



      scroll.remove(content);

      content = new Panel ();

      content.setLayout(new BorderLayout());

      content.add(top, BorderLayout.CENTER);

      content.add(bottom, BorderLayout.SOUTH);

      scroll.add(content);

      setVisible(true);



    } catch (Exception e) {

      e.printStackTrace();

    }

  }



  private void mapScreen (int i) {

    try {

      ImageItem img;

      byte [] imgarray;

      SoapObject method = new SoapObject("", "getMap");

      HttpTransportSE rpc =

        new HttpTransportSE(endPointURL, "\"\"");

      rpc.setClassMap(cm);

      method.addProperty("in0", new Integer(i));

      method.addProperty("in1", new Integer(200));

      method.addProperty("in2", new Integer(200));

      imgarray = (byte []) rpc.call (method);

      img = new ImageItem(imgarray, 200, 200);



      Panel top = new Panel ();

      top.add(img);

      Panel bottom = new Panel ();

      bottom.add(startOver);

      bottom.add(showDirections);



      scroll.remove(content);

      content = new Panel ();

      content.setLayout(new BorderLayout());

      content.add(top, BorderLayout.CENTER);

      content.add(bottom, BorderLayout.SOUTH);

      scroll.add(content);

      setVisible(true);



    } catch (Exception e) {

      e.printStackTrace();

    }

  }



  // Other UI and event handling methods

}

18.3.2 MIDP Clients

Figure 18.3 shows the MIDP client in action in a MIDP v2.0 emulator. Since MapPoint supports only GIF image format rendering at this stage, but MIDP requires PNG format, driving maps are not yet available in the MIDP client. A quick fix would be to convert GIF images to PNG images inside the facade using the Java imaging API.

 

Complete source code and build scripts for both Java clients as well as for a .NET Compact Framework client are available for download from this book's Web site.

18.4 Enhancing the Driving Directions Application

The driving directions application we demonstrated above is not particularly easy to use. For example, if we are lost while driving around, we need to find the route from the current location to the destination. To find out the current street address and manually enter it into the device could be a major nuisance. A driving directions application that is aware of the current location context and automatically fills out the From field can be much more valuable to users. In fact, most LBS business models require access to the mobile client's current location.

18.4.1 Location Determination Techniques

There are several ways to obtain the current locations of mobile devices.

• Terminal-based: A GPS-equipped device can calculate its coordinates using GPS satellite signals. This method is accurate and straightforward, and it works everywhere in the world. However, GPS modules are expensive, slow, and a drain on batteries.

• Network-based: Cellular network operators can determine location of any phone in the network using its signal strength received by three nearby access stations (triangling). On-device smart applications (e.g., the driving directions application) can access the location data via the data network. With user authorization, the location data can also be made available to third parties from the carrier's Web site. This is an excellent approach if we need to track a large number of users from the back end (e.g., push services). However, the drawbacks are that the user must be within the cellular network coverage; the service is not yet available nationally, and the location accuracy is not as good as the GPS approach.

• Network-assisted GPS: Of course, we can combine the above two approaches: GPS devices can use network data to determine an approximate position first and then use the GPS module to get accurate corrections. This speeds up the GPS look-up process considerably.

• Local wireless network-based: Advances in new technologies will also enable location determination in local wireless networks, such as WiFi and Bluetooth networks, in the future.

• User-assisted: As the last resort, we can also ask the user to identify the closest landmark and calculate an approximate coordinate based on the known coordinate of the landmark. This works well in controlled environments like a college or company campus.

Note

The Oracle wireless application server works with wireless carrier location servers to provide SOAP interfaces for network-based location data of all devices in the network.

 

18.4.2 The Location API for J2ME

The J2ME Location API (JSR 179) is a standard Optional Package for both CDC-based and CLDC-based devices. It allows J2ME applications to access location information on any device through standard APIs regardless of the underlying technology and service provider. Table 18.2 shows the entire J2ME Location API defined in the javax.microedition.location package. It is based on the v1.0 final release (September 2003).

Listing 18.3 illustrates how to construct a simple location-based application using the JSR 179 API. For more information about the J2ME Location API and usage examples, please refer to JSR 179 documentation.

Listing 18.3. A simple J2ME Location API application

Criteria criteria = new Criteria ();

criteria.setPreferredResponseTime(20);

criteria.seVerticalAccuracy(10);

// set other criteria



LocationProvider provider =

    LocationProvider.getInstance(criteria);



// The StepTracker's locationUpdated() method

// will be called every 1 second until the 100th second.

// The passed location data cannot be more than 2 seconds old.



StepTracker tracker = new StepTracker ();

provider.setLocationListener(tracker, 1, 100, 2);



// Add the collision handling logic. The CollisionHandler's

// proximityEvent() method is called when the device

// enters the 0.5 meter radius of either coord1 or coord2



Coordinates coord1 = new Coordinates(lat1, long1, alt1);

Coordinates coord2 = new Coordinates(lat2, long2, alt2);

CollisionHandler collision = new CollisionHandler ();

provider.addProximityListener(collision, coord1, 0.5);

provider.addProximityListener(collision, coord2, 0.5);



public StepTracker implements LocationListener {



  public StepTracker () {

  }



  // Both threads below must return immediately.

  // So, put long processes in a separate thread.



  public void locationUpdated (LocationProvider provider,

                               Location location) {

    // Do something with the new location

    // For example, update the steps on a map.

  }



  public void providerStateChanged(LocationProvider provider,

                                   int newState) {

    // Handle the state change. For example, if the

    // provider becomes unavailable, alert the user.

  }



}



public CollisionHandler implements ProximityListener {



  public CollisionHandler () {

  }



  public void proximityEvent(Coordinates coordinates,

                             Location location) {

    // Handle the collision here.

    // For example, alert the user and provide a direction

    // to move away from the collision point.

  }



  public void monitoringStateChanged(boolean isActive) {

    // Handle the state change in the provider

  }



}