Client Protocols and Languages

XML

XML is a set of rules for designing text formats that allow you to structure data. Examples of structured data include presentations, spreadsheets, address books, financial transactions, maps, and driving directions. Using XML makes it easy for a software application to create, organize, and share information with other software applications. Furthermore, XML is extensible, it is platform independent, and it supports internationalization.

How Does XML Work?

Similar to HTML, XML uses tags (words delimited by < and >) and attributes (such as name ="value"). Unlike HTML, which specifies what tags and attributes mean and how they will be represented in a Web browser, XML uses tags to delimit data and leaves the interpretation of the data to the application. Also unlike HTML, XML is case sensitive and has a very rigid set of syntax rules.

Specifying a set of rules for structuring a certain type of data is done in a document type definition (DTD). There are specific DTDs for structuring geography data (GML), voice data (VXML), and countless other types of data. The family of XML technologies also includes cascading style sheets (CSS), Extensible Stylesheet Language (XSL), and XSL Transformations (XSLT). CSS are used to attach style elements (fonts, spacing, etc.) to structured data to separate content from presentation. CSS works the same with XML as it does with HTML. XSL is a language for expressing style sheets, and XSLT is a language for transforming XML documents into other XML documents. The value of using style sheets in this manner is that spatial and positioning data retrieval can operate without specific knowledge of how the data will be employed by the location server client.

An engineering team tasked with building a location services infrastructure could be split into core spatial operations, core positioning operations, and application delivery operations. Application delivery operations could generate routing queries to the spatial engine and positioning queries to the positioning engine without having to know anything about their underlying algorithms. The application delivery operations could then package the results in a standard XML format, customized for the intended target client using CSS and XSL/XSLT. If data needs to be sent to the client in GML, the GML style sheet is employed and data is transformed into GML. If data needs to be sent to the client in WML, the WML style sheet is employed and data is transformed into WML. This modular approach allows spatial operations to focus on fast, reliable spatial data retrieval without worrying about delivering data to the client application. The same is true for the positioning operations team. In this environment, the client development team knows that information will be received according to the agreed XML specification, and can proceed with development in parallel using dummy data.

SOAP

Based on XML, SOAP is a lightweight protocol for exchanging information in a distributed, decentralized environment. SOAP is used for application-to-application communication, and consists of three parts : an envelope that defines a framework for describing what's in a message and how to process it, encoding rules for expressing instances of application-defined datatypes, and a method for representing remote procedure calls and responses.

SOAP enables more flexible mobile location service applications by making servers more modular and not relying on a proprietary interface. SOAP is typically used in conjunction with HTTP. Example 10.1 shows a SOAP request and response loosely based on the Standard Location Immediate Report DTD defined in LIF's Mobile Location Protocol (see Appendix C for details).

Example 10.1 SOAP Message Embedded in HTTP Request.

 POST /GetVehicleLocation HTTP/1.1 Host: www.mobilelbs.com Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAPAction: "Some-URI" <SOAP-ENV:Envelope  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"  SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">  <SOAP-ENV:Body>    <m:GetLastPosition xmlns:m="Some-URI">      <VehicleID>1010101010</VehicleID>    </m:GetLastPosition>  </SOAP-ENV:Body> </SOAP-ENV:Envelope> 

Example 10.2 shows a sample response HTTP message with the SOAP message as the payload.

Example 10.2 SOAP Message Embedded in HTTP Response.

 HTTP/1.1 200 OK Content-Type: text/xml; charset="utf-8" Content-Length: nnnn <SOAP-ENV:Envelope  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"  SOAP- ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>  <SOAP-ENV:Body>  <m:GetLastPositionResponse xmlns:m="Some-URI">  <pos>   <msid>461018765711</msid>   <pd>    <time utc_off="+0300">20000623110205</time>    <shape>     <circle>      <point>       <ll_point>        <lat>37.789200</lat>        <long>-122.415700</long>       </ll_point>      </point>      <rad>15</rad>     </circle>    </shape>   </pd>  </pos>  </m:GetLastPositionResponse>  </SOAP-ENV:Body> </SOAP-ENV:Envelope> 

WAP and WML

