perfectxml.com
 Basic Search  Advanced Search   
Topics Resources Free Library Software XML News About Us
  You are here: home »» Info Bank »» Articles » Wireless Apps: The Reality Today Tuesday, 18 September 2007
 

Back to Articles Page      

        

TechMetrix Wireless Apps: The Reality Today
 Reproduced with kind permission of TechMetrix Research External link
 Article written by: JEAN-BAPTISTE MINCHELLI, Consultant (jbminchelli@techmetrix.net)

Introduction

Wireless has been a buzzword for a little over a year now. In this short time, it has seen some of the industry's greatest technological progress (Wireless IP) and its most dramatic marketing flops (WAP over GSM), some of the biggest public crazes (i-Mode) and most crashing disappointments (WAP, again…). But it is still the word on everybody's lips today, and technologies like UMTS and GPRS look set to catapult Wireless into all our daily lives.

It is not difficult to create a Wireless application using existing resources (whatever these may be); in most cases, this involves configuration of the server followed by the appropriate developments. The first Wireless applications to be developed followed this principle; in other words, they used the resources available.

This article has three main aims:

  • To give an insight into current wireless architectures using a specific example.
  • To present the ideal future solutions.
  • To set down the factors that turn a wireless application into a real value-adder for an information system.

Today's Wireless environments

Introduction

Development of a Wireless application does not usually require any specific procedure. This means that a number of vendors have been quick to use Wireless to promote their products, although these possess no specific Wireless feature. We could mention Allaire, for example, who proudly announced their products' support for WAP; in fact, all this turns out to mean is that a few tags have been inserted.

We will see that by using standard Web technologies, it is quite possible to set up a Wireless application.

Existing environments

The environment is the non-visible part of the application; essentially, this refers to a resource which governs much of the development and operation of the application.

The first Wireless services were grafted onto existing systems which, naturally, had not been designed to integrate Wireless technology. Wireless applications therefore often cohabited with standard Web applications, quite independently; this usually involved new developments in order to make new services available.

Environment of early Wireless applications

An example of a Wireless application

Below is a simple example of a WAP application set up in a relatively conventional Web environment:

  • Web Server: Apache External link
  • Server-side scripting language: PHP External link

WAP (which stands for Wireless Application Protocol) is a specification from the WAP Forum which aims to define how applications should operate within the Wireless domain. Although a gateway is essential in the WAP protocol, it is only implemented by operators. For information, the gateway works as a link between the Wireless world and the Web (translation of requests, content coders, and so on). Therefore, only the elements mentioned above are required to set up a WAP application.

Server configuration

The application server (or the Web server) needs to be configured in order to deliver WAP content. So you need to tell the server when it must make it known that the message is a WAP message. This means specifying the MIME-types (content-type) specific to WAP. For Apache, you need to edit the httpd.conf file and add the following:

AddType text/vnd.wap.wml wml
AddType text/vnd.wap.wmlscript wmls
AddType application/vnd.wap.wmlc wmlc
AddType application/vnd.wap.wmlscriptc wmlscAddType image/vnd.wap.wbmp wbmp

The server is now able to supply WAP content. It is only essential to specify the MIME-types for static pages. Otherwise, these can be specified dynamically, as we will see later on.

Application development and testing

WAP currently uses WML (Wireless Markup Language), which is based on XML, and WMLScript, based on ECMAScript. If we compare it to a Web application, we could say that WML plays the role of HTML (document formatting) and WMLScript is like JavaScript (client-side scripting language).

Below is an example of WML:

<?xml version="1.0"?>
<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" "http://www.WAPforum.org/DTD/wml_1.1.xml">

<wml>
<card id="hello">
<p>
<do type="accept">
<go href="Hello.wmls#Display('Hello in WMLS')"/>
</do>
Hello world!
</p>
</card>
</wml>

Hello.wml

And now, here is an example of WMLScript:

extern function Display(msg)
{
Dialogs.alert(MSG);
return;
}

Hello.wmls

To test this first Wireless application, place the Hello.wml and Hello.wmls in the Web server's root folder, and then browse the page with a WAP simulator such as that offered by Phone.com External link (now OpenWave).

YoSpace Emulator

The above picture shows the result that you should then obtain. As long as your server is accessible via Internet, you should be able to access your application using any WAP phone. All you need to do is enter the relevant URL to access the resource.

We will now put together a dynamic application which generates WAP content on the fly. We will use PHP to do this. Of course, it is equally possible to use any other technology to dynamically generate documents (ASP, JSP…). Below is the source code for our example:

<?
header("Content-Type: text/vnd.wap.wml");
echo "<?xml version=\"1.0\"?>";
echo "<!DOCTYPE wml PUBLIC \"-//WAPFORUM//DTD WML 1.1//EN\"
\"http://www.wapforum.org/DTD/wml_1.1.xml\">";
?>

<wml>
<card id="hello">
<p>
<?
$word = "hello";
$word .= " world!";
echo $word;
?>
</p>
</card>
</wml>

Hello.php

