Chapter: XML and Web Services : Applied XML : Delivering Wireless and Voice Services with XML

Wireless Applications with WAP and WML

A WML Application Architecture, WML Applications, Example: A Wireless Phonebook Service with WML, WML Structure and Elements, WMLScript, Development Primer , Getting Started, Future WAP/WML Developments.

Wireless Applications with WAP and WML

This section discusses how to use a multiclient XML/XSL-based architecture to deliver Web applications to Web phones using WML. It presents the WML application architec-ture, which is used as a framework to introduce each of the components that collaborate to deliver WML Web applications. The phonebook business service is then presented as a sample business service to illustrate the delivery concepts and how to develop XML, XSL, and WML content to drive the multiclient architecture so that WML Web phones may access it.

A WML Application Architecture

The WML architecture consists of a number of major user and system components that together contribute to a system for human interaction with applications via telephony devices. Figure 21.2 shows the overall WML application architecture that is discussed in this section.

Here’s a list of the components:

Mobile user. The user of a WML-enabled Web phone.

Web phone. A wireless phone equipped with a WML-compatible browser.

Base station. A cellular base station in a wireless network that handles both voice and wireless data connections.

Telecommunications infrastructure. The telecommunications provider’s infrastruc-ture for routing and managing telephone connections.

Phone. A standard landline phone used by the phone user to receive a voice call in this example.

Phone user. A user of a standard phone who is talking with the mobile user on a standard voice call initiated from a WML session.

WAP gateway. A wireless system gateway that interfaces the WML browser to the Internet.

Multiclient pull architecture. The architecture that delivers Web applications to a variety of different types of clients. The architecture is described as “pull” because when the mobile user issues a request, he waits while the request is being processed until the response is received.

WML Applications

Just because access to wireless and telephony-based services is enabled by technologies such as WAP and WML, it doesn’t mean this is appropriate in all circumstances. It is important to realize what advantages and disadvantages these new technologies offer users and developers, and consequentially which business applications are most appropri-ate for use in this environment. As a result, it is important to review some of these bene-fits and challenges to adoption.

Advantages

Web phone access to wireless services has the following specific advantages:

Familiarity. Phones are familiar and available to people, in contrast with other wireless devices, including wireless PDAs and two-way pagers.

Multifunction client devices. Web phones can be used for wireless data as well as voice calls, although not concurrently.

Low cost. Many users already have phones capable of accessing Web applications and simply need to activate this feature in their associated service plan.

Limitations

Mainly the technology’s relative immaturity and the issues surrounding the combination of previously unrelated technologies evidence the limitations of this mode of access. In particular, the challenges include the following:

Significant security holes in the WAP protocol

Challenges to user experience due to different input paradigms

Not eyes and hands free

Small, monochrome user interface

Inconsistent WML support

Security Holes in WAP

As a WAP gateway interfaces WML requests and responses, there is a point at which the request and supporting information is unencrypted, thus opening a potential security hole in the WAP architecture.

For most WML applications, this hole is not an issue because the providers that maintain the WAP gateway provide adequate security around the gateway so that this hole is not exposed for would-be attackers to access.

However, the next release of WAP, version 2.0, has been updated to overcome this security hole.

Challenges to User Experience Due to Different Input Paradigms

Web phones use methods of input that are unfamiliar to PC users:

• Alphanumeric input using the telephone keypad to enter individual characters

Alpha entry using the “T9” system, which “guesses” at the user’s intent as she presses keypad buttons

Scrolling and “clicking” using unfamiliar handset-specific buttons

Not Eyes and Hands Free

Web phones require at least one hand as well as the attention of the user’s eyes to operate them. This issue limits the usability of Web phones for wireless data access while dri-ving, walking, or engaging in other activities that require the user’s full attention.

Small Monochrome Screen

A typical Web phone screen is approximately 1× 1 inch square and either is monochrome or has a few grayscale levels at most, thus effectively limiting the visual output of the phone to text or primitive icons only. This size of screen generally permits typically 4 lines of 15 characters per line and varies by Web phone model.

Inconsistent WML Support

