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:
give an insight into current wireless architectures using
a specific example.
present the ideal future solutions.
set down the factors that turn a wireless application
into a real value-adder for an information system.
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.
will see that by using standard Web technologies, it is
quite possible to set up a Wireless application.
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.
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
of early Wireless applications
example of a Wireless application
is a simple example of a WAP application set up in a relatively
conventional Web environment:
Web Server: Apache
scripting language: PHP
(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.
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.wmlscript wmls
AddType application/vnd.wap.wmlc wmlc
AddType application/vnd.wap.wmlscriptc wmlscAddType
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.
development and testing
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
is an example of WML:
<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML
<go href="Hello.wmls#Display('Hello in WMLS')"/>
now, here is an example of WMLScript:
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
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
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:
echo "<?xml version=\"1.0\"?>";
echo "<!DOCTYPE wml PUBLIC \"-//WAPFORUM//DTD
$word = "hello";
$word .= " world!";
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…).
Application specifically designed for Wireless devices.
Requires redevelopment of application.
costly in terms of development and maintenance.
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.
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.
up Wireless applications is now more complex than setting
up conventional Web applications.
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
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.
extensibility of the system is also important, as it must
allow support for devices which do not yet exist.
here for a larger image
example of a multi-device application
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.
<Article id="tmk0600-1" language="english">
<Title>E-business : Reshaping the Application
HTML XSL stylesheet:
<li><font size="1" face="Verdana,
Arial, Helvetica, sans-serif">
Read the story
WML XSL stylesheet:
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<do type="options" name="home"
<do type="prev" name="previous"
Read the story
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.
Ease of deployment: new services and/or media quick
Lengthy design phase.
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
of a Wireless application
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.
features of each device
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.
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…
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
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.
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.
applications must take account of the constraints which
are inherent to the access platform:
- Online / offline
- Screen size
Content in relation to device.
service in all circumstances.
of information on preferences and behavior of user.
required before application can be set up, for each
device and service.
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.
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.
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.
DoCoMo - http://www.nttdocomo.com/i/
Microsoft Mobile Information Server: http://www.microsoft.com/servers/miserver/
Phone.com developer forum (WML and HDML): http://developer.phone.com
WAP specifications- www.wapforum.org
Information - http://www.allnetdevices.com
Specifications - http://www.w3.org/TR/xslt