WAP has been developed by an international group of wireless infrastructure providers that include Nokia, Ericsson, Motorola, Openwave, Microsoft, and Palm. WAP is designed for the markup and presentation of wireless content on small-form factor devices, such as mobile phones and handheld devices. The WAP standard defines a very sophisticated environment for wireless applications (see Figure 10.10). At its base is the underlying bearer network of the mobile operator. Built on top of the bearer network layer is the transport layer, which is based on TCP/IP's UDP protocol and is designed to address some wireless-data-specific issues such as latency. Above the transport layer are the Wireless Transport Layer Security (WTLS) and the Wireless Transaction Protocol (WTP) layers that enable secure transactions between hosts . Above the WTP layer is the Wireless Session Protocol (WSP), which provides both a connection-oriented and connectionless service that uses WDP. Relying on WSP is the WML, which uses WSP to facilitate communications between the server and the mobile device.

Figure 10.10. Wireless Application Protocol Reference Model. 2002 Open Mobile Alliance.

WAP is a very efficient standard, and has been designed specifically for wireless use. Accordingly, it is much more efficient than Web-based technologies. WML content is compiled before communications with a client take place, and WML content is generally more compact than HTML content. WTP and WSP are also more efficient than TCP/IP or HTTP.

Development using WAP uses the paradigm of a deck of cards rather than the paradigm of individual pages used in the World Wide Web. A card is a grouping of user interface elements that is presented as a single screen on a mobile device, although scrolling might be required, depending on the contents of the card. A deck is a collection of cards, or a WML file. The benefit of structuring mobile applications this way is that it reduces network traffic and compensates for inherent problems in wireless networks, such as service availability.

WAP was heavily hyped in 1999 and 2000 ”with a general disappointment when users failed to flock to services. This failure is part marketing and business model failure and part technology failure. Many Web applications were translated directly to WAP applications without considerable thought as to whether they made sense. Mobile applications must allow users to get information and handle problems quickly. Interfaces are fundamentally different. They must be simple enough to be used in one hand while the user is walking or engaged in another activity. Applications designed with mobility in mind, applications that are heavily personalized and enhanced with location-based information, and applications that solve real user problems are the applications that will be highly successful. Of course, a legitimate business model is also needed. Possible models include transaction-oriented or ticket-based applications that pay the provider a commission for facilitating them.

Compounding the problems with WAP was the consensus among mobile operators to control the contents of the WAP start page, often selling placements on this page to the highest bidder. Most mobile operators do not allow you to create your own WAP start page, and even worse , they often block WAP sites that you might actually want to use (e.g., Yahoo!) for fear of competition. This is a problem, particularly in Europe. Few of the principles that made the Internet a wildly successful new paradigm were followed with the launch of WAP, so it is no surprise that WAP has struggled.

Voice and VoiceXML

Driver distraction problems and the challenges of inputting data with a mobile phone interface like WAP have generated a significant amount of interest in voice-based user interfaces. These interfaces are comprised of voice-recognition technology and prerecorded messages. The best and most natural-sounding voice user interfaces use prerecorded speech segments whenever possible to create a natural-sounding dialogue.

It is easy to underestimate the substantial amount of work required to deliver a high-quality voice interface. In the mobile location services environment we have been discussing, a voice user interface would require additional software integration in both the client and the server components of a location services infrastructure. The client is a voice browser that the user connects to via a mobile phone connection. This could be by dialing a specific phone number, or pressing a button on a mobile phone system or in-vehicle navigation system. The voice browser processes VXML, the markup language for structuring voice data. Input is sent to a speech recognition engine, which uses a system such as Nuance's, modified by pronunciation and grammar dictionaries and acoustic models that have been tuned for the target audience. Output is sent to an audio processing engine, which programmatically sequences and streams audio files back to the user.

VXML is designed to allow developers to create audio dialogues that utilize speech recognition, digitized audio, telephony, speech recording, and synthesized speech. The major goal of VXML is to provide the advantages of Web-based development and content delivery to voice applications. Example 10.3 shows part of a VXML document that processes a request for driving directions.

Example 10.3 Sample of a VXML Document.

 <form id="get_from_and_to_cities"> <grammar src="http://sample.mobilelbs.com/grammars/from-to.grxml"    type="application/grammar+xml"/>  <block>    Welcome to the Driving Directions By Phone.  </block>  <initial name="bypass_init">   <prompt>    Where do you want to drive from and to?   </prompt>   <nomatch count="1">     Please say something like "from London to Oxford".   </nomatch>   <nomatch count="2">     I'm sorry, I still don't understand.     I'll ask you for information one piece at a time.     <assign name="bypass_init" expr="true"/>     <reprompt/>   </nomatch>  </initial>  <field> ...etcetera </form> 