It is crucial not to omit the Content-Type information from the header. It is this information that enables the different agents in the protocol to correctly process the message (gateway, browser…). The rest of the code is conventional — you insert the PHP code inside the WML code. You can therefore carry out any processes you want (database access, image generation…).

Recap

Pros

Cons

  • Uses existing structures.
  • Swift to implement.
  • Application specifically designed for Wireless devices.
  • Requires redevelopment of application.
  • Extremely costly in terms of development and maintenance.

From this rudimentary example, we can see that it is possible to build any Wireless application. But as we have already mentioned, the present case involves redeveloping applications. And since, as we know, you need one version for HDML, one for WAP, another in HTML 3.2 for PDAs, and so on, it is clear that development and maintenance costs will quickly begin to add up.

Multi-Device Wireless environments

Introduction

Web applications based on application servers offering multi-device support are tending to replace scripting languages. Although they require greater modeling work during the early phases of application development, these solutions have the advantage of being based on a single data layer. The separation of data and presentation is now the objective of these application layers. The tendency is therefore to use the new document description standards (such as XML) to achieve this. These application servers are Java-based, on the whole.

Architecture

Setting up Wireless applications is now more complex than setting up conventional Web applications.

The main difficulty can be put down to the fact that content needs to be provided for an ever-increasing number of devices. Hence, the language, protocol and interface must all be taken into account when setting up the service. The ideal development environment should therefore clearly separate content from presentation. Indeed, such an environment would mean we would not have to worry about the specific features of each device, while remembering nonetheless that these exist!

A multi-device environment must therefore be independent from:

  • The access platform: The client side of the application must be easy to implement.
  • The network and protocol: The system must be able to communicate with as many Wireless networks as possible.

The extensibility of the system is also important, as it must allow support for devices which do not yet exist.

Click here for a larger image

Technical Multi-Device Architecture

Click here for a larger image

An example of a multi-device application

Our next step will be to create a multi-device application using XML/XSL. Derived from XML meta-language, XSL is a language in its own right. Its elements and attributes are described using XML syntax. Both XSL and XSLT are W3C specifications; version 1.0 has been an official recommendation since November 16, 1999. XSLT describes the manner in which an XML document can be transformed into another XML document. An XSLT Processor is needed to carry out an XSL transformation. The processor takes an XML document and an XSL stylesheet and generates output (XML, HTML, WML…). We used the Xalan processor for the XSLT example presented in this article.


XSLT Architecture

Our XML Document:

<?xml version="1.0"?>
<Article id="tmk0600-1" language="english">
<Title>E-business : Reshaping the Application Server Market</Title>
<PubDate>June 2000</PubDate>
<Author><FirstName>Jean-Christophe</FirstName>
<Surname>Cimetiere</Surname>
<JobTitle>CEO</JobTitle>
<OrgName>Techmetrix Research</OrgName>
<Email>jcc@techmetrix.com</Email>
</Author>
<Abstract>...</Abstract>
<Sect1>...</sect1>
</Article>

Our HTML XSL stylesheet:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="html"/>
<xsl:template match="/">
<ul>
</xsl:template>
<xsl:template match="Contents/Article">
<li><font size="1" face="Verdana, Arial, Helvetica, sans-serif">
<xsl:apply-templates/>
<a>
<xsl:attribute name="href">../<xsl:value-of select="@id"/>.html
</xsl:attribute>
Read the story
</a>
</font></li><br/><Br/>
</xsl:template>
<xsl:template match="Contents/Article/Title">
<b>
<xsl:apply-templates/>
</b><Br/>
</xsl:template>
<xsl:template match="Contents/Article/Abstract">
<xsl:apply-templates/>
<Br/>
</xsl:template>
</xsl:stylesheet>

Our WML XSL stylesheet:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
<wml>
<template>
<do type="options" name="home" label="Home">
<go href="http://www.trendmarkers.com/wap/index.wml"/>
</do>
<do type="prev" name="previous" label="Back"> <prev/>
</do>
</template>
<xsl:apply-templates/>
</wml>
</xsl:template>
<xsl:template match="Contents/Article">
<xsl:variable name="filename">
<xsl:value-of select="@id"/>
</xsl:variable>
<card id="{$filename}">
<p>
<xsl:apply-templates/>
<Br/>
<anchor title="Link">
<go>
<xsl:attribute name="href">../<xsl:value-of select="$filename"/>.wml</xsl:attribute>
</go>
Read the story
</anchor>
</p>
</card>
</xsl:template>
<xsl:template match="Contents/Article/Title">
<b>
<xsl:apply-templates/>
</b>
<Br/>
</xsl:template>
<xsl:template match="Contents/Article/Abstract">
<xsl:apply-templates/>
<Br/>
</xsl:template>
</xsl:stylesheet>

From this example, we generate HTML content on the fly using a Java Servlet. Alternatively, we could have used another stylesheet to generate WML or HDML content — all you need is to have as many stylesheets as desired presentations. True, application servers offer more and more components for reading/writing XML flow, but what are really lacking are more highly developed components capable of exploiting XSLT fully and easily.