Some inconsistency exists in the behavior across different models of Web phones. This is due in part to inconsistent or incomplete implementations of the WAP/WML specification or the introduction in some phones of proprietary features not supported by all phones.

The Profile of a Successful WML Application

Despite the aforementioned challenges, a number of forward-looking enterprises have embarked on the creation of WML-based applications, and some with a reasonable amount of success. As a result, a few characteristics of a successful WML application are outlined here to give the tentative WML application creator some insight into the types of business services that lend themselves well to this mode of access:

Concise input. (Selecting options from a list is preferable to keying in text input.)

Navigation requires a minimal number of steps (fewer than 10 is a starting rule of thumb).

Concise text output.

Sparing use of icon graphics.

Retrieves volatile information that is important to the user.

Information is required outside of business hours or away from the office.

Example: A Wireless Phonebook Service with WML

Regardless of the limitations of WML, there are many reasons to at least dive in and give the technology a try. The following example uses a phonebook service to illustrate WML access to business Web applications. The concepts discussed here are applicable to WML Web applications in general. This example is a common one—a user accesses a company phonebook, looks up a contact, and then calls the contact via the phone device.

Usage Scenario

This usage scenario outlines the chronological sequence of steps required to realize the goal:

The user accesses the phonebook service to get a list of contact groups.

The user selects a group to view a list of its contacts.

The user selects a contact to view the details of that contact, including phone numbers.

The user selects a phone number to call that contact.

Collaborations

The first three steps in the usage scenario each involve a separate type of request to the multiclient architecture, whereas the last step involves the Web phone using WTAI to ini-tiate a voice call directly to a phone number retrieved from the phonebook service. To support the steps, the phonebook service retrieves data, selects the proper XSL style sheet, and transforms the data into WML for delivery to the gateway. For a diagram of the architecture that is applicable for these collaborations, refer to Figure 21.1 earlier in this chapter.

Developing the Content

This section discusses how to develop the content required to power the WML phone-book service. This content is presented in the order of the steps of the usage scenario outlined previously.

Accessing the Service to Get a List of Contact Groups

The user first enters the URL of the phonebook service into the Web phone using one of the two Web phone text-entry methods discussed previously. Here’s an example:

https://www.MyDomain.com/servlet/Phonebook

Here, www.MyDomain.com is the domain of the business Web site providing the phone-book service.

The XML that is returned by the data component in response to this request appears in Listing 21.1.

LISTING 21.1 Phonebook_Empty.xml—Phonebook Service XML Empty Response

<?xml version=”1.0” encoding=”UTF-8”?>

This XML response conveys the name of the phonebook as “XYZ Inc” and the group as “None” to indicate that this phonebook XML document contains no contacts.

The XSL style sheet used by the phonebook view component to transform this XML response into WML is shown in Listing 21.2. The purpose of the style sheet is to trans-form the XML business data in the phonebook application so the data can be delivered as WML. If you need more information about using and developing with XSL, refer to Chapter 9, “Transforming XML with XSL.”

LISTING 21.2 GetListOfContactGroups_WML.xsl—The XSL Used by the Phonebook

View to Transform the XML into a WML List of Contact Groups

<?xml version=”1.0” encoding=”UTF-8”?>

<xsl:stylesheet version=”1.0” xmlns:xsl=”http://www.w3.org/1999/XSL/Transform”>

<xsl:param name=”servlet” select=”’undefined’”/>

<xsl:template match=”/”>

<xsl:text disable-output-escaping=”yes”>