Voice-enabling mobile location service applications requires a number of highly specialized processes, mainly involving prerecording city, street, and POI names in the map data you plan to use. This is a time-consuming task that must be repeated with every map database update to reflect the latest changes. It is also necessary in many cases to tune and trim the route explication (or the text of the driving directions) to eliminate unnecessary detail that confuses users in a voice system. Voice interfaces are expensive to develop and maintain, but when they are designed correctly, they can be highly effective. Detailed technical information on VXML can be found at the VoiceXML Forum (http://www.voicexml.org).

Java and J2ME

What Is J2ME?

J2ME is an end-to-end platform developed by Sun Microsystems to allow the development of network-enabled applications and products for the consumer and embedded systems markets. J2ME technology consists of a Java virtual machine and a suite of interfaces that are designed to provide customized run-time environments for embedded and consumer electronics.

J2ME has configurations specifically designed for different types of devices. The Connected Limited Device Configuration (CLDC) is designed for small, resource-constrained devices such as mobile phones and mainstream digital organizers. CLDC is built around Sun's K Java virtual machine (KVM), and is suitable for devices that have 16- or 32-bit reduced instruction set computer (RISC)/complex instruction set computer (CISC) microprocessors and as little as 160 KB of available memory. For higher end devices such as smart communicators , PDAs, and set-top boxes, Sun provides the Connected Device Configuration (CDC). CDC utilizes Sun's CVM Java virtual machine and supports devices with at least a 32-bit microprocessor and 2 MB of available memory.

Because device interfaces can be highly proprietary, a J2ME configuration relies on a device-specific profile to provide supplementary APIs such as user interface, database, and device-specific networking (see Figure 10.11). The APIs of the profile are layered above the low-level system APIs of CLDC or CDC. CLDC uses a profile specification called Mobile Information Device Profile (MIDP) and CDC uses a profile specification called Foundation. Applications built to run on a device supporting MIDP are called MIDlets, and are similar to applets in some ways. MIDPs are device specific, but MIDlets written to run on one MIDP will run on other MIDPs, providing application portability across a variety of mobile devices. CDC's Foundation profile is actually a subset of Java 2 Standard Edition (J2SE), with GUI-specific dependencies of the Abstract Windowing Toolkit (AWT) removed and various other modifications to tune the APIs for mobile devices.

Figure 10.11. J2ME Configurations and Profiles.

When to Use J2ME

Developing a mobile location service application using J2ME provides you with tremendous flexibility and ability to deploy on multiple client devices. However, with this flexibility comes substantially more work than that required for an application that leverages an existing environment such as WAP. WAP and J2ME are both valuable and have different uses. WAP allows very thin client applications that are optimized for wireless delivery. J2ME allows thicker client applications with more sophisticated logic and the ability to run in "offline" mode.

It makes sense to use a technology like J2ME when necessary to overcome user interface and technology limitations of existing wireless client technology. Network-centric applications that do not require the advanced capabilities of J2ME, such as its security, are better developed using WAP's WML and Wireless Markup Language Script (WMLS).

Additional technical details and specifications are available from Sun at http://www.java.sun.com/j2me/.

BREW

What Is BREW?

BREW is Qualcomm 's Binary Runtime Environment for Wireless, an application execution environment for mobile devices. BREW is a thin, fast environment that runs C/C++ applications.

BREW uses an event-driven architecture similar to Microsoft Windows or UNIX X-Windows, and efficiently uses RAM and persistent memory by loading and unloading objects on an as-needed basis. All text is managed as Unicode, and BREW provides a set of core classes that allow applets built in the BREW environment (note that these applets are not the same as Java applets). These core classes include time/timers, notifications, networks/sockets, HTTP, download/billing, display, graphics, and sound.

When to Use BREW

Device-dependent applications can gain an advantage by leveraging the high performance of BREW. It is important to keep in mind, though, that BREW is very Qualcomm-specific and is biased toward network chips. For high-level business applications, J2ME and Java might be a better choice for multidevice support. It is, of course, possible to run a Java virtual machine under BREW and split application development between high-level business logic running in Java and low-level device drivers and system logic running under BREW. Additional information and technical specifications are available from Qualcomm at http://www.qualcomm.com/brew.