Recap

Pros

Cons

  • Ease of deployment: new services and/or media quick to implement.
  • Ease of maintenance.
  • Lengthy design phase.
  • Tricky development.

From this short example we can see that it is possible to use a single data layer (the XML document in our example) to build a multi-device Wireless application. But as we saw earlier on, to implement such applications more extensive study is required in initial phases. Not only must you have an application which can be used in Wireless, but you also need to take the particular features of each device into account.

Purpose of a Wireless application

Introduction

Wireless applications must offer some degree of utility. Although it might be useful to port an information or games service to Wireless, for a corporate site, it would be a different matter. This means that not all Internet sites will necessarily find their niche within Wireless technology; mobile services must focus on clients and information. Likewise, it is essential to take the access platform into account: while it is possible these days to do almost anything you want on Internet, possibilities are limited on PDAs and are severely restricted on WAP devices.

Specific features of each device

Functionalities

One of the undeniable advantages of Wireless is that it offers access to certain personal/professional information any time, any place. Therefore, the chances are that personal information portals (e-mail, banking service…) will have the edge over personalizable information portals (user selection of categories). The end goal is to have personal services which use geolocation. For example, the Wyndham hotel chain enables loyal customers to reserve a room (via the Web or Wireless), but also allows them to personalize it with their choice of newspapers or drinks. It will also be possible for customers to use their mobiles to directly access rooms without having to stop by the reception desk.

Personalization of an application can therefore operate on different levels:

  • Directly, via the user: selection of information modules, for example. Typically, the user makes this selection from a Web site.
  • By using user data: age, nationality…
  • By collecting data on user behavior: particular service used more than another…

Dedicated services

A Web application cannot always be ported to Wireless and vice versa, as some functionalities may only be suitable for Wireless. Usually, a Web application cannot (indeed, must not) have the same functionalities as a PDA or WAP application.


Application functionalities

Mobile services must be developed in accordance with the access platform. Devices which support WAP, for example, currently only offer limited bandwidth (between 9600 and 14400 Kbps). Even though server access is possible, this must be restricted due to the length of the response time.

The interface is without a doubt the most troublesome factor when it comes to Wireless. Many solutions aim to facilitate user input on mobile phones; for instance, some telephones complete input words using a built-in dictionary, but the number of dictionary entries is severely limited. Another solution is voice recognition, but this is only feasible if the system is powerful enough to cope with it.

Developed applications must take account of the constraints which are inherent to the access platform:

  • Online / offline
  • Screen size
  • Color
  • Ergonomics

Recap

Pros

Cons

  • Content in relation to device.
  • Best service in all circumstances.
  • Customer loyalty.
  • Collection of information on preferences and behavior of user.
  • Research required before application can be set up, for each device and service.

A Wireless application must be truly useful in order to attract the attention of users. Certain professional services are currently moving toward this. More than having access to the company intranet, as Microsoft is to offer with its Mobile Information Server, certain "emergency" services will very soon become commonplace.

Today it is possible to use a mobile to monitor a network. When the Web server stops running, for example, you can be alerted via SMS, and can then use your mobile to connect to the administration tools to set it running again. Some hospitals (in New York City, for example) have ditched the traditional notion of records. Doctors have access to patient files using their Wireless terminals. Transfer, tracking, discharge or reimbursement… every process has been speeded up. This kind of service, at present the exclusive domain of professionals, shall soon trickle down to the consumer, with the arrival of electronic wallets or other services aimed at the general public.

Conclusion

A good Wireless application is therefore a Web application that fits into the information system as a service. So it is important to rely on multi-device environments that enable new standards to be easily processed. All that will need to be done then is to add further layers to the existing applications, rather than to redevelop another independent application that would be costly to develop and not necessarily suited to the device — and therefore the user.

Wireless has often been compared to the Internet in its early days, but such superficial comparisons are not helpful. True, Wireless is also in its early days and it will evolve, just as Internet did. But the similarity ends there. What made Internet so successful was the freedom that it brought; the same cannot be said for Wireless. Even though operators today are beginning to open up their service portals, there are still no standards. WAP, GSM, WML et al should be rubbing shoulders with HTML, DHTML and soon XHTML, even XML. The diversity of the Wireless world means that the move towards multi-device solutions is inevitable, if Wireless and Web are truly to become one.

Links

I-Mode
DoCoMo - http://www.nttdocomo.com/i/ External link
Solutions
Microsoft Mobile Information Server: http://www.microsoft.com/servers/miserver/ External link
WAP
Phone.com developer forum (WML and HDML): http://developer.phone.com External link
WAP specifications- www.wapforum.org External link
Wireless
Information - http://www.allnetdevices.com External link
XSLT
Specifications - http://www.w3.org/TR/xslt External link

 

TechMetrix
 Reproduced with kind permission of TechMetrix Research External link


  

Back to Articles Page      



  Contact Us | E-mail Us | Site Guide | About PerfectXML | Advertise ©2004 perfectxml.com. All rights reserved. | Privacy