<![CDATA[<!DOCTYPE wml PUBLIC “-//WAPFORUM//DTD WML 1.1//EN”

➥ ”http://www.wapforum.org/DTD/wml_1.1.xml”>]]> </xsl:text>

<wml>

<xsl:attribute name=”href”><xsl:value-of select=”$servlet”/> ➥ </xsl:attribute>

</go>

</do>

<p>

</select>

</p>

</card>

</wml>

</xsl:template>

</xsl:stylesheet>

When the XML in Listing 21.1 is transformed using the XSL in Listing 21.2, it results in the WML response shown in Listing 21.3.

LISTING 21.3 ListOfContactGroups.wml—The WML Response for a List of Contact Groups

<?xml version=”1.0” encoding=”UTF-8”?>

<!DOCTYPE wml PUBLIC “-//WAPFORUM//DTD WML 1.1//EN” ➥ ”http://www.wapforum.org/DTD/wml_1.1.xml”>

<wml>

</go>

</do>

<p>

</select>

</p>

</card>

</wml>

The output listing illustrates these characteristics of WML:

The <wml> root element common to WML documents.

The card-based paradigm. This WML document has a single card, as specified by the card element.

The <do> element, to define and accept user input. This example specifies a soft menu at the base of the Web phone screen that will have the label OK and the type

accept, meaning that when the user presses the key associated with the OK label, the Web phone will accept and submit the input.

The <go> element, to define the submission method and arguments. The example uses HTTP GET. The first argument sets the parameter with the name mode to the value selectContact, informing the phonebook view that the request is intended to get the WML page required to select a particular contact of the phonebook. The second argument sets the parameter with the name group to the value of the local WML variable named group.

The <p> element, which controls output display on the Web phone screen.

The <b> element that indicates the enclosed text should be displayed in bold font to serve as a title for the phonebook being displayed.

<select> element, which presents a list of options for the user. When the user selects an option, the form enclosed by the go element is submitted. In this case, the user is selecting the group containing the first letter of the last name of the con-tact she wishes to call.

When this WML is loaded into a Web phone, the screen appears as shown in Figure 21.3.

Selecting a Group to View a List of Its Contacts

Next, the user needs to select a group to view its contacts. In this example, we select the group [A-C] and submit the request by pressing OK. The ensuing collaborations generate the XML response in Listing 21.4.

LISTING 21.4 Phonebook_a2c.xml—The Phonebook Service XML Response for Contacts in a Selected Group

<?xml version=”1.0” encoding=”UTF-8”?>

<name>

<lastname>Ashworth</lastname>

</name>

</phone>

</phone>

</contact>

<lastname>Currie</lastname>

</name>

</phone>

</phone>

</contact>

</phonebook>

The XSL used to transform Listing 21.4 is shown in Listing 21.5.

LISTING 21.5 GetListOfContacts_WML.xsl—The XSL Used by the Phonebook View to Transform the XML into a WML List of Contacts in a Group

<?xml version=”1.0” encoding=”UTF-8”?>

<xsl:stylesheet version=”1.0” xmlns:xsl=”http://www.w3.org/1999/XSL/Transform”> <xsl:param name=”servlet” select=”’undefined’”/>

<xsl:param name=”group” select=”’undefined’”/> <xsl:template match=”/”>

<xsl:text disable-output-escaping=”yes”>

<![CDATA[<!DOCTYPE wml PUBLIC “-//WAPFORUM//DTD WML 1.1//EN”

➥ ”http://www.wapforum.org/DTD/wml_1.1.xml”>]]> </xsl:text>

<wml>

<xsl:attribute name=”href”><xsl:value-of select=”$servlet”/> ➥ </xsl:attribute>

</go>

</do>

<p>

<xsl:for-each select=”phonebook/contact”> <option>

<xsl:attribute name=”value”><xsl:value-of select=”@id”/> ➥ </xsl:attribute>

<xsl:value-of select=”name/firstname”/><xsl:text> </xsl:text> ➥ <xsl:value-of select=”name/lastname”/>

</option> </xsl:for-each>

<option><xsl:attribute name=”onpick”><xsl:value-of

➥ select=”$servlet”/>?mode=selectGroup</xsl:attribute>[Back]</option> </select>

</p>

</card>

</wml>

</xsl:template>

</xsl:stylesheet>

The WML that is generated as a result of transforming the XML in Listing 21.4 with the XSL in Listing 21.5 is shown in Listing 21.6.

LISTING 21.6 ListOfContacts.wml—The WML Response for a List of Contacts in a Group

<?xml version=”1.0” encoding=”UTF-8”?>

<!DOCTYPE wml PUBLIC “-//WAPFORUM//DTD WML 1.1//EN” ➥ ”http://www.wapforum.org/DTD/wml_1.1.xml”>

<wml>

</go>

</do>

<p>

<option value=”e5678”>Joe Ashworth</option> <option value=”e9921”>Bill Currie</option>

</p>

</card>

</wml>

As in the previous request, this output contains a single WML card element:

This card contains two child elements: do and p. The function of these elements is the same as discussed for the previous request, except in this case the form submitted by the go child element of the do element includes mode, group, and contact parameters:

The mode parameter is set to the value selectNumber, indicating that the request is to get a WML view showing details of a contact, including phone numbers, that enables the user to select a number to call. The group parameter is set with the value [A-C] passed from the previous request. Lastly, the contact parameter is set to the employee ID of the contact selected in the selection list.

The display on the Web phone for this card includes a bold line at the top with the text

XYZ Inc - [A-C]:

A selection list follows that assigns the value of the option selected to the variable named contact:

Two options for contacts in the list correspond to the two contact elements in the source XML:

<option value=”e5678”>Joe Ashworth</option> <option value=”e9921”>Bill Currie</option>

The last option in the selection list appears on the Web phone screen as the text [Back], informing the user that selecting this option causes the phonebook service to go back to the previous step:

This option enables users to drill down into a contact group to look at the contacts in that group and then navigate back to the list of contact groups to look at contacts in other contact groups.

When this WML is loaded into a Web phone, the screen appears as shown in Figure 21.4.

Selecting a Contact to View Its Details

In this step, the user selects a contact from the list in order to see the details of that con-tact. In this example, the mobile user selects the contact with the name Bill Currie. The XML response to this request from the phonebook data servlet is shown in Listing 21.7.

LISTING 21.7 Phonebook_e9921.xml—The Phonebook Service XML Response for Contact Details

<?xml version=”1.0” encoding=”UTF-8”?>

<name>

<lastname>Currie</lastname>

</name>

</phone>

</phone>

</contact>

</phonebook>

Note in this XML that the group attribute of the phonebook element has the value e9921, indicating that this particular XML document contains the phonebook details for only one contact. The contact is Bill Currie, and two phone numbers are listed: a work phone number and mobile phone number. The XSL used to transform this XML is shown in Listing 21.8.

LISTING 21.8 GetContactDetails_WML.xsl—The XSL Used by the Phonebook View to Transform the XML into WML Contact Details

<?xml version=”1.0” encoding=”UTF-8”?>

<xsl:stylesheet version=”1.0” xmlns:xsl=”http://www.w3.org/1999/XSL/Transform”> <xsl:param name=”servlet” select=”’undefined’”/>

<xsl:param name=”group” select=”’undefined’”/> <xsl:template match=”/”>

<xsl:text disable-output-escaping=”yes”>

<![CDATA[<!DOCTYPE wml PUBLIC “-//WAPFORUM//DTD WML 1.1//EN” ➥ ”http://www.wapforum.org/DTD/wml_1.1.xml”>]]>

</xsl:text>

<wml>

<p>

<xsl:for-each select=”phonebook/contact[1]”> <b>XYZ Inc - <xsl:for-each select=”name”>

<xsl:value-of select=”firstname”/> <xsl:text> </xsl:text> <xsl:value-of select=”lastname”/>

</xsl:for-each> </b>

<xsl:attribute name=”value”><xsl:value-of select=”areacode”/> ➥ <xsl:value-of select=”number”/></xsl:attribute>

<xsl:value-of select=”@type”/> <xsl:text> - </xsl:text> <xsl:value-of select=”areacode”/> <xsl:text> </xsl:text> <xsl:value-of select=”number”/>

</option> </xsl:for-each> <option>

<xsl:attribute name=”onpick”><xsl:value-of select=”$servlet”/>

➥ ?mode=selectContact&group=<xsl:value-of select=”$group”/> ➥ </xsl:attribute>[Back]</option>

</select> </xsl:for-each>

</p>

</card>

</wml>

</xsl:template>

</xsl:stylesheet>

The WML that is generated as a result of transforming the XML in Listing 21.7 with the XSL in Listing 21.8 is shown in Listing 21.9.

<?xml version=”1.0” encoding=”UTF-8”?>

<!DOCTYPE wml PUBLIC “-//WAPFORUM//DTD WML 1.1//EN”

➥ ”http://www.wapforum.org/DTD/wml_1.1.xml”> <wml>

<p>

<b>XYZ Inc - Bill Currie</b> <select name=”number”>

<option value=”8132367856”>Work - 813 2367856</option> <option value=”8139835646”>Mobile - 813 9835646</option>

</select>

</p>

</card>

</wml>

This WML is again similar to other previously presented WML documents, with a few differences highlighted here. The soft menu at the bottom of the Web phone screen is assigned the label “Call” to indicate that the user is not only making a phone number selection but is also initiating a call to that number:

The URL to which the Web phone navigates once the phone number selection is made uses the WTAI interface in the Web phone to initiate a voice call, as indicated by the pro-tocol of the URL, “wtai”. The wp part of this URL specifies that the WTAIPublic func-tion library is to be used, and the mc part specifies that the makeCall function in the WTAIPublic library is to be invoked. Lastly, the $(number) part of the URL passes the phone number, including the area code, as an argument to the makeCall function. The value of this number variable is set just prior to navigating to this URL when the user selects a phone number in the selection list in the same WML card:

For more information on the WTAI syntax and other available functions, see the WTAI specification at the WAP Forum (Wapforum.org).

When this WML is loaded into a Web phone, the screen appears as shown in Figure 21.5.

Selecting a Phone Number to Call a Contact

When the user navigates to a phone number and presses the “Call” button, the WAP/WML wireless data connection from the Web phone is dropped and a voice connection through the public telephone network is established by the WTAI makeCall function.

WML Structure and Elements

This section briefly reviews the key elements of WML, including all the elements used in the preceding example. For a complete, detailed WML specification, see the WAP Forum (www.wapforum.org).

Figure 21.6 shows a high-level graphical view of the structure of a WML document.

This view was derived from the WML 1.1 DTD ( www.wapforum.org/DTD/wml_1.1.xml).

Table 21.1 provides descriptions of the various elements of WML.

TABLE 21.1 WML Elements with Descriptions

WMLScript

WMLScript is a script language used to provide programmatic control of mobile devices. WML is an extended subset of ECMAScript (formerly known as JavaScript), which has been modified to better support low-bandwidth communication and thin clients. For example, client-side scripting can be used to check the validity of user input, thus enabling errors or omissions to be detected prior to incurring the cost of a network request. This has benefits for both the client and server. The client experiences a faster response time and lower wireless network usage and associated cost. The server, on the other hand, experiences fewer bad or invalid requests, thus improving its signal-to-noise ratio and enabling it to scale to handle more clients. WMLScript can also enable the user to access facilities on the device—for example, in order to store a phone number in an address book on the device.

Development Primer

This section provides some general tips and outlines common pitfalls in WAP/WML ser-vice development. It also provides some references to complement those already made in the previous discussion to assist you with getting started in WML development.

Focusing WML Responses

WAP/WML services impose restrictions on the length of content returned in a single response. Some limits are as low as 512 bytes. Although some systems have a higher limit on the length of the content (rather than the length of content per card), the 512 figure serves a lowest-common denominator with which systems should conform.

Consequently, it is necessary to focus information delivered to the client. For example, this can be achieved through a multistep hierarchical search, such as that used in the phonebook example presented previously. When responses exceed the limit, the mobile device typically returns an error rather than the subset of content that falls within the limit. Therefore, it is desirable to stay well within this limit because straying outside will cause a fatal application error.

Caching WML Responses

WAP gateways may cache WML responses. Sometimes, a user may expect a given request made previously to cause a hit on the business Web site, but this might not be the case due to the cached responses. This can be confusing and frustrating during develop-ment, testing, and demonstrations. Most Web phones provide a menu option to flush the cache and, in effect, force a request to hit the target business Web site.

Setting the WML MIME Content Type

In order for a Web server to serve a static WML page with the correct MIME content type, it must be configured to associate the *.wml extension with the MIME content type text/vnd.wap.wml. Failing to make this configuration will cause an error if a Web phone tries to access content via that Web server. Similarly, the *.wmls extension for WMLScript documents should be associated with the MIME content type text/vnd.wap.wmlscript. If BMP or WBMP images are used in WML content, the *.bmp and *.wbmp extensions should be associated with the image/bmp and image/vnd.wap.wbmp MIME content types, respectively.

Testing Usability

There is no substitute for extensive usability testing during the conceptual and prototyp-ing phase of development to help identify subtle but potentially fatal usability issues. Where end users may not yet have Web phones or a service being tested is not yet live, it may be possible to conduct some preliminary usability testing with Web phone emula-tors, such as UP.SDK, as discussed previously in this section. However, there is no substitute for the real testing that should incorporate the real Web phones and live wireless network.

Getting Started

The Openwave Developer Program (developer.openwave.com) provides downloads of SDKs that may be used to start HDML and WML development and testing. This site also provides excellent training material and reference documentation as well as forums for the developer community.

For J2ME-enabled Web phones and other handheld devices, KBrowser from 4thpass (www.4thpass.com) is a microbrowser capable of accessing WML and WMLScript services.

Future WAP/WML Developments

Any system intended to live for more than a few years should be designed with sufficient flexibility to accommodate future changes. Although all changes cannot be anticipated, there are some that can. These expected future developments should be used to stress-test any design to ensure that it can adapt to meet future changes.

WML 2 and XHTML Basic

In WAP 2.0, WML converges with the core of XHTML, known as XHTML Basic, a stan-dard overseen by the W3C. WML 2.0 is a markup language that extends the syntax and semantics of XHTML Basic and CSS Mobile Profile with the unique semantics of WML 1.0. HDML and cHTML (Compact HTML) are also both converging to XHTML Basic. XHTML is designed for Web clients such as mobile phones, PDAs, pagers, and set-top boxes that cannot handle the full XHTML markup language. One of the goals of XHTML Basic is to be a common markup language understood by a variety of Web clients. This promises to simplify the development of content for multiclient architec-tures. However, even in the event that XHTML Basic is wildly successful in becoming the de facto standard markup language for mobile devices in the long term, separate XSL transformations in a multiclient XML/XSL-based architecture will still be required for each client type (for example, to tailor content for different device capabilities).

3G Wireless Networks

Third-generation packet-based wireless networks promise to deliver higher rates, concur-rent voice and wireless data services, and “always-on” wireless connectivity with data rates up to 2Mbps. These higher bandwidths and simultaneous voice and data channels promise to deliver more powerful multimedia services and a richer, more interactive user experience. When these more powerful networks are available and the number of clients capable of using them becomes significant, demand on multiclient architectures deliver-ing Web applications to these clients will increase. Therefore, when you’re designing multiclient architectures, it is wise to build into them the ability to scale to meet this future growth in demand.

Multimode

Currently, wireless services do not support voice and wireless data concurrently. However, as wireless networks, devices, and markup languages evolve and become avail-able, wireless data and voice services will converge to enable future multimode services. For example, this will enable wireless data services, such as those currently driven by WML, to work in parallel with voice services, such as those currently driven by VoiceXML, in a hybrid multimode service. At the markup language level, the Synchronized Multimedia Integration Language (SMIL, pronounced smile) is a new stan-dard overseen by the W3C that promises to provide a way to coordinate such hybrid or multimode services. SMIL is an XML-based markup language and may be easily gener-ated from the multiclient XML/XSL-based architecture presented in this discussion, enabling it to easily adapt to deliver these new hybrid multimode services when client devices become able to handle them.

Wi-Fi (IEEE 802.1lb) and Bluetooth

Wi-Fi (standards.ieee.org/wireless) and Bluetooth (www.bluetooth.com) are both short-range wireless networks that promise to deliver Web applications to a variety of mobile devices, including PDAs and laptops in particular. Because these networks do not specify content types or markup languages to be used at the application level, they will not have a direct impact on multiclient XML/XSL-based architectures.

Study Material, Lecturing Notes, Assignment, Reference, Wiki description explanation, brief detail

XML and Web Services : Applied XML : Delivering Wireless and Voice Services with XML : Wireless Applications with WAP and WML |