A Technology Analysis on Mobilizing Corporate Data
by
Ambrose Kam
B.S. Mechanical Engineering (1994)
State University of New York at Buffalo
M.Eng. Mechanical Engineering (1995)
Cornell University
Submitted to the System Design and Management Program
in Partial Fulfillment of the Requirements for the Degree of
Master of Science in Engineering and Business Management
at the
Massachusetts Institute of Technology
December 2001
2001 Massachusetts Institute of Technology
All Rights Reserved
Signature of Author
System Design and Management Program
January 5, 2001
Certified by
Stuart E. Madnick
John Norris Maguire Professor of Information Technology
& Leaders for Manufacturing Professor of Management Science
MIT Sloan School of Management
Thesis Supervisor
Accepted by
Steven D. Eppinger
LFM/SDM Co-Director
GM LFM Professor of Management Science and Engineering Systems
Accepted by
Paul A. Lagace
'JFM/SDM Co-Director
Professor of Aeronautics & Astronautics and Engineering Systems
OF TECHNOLOGY
JUL 18 2002
UIBRARIES
MW
A Technology Analysis on Mobilizing Corporate Data
by
Ambrose Kam
Submitted to the System Design and Management Program
on January 5, 2001 in Partial Fulfillment of the
Requirements for the Degree of Master of Science in
Engineering and Business Management
ABSTRACT
To succeed in today's competitive business environment, companies have to rely on
cutting-edge information technologies (IT) to improve employee productivity, and
enhance customer satisfaction and loyalty. By making corporate data accessible to the
employees, managers or business partners anytime and anywhere, companies can make
quick but informed decisions to seize any business opportunities. Mobile enterprise
business applications (EBAs) will shortly be reality in a rapidly evolving world of
enterprise applications, E-commerce, and wireless mobile devices, such as personal
digital assistants (PDAs) and digital cellular phones, which would take advantage of the
soon-to-be-deployed 3G wireless networks. The change will be revolutionary, and the
stakes are high as there are many potential risks as well as opportunities. Companies,
which see through the hypes, and are capable of tweaking the mobile EBAs to fit their
business model, will benefit the most.
The main theme of this thesis is to explore different ways to access the corporate
application (such as consumer relationship management and enterprise resource
planning) data wirelessly with handheld computers and cell phones. In addition, it
illustrates what companies could do to exploit the latest wireless technologies as a
medium. This thesis compares and contrasts the use of Extensible Markup Language
(XML), Web wrapping techniques and other technologies to better extract corporate
backend data. Specifically, it discusses what strategies companies should adopt towards
XML as it becomes a widely accepted standard of exchanging data among companies.
We will also explore whether companies should concentrate on building a wrapper to
translate the corporate data to any type of handheld devices in the short term, or they
should migrate to the XML technologies gradually now.
Thesis Supervisor: Stuart Madnick
Title: John Norris Maguire Professor of Information Technology & Leaders for
Manufacturing Professor of Management Science
2
Acknowledgement
I would like to sincerely thank my thesis advisor, Dr. Stuart Madnick and his research
team at MIT for their insightful advice and for providing this unique research
opportunity. Dr. Madnick's profound knowledge and years of practices in the
Information Technology field fostered me with a new level of understanding. Without
Dr. Madnick's constant guidance and support, this thesis effort would not be possible.
My thanks are also extended to all my SDM colleagues for sharing their experience
throughout the program and offering constant encouragement. I have learned as much
from them as I have from the resourceful professors at MIT.
Finally, I would like to deeply thank my family and most importantly, my wife for their
moral support during my study at MIT. I understand that spending the Christmas and
New Year holidays reviewing a long thesis is not the ideal way to spend a vacation, but
my brother, Paul, has done just that. My wife, Christie, has sacrificed what little of her
leisure time to look at my thesis as well, and given me great comments even though it
drove her to bang her head against the wall a few times by reading it. She must be the
most patient woman in the world for putting up with me over the two long years of the
SDM program.
3
TABLE OF CONTENTS
I
Introduction .............................................................................
.8
1.1 EBAs, e-Business, and the Mobile Digital Device..............................13
1.2 Key Driving Factors of Mobile EBAs..........................................
14
1.3 Mobile EBAs and Mobile Devices: PDAs, and Digital Phones............. 15
1.4 Mobile Internet Infrastructure...................................................
16
1.4.1 Data Transformation and Loading........................................
17
2. Overview of Current Wireless Technology Developments......................
21
2.1 Personal Digital Assistant (PDA)...............................................
21
2.2 C ell Phone ...........................................................................
22
2.3 Wireless Network Development...................................................24
2.3.1 2.5G Technologies........................................................25
2.3.2 3G Technologies..........................................................
26
2.4 Other Limitations for Mobile Devices........................................30
2.4.1 Screen Size ................................................................
30
2.4.2 User Input Interface / Ease of Use.....................................30
2.4.3 Security....................................................................
31
2.4.4 B attery Life..................................................................
32
2.4.5 Other Obstacles Facing the Wireless Industry........................32
3
WA P Issues............................................................................
3.1 Introduction to WAP...............................................................34
3.1.1 Business Strategy........................................................35
3.1.2 Market Strategy..........................................................35
3.1.3 Technology Strategy ....................................................
3.2 WAP Protocol Stack.............................................................37
3.3 WAP Architecture...............................................................39
3.4 Wireless Markup Language (WML)..........................................
3.5 Alternatives to WML/WAP ....................................................
3.5.1 i-Mode & cHTML.........................................................44
3.5.2 WAP vs. i-Mode........................................................
3.6 Final Thoughts on WAP........................................................
34
36
40
44
45
47
4
49
Building MultipleVersions of Company Web Site..............................
4.1 Perils of Multiple Version Approach...........................................49
4.2 Other Alternatives...............................................................50
5
M-Business Enablers/Wireless Application Service Providers (WASP)........ 53
5.1 Wireless Application Service Providers........................................
53
56
5.2 T ranscoding .........................................................................
5.2.1 Transcoding Technology.................................................
56
5.2.2 General Tips for Supporting Transcoding Approach...............57
5.2.3 Final Thoughts on Transcoding.......................................
58
5.3 Web Wrapping..................................................................59
4
5.3.1
5.3.2
6
7
8
9
How does a Web Wrapper Work?............. . . . . . . . . . . . . . . . . . . . . . . ..60
Final Thoughts on Web Wrapping.....................................61
XML......................................................................................
6.1 X M L 10 1.........................................................................
6.2 Reading and Writing XML Documents.........................................66
6.3 Displaying XML.................................................................66
6.3.1 Cascading Style Sheets (CSS)........................................
6 .3 .2 X S L ..........................................................................
6.4 Business Benefits from XML....................................................
6.5 Other Uses of XML...............................................................
6.6 Disadvantages of XML..........................................................71
6.7 Final Thoughts on XML........................................................
62
62
X H T M L ................................................................................
7.1 Modularization Design..........................................................73
7.2 Benefits of Using XHTML over HTML.....................................
7.3 Final Thoughts for XHTML...................................................
73
Java 2 Micro-Edition (J2ME) ......................................................
8.1 J2ME Technologies.............................................................
8.2 J2ME Deployment...............................................................83
8.3 Hurdles for J2ME...............................................................
8.4 W A P vs. J2ME ....................................................................
8.5 Final Thoughts on J2ME........................................................
80
80
67
68
69
70
71
76
78
84
84
86
C onclusion ...............................................................................
87
9.1 Know the Users Needs..........................................................87
9.2 Know the Technology...........................................................
88
9.2.1 Data Transformation and Loading.....................................88
9.3 M obilize Now !......................................................................89
Appendices...................................................................................95
Appendix I: Listing 1 WML Java Servlet Example..............................95
Appendix II: Listing 2 WML Java Servlet Example............................ 97
G lo ssary ........................................................................................
R eferen ces......................................................................................10
99
5
5
LIST OF FIGURES
Fig. 1.1 Loading Mobile Data Directly from Operational Databases................18
Fig. 1.2 Mobile Data Replication..........................................................
19
Fig. 2.1 Typical Cell Phone Network.....................................................
22
Fig. 2.2 S-Curve for Cell Phone Network Development..............................
24
Fig. 2.3 Wireless Network Upgrade Path..................................................
25
Fig. 2.4 Crossing the Chasm.............................................................
28
Fig. 3.1 The WAP Protocol Stack........................................................
38
Fig. 3.2 The WAP Architecture..........................................................
39
Fig. 3.3 Typical WAP Network Infrastructure............................................
40
Fig. 4.1 Transcoding Technique..........................................................
50
Fig. 4.2 Web Wrapping Technique.........................................................
51
Fig. 4.2 XML Transformation............................................................
52
Fig. 6.1 DTD Output Options.............................................................
65
Fig. 6.2 Viewing a XML Document in Internet Explorer 5............................. 67
Fig. 8.1 The Architecture of Configurations and Profiles............................ 82
6
LIST OF TABLES
Table
Table
Table
Table
Table
Table
1.1
2.1
3.1
3.2
7.1
9.1
Data Synchronization Summary................................................20
Limitations of Mobile Device.................................................33
41
WML Data Types...............................................................
46
cHTML Language Reference.................................................
Three Flavors of XHTML Document Type Definitions.....................74
90
Technology Summary Table.................................................
7
Chapter 1 Introduction
Today, corporate application (such as enterprise resource planning [ERP] and consumer
relationship management [CRM]) data can only be accessed in a "static" form.
Employees can access the data only if they have established a physical connection to the
corporate network. With the introduction of Virtual Private Network (VPN), employees
can access their corporate network at home, in a hotel room or wherever they can find a
dial-up connection. Such convenience is certainly welcomed by the employees, but
mobility is still limited since most users need to have Ethernet' or phone line connections
every time they want to get connected. Another issue is data perishability. One may
suggest that it is easier and more cost-efficient to download data onto a portable medium
like diskettes or CD-Rs than to have a corporate network reach-back capability.
However, the problem is that corporate data like inventory levels are subject to change
from day to day or even second to second. Oftentimes, depending on the nature of data,
it is better to have no data than wrong (or outdated) data. Therefore, being able to access
the data anywhere, anytime would greatly enhance the value of the data.
Some corporations are beginning to take notice of the latest wireless technologies, and
are interested in applying them to increase employee productivity while enhancing
customer satisfaction. Take Famous Footwear for example. The Madison, Wisconsinbased Famous Footwear is the largest chain of brand-name family shoe stores in the
United States, and it has eliminated 75 percent of its pricing errors by implementing a
handheld (Palm-based) solution that took less than six weeks to develop and implement.2
In conjunction with handheld PDAs, the retail chain uses integrated barcode scanners to
ensure better pricing accuracy across its 975 stores.
Before the wireless solution was in place, store sales associates had to hunt for specific
shoes and manually change and verify prices with a price gun and printout. The process
typically took up to six hours every week and was prone to pricing errors. Now, each
Famous Footwear store is equipped with handhelds, which are connected back to the
home office. When the time comes for the sales managers to change prices, all they have
to do is entering new prices and the effective date to the system. Then, when an associate
scans a box, the item number is sent to the home office system, which returns the
effective price at the time. The improved pricing accuracy has led to better profits and
happier customers.
Another company that is taking advantage of the wireless phenomena is EES Company
of Natick, Mass., which develops software for small businesses on the Palm OS platform.
EES created Duck-Links, a custom version of its POS/OE 4 PDA software to let one of
its clients, Boston Duck Tours, manage critical corporate information in the field using
Palm VII wireless handhelds. By having up-to-the-minute seating information, Boston
Duck Tours is able to sell tickets from remote locations throughout Boston.
Wireless local area network system (WLAN) such as 802.1 lb or 802.1 la improves employee mobility to
a degree, but it is still very limited to coverage area.
2 Palm, Inc., Famous FootwearSuccess Story,
http://www.palm.com/enterprise/studies/study27.html
8
Before Duck-Links, tickets were available only in one location, with guests having to
navigate long lines during peak season. Today, the Duck-Links wireless system includes
a Palm VII handheld, a portable receipt/ticket printer and a credit card reader, which
allows for real-time credit card approval and ticketing.3 The result is a more efficient
sales channel, which optimally matches the number of tourists with its trolley capacity.
Wireless handhelds are also making a big impact in real estate industry. They provide
real estate agents with timely information onsite at properties, letting them access listing
databases and schedule appointments on the fly, track walk-through tours, get real-time
interest rates and even calculate loan amounts. As a result, agents can show more homes
and connect more buyers and sellers.
Sussex and Reilly, a real estate company based in Chicago, uses wireless handhelds to
manage more than 350 property showings per week. Potential home-buyers tour a house
while the agent fills out a survey on what client likes or dislikes about the house. When
the walk-through is complete, agents wirelessly transmit the ratings to a Website where
the seller can immediately check the survey results. In addition, the wireless access
provides all Sussex and Reilly agents with up-to-the-minute and comprehensive property
data, allowing them to answer any questions the potential home-buyers may have while
still onsite. The wireless solution enables the agents to do three times as many showings
as before. And in the real estate business, more showings mean faster sales and happier
clients. 4
Wireless handheld solution is also spreading to the public safety sector. Public Safety
departments embrace wireless technology in an effort to protect citizens and locate
criminals. Mobile device manufacturers have joined forces with police and fire
departments to provide real-time information to officers in the field while streamlining
their paperwork-intensive data filing processes.
Take Bellevue (Washington State) Police Department, for example. Although PDAs will
not replace laptops for the Bellevue police officers any time soon, they can fill a large
gap for officers on foot, on horse patrol or on motorcycle and bicycle patrol--PDAs are
most useful in conducting instant background checks and writing citations. Thirty
Bellevue Police Department officers who patrol on motorcycles or bicycles have been
given Palm VIIx wireless handhelds to connect with the state police database. This access
lets them confirm validity of driver's licenses, weapons registrations, license plates and
other information stored in the archive. Officers can also access current and pending calls
from dispatchers using software provided with the PDAs.
With the mobile device, police officers can retrieve records quicker than calling the
dispatchers on the radio. It is also easier for them to look up records, check the status of
criminal incidents or even run background checks on individuals while patrolling the city.
3 Palm, Inc., Palm Handhelds Help Small Businesses Stay Competitive, Press Release, 9/11/0 1
4 Palm, Inc., Real Estate Industry Reaps Rewards of Wireless Palm Handheld Computers, Press
Release,
8/15/01
9
Besides police departments, wireless handhelds are also deployed for the fire
departments. The Office of Public Safety Communications in San Mateo County,
California has used mobile technology to contact fire engines in the field, perform
alphanumeric paging, open fire station doors and monitor equipment rosters. Firefighters
are deployed in emergency situations when it is essential to keep track of their
whereabouts. With the new PDA system, fire chiefs can stay in constant communication
with their crews, allowing them to have a big-picture view of which firefighters are
working at what location--which helps ensure firefighter safety in the field. 5
Handhelds are also helping hospitals ensure smooth and efficient patient care, such as
streamlining post-operative patient-management, medication-monitoring and riskassessment procedures. The Pediatric International Heart Center at Miami Children's
Hospital has used wireless PDA devices to track the progress of pediatric cardiac patients
in the Cardiac Intensive Care Unit (CICU). Physicians and nurses, who once relied on
paper forms to collect patient data, now use handheld devices to gather the information,
and transmit it wirelessly over a network to the hospital's clinical outcomes database.
With the implementation of wireless solution, doctors and nurse practitioners can now
spend more time with their patients, rather than filling out paper forms. Progress notes
and billing summaries that used to take several hours to write by hand are now completed
in a few minutes. In life-and-death situations, hospital staff has the information at their
fingertips and can share it quickly as needed.6
Although it is clear that mobilizing corporate data offers companies or organizations a
clear competitive advantage, many Chief Information Officers (ClOs), Chief Technology
Officers (CTOs) or IT managers are confused because there are so many different
approaches to develop a mobile wireless strategy, and each approach involves so many
different elements. Some companies may opt to work with wireless application service
providers (WASPs) like Avantgo and Isovia to mobilize their corporate data. However,
this is generally a very short-term solution because neither company offers a truly
efficient and dynamic solution. Their approaches are based on proprietary hardware and
software, which could be costly if the companies want to migrate to a mainstream
solution later. Some other companies might choose XML since it looks like a safe bet in
the future. The problem with XML is that it is an evolving standard at best. Any
investments in XML development could be wasted if it is not managed carefully.
Chapter one of this thesis provides an in-depth discussion of how global enterprises are
using the services of front-office applications, such as Customer Relationship
Management (CRM) and backend tools like Enterprise Resource Planning (ERP) to
optimally manage company resources; to improve customer relationships and enhance
customer satisfaction; and to provide their field support personnel with the information
they need on-site accurately, quickly and effectively. The chapter also explores what the
5 Wrolstad,
6 Palm,
J., Palm Devices Give Public Safety a Hand, Wireless.NewsFactor.com, 10/22/2001
Inc., Palm PoweredHandhelds Enable Improved Patient Care Within Hospitals, Press Release,
10/15/2001
10
technology, business and social drivers are for mobilizing enterprise business
applications.
The implementation of mobile enterprise business applications, however, is currently
hindered by system incompatibility challenges and hardware limitations in mobile
devices. The system incompatibility challenges, which are described in chapter two, arise
because there are such a large variety of PDAs and cell phones. Even though most of
them are "web-enabled ", they often access the Internet differently through different
protocols and interfaces. Therefore, importing a common HTML browser to a mobile
device and displaying the same Web pages that we are accustomed to in a PC would be
unrealistic given the hardware requirements of a typical HTML browser. The mobile
hardware limitations are usually due to small screen sizes, short battery life, inconvenient
user-input interface, and limited bandwidth, processing power and onboard memory.
With these limitations, mobile devices are often not the most user-friendly platform for
accessing corporate data. Furthermore, data might be presented differently in different
devices, and hence user experience uniformity is almost impossible to achieve. WAP,
which burst into the wireless industry a few years ago, was supposed to provide a
uniform user experience despite the aforementioned hardware issues. However, WAP is
still a long way from reaching a critical mass that WAP Forum has originally envisioned.
Hindered by today's slow second-generation (2G) wireless networks, the user experience
on WAP has generally been disappointing. With the deployment of the faster 2.5G and
3G network in the next few years, WAP might be getting its last chance to become the
"Internet Explorer" of the mobile world, as it continues to battle system incompatibility
issues.
Chapters three, four, five, and six of the thesis examine and evaluate the effectiveness of
popular system integration and interoperability technologies and techniques being applied
to the mobile space today. The discussions include wireless markup language (WML),
compressed hyper text markup language (cHTML), extensible hyper text markup
language (XHTML), transcoding, and Web wrapping techniques. WML, which works
mainly with WAP browser, is based on XML. Because of its almost exclusive reliance
on WAP, devices that do not have a WAP interface cannot take advantage of WML's
features. Thus, its usefulness is seriously limited, particularly when a Java-based opensource browser initiative is taken momentum in the wireless industry. Another potential
challenger to WAP is i-Mode, which is the brainchild of DoCoMo. i-Mode browser are
used to access cHTML-based Web sites. Since cHTML is loosely based on HTML it has
a major advantage over WML, in terms of ease of use from the programmers' point of
view, though admittedly, it is too reliant on a single type of browser.
Transcoding, which is being described in chapter four, is a technique to translate existing
HTML data into WML (or cHTML) so that same data can be displayed on a mobile
device as it would on a PC. Transcoding represents the most cost-effective short-term
solution due to its quick implementation time while bringing the least amount of
technology disruptions to the enterprises. Another possible approach in mobilizing
business applications is to leverage the existing Web-based interface, and build a Javabased Web wrapper engine to extract and deliver only the necessary data to the handheld
I1
devices. This might represent the best interim solution because enterprises typically do
not have to change their current HTML Web designs nor their backend infrastructure.
From the development, implementation and maintenance standpoints, the approach is
also cost-effective.
Chapter six focuses on XML. Although XML itself will not directly resolve the
limitations often associated with mobile devices, XML can display Web pages and
interact with the users in the best possible manner given each device type. When used in
conjunction with Extensible Stylesheet Language (XSL), XML will yield an output that
is highly customizable for the screen size, user-input configuration, memory and
bandwidth of a particular type of device. Due to XML's platform-independence
characteristic, it has to potential to be highly adaptive. Once a specific XSL is defined, it
can work with almost any browser both in existence or in the future. By rewriting the
company Web pages in Extensible Markup Language (XML), this approach might be
more expensive and more time consuming in the short-term, but it should bring more
values to the enterprises in the long run.
In chapter seven, the discussion is on XHTML. XHTML is a hybrid between HTML and
XML. It has the added feature of XML's extensibility, while keeping the simplicity of
HTML. While some Web developers are looking at XHTML as a transition technology
before the business world is ready for XML, it has its share of disadvantages.
Chapter eight primarily focuses on Java 2 Micro-Edition (J2ME). It discusses the
underlying technology J2ME and how the wireless industry can leverage it to mobilize
backend corporate data. Rather than building a stove-piped architecture based on a
specific language like HTML, J2ME offers Web developers the "write once, works
everywhere" promise. Whether this promise could be fulfilled depends largely on how
well J2ME works across different mobile platforms once it is mature. Finally, this
chapter compares J2ME with WAP. From the decision-makers' point of view, it is
important to understand the strengths and weakness of each technology. Knowing how
they are different could help make the decision on which one to apply for a wireless
initiative.
Chapter nine is the conclusion, and it offers a summary of all the technologies that we
have discussed in this thesis. It will also provide a set of recommendations based on the
findings presented. Although there is no silver bullet in mobilizing corporate data, this
thesis should clear up some of the confusion regarding the wireless space.
12
1.1 Mobile Enterprise Business Applications (EBAs)
Paradigm shifts periodically in the computing industry. In the 1970s, PCs were largely
toys, until people realized that they could be used to create, store, and most importantly,
edit documents and run spreadsheets programs.7 Still, it was only after the adoption of
network technology that PCs became business machines-information could be shared
between individuals, centralized data stores could be searched and maintained, and
precious hardware resources could be distributed. With the availability of data networks,
the communication factor in PCs has been increased by several orders of magnitude.
The Internet was the next paradigm shift. The concept was deceptively simple-a
network that does not care about the particular architecture of each of its nodes or their
physical locations. The real strength in a computer does not come from any one
application or from the operating system; it comes from the ability to take the results of
one application or service and apply it to another. The two most important operations
that an application or a service can do are to pass the data to another device or service or
application, and to act on information that it receives from that other source.
A decade ago, it was a safe bet that the other computer had a compatible operating
system, but it has gotten worse with the Internet. The likelihood that any two systems
sharing a common OS has dropped steadily as the number of computers connected to the
Internet has risen. The current influx of mobile devices with wireless Internet
connectivity has magnified or will continue to magnify this problem to another order of
magnitude. In order to gain or maintain a competitive edge, the globally extended
enterprises are challenged to support this wide range of devices with the necessary data
synchronization, file distribution, software distribution, and systems management tools
needed to integrate these mobile devices with mainstream, mission-critical applications.
Highly mobile organizations face daunting tasks to manage the scores of laptops and the
data held on these devices, as employees become increasingly mobile. This problem will
only grow as more devices and worse, new types of devices become part of the extended
enterprises.
The scalability issue will be highlighted, as companies want to extend their existing
ebusiness architecture to support Enterprise Business Applications (or EBA) in a mobile
environment. EBAs is a set of business software applications that provides functionality
and services for the key front- and back-office initiatives of virtually any enterprises.
EBAs can be broken down into three distinct but inter-related and increasingly
interdependent application areas: front-office, back-office and e-Business.
An example of front-office applications is CRM, which typically includes sales force
automation (SFA), call center, and customer contact center applications; marketing
automation applications; and customer support and service applications. All of these
CRM applications underpin the enterprise's ability to sell and support customers. The
applications' ability to provide the enterprise with a competitive advantage, optimally
7 Cagle, K., ArchitectureX: Designingfor
AWL, Volume 5, No. 3, Fall 2000
13
manage and retain customer relationships, and maximize revenues will help drive this
segment of EBA to an estimated $14 billion in investments by 2002.
A prime example of back-office applications is ERP, which includes supply chain
management applications; financial management and human resource planning
applications; and legacy or line-of-business applications used to manage functions such
as billing, order processing, or specific vertical industry requirements. ERP applications
are a key source of functionality and information for any enterprise and are beginning to
play a major role in Internet-based procurement, supply chain management, and businessto-business (B-to-B) commerce.
e-Business applications are Internet-centric applications integrated with front- and backoffice applications. More recently, Internet-based commerce and e-Business applications
have dramatically changed the way in which enterprises think about interfacing with their
customers and business partners. Although e-Commerce was initially treated as little
more than a set of functionality that existed on a Web site to support order processing
capabilities, e-Business has become the macro-category used to describe the intersection
of the Internet, CRM, and ERP applications. In particular, e-Business applications
leverage the presence and reach of the Internet to extend demand-side CRM applications
and supply-side back-office applications to customers, partners, and suppliers.
e-Business can either provide back-office functionality such as Internet-centric supply
chain and B-to-B e-Procurement applications, or it can focus on front-office customerfacing applications. Not only customers can access CRM-centric applications over the
Web to order products or services, but also inquire on the delivery status, resolve a
technical issue, or participate in a marketing campaign.
Because of the positive impact that EBAs can have on an enterprise's revenue and bottom
line, CRM- and ERP-based applications are today well-established, mission-critical
services present in many, if not most, companies. More recently, brick-and-mortar and
click-and-mortar companies are merging physical processes, such as sales, manufacturing
and shipping, with the online world of the Internet. Some suggest that the next
movement with EBAs will be towards extending access to these mission-critical
applications and data repositories to partners, customers, and customer-facing employees.
1.2 Key Driving Factors of Mobile EBAs
There are several key drivers impacting and accelerating the growth and acceptance of
mobile EBAs. These key driving factors include business- and revenue-centric issues; the
availability of enabling technologies; and the acceptance of different social models of
how and where business is conducted.
The business issues driving the implementation of EBAs are relatively straightforward.
ERP and back-office applications were implemented to improve the efficiency of the
enterprise, to manage the growth and complexity of the global enterprise, and ultimately
14
to help reduce business expenses. CRM and e-Business applications have increased
dramatically because of the direct impact they bring to the bottom line of an enterprise.
CRM applications help sell more effectively, optimize customer relationships and
increase the revenue from each relationship.
The business drivers behind e-Business are the near-universal presence of the Internet
and the need for businesses to communicate with, sell to, and support their customers
over the Internet. As wireless and unplugged mobile devices become more common, the
ability to support such mobile devices will become a necessity. Just as the Internet has
spurred new ways of doing business, the advent of mobile devices will create new
opportunities. Legions of sales professionals and technical support professionals rely on
their laptop devices and the enterprise data that resided in them, to work effectively with
their customers and partners. In the near future, this business driver will mandate the use
of other devices like cellular telephone, PDA, and other wireless or unplugged mobile
devices.
There are also technology drivers for mobile EBAs. New technologies create
opportunities to do business in ways not feasible in the past. The emergence of the
Internet, e-Business applications and inexpensive yet powerful laptops open various
options for the enterprise to sell to its customers. Applications used to support pricing
and configuration tools, for example, are now being provided to support salespeople on
the field. Contact and opportunity management tools are now being extended to palmsize devices.
The social drivers of changing business models should not be overlooked. Resulted from
the user-friendly Internet, consumers as well as business partners today are accustomed to
conducting business globally, virtually, and remotely. Products and services can be
acquired from almost anywhere using PCs, PDAs, and cellular phones. The evolution
from making purchases and accessing corporate data from Web sites on PCs or other
mobile devices has slowly unfolded before our eyes. Since the Internet has been widely
adopted as a mean to do business, migration to fully mobile devices will happen sooner
than later once all the necessary elements are in place.
1.3
Mobile EBAs and Mobile Devices: PDAs, and Digital Phones
One has only to look as far as the Internet to get some insights into how quickly highlevel business, technical and social acceptance factors can change the rules of business.
In the last three years, the Internet and e-Business have almost entirely changed how
customers interact with suppliers. As users feel comfortable with communicating via
Internet, many long-standing rules of building an enterprise, such as investment in
physical storefronts, retail locations, supply chain management, distribution, sales
channel relationships and reliance on human agents as intermediaries to connect
customers and information, have to change accordingly.
15
Likewise, as corporations and consumers adopt new models of mobile commerce (or mcommerce), the enterprise will be challenged once again to implement new models of
mobile enterprise applications to keep pace with the new technologies. The challenges
will occur much more rapidly than most enterprises realize. In some instances, making
application data accessible to customers, employees or partners will be as simple as
posting them on the Internet or making them available via a browser-based link. More
often, however, extending this data and information to both internal users and external
partners will require a well-architected and well-implemented value chain of information
that will connect the data and the device. This information value chain, a critical
component in conducting business internally and externally to the enterprise, will be built
on the technology identified above.
Much attention has been drawn to the new era of devices. In the U.S. market, PDAs, led
by Palm, Microsoft's Windows CE and Pocket PC based devices, have garnered
tremendous attention as the preferred device of the mobile professional. In Europe,
cellular telephones that provide digital wireless and WAP support are predominant. Once
the mobile devices reach a critical mass, m-commerce will have a chance to take off. As
these devices are becoming the de facto way to perform business transactions, most
business strategists agree that m-commerce should be the next arena where ebusiness as
well as the traditional brick-and-mortar companies would compete and strive to excel.
To succeed, they need to create a mobile Internet architecture that redefines how
information is shared, coordinated and distributed. On the operational level, enterprise
strategists should also consider the number and types of mobile devices likely to be
represented in their organizations and plan accordingly.
1.4 The Mobile Internet Infrastructure
The m-commerce business model challenges today's enterprises to use their existing
Internet infrastructure to allow users access to corporate information, data, and services,
regardless of location or device type. The new mobile Internet infrastructure should be
designed to handle data transfer, file access and distribution, and synchronization
throughout the system. This new architecture will be an extension of the current ebusiness infrastructure. It will accommodate all device types used to manage data
remotely while providing access points, or ideally, portals, that will serve as entry points
for the mobile users.
Services that will need to be accommodated to support the access of CRM, ERP,
proprietary or custom-developed line of business applications, legacy data and
applications, and ebusiness/m-commerce data should include the following:
" Data synchronization between handheld devices and server-based systems;
* File distribution, including the ability to refresh commonly used or accessed
data files with updated information;
" Software updates and distribution, particularly important for client-serverbased enterprise applications; and
16
*
Portal-based entry into data repositories, which will provide a central point of
presence for both internal and external users to identify, retrieve, and
synchronize information.
The challenge of designing and implementing an enterprise architecture for mobile
Internet users may seem daunting, particularly given the small profiles of many of the
devices that need to be accommodated. However, the depth and robustness of these
services will become critical in supporting complex enterprise applications and data
access, particularly when that access needs to be independent of device type. ERP and
CRM applications are both mission-critical, and are both noted for the complexity of their
data models. Simple device-to-desktop synchronization, although appealing and useful in
many cases, may not be applicable for applications beyond trivial data exchange.
To truly extend these applications and data to mobile users, the new mobile Internet
architecture has to include a value chain of information. This value chain will be
composed of:
*
*
"
"
*
1.4.1
applications,
their associated data,
mobile devices, including laptops, PDAs, and digital cellular telephones;
a wired or wireless communications link between the device and the systems
supporting the application; and
a middleware software to support and control the synchronization, systems
management, and data distribution that occurs between the central data
repository and the mobile device.
Data Transformation and Loading
There are three basic approaches to this data synchronization strategy. You can load the
data directly from operational databases (see Fig. 1.1); you can load your enterprise
warehouse conventionally, then employ specialized facilities for intermittent
communication. Or you can load the enterprise warehouse conventionally and use
snapshot replication to populate data marts (temporary data storage for mobile users)
from that warehouse.
The first option-loading the mobile data directly from the operational databases, has its
pros and cons. The success of this method lies on whether the data transformation and
loading services can operate over intermittent communication channels; whether this
service can select the appropriate data for the decision maker; whether it can perform the
transformation and loading quick enough, and whether the entire strategy addresses the
timeliness requirements of the user. The latter issues are particularly of concerned to
most network architects because updating existing data is often a row-by-row operation,
which can be inefficient over slow communication lines. Over a typical 9.6kbps wireless
connection, some of the data transformation and loading steps could take too long to
perform, and thus, limiting its usefulness.
17
Operational
databases
Data
warehouse
Mobile
data marts
Corporate decision
OLTP
makers
users
Data transfer
and loading
Dept. decision
Data transfer
and loading
makers
Fig. 1.1 Loading Mobile Data Directly from Operational Databases
A related problem is that most of the data transfer and loading packages employ push
technology-"pushed" from source database to the data warehouse. With mobile data
marts, one actually requires pull technology-the data mart pulls the data off the source
database when it is connected to the network. However, recent advances made in agent
technology can tell the source system when the mobile data mart system is connected.
So, it becomes less of an issue as long as the data transfer and loading packages support
the appropriate agent technology.
The second approach to data transformation and loading is to load an enterprise or
departmental data warehouse in the conventional way, and then use specialized
facilities,
such as transaction replication software especially designed for intermittent
communication (see Figure 1.2). With this approach, only the relevant changes to the
source data warehouse database are replicated to the mobile data mart when the two
systems are connected. Note that the operations that were applied to the source data
warehouse are re-applied to the mobile data mart over the dial-up connection. Setting up
the replication software and managing the transaction replication process in a timely
manner are critical. Because this approach involves two steps, the information loaded
into the mobile data mart may be slightly older than near-present. Replication is also
very complex to set up, especially if there are different databases or different database
management systems (DBMSs) in the configuration. Conflicts can be encountered if the
same data items are updated at different time in different databases. A conflict resolution
scheme is necessary to decide which copy is the correct one, or which of the conflicting
operations to apply, and then forcing all the other copies consistently to that value. This
often requires in-depth knowledge of the data structures, data representations and the
8 The
only issue is that the data transfer and loading packages must support the technology.
18
operations. Furthermore, managing transaction replication is a serious matter because the
replication process can be interrupted by a communication failure.
Operational
databases
O.TP
users
Data
warehouse
Mobile
data marts
Corpo rate decision
makers
Data transfer
and loading
m
Dept. decision
makers
Subset
replication
Fig. 1.2 Mobile Data Replication
The third approach is to load the enterprise or departmental data warehouse, and then use
snapshot replication to populate the mobile data marts from the enterprise or
departmental data warehouse. The schematic diagram is actually the same as the second
approach (see Fig. 1.2) because the only difference between the two is that one calls for
transaction-based replication-only a subset of the data warehouse is loaded, while the
other calls for snapshot replication-the entire mobile data mart gets re-loaded. This
approach share some of same weaknesses as the first approach. The major issues to
consider are the size of the mobile data mart, the selectivity of the snapshot, and again
whether the entire strategy addresses the timeliness requirements of the user.
Snapshot replication facilities are much easier to configure and manage than transactionbased replication facilities. The replication process is also much simpler, as the entire
database gets re-loaded from the source database. The issue is whether the mobile data
mart database is small enough for this process to be done repeatedly over a dial-up
connection (or even worse with a 9.2kbps wireless data stream). If the mobile data mart is
too big to be reloaded repeatedly, this approach becomes impractical. For this reason, it's
useful to limit the size and duration of the refresh operation, and to select only the data
relevant for each particular mobile data mart user. The key is to specify the selected parts
to the snapshot replication facilities. Only some of the replication products have the
facilities to create such partial snapshots.
There is no one single solution for handling the data warehousing or data synchronization
issues in a wireless initiative. The selection should be based on the size, time criticality
and usage of the data, as well as the types of mobile device and network being supported.
19
These latter issues are being discussed in the following chapters. Table 1.1 summarizes
the salient facts of the three data synchronization approaches.
Pros
Direct Loading
*
No change involvedPros
in the
current data synchronization
structure.
Transaction-based
Replication
*
Only the relevant changes are
replicated to the mobile data
mart
Cons
Data transformation and
loading steps may take too
long to be practical.
0 Susceptible to
communication failure.
.
Replication process could be
complicated
* Data is only near-present
0 Requires a conflict
resolution scheme if there
are different databases
involved.
* Susceptible to
communication failure.
Snapshot-based
Replication
*
Ease of Initial
Configuration/Maintenance
0
*
*
Data mart could be too big
for the network bandwidth.
Susceptible to
communication failure.
Table 1.1 Data Synchronization Summary
20
Chapter 2 Overview of Current Wireless Technology Developments
The industry is buzzing about small, mobile, Internet-enabled devices, and all types of
handheld devices are hitting the market.9 Among these, the personal digital assistants
(PDA) and cell phones are platforms of choice for deploying mobile applications. This
thesis concentrates on PDAs and cell phones because they are inexpensive and
immensely popular. They also provide a relatively stable environment for business
application development. Of course, there are many obstacles before the true benefit of
mobile, Web-enabled applications will be realized. Until users can truly access critical
business data and resources efficiently anywhere, anytime, enterprises will have
difficulties in bringing resources and services closer to the customers and business
partners, enabling quicker response times, better service, and more efficient resource
management.
With today's wireless Internet-enabled mobile devices, PDA and cell phone users can
check their emails, browse specially formatted Web channels, shop online, track
investment portfolio; and even obtain travel directions.10 Based on the current
popularity, it is no surprise that International Data Corp. (IDC) predicts U.S. unit
shipments of consumer information appliances, including PDAs, wireless devices, will
outnumber those of consumer PCs by 2002. The total market will exceed 89 million
units, or $17.8 billion, in 2004, up from 11 million units and $2.4 billion in 1999." It is
estimated that almost 300 million wireless devices are already in use, and that there will
be almost 300 million more in three years.' 2 Cellular growth is expected to contribute to
PDA's growth. According to Bear Steams, today's 86 million cell phone users in the US
market represent only 30% penetration but that will be doubled in the next four years,
possibly reaching 76% by 2009. With these rosy predictions, companies have to meet the
needs of this new growing breed of mobile users in order to gain the competitive edge.
Thus, apart from expanding their business to the Internet space, companies have to
consider developing mobile versions of their internal applications attuned to the limits of
handheld devices and low-bandwidth mobile networks.
2.1
Personal Digital Assistant (PDA)
A typical method of wireless connectivity for mobile devices is to establish a connection
(via a data cable or infrared) between an analog or digital cell phone and a PDA. In this
case, the phone acts like a modem to the PDA. Another way is to use CompactFlash
(CF)/PC card modems. This is very common in Pocket PC or Window CE products. The
CF modem card is typically inserted into a PDA for wireless connectivity.' 3 Some Palm
Allen, J., Merging Mobility and Middleware,
http://www.devx.com/upload/free/features/avapro/2000/07juloo/ja07/jaOO07. asp
9
"D Brown, B. & Brown, M., Wireless PDA Communication, PC Mag, 6/16/2000
" Miles, S., Handhelds to share data with new Web service, CNET News.com, 5/16/2000
[2
Most of these are cellular phones, but the numbers include other
devices, such as PDAs.
13 Handspring products have the same feature except they are relying
on the Springboard modules rather
than the CF modem cards.
21
models such as the Palm VII series have wireless modem built-in. Virtually, all wireless
modems designed for PDAs rely on a Cellular Digital Packet Data (CDPD) network.
CDPD is a data transmission technology developed for use on cellular phone frequencies.
It takes the unused cellular channels (in the 800- to 900-MHz range) to transmit data in
packets. This technology offers data transfer rates up to 19.2 Kbps, quicker call set up,
and better error correction than using modems on an analog cellular channel. Since
CDPD is based on the TCP/IP, it is compatible with nearly all TCP/IP-based Internet
applications, like Web browsing and e-mail.
As with the cell phone, there are different CDPD networks in United States. The Palm
VII series are running on the Bell South wireless pager CDPD network, and their wireless
service is called Palm.Net for connections in most US metropolitan areas. Other wireless
service providers like Omnisky and GoAmerica offer similar wireless services on their
CDPD networks.
2.2
Cell Phone
The cell phone industry has been evolving rapidly since the first analog AMPS phone
was introduced. Independent from the airlink protocol, a cellular phone system consists
of mobile units, base stations and switches. A cellular phone is different from a regular
phone in that it has a transceiver (transmitter/receiver), meaning that it can both send and
receive radio signals to/from a base station antenna. A base station is a stationary
antenna, located within the middle of a cell-shaped transmit and receive area (see Fig.
2.1). The cells have a limited geographical area that may cover an entire town or a
segment of a large metropolitan area. A typical cell is about 20km across but can vary in
size and coverage, depending on the kind of wireless network and other extraneous
factors. Within a cell phone system, a switch is needed in order to route the phone call or
data to/from the appropriate base station based on the location of the user.
Fig. 2.1 Typical Cell Phone Network
The current digital format (2G) first came out in the early 90s in the Scandinavia
countries. There are three competing airlink protocols exist: Global System for Mobile
22
Communication (GSM), Time Division Multiple Access (TDMA) and Code Division
Multiple Access (CDMA). GSM was adopted by the European countries, and is by far the
most dominant format in the world. In the US, all three formats are competing, and the
confusion created hindered the adoption of 2G phones at the beginning.
Despite extensive hype, second-generation (2G) mobile networks were slow (data
throughput has been restricted to 9.6-Kbps circuit-switched service), services were
expensive, and islands of networks running different airlink protocols limited service
coverage. The next generation data (NGD) phones were later introduced allowing users
to roam the globe and use a single device (and IP address) to access intranet applications,
Web pages and unified mailboxes.
NGD represents a new S-curve, in terms of ease of use and data throughput rate. S-curves
were first popularized as a tool for understanding the technology life cycle in Dick
Foster's book The Attacker 's Advantage. Foster suggested that as an industry matured,
the rate of return to technological effort changed in predictable ways (see Fig. 2.2). In
the beginning, firms or individuals would put in quite a lot of work for not very much
progress (ferment phase). Then, once the dominant design was established, the rate of
return to effort would rise very dramatically, such that the same effort would result in
much greater increments in performance (takeoff phase). This improvement, however,
was self-limiting. As firms invested more and more effort in a particular technology, the
returns to effort would fall (maturity phase). The industry would enter a period of
"maturity" in which progress was basically a process of "squeezing the last few drops of
juice" out of established technology. Essentially, that is what has been happening in the
2G network development. Ever since its initial launch in the early 90's, the wireless
industry has been improving the 2G network performance (for example, from the
operators' standpoint, the CDMA format has really enhanced the capacity and voice
quality of a wireless link over GSM). However, because 2G is based on a circuitswitched technology, the data rate cannot be improved any further beyond the 9.6kbps
boundary. Thus, in a sense, the 2G has reached the maturity phase of the S-curve, and
NGD signals the beginning of a new S-curve.
With this new S-curve, NGD represents new market opportunities for the equipment
vendors and service providers in the increasingly saturated 2G consumer space. In some
countries such as Finland and Japan, cell phone penetration has reached well over 50%,
and cell phones have become a commodity-like product. To survive in this highlycompetitive business, cell phone manufacturers have to differentiate their products from
the competition. By migrating to NGD, equipment manufacturers hope it will spark a
new wave of demand. Even though from the operators' perspective, there is clearly a risk
in undertaking these investments given regional and national variations in take-up rate,
opting out of NGD investments carries the risk that such operators may be permanently
locking themselves out of the high end of the user market. Furthermore, almost since the
inception of the first GSM networks, primary and third-party vendors have sought to
persuade operators to differentiate themselves through value-added services. NGD will
be a clear and fundamental differentiator given its new application possibilities (such as
live video streaming and conferencing). As a result, vendors want to create an
23
environment in which NGD can serve a real market need, generate new revenue, and
protect existing voice revenues. For service operators, handset and infrastructure vendors,
NGD offers new opportunities to reduce operating cost, increase sales, and improve
market share.
NGD can be categorized into High-Speed Circuit-Switched Data (HSCSD), Enhanced
Data Rates for Global Evolution (EDGE), General Packet Radio Service (GPRS) and
Third Generation (3G). Telecommunication analysts foresaw over 22.9 million NGD
users in Europe by 2005, constituting 22% of all cellular subscribers. The CDMA and
TDMA communities can migrate to 3G by simply upgrading software to the base stations
and new cards for the handsets, while the GSM users will experience more costly
migration.
A
Maturity
Disruption
Performance
Takeoff
Ferment
Time
Fig. 2.2 S-Curve for Cell Phone Network Development
2.3
Wireless Network Development
The main issue in mobile wireless connections is its limited data rate. Currently, the
fastest download option in the U.S. for a mobile handheld device is Cellular Digital
24
Packet Data (CDPD), and the data rates range from 9.6kbps to 19.2kbps. It is almost
impossible to transfer large amounts of data over a PDA or cell phone. The connection is
due to jump to 56kbps in early 2002 with the arrival of 2.5G and some early versions of
3G network.
2.3.1
2.5G Technologies
The migration to 3G involves many intermediate steps. For CDMA network, it is relative
simple-mostly software changes and hardware reconfigurations (IXRTT and 3XRTT).
For TDMA, it could be very complicated even the diagram below only illustrates there
are only two intermediate steps. The jump from TDMA to EDGE is very complex,
which involves expensive service station upgrades. The migration path for GSM
includes HSCSD, GPRS, EDGE and UMTS (see Fig. 2.3), although not all the steps have
to be implemented. For example, most service providers might decide to bypass HSCSD
completely, and go straight to GPRS.
3G
UTS
UMTS
3 XRTT
Interim Steps
EDGE
2.5G
GPRS
EDGE
1
2G
GSM
I XRTT
1 XR1F1
TDMA
CDMA
Fig. 2.3 Wireless Network Upgrade Path
HSCSD is a low-cost technology to implement, but it is a circuit-switched technology
hence its capacity is inefficient. Many predict that HSCSD's bandwidth inefficiencies
will prevent it from gaining a significant share of the worldwide market. In fact, many
GSM service providers are considering bypassing HSCSD and migrate to GPRS directly.
25
General Packet Radio Service (GPRS) is by far the favored NGD technology amongst the
cell phone operators as 80% of the existing GSM operators in Western Europe will
deploy GPRS infrastructure over the next three years. GPRS offers two main advantages;
it offers higher data speeds and greater spectral efficiency than 2G GSM systems. One of
the biggest benefits of GPRS is its always-on technology, which is ready to receive data
without taking up a whole channel. It sends data in packets and its data rates can reach up
to 115 Kbps (though initial service will only achieve 30-50 Kbps). However, if you
compare GPRS with HSCSD, GPRS is more expensive and takes longer to deploy and
implement. Regardless of the disadvantages, GPRS enables operators to familiarize
themselves with operating a packet network, test out applications (which could be
adapted for 3G), and create demand for a plethora of high-speed mobile data services.
From the operators' perspective, GPRS is very capacity-efficient, and for users GPRS is
likely to be relatively cheap. GSM has a graceful evolution to GPRS. On grounds of
network efficiency, time-to-market, and relatively low cost of deployment, most analysts
expect that GPRS will account for more than 90% of investment in NGD by European
GSM operators over the next three years and more than 60% over the next five years.
Enhanced Data Rates for Global Evolution (EDGE) theoretically enables maximum data
rates up to of 511 Kbps but only 80-100 Kbps in reality. It is not fast enough to compete
with GPRS on speed alone. Additionally, the cost of deploying EDGE is roughly eight
times that of GPRS. As 3G networks will roll out faster than originally forecast (for
operators want to speedily recoup the high investment of obtaining 3G licenses), vendors
are increasingly positioning EDGE as a niche commodity aimed at non-3G license
winners and as a complementary service to 3G city networks.
Universal Mobile Telecommunications Systems (UMTS) will implement a single,
globally accepted standard allowing users access to high data rate services in any country.
UMTS will be an ATM-based packet network with a more spectrum-efficient radio
interface, a faster data rate and lower costs for supporting mass-market mobile data
traffic. UMTS requires the deployment of a whole new network, including a whole new
radio base station network, from scratch. Achieving the same nationwide coverage for
UMTS will cost $1.5 billion (as opposed to $120 million for GPRS).
The upgrade process for CDMA networks is much simpler than GSM or TDMA. The
first step is 1XRTT. It could provide a theoretical data rate of 144kbps and voice
capacity twice that of the current CDMA. From 1 XRTT, the CDMA path continues
along a series of incremental steps that include 1 XEV (1 xevolution), leading finally to
3XRTT, which is also called CDMA2000. This technology, which provides a maximum
data rate of 2Mbps, represents significant improvement over 1 XRTT in terms of voice
quality and quality of service (QoS) for delivering multimedia mobile data services (such
as video conferencing or live video streaming).
2.3.2
3G Technologies
3G networks, which will be rolling out around the globe through 2002 (Japan's DoCoMo
plans to start their own version as early as May 2001), will run at a theoretical speed of 2
26
Mbps. The 3G networks will be compatible with networks running different airlink
protocols, such as CDMA, TDMA and GSM. The estimated average cost of rolling out
a 3G network will be $12.5 billion.' 4
One of the major problems facing 3G rollout is frequency spectrum. In some countries
like France as well as the United States, the 3G spectrum is being occupied by the
military, older analog services, local wireless providers and satellite broadcasters. One of
the main goals of 3G is to become the de-facto universal standard in the wireless
communication arena. This means that individual users can use the same 3G handset in
every part of the world. Achieving this goal would be seriously jeopardized if some
countries are not clearing out the proposed 3G spectrum.
Apart from the frequency spectrum issue, the deployment of 3G networks requires
substantial investment from service providers. For example, the GSM based carriers,
who are migrating their networks to a higher frequency spectrum, may be required to
replace most of their base stations. Furthermore, since the cell size becomes smaller by
moving up the frequency band, more 3G-enabled base stations will be necessary to cover
the same area. The other issue is license cost. Because of the huge 3G potential benefits,
licensing the frequency domain in the auction house was extremely costly. It added to
the ballooning debt burdens on many providers. In Europe, companies spent $108 billion
bidding on national licenses, leading many investors over the past year to question if 3G
services will ever yield enough revenue to justify the cost. Some analysts argue that
service providers can recoup a majority portion of the licensing fees by rolling out the 3G
network earlier. However, this will require the financial support from network equipment
manufacturers as well as handset manufacturers. Furthermore, rolling out a new wireless
network involves extensive testing.'5 Cost is also important from the consumers'
perspective. First of all, wireless service providers have to convince their potential
customers that the 3G service is worth to upgrade to. This is the reason why the service
providers are looking for the next "killer app." The average consumers have to not only
shell out extra cash to buy the latest 3G handsets, but also need to get used to a new
pricing system. Because the 3G service is an always-on technology, the current billing
scheme has to change. Instead of being billed on a per minute basis or at a flat rate, the
new networks will be volume based (or kilobyte basis). The more data being
downloaded, the more the users have to pay.
As Asia and Europe gear up to offer 3G mobile phone services, US wireless operators are
still focused on stitching together a truly national network with enough antennae just to
cover existing callers. Beyond complaints about calls being cut off, the US faces tough
transitions to offer 3G services that Asian and European operators plan to deliver by this
year or next. Hurdles include airwave allocation issues, competing technical standards,
and choices consumers have in the ways they connect to the Internet. Users are going to
compare their wireless Internet experience with their PC experience. This will further
slow down the 3G adoption rate. The difference boils down to how US consumers expect
the cost of a 3G license, the cost of building a network, and the cost of
developing and promoting
applications and content
15 Wexler, J., Network World Wireless
in the Enterprise Newsletter, 8/23/2000
14
27
relatively unencumbered access to Web sites and e-mail via computers. By contrast, a
large and growing percentage of international consumers rely on mobile phones for Net
links. Wired Internet penetration is below 10% in Japan versus more than 50% in US.
2.5/3G handsets do not solve all the problems in terms of mobilizing corporate data
because true 2.5G/3G networks are not really here yet. As of mid-2001, early forms of
2.5G networks are just taking shape in the United States. Even so, the people that are
buying into the 2.5G service are the few early technology adopters. These are the people
who want to be the "first on the block" to own new technologies. Hence, they do not
mind that the 2.5G service today has inconsistent download speed and the coverage is
sporadic. However, to truly "diffuse" the 2.5G or 3G technologies to the main consumer
market, a chasm has to be crossed (see Fig. 2.4 below). In Inside the Tornado, Geoffrey
Moore discussed this common phenomenon in new technology. He mentioned that the
point of greatest peril in the development of a high-tech market lies in making the
transition from an early market dominated by a few visionary customers to a mainstream
market dominated by a large block of customers, who are predominantly pragmatistsin
orientation. The gap between these two markets, heretofore ignored, is in fact so
significant as to warrant being called a chasm, and crossing this chasm must be the
primary focus of any long-term high-tech marketing plan . A successful crossing is how
high-tech fortunes are made; failure in the attempt is how they are lost.
The Chasm
The Early
Market
The Mainstream
Market
ante
he
Chasm
Fig. 2.4 Crossing the Chasm
Fig. 2.4 illustrates this crossing the chasm concept (technology adoption is supposed to
go from left to right). According to Geoffrey Moore, the technology enthusiasts (who
focus more on technology exploration), and visionaries (who focus more on technology
exploitation) are the early adopters. These are people who see breakthrough potential in
some technology, and are willing to brave hell and high water to realize that potential;
they are not too bothered by the fact that the technology does not quite work, and they are
Moore, G., Inside the Tornado: Marketing Strategiesfrom
Silicon Valley's Cutting Edge, Harper
Business, 1996
16
28
willing to make it work. After the technology enthusiasts fiddle with a technology and
discover it is real, they tell the visionaries. The visionaries then will pass the good word
on to the pragmatists. The pragmatists are typically the people that want a technology that
work and they are not interested in debugging it. They want to be able to hire people who
have used it. In short, they don't just want a product--they want a 100% solution to their
business problem. When the pragmatists become the market leader, the technology is
usually mature enough that companies should start making the money they have
anticipated. They also have enough volume and experience that the technology is cheap
enough and undemanding enough for the conservatives. Conservatives buy products
because they really have no choice. They want products that are cheap and do their job as
unobtrusively as possible. Finally, there are the skeptics, who are typically the market
laggards, and they are not going to buy, and they may even talk other people out of
buying.
The problem dealt with in Crossing the Chasm is that the visionaries are not in fact good
references for the pragmatists. They provide tales of heroics-not stories of smooth,
predictable adoption. Pragmatists want references from other pragmatists. Pragmatists
want a "safe" buy from the market leader, but there is not one yet. Thus, in a sense,
Crossing the Chasm is really about getting the first toehold in the pragmatist market.
Although Moore's technology lifecycle model is somewhat oversimplified, and it draws
clear boundaries where reality is perhaps fuzzier, the chasm concept can definitely be
applied to the current NGD development.
NGD networks will not be widely available in the United States for another two to three
years. This presents a problem to the wireless industry because until the NGD
technologies are widely deployed, the cost of owning/using such technologies is probably
too high for the mainstreamers (such as the pragmatists and conservatives). On top of
that, the mainstreamers might also want to wait because the NGD technologies are simply
not mature enough such that most of the technical issues are ironed out. Besides this
vicious cycle occurring on user side, the operators are also facing tremendous difficulties
with NGD. As these NGD networks are being roll-out, wireless service providers in the
United States would have no choice but to support 2G, 2.5G or even 3G (a total of 9
different formats) simultaneously in the near future. Even though the deployment,
maintenance and system integration costs are almost astronomical, the service providers
still have to take this risk because they do not to want to be left behind on the technology
curve. So, it is a fair assumption that those intermediate wireless networks (different
flavors of 2.5G) will continue to confuse the public, and thus further delay the
deployment of a true 3G network. There are other problems associated with NGD
networks. For example, the wireless coverage is limited mainly to major US metropolitan
areas, and the reception degrades substantially for those in the rural areas. In the US,
there is no single, nationwide wireless operator that blankets US with coverage. Because
of the nature of terrestrial radio, even a covered area is usually dependent, to some
degree, on the effects of structure, foliage and weather-absorbing radio frequency (RF)
energy. So, this wireless coverage issue that is associated with the current 2G cellular
phone and CDPD networks will also exist in the upcoming 2.5G/3G networks as well.
In short, the path to a true 3G wireless world is not going to be a smooth one, and there
will be many obstacles ahead. It is unwise to think that NGD networks will fix all the
29
problems in mobilizing corporate data. Instead, the companies or organizations should
focus their energies in addressing other areas that are critical in mobilizing corporate
data. In this way, when a true 3G network is achieved in the next three to four years, they
can take advantage of it.
2.4
Other Limitations for Mobile Devices
As noted earlier, the range of tasks you can perform and information you can access in
wireless mode is increasing quickly, driven by the "Internet everywhere" concept.1 7 The
question is not how to connect wirelessly, but rather which method to use and how to
fully utilize the mobile device. With encryption and preset accounts, users can make
even sensitive transactions like stock trading and bank account management possible
with wireless devices. Before enterprises could truly realize the benefits of the "any
time, anywhere" concept, there are some other problems (besides wireless bandwidth)
that have to be tackled.
2.4.1
Screen Size
It is widely believed that wireless usage is due to take off even more quickly when the
faster wireless channels with 2.5G and 3G wireless networks are beginning to roll out in
the next few years. But these devices would still be constrained by other problems.
Since the devices are small and wireless, they have constraints not normally found in a
Web client. For example, although the new Internet ready phones can be used for
wireless access, the small display screens of low resolution capable of displaying only a
few lines of text making them difficult to use them for more than short messaging. The
mobile devices, generally, are just adequate for query Web sites with structured
information. The greater utility and screen size of PDAs make them likely that they will
be useful for several more years. Current Internet phone browsers typically support 3-5
lines of 12-17 characters each, making succinct menus and message the rule. With small
screen size, displaying a regular sized HTML Web page is not realistic. However, in
order for m-commerce to take off, screen size has to improve.
In the near future, PDAs would be merged with the cell phones, and the resulting hybrids
would likely have bigger screen size. Kycoera, Nokia and Samsung have begun shipping
production models of such hybrids. Although these early attempts are bulky, the screen
size is indeed bigger than the typical cell phone. Another potential solution is to combine
pen computing (as used by the PDAs) and voice recognition. Such an approach will
minimize the user's reliance on visualizing data on a stamp-sized screen.
2.4.2
User Input Interface
User input interface is another issue for mobile devices. Unlike a PC, where users can
use a mouse and a keyboard for text input and onscreen navigation, interfacing with cell
phones is difficult and frustrating since all the text input is done via a numeric keypad.
1 Brown B., Brown, M., Wireless PDA Communication, PC Mag, 6/16/2000
30
Onscreen navigation can be improved with a touch screen. Most of the PDAs in the
market today have a touch sensitive screen making user interaction with the device easier.
Cell phones are just beginning to catch on this touch screen concept. However, because
of their limited screen size, having this feature is not as useful as in the PDAs. There
have been many attempts to resolve the text-input issue. Some mobile devices (mainly
PDAs) offer virtual keypads, which help a little, although users can only input text by
tapping on the keys. This is very clumsy.' 8 For cell phone users, relief might come in
the way of speech-to-text and text-to-speech. Already some high-end cell phones offer
limited voice recognition feature. However, the vocabulary used is very limited and
therefore, reducing its usefulness. More enhanced versions of speech-to-text are possible
with a more powerful CPU and large amounts of RAM. However, most handset vendors
are reluctant to employ the more expensive CPU, and extra RAM in order to keep the
cost down-at least, reachable by most of the consumers. Besides cost, battery life is
another area that would suffer if more powerful CPUs are used. Studies have shown that
battery life is the most valued feature in a cell phones only next to the ease of use. Thus,
it is hard to imagine that handset manufacturers would improve user interface at the
expense of battery life.
2.4.3
Security
Security is, and will continue to be important in wireless devices. Mobile device
management becomes critical when considering that sensitive (and in some cases,
confidential) corporate data is being putting into devices that are designed to go
anywhere. Employees must be trained to safeguard their mobile device as they would
with their own wallet. Another area of concern is virus protection. This is especially true
for a large user base because the possibility of a virus attack increases significantly when
more mobile devices are being allowed to connect to the backend infrastructure. Having
a virus contaminated a mobile device is bad enough, but if the whole corporate network is
infected, the result is nothing short of disastrous.
Another potential security breech is eavesdropping. In the wireless era, every innovation
has been followed by a host of security concerns. Wireless data networks present
potentially greater risks than cell phones because they often broadcast a bounty of
corporate data in the air. Although no system is foolproof, wireless snoops can be
deflected by redesigning the network and using encryption software. To enhance data
security, wireless carriers have some security built into their networks. Companies
usually have Virtual Private Networks (VPN)' 9 that could secure sensitive data behind
their firewalls in the Internet environment. For the wireless space, end-to-end security
between the mobile user and a corporate database can be achieved by providing a secure
tunnel through the corporate firewall-similar to the wired counterpart. Various
' Some handheld devices offer T9 feature. T9 is an attempt to reduce number of keystrokes by predicting
words that users are looking for. For example, when an user type "whe", the device will offer the word
"when". Of course, the T9 feature does not always work well. The user could mean to type "where"
instead of "when."
19 Some of the commercial VPNs applications have been developed specifically for mobile devices.
20 Tomen, D., Wat Are CIOs Waiting For? [Developer's
Notebook],
http://www.avg.com/R.o'?t=ww073 101&l=/wireless/Article.po'?id=223043, 7/25/2001
31
solution providers offer a secure tunneling option incorporating both existing security
measures and cryptography algorithms created by companies such as Certicom.
Additional authentication and authorization procedures can prevent unauthorized access
to sensitive company databases, and will maintain the integrity of those databases.
2.4.4
Battery Life
More than any other factor, battery size and capacity dictate handheld wireless device
form, function, and affordability. Most users rate battery life as one of the top features in
choosing a device, and so, it plays a critical role in the success of a handheld device. The
battery of a handheld device accounts for at least half of the weight and often up to a
quarter of the cost of a typical handheld. Battery life and CPU power are closely
correlated. The current development in CPU research has allowed more powerful
processor to be integrated into a mobile device. Device manufacturers also would like to
employ more powerful CPUs in their devices. However, with more powerful CPU, the
power consumption rate will shorten the battery life. The advances in battery lag well
behind the CPU development. One promising approach is to improve the battery's
controlling circuitry. These so-called smart batteries use embedded microprocessor chips
to control their charge and discharge rates, thereby extending battery life. This
technology has been applied successfully in laptop computer battery designs. Another
more active approach is to employ the latest fuel cell technology. Instead of storing
electrical charge in Lithium polymer or Lithium ion batteries, electric current is produced
in a fuel cell through a series of chemical reaction with hydrogen. Fuel cell could be a
viable alternative if engineers could solve or at least, reduce the risk of an explosion with
compressed or liquid hydrogen.
2.4.5
Obstacles Facing the Wireless Industry
Table 2.1 summarizes the limitations of the current crop of mobile devices when
compared to a traditional PC. The wireless industry has been working hard to tackle
some of these issues. The future of the whole industry will be dependent on how the
consumers respond to the solutions presented by the key players in the industry. For
example, Openwave (formerly, Phone.com) has created the wireless application protocol
(WAP) in an attempt to send and display Internet content on devices with small screens,
low bandwidth , significantly slow response times , minimum CPU processing power,
internal memory. So far, consumer response has been lukewarm, mainly because of the
slow data rates provided by the current generation of 2G networks. Nonetheless, WAP
represents a true "platform" that can work across different types of wireless networks
(2G, 2.5G, 3G and CDPD). In the next chapter, we will explore WAP, and compare it
with other alternatives.
21
22
anywhere from 300bps to 10Kbps
on the order of five to 10 seconds for round-trip transmissions
32
PC
Mobile
device
High bandwidth
Low bandwidth
Large screen
Small screen
Keyboard & mouse
Limited
Large memory
Small memory
Fast CPU
Slower CPU
Electric power
Limited battery
Table 2.1 Limitations of Mobile Devices
33
Chapter 3 WAP Issues
WAP is a set of specifications that controls how network servers provide content to
devices-specifically using Wireless Markup Language (WML). Although WAP is just
beginning in U.S. with limited availability on Internet phones, WAP-compliant Web sites
can usually be read successfully with other devices (such as Windows CE or Pocket PCbased handheld computers and Palm-based PDAs) with WML browsers.
With WAP, enterprise business application could become wireless-enabled applications.
The main beneficiaries of a wireless-enabled enterprise application architecture are sales
staff, customer service representatives, mobile support staff, managers, and any other
corporate knowledge workers. All of them can immediately benefit from quick and easy
access to contacts, schedules, e-mails as well as up-to-the-minute inventory tracking and
order entry with instantaneous confirmation. Furthermore, enterprise architects can
leverage WAP's push capabilities to enable the broadcast of business-critical or timesensitive information.
WAP is intended to integrate easily into existing Web architectures. If the company data
warehouse and other core systems are already delivered through a Web interface,
mobilizing them through a WAP interface is quite simple. WAP and the WML are
designed to work like HTTP and HTML. WML makes use of WAP to enable the
creation and use of a microbrowser optimized for small displays and low-speed dial-up
networks. WML's WMLScript component has been optimized for use on handheld
wireless devices by making minimal demands on memory and CPU usage.
3.1
Introduction to WAP
At its launch, WAP was touted as the key in the next generation mobile data networks.
WAP browsers were originally deployed on cell phones, but WAP-compliant Web sites
can be read successfully with PDAs or other handheld devices (with a generic WML
browser). Thus, WAP has subsequently been migrated to other mobile device markets as
well. WAP inherited from the Handheld Device Markup Language (HDML) developed
several years ago by Unwired Planet (now Openwave System). It acts as both a
communications protocol and an application environment. The goal of WAP is to create
a global wireless protocol specification that will work across different wireless network
technologies. WAP basically defines a mini-Web browser optimized for mobile
devices.2 Since WAP was designed to require minimal RAM, ROM, display, CPU and
bandwidth, it can handle different size displays, different navigation configurations, etc.
This is exactly one of the reasons why HTML browsers would never work in mobile
devices. Insufficient CPU power and internal memory and screen size also means that
current HTML Web pages cannot display information and interact with their users the
same way in PC. HTML browsers also would not work because they are not designed
for limited RAM/ROM devices, and are not prepared to handle one-thumb navigation
interface common in most handheld devices.
23
Wexler, J., Today's focus: What's up with WAP? Part I of 2, Network World, 7/24/01
34
Lastly, WAP attempts to enable the creation of content and applications that scale across
a wide range of bearer networks and device types, and to extend existing standards and
technologies. For example, WAP is designed to work with most airlink protocols. Its
business data architects do not have to worry whether the mobile data users are on a
CDMA, GSM or TDMA network. Since its inception, WAP was considered an
important step for the sub-20K bit/sec wireless networks in wide use today.
3.1.1
Business Strategy
In order to establish WAP as a cell phone standard, Openwave promoted an open
standard approach, and attempted to create the network effects by convincing every
major cell phone manufacturers to adopt the WAP browser. To further encourage cell
phone manufacturers to embrace WAP features, and third party software developers to
write software applications to take advantage of the standard WAP browser (much like
the plug-ins for Netscape and Internet Explorer), Openwave founded the WAP Forum.
The primary goal of the WAP Forum is to bring together companies from all segments of
the wireless industry value chain to ensure product interoperability and growth of
wireless market. Being the system architect of WAP, Openwave has to resolve conflicts
amongst the members, and form a bridge between the hardware manufacturers and the
application developers. Currently, the WAP Forum members represent over 90% of the
global handset market, carriers with more than 100 million subscribers, leading
infrastructure providers, software developers and other organizations providing solutions
to the wireless industry.
3.1.2
Market Strategy
Analysts or strategists often listed satisfying the voice of the customers as one of the key
market strategies. However, Openwave has to do more than just satisfy the customer
needs. It actually has to de-mystify a common misconception that users' Internet
experience on their mobile devices is mirroring that of their desktop Internet. Anyone
holding such misconception will come away sorely disappointed when he/she tests the
latest WAP-compatible phones. Openwave and the WAP Forum have to avoid overhyping the WAP to a point where it cannot meet its user's unrealistic expectation.
Creativity definitely plays a key role in WAP deployment. Ultimately, WAP's future will
be determined by the development of innovative applications that are unique to the
wireless environment, something beyond stock quotes, news stories, and weather updates.
This is the reason why Openwave and its WAP Forum members are working hard to
develop a new "killer app" for the WAP phones. Openwave is currently working with
third party software developers to explore using the WAP browser interface to sync backend corporate data. Furthermore, to portrait WAP as the centerpiece of the future mbusiness, Openwave works with hardware vendors to mimic the same looks and feels of
the Internet experience that most Web users come to expect.
35
3.1.3
Technology Strategy
While the picture painted by the WAP Forum is a pretty one, some ugliness is behind the
scenes; most users of today's WAP-enabled phones are disappointed with their
performance. Openwave has many technical challenges to overcome before delivering
what it has promised to its WAP users. For example, the phone screen display is too
limited for anything more than short messaging. Query to web sites is restricted to those
designed with structured information. Text input is impractical. To enter an URL like
"mobile.edmund.com" would take more than 35 keystrokes. It makes the text entry too
slow and painful. Furthermore, WAP-enabled phones are still too expensive for the mass
market.
On top of the problems mentioned above, Openwave needs to address issues like
Wireless telephony application (or WTA), end-to-end security, and interoperability.
These are the key areas that would play a critical role in determining the future of WAP.
Openwave has to work on the WTA issue as it remains absent from WAP version 1.1.
Once the specification is attained, these services must be implemented in the handsets
and servers and tested-internally for functionality and externally for interoperability. If
implemented properly, WTA could potentially provide both voice and data applications
in a way unlike anything wireless users have ever experienced in a traditional desktop
environment.
End-to-end security is another issue that WAP has to tackle. Currently, the Wireless
Transport Layer Security (WTLS) serves as the leg between the WAP client and the
WAP gateway. However, WTLS fails to provide an entire end-to-end solution. Coming
from the Web server, there is a translation point where the security language must be
converted from SSL to WTLS. At this point, data is decrypted and re-encrypted into
WTLS. Though the translation merely takes milliseconds, and occurs in the WAP
gateway memory, the decrypted data are vulnerable during this short period of time. This
is known as the "gap in WAP" issue. A total security solution can only be achieved if
the proxy is trusted or collocated with the server. The WAP Forum is currently working
on a new standard, which allows companies to run their own WTLS sessions behind their
firewall. To date, additional measures beyond those taken by the WAP Forum to protect
against this "gap in WAP" have been minimal.
Complexity arises as the wireless Internet complicates the runtime environment further.
WAP access to Internet applications adds three layers to the application (i.e., three more
possible points of failure): the microbrowser of the cell phone or the PDA, the WAP
gateway, and the wireless network connection. Wireless Internet applications are
therefore inherently more susceptible to failure than fixed Internet and client server
applications, which underlines the need for pre-launch testing.
Interoperability is another big issue for WAP. Complete interoperability has to be
established between devices and gateways, as well as between gateways and browsers.
Currently, WAP consists of an environment in which at least twenty-seven WAP-enabled
phones (and more in the future) must comply with over five different gateways, which
36
are supported by the constantly upgraded versions of WAP. To put this chaos under
control, interoperability is necessary. Since about 30% of the WAP standard remain
undecided, handset developers and browser developers could potentially produce
different versions. The interoperability issue goes beyond network operators. Any
company intending to set up WAP sites has to run tests to ensure compliance with all
available handsets and gateways. Consumers are forced to continuously upgrade their
handsets. In addition, because of the influx of different handsets, devices, and PDAs,
WAP applications must be constantly modified to provide compatible user interfaces.
By the end of 2002, the gateway vendors should have field-tested with the WAP Forum's
certification of interoperability standards. Because of the variance in devices and
gateways in today's market, interoperation will most likely determine the fate of WAP. A
seamless network will most likely go unrecognized. Any glitches in the networks will
directly impact the users and their WAP experience. If users have trouble accessing the
Internet because of incompatibility between browser and gateway, or they are constantly
asked to upgrade to their handsets to comply with the latest standards, they will look for
other better options and WAP will suffer. System interoperability is the top priority for
WAP.
3.2
The WAP Protocol Stack
The WAP protocol stack has five layers on top of the lowest level bearer services (see
Fig. 3.1 below). Although each layer is accessible by non-WAP applications, not every
layer is required in a WAP implementation.
The first layer at the top is Wireless Application Environment (WAE). It is a generalpurpose application architecture that fits into the WAP architecture. The WAE model is
designed to enable applications to run on wireless phones and other devices with limited
memory, power, and screen sizes. Those who have developed applications for Palm OS
or Windows CE devices have already faced the challenge of delivering a rich and
practical user experience on a restrictive device. The types of devices that are targeted by
WAE take this to the extreme.
WAE is also intended to make running distributed applications possible over networks
with narrow bandwidth, while providing adequate security. The members of the WAP
Forum are also keen on ensuring that WAP and WAE are global standards that support
multiple languages, bi-directionality, diverse input methods, and a wide range of wireless
network technologies.
WAE is intended to leverage the familiarity and simple elegance of the World Wide Web
(WWW). It consists of the following components: a microbrowser specification,
Wireless Markup Language (WML), WMLScript and Wireless Telephony Applications
(WTA). WML, which we will discuss more later in this chapter, is based on XML, and is
optimized for small devices such as cell phones and PDAs. WMLScript is similar to
JavaScript in the PC world both in form and purpose. To facilitate rapid movement of
37
content over tiny wireless pipes, the WAP architecture specifies compressed encoding of
WML and byte-code encoding of WMLScript. This is mostly transparent to those
building enterprise components and applications at the higher layers of WAP. WTA
provides the framework to access telephony commands using WML and WMLScript.
Application Layer
Wireless Application Environment (WAE)
Session Layer
Wireless Session Protocol (WSP)
Transaction Layer
Security Layer
Transport Layer
Network Layer
Wireless Transactional Protocol (WTP)
Wireless Transport Layer Security (WTLS)
Wireless Datagram Protocol (WDP)
Wireless Bearers: CDPD, 2G, 2.5G 3G
Fig. 3.1 The WAP Protocol Stack
Below WTA, there is Wireless Session Protocol (WSP). It is analogous to the Hyper
Text Transfer Protocol (HTTP), but it is not equivalent. WSP provides physical data
connectivity. It provides two session services, one that uses Wireless Transactional
Protocol (WTP) to provide connections and one that operates in a connectionless manner
over secure or non-secure Wireless Datagram Protocol (WDP). The WSP specification
currently provides support for browsing via an optimized ementation of HTTP/ 1.1 and
sophisticated session facilities such as state maintenance, suspend, and resume.
Below WTP is the Wireless Transport Layer Security (WTLS). WTLS provides data
integrity, privacy, authentication, and a degree of denial-of-service protection. Finally, at
the bottom of the WAP Protocol Stack is the transport layer-Wireless Datagram
Protocol (WDP). WDP isolates the higher layers from the bearer-specific network
details. Bearer services might be short message, circuit-switched data, or packet data.
The WDP Specification lists currently supported bearers, and new bearers will be added
as needed. Alternately, some WAP applications can run on top of UDP over IP networks
and do not even require WDP.
38
3.3
The WAP Architecture
Not only does WAP borrow from standard HTML Web programming and network
models, WAP content can also be served from the same HTTP servers in most real world
applications. On the Web, the application model has a client (most often a browser on a
PC platform) that sends requests for data to a server (possibly via a proxy server). The
server responds to the client request with data, and sends it via HTTP to the client. In the
WAP model, client requests from the browser of a mobile phone or other wireless device
are funneled through a WAP gateway on their way to the server and back out to the
wireless client (see Fig. 3.2). This makes the WAP gateway an important component of
an enterprise WAP architecture. It is responsible for encoding and decoding data while
minimizing its size and complexity.
Supply-Chain
mgt application
Company Gateway/
Firewall
ERP Sys
Web Server
Sales/Marketing
CRM Sys
Middleware
*application server
'synchronization server
.data transformation/
Internet Users
VPN Users
Wireless Server
*WAP
*i-Mode
*extraction
Wireless Gateway
Wireless Devices
Wireless Network Provider
Fig. 3.2 The WAP Architecture
Generating WML content is very much like generating HTML. Although Web
developers will likely have to rewrite the Web query applications and HTML output
generators to accommodate the special requirements of the WML and WAP browser,
they could leave the rest of the process to the WAP proxy server (Fig. 3.3 below shows
three ways to generate WML content: generated directly at the Web server, generated via
an external transcoding filter process, or generated by WAP proxy server itself). In
most cases, WAP proxy server could be used either as a WAP gateway to other Web
servers over HTTP, or it can operate standalone. The WAP gateway compresses WML
information and sends it off to the device that requested it. Unlike HTML, WML breaks
the page paradigm in favor of a deck-and-card structure to accommodate the inherent
latency associated with wireless communication. WML uses the deck-and-card model to
24
The WAP Server can serve static WML content or interactive applications via Java servlets.
39
batch up cards into logical bundles. A deck (analogous to a Web URL) is a document that
contains a set of cards. Like HTML, decks can either be static or dynamically generated
in response to a specific request. The concept of a "card" is new in WML. Depending on
the actual implementations, a card is basically a logical set of data to be displayed on the
same screen. Because of the latency issues common in most mobile devices, this deckand-card structure allows WML data to be transmitted and displayed in smaller chunks.
The intent is to improve the user experience of mobile devices despite their poor network
connectivity and small screen sizes.
Filter
HTMl
WML
HIM(,
WM1_
Web
Server
H I
ML
FiterWM
WAP Proxy
Server,
Fig. 3.3 Typical WAP Network Infrastructure25
3.4
Wireless Markup Language (WML)
To fully appreciate WAP, one has to understand WML, the native language of WAP.
WML was specifically designed to work with mobile devices, which typically have small
screen size, limited bandwidth and user input constraints. To alleviate some of the
limitations, WML could only provide text and limited image support, along with
formatting commands. Just as HTML is broken into small units called Web pages, WML
is segmented into units called "cards" and grouped into "decks." The WML deck is also
similar to HTML pages in that it is invoked by reference to a URL. In addition to
formatting syntax, WML offers features such as event handling and variable/parameter
substitution. Beyond this, however, WML inherits most of its syntax constructs from
XML. Table 2 below illustrates common WML tags. WML is a simple language
because it is composed of only thirty-five tags and associated attributes. Fourteen of such
WML tags have no analog in HTML 4.01. Two of the attributes, class and id, are
available for all tags and serve the same purpose as their counterparts in HTML.
There are a few rules that WML developers have to follow. The WML tag and attribute
names are always in lower case. Like XML, all WML tags must be closed. For self25
Jurvis, J., WAE to Go, Web Builder, Volume 5, No. 3, Fall
2000
40
closing tags, they have to end with a space and slash (e.g. <noop />). An open and closed
WML tag is commonly referred to as a WML element. Unlike HTML, all text must be
contained in a valid WML element. There is no freestanding text. 2 6
<a>
<b>
<card>
<fieldset>
i>
<meta>
<access>
<big>
<do>
<go>
<img>
<noop>
<optgroup>
<option>
<p>
<postfield>
<select>
<strong>
<template>
<prev>
<setvar>
<table>
<timer>
<refresh>
<small>
<td>
<tr>
<U>
<wml>
<anchor>
<br>
<em>
<head>
<input>
<onevent>
Table 3.1 WML Data Types
27
Any text editor is good to create a WML deck. WML development kits are readily
available over the Internet. A WML development environment typically provides XML
validation, which could be useful if the WML content is intended to be transformed to
XML later.
Just like in HTML, there is a lot freedom in terms of generating a WML page. A typical
WML program could probably look like the following:
<?xml version=" 1.0"?>
<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML
I . 1//EN""http://ww.wapforum.org/DTD/wml_1.1 .xml">
<wml>
<card id="Palm VII X" title="Palm VIIX Info">
<p>
Palm V1I X
Our Price: $ 268.99
Stock Status: [YES]
<P>
</card>
</wml>
The first couple of lines denote the origin of WML, and how it is closely related to XML.
As illustrated in Table 3.1 above, most of the WML tags are self-explanatory, and in most
26
http://www.devguru.com/Technologies/wml/quickref/wml
27
http://www.bigwapsite.co.uk/tags.htm
intro.html
41
cases, are very similar to HTML tags. The major differences are the <wml> and <card>
reflecting the deck-and-card approach of WML.
Similar to HTML, WML can also be integrated with a JAVA servlet. The example
presented in Appendix I illustrates how a wireless application can be developed using
WML to allow a cell phone user to place orders over the Internet. The example is
structured to call a servlet from 127.0.0.1 (the local host address). The simple servlet
presented here is fully functional. It processes, validates, accepts, and stores transactions
in a relational database. These transactions that originated from a cellular phone are
transmitted to the servlet using WML and WAP.
In this example, we will assume that a relational database containing customer order
information already exists. In this database, there is a table containing columns for
OrderNumber, FirstName, LastName, Street, City, State, Zip, and Product. The table is
contained in an Access97 database named wmldb.mdb, which can be accessed using
JDBC ODBC driver. In practice, any supported drivers and relational databases are
supported. Though the host does not require to install Access97 to access the database, a
Access ODBC driver is needed. We'll use this information to develop our graphical user
interface, which in our case consists of a single WML deck (see Listing 1 in Appendix I).
The purpose of this WML deck is simply to capture the order information entered by the
customer and pass it along to the WMLServlet. The WML will generate a series of
options that can be selected using the cell phone keypad. In terms of servlet processing,
the most significant part of the WML is the line
<go method="post" href=
"http://127.0.0.1:8080/servlet/
WMLServlet">
It uses the POST method to upload the customer information to the WMLServlet. The
location of the servlet is specified by the server's IP address (127.0.0.1, the local host
address in this case), port (8080), and the servlet path (servlet), as well as the name of the
servlet itself (WMLServlet). When the user selects Submit, the information is sent to the
servlet.
The first three statements are standard XML and state the version, document type
definition (DTD) 28 of WML, and namespace. The root element is also WML.
<?xml version=" 1.0"9>
<!DOCTYPE wml PUBLIC
"-//WAPFORUM//DTD WML 1.1//EN"
"http://www.wapforum.org/DTD/
wml_1.l.xml">
A DTD is a collection of declarations that define the legal structure, elements, and
attributes that are
available for use in a document. A more detailed discussion of DTD is presented in a later chapter.
28
42
<wml>
The next statement
<card id="card 1" title="WML EC" newcontext="true">
identifies the card in the WML deck, generates a title in the cell phone display, and flags
that this is a new context. The next block of statements
OrderNumber:<input format="*N"
name="order _number"
title="Order Num.:" value="00 "/>
<br/>
correlates the input fields with the database fields, as well as setting the input format.
The next code block is a "do" construct of the form
<do type="accept" label="Submit">
<go method="post" href-"http://
127.0.0.1:8080/servlet/
WMLServlet">
<postfield name="firstname" value=
'$(firstname)' />
This "do" construct posts the input values to the servlet and to the database. The "accept"
type is given a display label of Submit. Note that each postfield is given a name, which
must correlate to the servlet field names, and the values are passed to the servlet using the
syntax $(first-name).
Finally, there is another "do" construct which allows the user to display a help card.
The WMLServlet, in turn, accepts the posted information and passes it to the WMLtoDB
class object instance for processing (see Listing 2 in Appendix II). WML toDB accepts
and sends WML to the user interface. Database, user id, and password values are
initialized. The doPosto method of the HttpServlet class creates instances of the
HttpServletRequest and HttpServletResponse objects and generates a ServletException
or IOException if errors are found.
It is important to note that the content of the response is set to WML using the statement
html response.setContentType("text/vnd.wap.wml"). A PrintWriter object is instantiated
so it can be used to write WML- text back to the cell phone display with the response.
The database column values posted from the WML card are passed as parameters. The
transaction verification from the PrintWriter object to the browser is defined. Connection
to the database using JDBC is then established and a WMLtoDB object is instantiated. A
43
message telling the database to do the SQL using the order information supplied by the
customer is sent.
The WMLtoDB class updates the database with this information using SQL through
JDBC. The class implements the serializable interface, which allows the servlet to
provide a persistent state to the data it processes. First, all database column values are set
in the constructor. Next, the dothe _sql() method instantiates a JDBC Statement object.
The syntax to perform the SQL Insert is built using the database column information
supplied. This syntax is passed by the executeUpdate() method to the JDBC statement
object. If there is a problem with the update, a SQLException is thrown. Note that the
code is liberally sprinkled with System.out.println messages for trouble-shooting. This
information will be displayed on the server console.
While this example is a relatively simple application of WML, the possibilities are
limited only by the constraints of limited display size and bandwidth. For example, a
European investment bank provides not only stock market quotes but also stock trend
graphs to its customers using WAP-enabled cell phones. Limitations often inspire
creativity to overcome them. In a certain way, it is deja vu all over again. In the early
days of microcomputers constraints of memory and processor speed sparked some
remarkable breakthroughs. If past is prologue, the wireless Web revolution will change
everything again.
3.5
Alternatives to WML/WAP
WAP is not the only way to distribute and display Internet content across different mobile
platforms. Other initiatives are also contributing to the wireless Web revolution. i-Mode,
for instance, has taken Japan (and some parts of Asia) by storm. In this section, we will
discuss how i-Mode works and what are the fundamental differences between i-Mode and
WAP.
3.5.1
i-Mode & cHTML
NTT DoCoMo has dominated more than 70% of the Japanese wireless market (in terms
of subscribers). Its wireless i-Mode (the "i" stands for information) service is often cited
as the biggest threat to WAP. Contrary to the current WAP implementations, i-Mode is
an "always-on" technology, which relies on packet data transmission.
One of the many reasons that i-Mode has been so successful in Japan is its billing
structure. As i-Mode is based on a packet-data (9.6 kbps) transmission system,
subscribers are charged by the volume of data transmitted, not the time spent on line
(unlike the current WAP implementations). With the "always on" connection, this
method is necessary as the time spent is unlimited. The billing structure encourages iMode users to be on the wireless Web. The change in user behavior induces quick
adoption of i-Mode in Japan, while the WAP community continues to struggle as a whole
44
(the users are frustrated with the slow download speed and the wireless
developers/service providers are disappointed with the slow adoption rate).
The billing structure also affects the i-Mode adoption rate in another way. Unlike their
WAP counterparts, i-Mode users do not need a credit card to purchase online, as the their
purchases are directly added to their mobile phone bills. It is particularly important for
companies targeting at younger audiences who do not have credit cards, or those who are
not comfortable in sending out their credit card numbers during a "wireless" purchase
transaction.
Typical Japanese wireless users have had good experience with i-Mode because the
Japanese characters are more concise than the English language, making messages so
much easier to transmit. Another success factor that is somewhat related is consumer
expectations. In Japan, the household Internet penetration rate is far lower than in the
United States. To many Japanese, their wireless device is their first and only way to
"surf' the Web. Furthermore, typical Americans have far more broadband experience in
their office or at home than their Japanese counterparts. As a result, Japanese wireless
users are more tolerant of slow download speed because of their low expectation to begin
with. This, perhaps, explains why many American mobile users complain about their
WAP experience, and why Japanese users enjoy their i-Mode handsets.
Finally, DoCoMo's near monopoly power in Japan should be credited for the success of iMode. Unlike the United States, where the value chain of the cell phone business is
badly fragmented, NTT DoCoMo is a vertically integrated enterprise, and its dominance
can be reflected from the initial system design of i-Mode to the specification of wireless
handsets to the backend infrastructure to content creation. Because of its strong market
presence in the wireless space, a single dominant design (basically DoCoMo's) could be
established easily in Japan, and thereby, the kind of confusion facing the American
wireless users could be avoided (see section 2.3.2).
3.5.2
WAP vs. i-Mode
Although WAP and i-Mode both allow users to access Web-based information with
transactional capabilities from a mobile phone, there are some major technical
differences. The first difference is the programming language. WAP uses the wireless
markup language (WML) while i-Mode uses cHTML (Compact HTML). cHTML is a
subset of HTML 2.0, 3.2 and 4.0. This explains why cHTML and HTML are so similar.
Table 3.2 below shows the default cHTML tags.
45
!-
->
<BODY>
<DD>
<H>
<INPUT>
<OPTION>
<SELECT>
<A>
<BR>
<DIV>
<HR>
<LI>
<P>
<TEXTAREA>
<BASE>
<CENTER>
<FORM>
<HTML>
<MENU>
<PLAINTEXT>
<TITLE>
<BLOCKQUOTE>
<DIR>
<HEAD>
<IMG>
<OL>
<PRE>
<UL>
Table 3.2 cHTML Language Reference
As illustrated in the tags above, cHTML is really just a stripped down version of a fullblown HTML. For those Web developers, who are familiar with HTML programming,
constructing cHTML pages is technically straightforward. This holds an important
advantage over WML in which the learning curve is much steeper because of its XML
origin. Furthermore, because i-Mode uses common HTML tags, cHTML pages created
for display on handsets can also be seen on PC and vice versa. This means that i-Mode
Web developers can test how the content would look in a traditional Web browser
without needing to use a mobile phone all the time. 29 Unlike their WML counterparts,
who typically need a WAP toolkit for their code development, i-Mode developers could
significantly cut down cHTML development time, and enjoys a level of convenience
WML developers could only dream of. However, this advantage should be short-lived.
There is little doubt that the future of Internet content serving is XML. The XML
learning curve is hardly noticeable for WML programmers, but it would be much more
difficult for cHTML developers to make the transition. So, in the long run, WML (or
WAP) is a technology that is favored by most wireless Web developers.
The second difference between WAP and i-Mode is that i-Mode is an always-on
connection. This means that unlike the current WAP implementation on the 2G phones, iMode users do not have to 'dial up' to access a site and email is instantly sent to their
phone. Until the new "always-on" 2.5G and 3G networks are in place, WAP users will
not enjoy the same level of convenience as their Japanese counterparts.
So far, we have discussed many advantages of i-Mode and cHTML. WML and WAP
also have their own strengths. In addition to displaying static data, WML is capable of
handling limited multimedia (video and audio) applications. This has always been a
weak area in cHTML and i-Mode because they were not designed to do so. Also, while
WMLScript basically does what JavaScript can do on a standard PC platform, no client
side scripting languages are currently supported in cHTML. This has severely limited the
complexity of the i-Mode Web sites. On other hand, WMLScript can work with WML,
and that allows Web developers more freedom to write programs that engage the users
more interactively.
29
http://www.wirelessinanutshe11.com/imode/
46
3.6
Final Thoughts on WAP
As we have illustrated here, there are both advantages and disadvantages in WAP and iMode. To borrow Foster's S-curve framework, both technologies are probably still in
the ferment phase, and there are still a lot of technical advancement in the wireless areas
that could affect the fate of these two technologies. Nonetheless, it is important to realize
that i-Mode is probably not the WAP killer the media has been waiting for. Just because
they are similar does not necessary mean it could turn into the famous Betamax and VHS
battle again. As a matter of fact, there will be a lot of collaborations between the two
camps in the near future, and they will learn how to complement one with the other.
While the current versions of WAP and i-Mode are not compatible, WAP 2.0
specifications are being created so as to take the i-Mode specifications into
considerations, and therefore, WAP 2.0 should become more like its Asian counterpart.
On the i-Mode's side, it is important to realize that DoCoMo is still an active participant
in the WAP Forum even though it has enjoyed tremendous success with i-Mode. There
are some indications that DoCoMo will abandon cHTML to give room for XHTML.
Interestingly, the WAP community is also pursuing in the same direction. The next
version of WAP (probably after version 2.0) would also be XHTML compatible. Thus, it
is very likely that a convergence between the two mobile Internet technology standards is
on the horizon. For this reason, this thesis treats WAP and i-Mode as a single platform.
In summary, both WAP and i-Mode are highly marketable wireless technologies. It is
unfortunate that WAP has not been as well received as it deserves. In a sense, WAP has
been a victim of itself. Before its launch, WAP was hailed as the future for mobile
communication, entertainment and commerce. The hype was massive and expectations
were almost unrealistic. As a result, after some of the users have now tried the WAP
technology, they are disappointed with the present offerings. To be fair, WAP has been
debuted on the slower circuit-switching 2G networks while i-Mode was launched on a
slightly more advanced packet-switching network. Even so, WAP has made a jump in
mobile technology, and we can now email, purchase and access data on the movesomething we could not do a little while ago. After the hype has died down, most of the
mobile users would realize that the current offering of WAP represents only a glimpse of
what to come in the future. With the faster 2.5G or 3G networks being deployed in the
next few years, WAP users should finally be able to take full advantage of its capability.
On other hand, it would be inaccurate to conclude that i-Mode could overtake WAP's
leading position in the wireless race. Even without a convergence between the two, iMode will experience its share of growing pains. The initial popularity of i-Mode was a
direct result of Japan's early implementation of packet-switched wireless networks. Once
the 3G packet-based data networks are widely implemented in the U.S. or Europe, WAP
should be able to eventually surpass the early success of i-Mode. Furthermore,
household Internet penetration in Japan is growing, and their mobile users are expecting
more from their i-Mode handsets. As a result, the Japanese users could conceivably be
getting less tolerant of congested networks due to the popularity of i-Mode. Lastly, since
DoCoMo recently has plans to expand their services into the European market, it is very
47
likely that i-Mode will experience the same problems as WAP has faced since the
beginning.
48
Chapter 4
Building Multiple Version of Company Wireless Web Sites
Both WAP and i-Mode are regarded as "common" platforms to develop wireless web
sites for. However, their actual implementations (especially for WAP) could be quite
different across various mobile devices. As discussed previously, interoperability is a
major issue for WAP. Different WAP-enabled mobile devices have different physical
properties (i.e. screen size, user interface, memory, processors and even bandwidth), and
thus, there is a lot of tweaking involved to render the same Web page for each
configuration. Some companies have been trying to develop multiple mobile versions of
their company Web sites. The advantage of this brute force approach is obvious. Users
on different mobile devices can be sure of the quality of the wireless Web page.
However, building and maintaining multiple versions of the Web sites could be a very
dangerous endeavor. The problem is scalability. Once companies have chosen which
markup language (basically, HTML, WML or cHTML), they have to decide which kind
of mobile device types they want to support. If a company wants to support all mobile
devices in all markup languages, the task could turn out to be unmanageable for most
companies.
4.1 Perils of Multiple Version Approach
Let us use Barpoint.com as an example. Barpoint.com is an e-tailer, whose wireless
strategy had nearly put Barpoint.com out of business. Originally, the company wanted to
zap product reviews and specs to shopper's mobile devices. The trouble was that
Barpoint needed to create customized versions of its site for different cell phones, PDAs
and pagers the shoppers might use. Since each device has its own specific screen size,
arrangement of buttons, protocols, and user interface, the staff at Barpoint.com was
frantically trying to maintain more than ninety versions of the company wireless web
sites at a point. That effort sucked in every available employee, pulling many away from
his or her regular duties and causing the company's core business to suffer. Although this
Barpoint case is mainly a business-to-consumer (B2C) example, there is much to be
learned for enterprises, which are interested in mobilizing corporate data in the businessto-employees (B2E) and business-to-business (B2B) arenas. For example, for a typical
size American enterprise, it might not need to maintain more than ninety different
versions of its wireless web sites as Barpoint did. However, a wireless initiative could
grow complicated very quickly if an enterprise has many business partners (given the fact
that the enterprise has no control over which type of mobile device the end user would
operate with), and it has to share ERP data with them.
Barpoint's experience highlights the onerous reality behind rolling out wireless services.
Unlike the traditional wired Web, the wireless world is fragmented by competing devices,
carriers and standards (as indicated in the earlier chapters of this thesis). Some cell
phones support the WAP standard, while others support earlier versions of handheld
device markup language. Some handheld products even rely on an altogether different
set of communications standards. Furthermore, because different carriers implement
49
their wireless gateways differently, data may appear one way on a Sprint WAP phone and
in another way on a Verizon WAP phone.
The lack of uniformity causes headaches for businesses trying to create a consistent
wireless version of their sites. The pain proved so debilitating for Barpoint that it finally
overhauled its entire development process. Rather than building countless individual
wireless sites from the ground up, Barpoint transferred its development efforts to a
wireless publishing platform by Brience.
4.2 Other Alternatives
With careful planning, developing a wireless strategy does not always have to end up
with a failure. In the case of Barpoint, it may not be necessary to build and maintain
various versions of the company Web sites. In fact, there are transcoding and web
wrapping techniques that a company like Barpoint should consider at the beginning. Fig.
4.1 below details how to implement transcoding. Transcoding is a way to transform
HTML data source into WML (or cHTML for i-Mode). It works fairly well (more in a
later chapter) in general but some fine-tunings are necessary before putting the WML
codes in production. For example, the HTML to WML transformation can be crude and
so, some minor modifications are still needed (depending on the intelligence of the
transcoder). Since the transcoding process is never concise, it tends to send excessive
data to the mobile users. The resulting WML web sites must be cleaned up, or they may
cause latency problem during transmission.
HTML
.. PC Users
Source
HTML
+
WML
Transform
(transcoding)
_______
I
Wireless
Users
Fig. 4.1 Transcoding Technique
50
Web wrapping represents another alternative. In order for Web wrapping to work
properly, a spec file with "wrapping" rules has to be defined (see Fig. 4.2 below). A
spec file typically contains schema, navigation rules, and extraction rules. Once the data
is extracted, it has to be presented into the WML format. This technique works primarily
for semi-structured HTML web sites (a professionally developed company Web site
tends to fall in this category) to extract specific pieces of data. Thus, it is a useful
technology in a limited bandwidth environment. We will explore this technology further
in the next chapter.
PC Users
W
HTML
Source
'I/
-.0
Web
"wrapping" ~
WML
Assembly
wrapping"
rules
4I00OF
Wireless
Users
Fig. 4.2 Web Wrapping Technique
The third approach involves leveraging the flexibility and extensibility of XHTML and
XML (we will discuss them both in later chapters). Both technologies promise quick
conversion from XML (or XHTML) to other markup languages like WML. In this case,
a common XML (or XHTML) source can be built for PC and mobile device users (see
Fig. 4.3 below). Using proper extensible style sheets (XSL), the same XML data can be
transformed into HTML for PC users and WML for mobile users. Although XML is
powerful, it faces many challenges. One of them is that most. existing (legacy) systems
do not use XML, and so, they would need to be modified to support it. As a result, the
functionality and interaction for mobile users might be different.
51
XML
HTML
Transftorm
""
...
XML
PC Users
Source
XML
WML
Transform
A0e
Wireless
Users
Fig. 4.3 XML Transformation
J2ME is certainly another feasible option, with its "write once, work everywhere"
concept. In the PC world, there is only one major platform: Windows 30 . Developers can
create programs that run on Windows and be sure to hit a huge market. But in wireless,
there are dozens of different makers and devices, each running its own OS, all with
different kinds of electronic innards. It has become a developer's nightmare. Programs
might be written for one kind of phone, but they do not work on others. This is why
J2ME can be so attractive. It is conceivable that developers could potentially write a
wrapper interface program or a browser that could work across different mobile devices
with different configurations.
Lastly, companies that intend to mobilize their corporate data could wait for a
microbrowser product (such as Pixo's) that could handle both HTML- and WMLencoded documents. Exactly how well Pixo's microbrowser works is anyone's guess, but
it shows that there are vendors out there paying close attention to the needs of the
wireless users. As a matter of fact, there are also wireless application service providers
(WASPs) that manage the transcoding or web wrapping processes for their clients if the
wireless initiative is being outsourced. In the next chapter, we will discuss more on this
subject.
Although various forms of Linux dominate the server market, Windows is still the
most common
operating system (OS) for a PC client.
30
52
Chapter 5 M-Business Enablers & Wireless Application Service
Providers
Since wireless handheld devices and Web-based wireless services can have a significant
impact on workforce productivity and e-commerce, it is no surprise that corporations are
attracted to the idea of providing their employees with real-time access to corporate
information and transactional capabilities. Numerous wireless Web services and portals
have launched for Internet-enabled cellular phones and wireless PDAs. This access-itanywhere paradigm is quickly being applied to business content.
As a result, many forward-looking companies are modifying their Web sites to be
wireless-device-friendly allowing them to conduct key business functions wirelessly
across the Internet, Intranets and extranets. Since there is a demand in the market, many
technology consulting companies and service providers are developing and deploying
Web-based mobile computing solutions for their clients, providing access to groupware,
information services , and back-end data stores anywhere, any time. Using a device's
interactive messaging functionality, these mobile solutions even allow company
professionals to receive and respond to event-triggered alerts.
5.1
Wireless Application Service Providers (WASP)
Given the potential benefits of mobile enterprise business application, it is safe to predict
that more corporate-wireless applications will be developed over time, and functionality
will only improve as network bandwidth increases and device capabilities improve.
According to some analysts' estimates, the number of wireless Internet connections
should overtake wired connections within three years. With this kind of prediction, some
companies have attempted to create a mobilized version of their Web sites. It is a risky
undertaking as we have learned from the Barpoint's failure. As a matter of fact, more
wireless attempts end in failure than success. To help companies mobilize their web
sites, Wireless Application Service Providers (WASP) like AvantGo, 2Roam,
AnyDevice, Everypath and JP Systems are established. To be fair, these companies face
the same type of technical issues as Barpoint encountered. The only difference is that
they have dedicated staff that specializes in dealing with those thorny mobilizing issues.
Thus, the clients could just hand over their corporate data, and the WASPs could take
care of the rest. As a matter of fact, many of these WASPs have partnerships with the
wireless infrastructure companies to provide mobile Internet access, and so, they could
become an end-to-end solution provider offering services like content management and
wireless web servers.
Take AvantGo for example. In the first few years of its existence, AvantGo focused on
becoming a leader in the consumer wireless space. It offered PDA users free software
download that allows devices to receive content from popular Internet sites, including
including email and calendar functions
such as performing order entry and tracking, reviewing sales forecasts and inventory status, and
gathering customers transaction and interaction histories
3
32
53
The New York Times and Salon, on their PDAs. With the recent release of AvantGo
Enterprise, AvantGo has shifted its focus to corporations. The move was coincided with
the efforts exhibited by Palm and Microsoft in attracting larger and potentially more
lucrative corporate accounts. While many companies support the devices their
employees purchased it is unclear how many of them will actually consider the mobile
devices as productivity tools for their workforces.
AvantGo Enterprise provides corporate applications, database information and content to
employees' devices. AvantGo charges its corporate customers a one-time set up fee and a
per user charge. The service is targeted at companies using sales force automation
software, document collaboration applications and real-time customer support.
With the introduction of AvantGo Enterprise Online, AvantGo gives organizations the
flexibility to choose how they deliver their mobile applications. AvantGo's corporate
solutions include AvantGo Enterprise Interactive and AvantGo Enterprise Publisher.
AvantGo Enterprise provides centralized administration of mobile devices multi-server
scalability and load balancing, device and server-side APIs to connect handheld
applications to back-end databases, and real-time (when the wireless connection is active)
or queued (when off-line) data exchange between devices and the server. Imagine a
warehouse worker with a PDA receiving new orders online, filling orders off-line, and
then updating order status online. AvantGo Publisher lets companies publish such
corporate information as catalogs, pricing sheets, technical specs, and Web pages to a
handheld wireless device in real time (or offline via synchronization methods). AvantGo
recently introduced AvantGo Enterprise Online for hosting mobile applications.
One of AvantGo's customers is McKesson. McKesson is the world's leading healthcare
and supply management information technology company, and it was able to reduce
imaging costs by 100 percent, legal claims by 50 percent, order errors by 50 percent and
delivery claims by 30 percent by implementing a Palm-based handheld solution in its vast
product delivery network.
McKesson drivers, making more than 25,000 deliveries of pharmaceutical and supplies
every day, claimed an error rate of less than one percent in collecting signatures from
delivery recipients. But that small percentage was very costly. The papers that held the
signatures, when lost or misplaced, subjected McKesson to disputes and potential
litigation. As a result, the company was spending significant effort and dollars annually
on tracking and scanning the paper signatures and correcting errors when they occurred. 3
Today, using AvantGo Enterprise software on Palm OS based handheld devices,
McKesson drivers scan each package as it comes off the truck and electronically capture
the customer signatures. The information is then synchronized via the Internet and
integrated with the company's existing backend systems, providing instant updates and
immediate customer access to the electronic "proof of delivery" data. As a result of this
streamlined and automated process, McKesson has eliminated the need for paper tracking
3
Palm, Inc., Palm PoweredHandhelds Drive ROI Gains, Press Release, 8/23/01
54
and reduced its claims and errors substantially. Furthermore, McKesson's information
tracking systems are now more accurate than ever.
Synchrologic is another WASP that appears to have taken a leadership position in
providing an integrated suite of products designed to support the mandatory
synchronization and data management capabilities required by the mobile enterprise.
Synchrologic, Inc. provides a comprehensive set of solutions designed to address the
mobile infrastructure needs of the global, extended enterprise. The company's iMobile
Suite enables companies to manage the synchronization, distribution, and control of data
to mobile users across a range of laptop-, PDA-, and cellular-telephone-based devices. It
is worth noting that the company's products will support a combination of device types
such as laptops and PDAs from the same product suite, and provide the necessary
synchronization, file management, software distribution, and systems management
capabilities described above. iMobile Suite is particularly designed for the
synchronization of complex, mission-critical, enterprise-wide data and applications with
mobile laptops and PDAs.
JP Systems is a mobile application service provider that has been developing and
marketing wireless products and solutions for four years. The company operates a
wireless portal site for end users and employees its InfoBearm client/server technology to
provide complete wireless-data solutions for ISPs, ASPs and enterprises. JP Systems
builds customized corporate wireless applications, including both client and back-end
software, host wireless applications and negotiates contracts with wireless network
service providers. InfoBeam includes many of the same features as other wireless servers
and JP Systems leverages the technology to build customized turnkey vertical market
wireless solutions for consulting industry, field service operations, financial institutions,
healthcare industry, network management, sales force automation, supply chain
management and transportation and recreation companies.
Wireless Knowledge is another company exploring this arena. It was a joint venture
between Microsoft and Qualcomm. Wireless Knowledge has attempted to create a
standard for wireless data transformation. It has a product called Anystyle, which
synchronizes data automatically over the air whenever the device is within network
range. That data is then saved for offline use until the next automatic update. Since the
application does not require a cradle, mobile users will be able to access and interact with
corporate data at any time from any location, eliminating the need to connect to the
Internet or the corporate network. In addition, the company said the software would let
users access important data regardless of wireless network coverage. Because Anystyle
lets mobile professionals manage what information and how much information is sent to
the device, users will gain greater control over their most critical corporate data. Using
Anystyle, customers can wirelessly access corporate data inside the firewall, connected to
the Internet or using wireless devices with offline capabilities. Anystyle can be installed
on the same server as the company's Workstyle Server, providing a one-server solution
with multiple device support.
55
Lastly, another newcomer called AlterEgo Networks recently announced its innovative
"Adaptive Network Services" that deserves considerations as well. The service is
comprised of a distributed network of scalable high-speed servers attached to the high
speed Inter NAP network infrastructure. For no cost, AlterEgo works with its customers
(Web content providers) to develop a set of HTML conversion rules (based on XML) that
can be applied against original HTML content from the customer's Web site. These rules
might do things like replace graphics with text or reduce graphics' size and/or resolution
by certain percentages depending on the capability of the target wireless device. Data
requested from a company's Web site destined for a mobile device will pass through
AlterEgo's Adaptation Servers and Image Transformation Servers prior to delivery,
where the data will be reformatted with the predefined conversion rules applied against
the original HTML on the fly (without modifying the actual Web site's HTML content).
AlterEgo makes money based on conversion transactions through its system. While this
system will simplify data delivery from existing Web sites for mobile presentation,
extracting data from corporate back-end databases for mobile use would still require
custom development. Also, for corporate wireless-Web applications tailored to specific
devices, it is likely to be more cost-effective to implement custom solutions without the
added transaction or cost-per-use overhead.
5.2
Transcoding
Although outsourcing is convenient, working with third party WASPs adds an extra layer
of risk. The issue is data security and integrity. Since most WASPs act as a
"middleman" between a company's backend data infrastructure and its wireless users,
WASPs might have a hand on a company's most sensitive corporate data, namely, CRM
and ERP. Depending on the level of sensitivity of the company data, this could represent
a serious peril. Therefore, companies should, perhaps, rely more on its internal IT staff
for developing a winning wireless strategy. It is important to keep in mind that most of
the WASPs are actually employing the same underlying technology known as
"transcoding"-the process in which HTML (or other markup language) material is
transcribed and adapted to a wireless format. Therefore, if companies are serious in
developing a mobile strategy, they may carry out the transcoding process by themselves.
The transcoding process is the quickest way to mobile-enable Web content and
applications. It is, perhaps, the least-invasive way of testing the wireless waters, in terms
of expense and effort. 34
5.2.1
Transcoding Technology
Transcoding has its roots in tools from the '80s that enabled developers to present legacy
IBM text-based information into graphical form. Now, transcoding tools enable
developers to bridge Web-based HTML data across multiple formats, markup languages
and mobile client devices (a high-level schematic diagram is presented in Fig. 4.1 on pg.
49). Transcoding technology is now being used as a simplistic method of translating
enterprise business applications so that they can be accessed via small devices.
3
Wexler, J., Screen ScrapingforBasic Mobilization, Network World Wireless Newsletter, 01/01/01
56
Transcoding basically involves "scraping" certain pieces from an application and sending
them in a modified presentation format appropriate for users of mobile computing
devices with very small screens. An example of the transcoding software is IBM's
WebSphere Transcoding Publisher, which is part of the WebSphere Everplace Suite. 35
HTML transcoding software selects pieces of the HTML data to present to the mobile
device, depending on its display format and the speed of the wireless network to which
the device is connected. The software customizes, on the fly, the presentation of the data
based on the user device and network variables. Transcoding services are supported by
many tool vendors and in premises-based server/gateway products. It is one of the many
functions performed by wireless application service providers on behalf of enterprises.
For certain simple business/consumer applications, transcoding can be an easy,
straightforward way of getting predetermined pieces of HTML-based content to small
client devices, such as Wireless Application Protocol (WAP) phones, which have screens
big enough to display a few lines of text. Transcoding is one of the functions available in
most mobile middleware servers and wireless ASP service.
As a long-term approach, however, most experts agree that transcoding could eventually
pose some scalability problems because the business logic of the application does not
translate to the scraped application. As a result, the ability to customize an application
around specific devices-say, optimizing an application for the processing, memory, and
screen capabilities of a particular PDA-is diminished.
5.2.2
General Tips for Supporting the Transcoding Approach
Although it is increasingly clear that transcoding is probably just a short-term solution,
there are tips that companies should take advantage of if they do choose to go with this
approach until a long-term solution is more apparent. To easily transport typical Web
sites to various wireless platforms, it is important to create a "liquid" design. The Web
site should be comfortably viewable at all resolutions. Because of the limited display
capability of most mobile devices, the general rule is to have the Web page fit on a screen
at 640x480 resolution. The simplest way to achieve liquid design is by using relative (%)
widths in the tables and keeping image widths small.36 Another helpful tip is to avoid
frames totally because frames take up valuable real estate on the small displays of
wireless devices.
Making sure that the Web content is easily accessible is another factor. The site's content
should be readily available to users with small browser windows, or browsers that do not
support images. It is wise to place important content at the top and less important content
(i.e. images) at the bottom of the page. In fact, it is even better if the pages are text only.
Images and animations demand far more bandwidth and computing power than text.
" Other IBM products like DB2 Everywhere for Windows CE and Palm OS and IBM Mobile Connect (a
DB2-to-wireless-devices synchronization tool) also play important roles in IBM's mobile application
development arsenal.
36 http://www.wirelessready.org/I0tips.asp
57
To make a Web site more bandwidth-friendly, images should be optimized to have as few
colors as possible, as in the case of gifs; and few frames, as in the case of animated gifs.
Programs such as Macromedia Fireworks and Adobe Photoshop could be used to
optimize the images. To further reduce download time, the HTML codes should be
streamlined. The HTML pages created with Microsoft Frontpage or Macromedia
Dreamweaver are littered with excess lines of code. To prepare a mobilized version of a
Web site, all the unnecessary lines and tags are removed.
Scripting is another potential hiccup. Internet Explorer (IE) for Windows CE and Pocket
PC supports Javascript and Jscript, but not VBScript37 . However, older versions of
Pocket PC IE do not support client-side scripting at all. To avoid any scripting support
problems, it is a good idea to do a browser detect (link to browser detect code) before
serving up pages built for the right client. Alternatively, the developers should move the
client-side script to the server side using asp, cgi, php3, etc., or totally avoid client-side
scripting.
If the transcoding approach is pursued, companies should pay close attention to browser
compatibility. For example, not all browsers support all flavors of HTML; Internet
Explorer (IE) for Windows CE-based devices supports HTML 4.0, while Pocket IE
supports HTML 3.2. A thorough browser detect helps solve many HTML compatibility
problems down the road, and thereby avoids a lot of unnecessary headaches.
In a related issue, Internet plug-ins are generally a roadblock for many wireless efforts.
For now, there is very little plug-in support available for wireless computing devices, and
so the site will need to be able to communicate with the user's device without plug-ins.
Similarly, Java/ActiveX support is very sparse for wireless devices. For now, Windows
CE has no Java Virtual Machine built-in, meaning those mind-blowing Java apps will be
invisible to wireless users. One solution is to port the Java app to an Active X control.
However, Web developers need to make sure the control works with the subset of the
Win32 API that is present on the user's platform.
Although these tips presented here are most applicable to the transcoding approach, they
are also helpful for other wireless efforts. For example, Web developers can also benefit
from these guidelines in terms of low maintainability should their companies decide to
pursue the multiple web-site version approach.
5.2.3
Final Thoughts on Transcoding
Transcoding gets a bad reputation for business applications because both Intranet and
Internet pages are getting more and more sophisticated with possibly hundreds of options
and links. It is, therefore, extremely difficult to automate the transcoding process to
handle such sophisticated web pages. Furthermore, each device type has different
properties (e.g. internal memory, processor, screen size, etc.), and so even if the
37
WAP devices support WMLScript.
58
transcoding process can be automated, there is still a lot of tweaking involved before the
requested content can be displayed properly.
In addition to tailoring an application for a particular mobile device, the application must
also be customized for the job function of each type of workers. In other words, most
business applications have long been written with a certain job function in mind--sales,
engineering, warehouse, etc. The same data residing within an inventory database, for
example, might be accessible and displayed via separate applications:
* One designed for a non-mobile inventory clerk to show the full breadth of inventory
information.
* One designed for an on-the-road sales representative needing to check product
availability.
* One designed for a locally mobile warehouse stock picker needing to find the location
of a product for shipment.
Thus, any wireless initiative quickly becomes complicated (thereby, enhancing its
chances of an unsuccessful deployment) if an enterprise intends to support multiple job
functions. As a result, any potential gain in efficiency (in terms of quick deployment
time, for example) may be offset by the complexity of such transcoding approach.
Another disadvantage with transcoding is that an application has to be first written for the
mobile job, and then map it to the appropriate device. If companies want to support
multiple device types, huge investment in time, money and efforts are required. Thus,
the belief that one can take complicated business applications and simply transcode them
is unrealistic. Finally, HTML transcoding often creates less-than-optimal user
experiences, because content was not originally developed for a wireless environment.
By the same token, because there is transcoding involved in information delivery, this
approach also tends to provide slower response time than data originally written in WML
format.
5.3
Web Wrapping Technology
Web wrapping is another technology for mobilizing corporate data. Web wrappers are
essential in interoperability efforts and used in selectively extracting structured content
from semi-structured Web sources. Unlike transcoding in which HTML-based data is
"transformed" into another format, Web wrapping is essentially a query-based program
that "extracts" selected data from a larger database (a company Web site could be looked
at as a database). Its usefulness has been demonstrated on a PC platform in the lab
environment. The same Web wrapping technology could be applied on a mobile
platform.
59
5.3.1
How does a Web Wrapper Work?
There are many Web wrapper examples. One of them is the Cameleon Web wrapper
engine, which was developed by the Context Interchange (COIN) team at MIT.
Cameleon extracts data from Web pages using declarative specification files that define
extraction rules. Cameleon is based on the relational model and designed to work as a
relational front-end to Web sources. It treats the Web as a giant relational database and
supports SQL for querying it. ODBC drivers are used to send SQL queries to Cameleon.
Query results from Cameleon are presented in either XML or HTML table formats.
To connect to Web pages, Cameleon uses the HTTPCIient package, which deals with
connection, authentication, redirection and cookie issues. The package was also made
capable of extracting information from sites that use SSL (secure Socket Layer). These
features allow users to connect virtually to any site on the net and extract the desired
information.
Cameleon runs as a Java Serviet (a client-side Java applet) and outputs in either XML or
HTML table formats. User can send SQL queries to Cameleon through http or ODBC
drivers. Cameleon ignores the HTML tag-based hierarchy and simply applies regular
expressions with any level of granularity. This regular expression pattern matching
approach is significantly faster than parsing. Furthermore, this approach is not specific to
HTML or any Web authoring language. For example, Web developers can treat XML as
relational databases with this approach and execute SQL queries against them. The
disadvantage is that the developers are forgoing the opportunity to utilize the information
hidden in the tag hierarchy (which could be useful particularly for XML).
There are two major components in Cameleon, the relational front-end and the core
engine. Relational front-end consists of a planner, an optimizer and an executioner. The
core of Cameleon is composed on query handling, extraction and retrieval modules.
Based on the input queries and interaction with the registry the query handler determines
which spec file to retrieve and sends a request to the spec file parser. The spec file parser
implemented using JavaCC (parser generator written in Java) and JJTree (an add-on
module to produce syntax trees), fills in the relevant internal data structures with pattern
and schema information. The query handler can then call the extractor. The extractor
module first calls the retrieval module, which in turn uses the HTTPClient to retrieve the
requested Web page. When the Web page is retrieved and returned back, the extractor
calls the regular expression engine and supplies the relevant attribute patterns to obtain
the desired data items. After the patterns are matched and data items are obtained, they
are forwarded to the query handler in a plain format. Finally, the query handler adjusts
the data format and returns the answer to the user.
The real advantage of Web wrapping over transcoding is that transcoding typically
translates the whole HTML document indiscriminately, and therefore, a large amount of
unnecessary data could be generated. Web wrapping, on other hand, selectively extract
only the data the user is interested in (based on the rules defined in spec file), and
60
thereby, saving valuable resources (both in terms of tweaking the retrieved data and
sending only relevant information over a typically narrow wireless link).
5.3.2
Final Thoughts on Web Wrapping
Similar to transcoding, Web wrapping has both strengths and weaknesses when applied
in a business environment. The main advantage is obvious-simplicity. What it takes is
probably a software engineer, who understands how to develop Java servlet, to create a
front-end interface for a particular type of mobile platform. Furthermore, because Web
Wrapping utilizes Regular Expression pattern matching, it can extract data not specific to
HTML or any Web authoring language. This feature gives Web wrapping the flexibility
to be future-proof. The same thing cannot be said about transcoding. However, Web
wrapping also suffers the same problems as transcoding in other ways. First, as useful as
it is being demonstrated under the lab environment, Web wrapping would have
scalability issues when applied to the real world. For Web wrapper to be effective, a
specific front-end interface program has to be created for each type of mobile device
supported. Some might argue that Java technology could help resolve this issue-that is,
a Java applet interface program could be created instead, and it can be reused by many
different mobile platforms. It is probably true that Java could somewhat reduce the
complication, but even if Java 2 Micro-Edition (J2ME) initiative turns out to be a
tremendous success as projected (more on this in the next chapter), it is not certain that
the "write once, work everywhere" becomes reality overnight. Furthermore, Web
wrapping technology, in its general form, works well only under a static environment (i.e.
neither the format nor the context of the source data could change significantly). To deal
with this context issue, the COIN team at MIT created the Context Mediator, which takes
inputs from the domain model and context axioms. A domain model is basically a
collection of definitions, where the context axioms define different interpretations of the
information in different data sources from the requester's point of view. Together, they
alleviate the most common context issues in Web wrapping. As a result, the Cameleon
engine (unlike other Web wrappers) can still be applied in a major corporation where
different types of mobile users could be supported-for example, a manufacturing
foreman on a shop floor would be interested in a different set of corporate data than that
of the company executives. While Web wrapping seems like a viable approach, we will
explore other options in the next few chapters.
61
Chapter 6 XML
Having means to pass consistent data between different computing platforms is key to
gaining competitive advantage in today's business environment. A few solutions have
been suggested to address the issue. They include Distributed COM, Corba and Java's
Remote Method Invocation (RMI). Unfortunately, these solutions suffer from two basic
limitations: a) the communicating parties have to implement the same solution; b) all
solutions are complex and require some heavy-duty transformations on the data before
the two can communicate.
Even Web pages have suffered from the need to communicate across different platforms
and to keep the complexity of the intermediate code down to a manageable level. The
browser wars are largely over, with little real doubt about who won. But Microsoft's
victory may have been Pyrrhic; the browser market is now badly fragmented, with
different and mainly incompatible versions of HMTL floating around to support it.
Besides the explosion in the number of tags in the standard, different Document Object
Models for scripting automation exacerbate the situation.
HTML (HyperText Markup Language) is defined as a fixed set of tags and attributes with
no provision for expansion. If Microsoft defines a new tag, nothing mandates that
Netscape implement the tag the same way, or even that it be included in the next version
of Navigator. Even worse, the wild Web is full of poorly written HTML that does not
follow even basic HTML rules. Because of the limitations of these widely variable
HTML implementations-along with Java applets, ActiveX controls, and other arcane
plug-ins and extensions-the notion of building comprehensive applications that work
across the Web is largely a dream. As a result, modem browsers are full of bloated code
to handle the sloppiness. To make it worse, different browsers handle the sloppiness
differently, and thus, the same page might appear differently, requiring even more
workarounds by the page author. Bloated code is somewhat acceptable on today's
machines with 128 MB of memory and 10-GB hard drives, but won't cut it on tomorrow's
"Web appliances", such as handheld devices like PDAs and cell phones. In the wireless
space, there are certain vendors out there saying, all the companies need to do is serve
HTML, and then they will have these devices that are somehow going to figure out how
to smartly render HTML directly on a wireless device. That is not really a feasible thing
to do. In most cases, companies actually need to be able to serve different content
because the interaction scenarios are different; they need a separate URL, typically, for
serving pages out to the wireless devices.
6.1 XML 101
Since different people have different requirements for their documents, HTML has been
used in ways that were never intended. What works well for describing a physics abstract
works at best awkwardly for showcasing one's services, getting shopping cart
information, or any of the millions of other functions that Web pages are called upon to
62
perform. When XML was initially proposed, it was in fact designed to solve just this
problem
Similar to HTML, XML is a tag-based language that is designed to organize data rather
than to format it. With XML, one can standardize the way data is exchanged within the
company or even with other companies. For example, let's say that company A wants to
send an invoice to its clients. Ideally, company A would send it electronically from their
accounting software so that their clients can easily import it into theirs. Alternatively,
company A could send the information as an Adobe Acrobat document, a Microsoft
Word file, or a plain text file. While this is convenient for humans, it is not as easy for a
computer to extract information from any of these formats. Company A could also work
with the client's accounting department to come up with a custom format, such as a
comma-delimited file. But the problem with this approach is that company A has to make
changes to their invoice generator program if their clients later decide to change the file
format to accommodate another vendor. This situation quickly worsens if company A
has many clients, each using a different custom format. XML offers a solution to this
problem. Your accounting program could e-mail the client a copy of the invoice in XML
that the client could then read into their system. Because XML is flexible, minor changes
to the format would not make the two systems unable to exchange information. By using
XML, one can finally concentrate on the business logic, rather than worrying about the
dreary work of writing parsing code for the custom format.
XML can even enhance sharing between applications. At the easiest level, current
communication between two applications means using a closely coupled mechanism
where one program calls the other through an API. XML eliminates that need-and that
has a long-term benefit aside from easier communication. Suppose there is a new version
of the application that is used to exchange data with another program. So long as there is
no change in what already existed (like the data elements and document definitions), the
old and new applications can work together without having to change anything.
Communicating at the API level, on the other hand, would mean having to upgrade an
application and redeploy it. In a distributed network with many nodes, trying to make
that many changes simultaneously is impractical. In fact, this was exactly what killed
client-server model; the client and server were too closely tied together. e-business and
application integration (EAI) is like the Web, where the browser and server are not
tightly coupled. So, there is a lot of room for dynamic change.
As we have indicated before, XML is designed to work on simple text files by adding
specialized tags. For example, in HTML, if the developer would like to bold some text,
he/she would use the <B> tag. This tag tells the Web browser where to start bolding text,
and its companion ending tag </B> tells it where to stop:
<B>This text is bold</B>
The markup in XML works essentially the same way:
<LASTNAME>Jones</LASTNAME>
63
Contrary to popular beliefs, XML is not designed to replace HTML; rather, the two
languages have significantly different aims and can, in some cases, be complementary.
Specifically, unlike HTML, XML is not designed to format data. Instead, its purpose is to
organize it. In HTML, developers apply tags to add formatting-to let the browser know
which text to bold, to italicize, or to make a hyperlink. In XML, on the other hand, tags
are used to classify the data into its parts and subparts.
This point highlights another major difference between XML and HTML, as well as most
other markup languages. In HTML, certain tags have meanings that have already been
specified (e g. <B> for bold, <I> for italics, and so forth), whereas the tags in XML mean
whatever the Web developer wants them to. For this reason, XML is said to be
extensible-if one needs a new tag, one can just make one up and use it. HTML needs to
be standardized so that a Web browser can interpret the tags on a page and display it for
the user. XML, on the other hand, is not as rigid. Because it is not designed for display
within the browser, whether or not the browser can interpret it is not really important.
Another advantage is that XML is designed to hold self-descriptive structured data in a
simple form that still retains context, and one can build tools around regardless to the
operating system, programming language, or processor that the data is run on. For
example, if one person creates an XML structure of data, any data, on a Intel-based
Pentium II notebook running Windows using Visual Basic, person B can read it (and
manipulate it) on a Linux system with Perl scripts or a Macintosh working with a Code
Warrior C++ implementation. In other words, XML becomes a completely transparent
implementation of data. Of course, the same thing can be true of SQL that serves as the
standard for querying and updating databases. However, in addition to implementation
differences, it is difficult to express and retain complex relationships outside of the
immediate context of the database. For example, it is one thing to write SQL program to
retrieve specific records, but transferring those records to a different database (especially
one with a slightly different SQL subset) requires some intermediate language.
XML, on the other hand, works well as a language for transferring data between a data
"producer" and a data "consumer" because it can retain these relationships in a way that
does not require the producer and consumer to have the same implementation. When an
XML document is sent, not only the data but also the metadata was also being sent.
Metadata represents how one piece of information relates to another, what information is
subordinate to other information, and-with the help of schemas-declarations
describing what kind of format the data uses.
This reliance upon schemas should be highlighted. A schema is a way of describing a
generalized data structure-a template of sorts. An XML schema also describes the valid
data types that specific elements and attributes can have, provides documentation that can
be referenced by the documents that follow the schema, sets possible default values and
constraints, and describes the models that the XML document can follow.
An XML document can reference its schema as an independent document or retain it
internally, primarily because the schema document is itself an XML document. The same
64
parser that handles manipulation of the XML information can be used to work with the
schema as well. So the schema itself can be modified dynamically, making it a powerful
tool for working with XML data that may have changing validation requirements.
While the specification of schemas is still under development by the World Wide Web
Consortium (W3C), there is a less powerful alternative to schema-Document Type
Definition (DTD). Similar to schema, a DTD is used to standardize the structure of the
XML documents you exchange with others-making XML an excellent data transfer
format.38 A DTD provides applications with advance notice of what names and structures
can be used in a particular document type. That is, DTD describes, in a standardized
way, the document's hierarchy, what elements (tags) are required, which ones are
optional, how they are put together, what attributes are legal, and a lot of other additional
information. In an invoice example, for instance, the clients would send the company the
DTD document that specifies how they are set up to receive XML invoices, and the
company would format its XML so that it conforms to what they expect. However, it
may be even simpler than that. Many industry groups are working to create DTDs
particular to their business to facilitate data exchange. Fig. 6.1 below illustrates how DTD
could be useful when combined with XSL. Once XML and stylesheets (DTDs, schemas)
are processed by an XSL processor (available from Microsoft and IBM), the data can be
output in a number of formats, including the Web (HTML), wireless devices (even
speech for a cell phone), and portable Document Format (PDF).
But DTDs are not as powerful as schemas because DTDs would not allow you to validate
the semantics of the content, and they will not let you say, for example, that the value of a
price should be a decimal number carried to two decimal places. All you can do is pass a
string. If you pass a price of "#64.K9," the DTD does not know the price value is invalid.
When schemas are finalized, many observers point to XML Authority as the solution of
choice. XML Authority both creates schemas and converts existing application and
document structures, including DTDs, to schemas.
HTML
XSL
D
Processo
(VoxML)
Other
Fig. 6.1 DTD Output Options39
Schemas are descriptions of how a document type should
be displayed.
39 Patrizio, A., XML Is Nearly Ready For Business, Web Builder, Volume 5, No. 3, Fall 2000
38
65
6.2 Reading and Writing XML Documents
Because XML documents are simply text with some tags added, one can create them with
any text editor, including Windows Notepad. However, on a larger scale, this way of
doing things is likely to be labor-intensive and less than efficient, much like creating
HTML pages by hand rather than with a good editor. Therefore, it is probably more
convenient to write a program to create XML documents by either extracting data from a
database or in response to how a user fills out a form.
Reading XML is also straightforward. You can create your own program to read and
interpret XML files. Alternatively, you can rely on such a program called an XML parser,
which have already been written in a number of languages, including Java, and chances
are that at least one is available for your platform.
Regardless which platform the XML code runs on, one of the main advantages of using
XML is that if you commit to exchanging data in XML, you can avoid writing repetitive
and error-prone parsing code. Instead of creating custom data interchange formats and the
read/write code to support them, by using XML one can standardize his/her data format
and reap the multitude of benefits. Not only is code that has specifically written to parse
XML likely to be faster than the custom code a developer writes himself/herself, it would
also be more productive for the developer to concentrate on business logic rather than
program data input/output.
6.3 Displaying XML
Besides exchanging data with others, displaying the data is another issue. Because a Web
browser does not have any idea of how to format custom XML tags (or what they mean),
there are two choices. On one hand, a developer can show the XML data to the userstags and all in Microsoft Internet Explorer 5. An XML file opened in IE5 is treated not
just as static text, but as an interactive document allowing users to work with the data,
collapsing and expanding the content within tags at will (see Fig. 6.2 below). The other
option is to go beyond just the data--by relying on the Extensible Stylesheet Language
(XSL) to convert the XML data into HTML for display purposes. Using XSL, one can
either embed display information right into the XML file or put it into a separate XSL
style sheet. XSL goes much further than what is possible with just HTML and Cascading
Style Sheets (CSS), and it provides a powerful framework for formatting the data. At the
same time, XSL allows the developers to separate their content cleanly from its
presentation.
66
<?xml version="1.0" ?>
-<invoice>
<orderlD>12345</orderD>
tirezone="Pacific">Sep 1, 1999 12:30:00</orderDate>
<billingAddress>
< firsT Namne>Boris c/firs tName(.,>
<1astNane>Feldman</Ias Mamre>
<street>123 Anywhere St.</c:reet>
<city>Anytown</cIty>
<state>CA</state>
<zip>9550<,zip:;
</billingAddress>
<phone voice="408-555-1234" fax="408-555-4321" />
<orderDate
<item>
<quantity>3</quantity>
<productD>456</productID>
<description>Widget</dlescrip: on>
-
<price>
<currency>USD</currency>
<amounti49.95</amount>
</price>
<warranty>30 days</warranty>
</item>
<item>
<guan tity>-1</quL-ntit y>
<price>
<armountb79.65</;mount>
Fig. 6.2 Viewing a XML Document in Internet Explorer 5
6.3.1
Cascading Style Sheets (CSS)
XSL is often compared to Cascading Style Sheets (CSS) as a way of applying specific
formats to XML tags. 40 However, this comparison is actually a little misleading. CSS
works well in dealing with XML that is presented in an irregular manner (such as is
typical of most Web pages) because such behavior emulates how Cascading Style Sheets
deal with normal HTML. CSS reads each XML element as it is scanned in the document
and applies styles in that order. For example, if you put your name at the bottom of the
XML document, CSS will place your name at the bottom of the document unless you
explicitly position it elsewhere with "position:absolute". In other words, CSS does not
change the structure of the XML; it merely changes the visual appearance of each node.
Furthermore, CSS will treat each tag of a given type in exactly the same manner-there's
no mechanism for doing things like placing a rule above the first paragraph in a set of
paragraphs without explicitly renaming the paragraph class.
A few problems also arise when CSS is working with regular data. For example, CSS
cannot filter, re-order data, nor can it add text or subordinate HTML structures. To a
certain extent this problem can be ameliorated through the use of DHTML behaviors, but
40
Cagle, K., Transform Your Data With XSL, Web Builder,
Volume 5, No. 3, Fall 2000
67
such behaviors are both proprietary solutions at this stage 4' and expensive in terms of
memory if you need a lot of them.
6.3.2
XSL
Unlike CSS, Extensible Stylesheet Language (XSL) is a transformational language. Since
XSL is also written entirely in XML, it can be manipulated using exactly the same tools
that the XML document itself uses. With XSL, the developer could apply a template that
could conceivably match the topmost node of the XML tree, applying a distinct
transformation to that node. This template, in turn, can call other templates to act on
subordinate nodes, until no more templates can be found that match the queried elements.
This means that a transformation can be applied on the object as a whole, rather than
treating individual properties in a sequential manner (though internally the parser does
this as well). The beauty of this technique is that developers can parameterize both XML
source and XSL transform, creating little programs that are effectively device
independent.
It is important to note that an XSL transform does not necessarily have to transform the
XML into a different form of XML. It can transform XML into HTML, limited script
blocks, XSL, SQL-in short, into a variety of possible formats. Thus, a developer could
convert a purchase order into an HTML form using one XSL filter. A second filter might
turn the same purchase order into a table of line items that could be sorted by price, date,
or some other qualifier. A third XSL filter could take the purchase order when it arrives
at the server and save it into a queue form, perhaps adding some additional client
information. A fourth could convert the purchase order into the native XML format that
the database uses for adding records, while a fifth filter might be used to construct an
invalid data page.
By adding XSL to the mix, the reliance on traditional transformational code (especially
scripting languages) drops dramatically. Moreover, the same XSL code can be migrated
to a different system without changing a line of code, even if the operating system and
development languages are completely different.
In the future, we will see this process go one step further. It does not take much
imagination to foresee devices, whether hardware or software really makes no difference,
that expose XML interfaces. With the right XSL transformation script, you could
essentially pass all the parameters into the device by pointing it at an XML provider, or
you could query the same device to get its system information. Thus, rather than relying
upon highly specialized (and expensive) programming interfaces, you could query or
program the device through the same mechanism that you use to send or receive Web
page information.
Microsoft HTC behaviors have been submitted for consideration to the W3C, but they're a long way from
being ratified
4
68
This does actually point to one other reason why XSL is so important: Different devices
(hardware or software) will likely end up using different XML schemas, perhaps
conforming broadly to some industry or legislated standard. But these devices would
differ at lower levels simply because they would have different functions. With XSL, an
XML-based solution exists for providing a cohesive link between these devices, and is
critical for any large-scale networked solution.
This architecture need not exist solely for interfacing hardware devices. However, the
model described here, in which dozens of services communicate either directly with one
another or indirectly through XML servers via XML, is one that has obvious applications
and implications for Web development.
6.4 Business Benefit from XML
As we have learned in this chapter, XML is simply a markup specification language. Web
developers must write a program to do something with an XML document because a
document simply does not do anything inherently. Document Object Model (DOM) and
Simple API for XML (SAX) are specifically designed to access and manipulate XML
documents (but not to interface with back-end databases). Clearly, the greatest value is
gained by using XML with live data. Corporate data will continue to originate from
database management systems and packaged applications, not from an XML document.
Several database vendors say they plan to provide ways to use XML to interface with
their database engines. These solutions, while built atop various XML standards, can
provide access only in a proprietary way until the vendors agree on a common solution.
Currently, the only data access methods compliant with industry standards are ODBC,
JDBC, and ADO/OLE DB. If standards are important to an organization, leveraging
XML with these existing data access standards may be the best approach to building
applications.
Now let us examine how XML can be used to give businesses new and robust
capabilities. Leveraging the Internet (or wireless Internet for that matter) involves
exchanging data over the Web, and as the Internet grows, data will be exchanged not only
with consumers but also with other businesses. For example, a consumer who orders
business supplies online might trigger a low-inventory event in the wholesaler's online
commerce system or ERP system. This event, in turn, could trigger an immediate re-order
of the item from the wholesaler to a supplier. Before the order was actually placed from
the wholesaler, the inventory levels of the supplier could be checked to make sure the
product was in stock. If not in stock, the wholesaler could choose an alternate supplier.
Traditionally, the wholesaler would have chosen to provide an online catalog of
merchandise in HTML format over the Web. Using XML, the wholesaler could now
provide its online catalog in XML format, adding the semantics to the catalog
information that allow the consumer to do business with the wholesaler in many possible
ways. For example, large-volume consumers could now use scripts or programs to query
69
the wholesaler's XML catalog and, similarly, could place orders more efficiently. If the
catalog were in HTML format, the catalog information would have no context, and
writing scripts or programs to interact with the catalog pages would be difficult.
As illustrated in this section, XML is more than just an interface for surfing the Web. It
can help business transform and transmit data from Point A to Point B. By jumping on
the XML bandwagon, not only companies can take advantage of its extensibility in the
wireless space, but also more importantly, they rip the benefits off XML as a transparent
layer for exchanging data
6.5 Other Uses of XML
There are many other uses of XML, once the Web developers or IT support staff are
getting themselves familiar with the technology. For example, XML could also have an
impact on voice communication as well. The most basic form of communication
between human beings is speech. Communication between people and computers is most
natural when conducted through speech recognition and text-to-speech processes. These
processes combined with existing telecommunication infrastructure provide people with
the ability interact with computers over fixed line and mobile phone telephone networks.
While there are no large deployments yet, the function will allow mobile workers to have
menus read to them and to verbally query the application for information, such as
customer status.
Voice based communication involves a challenge/response interchange between the
computer system and the user. This is where XML could help. The computer follows a
script or tree of statements to speak as the user responds. These scripts are written in an
XML based language called VoiceXML (originated from VoxML, which was developed
by Motorola) 4 2
The VoiceXML system has a relatively straightforward technology. To enable
VoiceXML, you need to place a series of XSL filters that interpret XML into VoxML for
production, and then place other XSL filters between the microphone's VoxML producer
and the Internet. So, when the user places a normal voice call to a VoiceXML server, the
gateway could translate the request (from a spoken command), retrieve the relevant
VoiceXML page from any Web server on the Internet via HTTP and perform actions
based on the commands specified in the page. These commands may include more
options allowing text to be transformed into speech and be read to the user. With
VoiceXML, the possibility is almost endless. You could potentially surf the Web,
transcribe memos to a word processor, and get a stock alert when your stocks dip too low.
One of the other advantages with XML is that by taking the time to learn XML, Web
developers can apply the same knowledge on relating areas such as VoiceXML, which
essentially, gives a "voice" front-end for interacting with the Web.
The VoiceXML Forum, a forum founded by leaders in the telecommunications industry - Motorola,
AT&T, IBM and Lucent Technologies, controls VoiceXML.
42
70
6.6 Disadvantage of XML
However, two key developments have hampered XML's progress. First, up until recently
only one browser (Microsoft's Internet Explorer 5.0) has truly supported XML.43
Netscape Navigator 4.7, which has fallen significantly behind in development, has no
native XML support at all, nor have secondary browsers such as Opera, or mobile devices
such as PalmPilot.
So, even though XML is more versatile than HTML, it has not taken off as a Web
authoring language. This has, in many ways, slowed the adoption of XML as a client
description language, although some analysts argue that the lack of native browser
support is only a nuisance because the most common scenario is to store XML in a
database, and when the information is requested, the Web server (or wireless server) will
detect what kind of browser is being used and apply the proper style sheet (presumably
XSL) for that browser on the server side. Once XSL has specified elements in a
document that are then mapped to objects, these objects can then render formatting and
style upon the elements. For "traditional" Web users, XML will simply be transformed to
HTML by XSL, and the requested information can then be displayed in a Netscape or
Internet Explorer browser. For wireless users, XML document could get mapped to
WML, and then displayed on a WAP browser. Thus, it is not clear if the lack of native
XML browser support is an important factor. Nonetheless, the recent ratification of
several key XML technologies will probably start to spur developers to develop
compliant browsers.
Second, while it's one thing to learn a set of well-defined tags to create markup, it's quite
another to create a consistent set of tags for markup in the first place. The latter requires
the ability to abstract a document into its constituent parts and find the commonality in
those parts for future usage. In other words, it's a lot easier for a Web developer to use an
existing standard than to write his or her own, and much easier to use a common, albeit
inferior, standard than to convince a company or organization to create its own
proprietary standard.
6.7 Final Thoughts on XML
Corporations see the Internet and its standards as a cheaper, simpler solution for interbusiness communication.44 In many ways, wireless, particularly with the use of XML
can take wireless communication to the next level. XML is a structured language,
allowing developers to specify what role that content should play. For example, content
in a section heading has a different meaning from content in a footnote, so that data
should be treated differently. Also, since XML is extensible, users can define their own
vocabulary for data, and thus define how the data should be handled. For this reason,
43 Microsoft has been very active in its support of XML and Internet Explorer 5.0 does have an XML parser
and XSL converter
44 Patrizio, A., XML Is Nearly Ready ForBusiness, Web Builder, Volume 5, No. 3, Fall 2000.
71
XML became popular as a platform-neutral means of sending both data and the
instructions for handling that data.
XML can best be compared to relational databases. Neither model pre-defines how to
store your data. Instead, they give users a standard foundation, then let you choose how to
use it. You must define the tables, rows, and columns. What relational databases do for
information storage, XML does for the transmission of information. XML does not define
how information will be structured, or what it means. That is both the strength and
weakness of XML. Because of this flexibility, there's too much room for error. The big
problem now is the proliferation of standards. Everyone says they have their own
standards and their own schemas. It's daunting to go to an XML Website to see how
many markup languages and initiatives are out there. Despite the fact that XML could be
too versatile, it could turn out to be an important technology in terms of mobilizing
corporate data due to its extensibility, once the standard issues have been worked out by
the major stakeholders.
72
Chapter 7 XHTML
As discussed in chapter 3, there is strong evidence that i-Mode and WAP are going to
converge into one powerful wireless platform. This trend is not so surprising because
even though DoCoMo has enjoyed tremendous success in Japan for the past three years,
it has remained an active participant in the WAP Forum. On the WAP camp, Openwave
has hinted that WAP 2.0 (or its next release) would possibly abandon WML in favor of
XHTML entirely. It coincides with the DoCoMo's recent decision that the next
generation of i-Mode devices will also be XHTML-enabled. Thus, it is important to
understand the XHTML technology as well if one has to make a decision regarding
mobilizing corporate data.
XHTML is often viewed as a stopgap measure in the inevitable movement from HTML
to XML. This view is simply not true because HTML and XML serve different purposes.
HTML formats the information to display on the Web whereas XML describes or
markups information (see last chapter). XHTML simply makes the best of both
technologies.
7.1
Modularization Design
Modularization plays a big role in XHTML thus far. Its importance will be even more
pronounced as the specification evolves. One of the major problems with HTML is that it
is fundamentally monolithic. Web developers have to either fully implement all styles of
HTML, or they would risk being non-conformant when a certain type of browser is used.
The primary consequence is that with the advent of Internet-enabled PDAs, cell phones
and other wireless handhelds, we are seeing any number of devices that simply do not
have the bandwidth to support the full specification, and so, they miss critical pieces of it.
Realizing that only modularizing the specifications was necessary to support mobile
devices, the World Wide Web Consortium (W3C) put forward the modular approach in
writing XHTML 1.1. Instead of defining a single standard, the XHTML specification
defines a core set of "basic" tags as the minimal level of support (primarily for PDAs and
handheld wireless devices), and adds modules to expand upon the core set. The principle
set of modules (Strict, Transitional and Frameset) that defined XHTML 1.045 is
summarized in Table 7.1. The Strict set is used when all of Web page (or document)
formatting is performed in Cascading Style Sheets (CSS), and that no <font> and <table>
tags are used to control how the browser displays the documents. The Transitional set is
used for making presentational markup in a document, so that users without an CSSenabled browsers can still view the document. Finally, the Frameset is used when the
document has frames.
Since XHTML 1.0 is a means to convert HTML 4.0 into an XML specification, it is not all that different
from the HTML 4.0 specification.
4
73
Type
XHTML 1.0 Strict
XHTML 1.0
Transitional
XHTML 1.0
Frameset
Descriptions
Use when all of Web page
Resources
<!DOCTYPE html PUBLIC
formatting is performed in
Cascading Style Sheets (CSS),
and no <font> and <table> tags
are used to control how the
browser displays the
documents.
Use when developers need to
use presentational markup in a
document, so that it does not
limit the audience to users with
browsers that support CSS.
"-//W3C//DTD XHTML 1.0
Strict//EN"
"http://www.w3.org/TR/xht
ml l/DTD/strict.dtd">
<!DOCTYPE html PUBLIC
"-//W3C//DTD XHTML 1.0
Transitional//EN"
"http://www.w3.org/TR/xht
mll/DTD/transitional.dtd">
Use when the documents have
<!DOCTYPE html PUBLIC
frames.
"-//W3C//DTD XHTML 1.0
Frameset//EN"
"http://www.w3.org/TR/xht
mll/DTD/frameset.dtd">
Table 7.1 Three flavors of XHTML Document Type Definitions
The modularization approach allows leeway for browser manufacturer to create
proprietary extension module to give its browser special functionality. For instance,
mobile phone companies may include an extension to the XHTML specification to make
voice-specific elements available-elements (or attributes) for specifying tonal qualities
in synthetic speech agents, language attributes for handling dialectic differences between
speakers, and so forth. This extension is incorporated into a namespace that is filtered
out by non-audio clients-they simply do not recognize the namespace extension for
voice interactions, or be stripped off by XSL scripts in servers. By the same token, the
servers work in the reverse direction, encoding XHTML code with VoxML (Voice
Markup Language, a voice transcription and recognition format) or similar extensions
when "talking" to a voice-enabled client.
Another advantage with XHTML is that users can run an XHTML document now. Most
current HTML browsers are non-validating meaning that they do not check to see if the
HTML codes are completely valid or not. For the most part, these browsers will let
wildly non-compliant HTML (even XHMTL) pass through unchecked because the
rendering engine (the part of the browser that interprets and displays the HTML) is given
some extremely wide latitude in handling output.
Ironically, this leniency should not be true with XHTML. XHTML works upon the
assumption that the code is pure XML, and an XML parser should complain if the
document being passed in is not completely valid. Fortunately, the rules to turn "normal"
74
HTML into XHTML are quite simple. Nonetheless, it is important to understand some of
the basic rules in XHTML.
First, all elements are containers, and must be closed. Any time a tag is created (such as
<p>, for paragraph), there must be a closing tag </p> that closes the current tag. If a tag
contains no text or inner elements, it can be terminated with a />. For example, in HTML,
the image tag is expressed as <img src="myURL">, while in XML, the same tag should
either be closed explicitly: <img src="myURL"></img> or terminated within the bracket
itself: <img src="myURL"/>.
In addition, all attributes must be enclosed within either single or double quote marks. It
is a common practice that most HTML editors do not place attributes within quotes
(especially ID elements). Therefore, strictly speaking, no HTML editor produces valid
XHTML.
The following code, taken from the W3C's XHMTL specifications, shows what a
minimal XHTML 1.0 document should look like:
<?xml version=" 1.0" encoding-"UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtmll/DTD/strict.dtd">
<html xmlns="http://www.w3.org/TR/xhtmll/strict"
xml:lang=="en">
<head>
<title>The Minimal XHTML 1.0 Document</title>
</head>
<body>
<p>This is a minimal XHTML 1.0 document.</p>
</body>
</html>
As shown above, an XHTML document does not appear all that radically different from a
"normal" HTML document. The root of such a document is still an <html> node. The
document is divided into a <head> and <body> section, and the tag usage is consistent
with what has been produced in HTML editors or by hand for the last decade. 46
However, there are some subtle differences. The first has to do with the fact that this is an
XML document after all. It contains the processing instruction <?xml version=" 1.0"
encoding-"UTF-8"?>, which tells the parser that it is an XML document and that it uses
the standard 8-bit encoding schema of most typical English documents. Secondly, the
code shows what kind of DTD specifications the document deals with. XHTML uses
XML's Document Type Definitions (DTDs)
4 7 to
make for conforming document
definitions.
Cagle, K., XHTML: HTML Merges With XML, Web Builder, Volume
5, No. 3, Fall 2000
DTD describes, in a standardized way, the document's hierarchy, what elements (tags) are required,
which ones are optional, how they are put together, what attributes are legal, and a lot of other additional
information. A more detailed description of DTD is presented in the XML section
46
47
75
7.2
Benefits of Using XHTML Over HTML
XHTML offers two major advantages to Web developers. The primary advantage is its
extensibility, which we have touched upon earlier in this chapter. HTML has been called
to provide functions it was not originally designed for. The addition of new HTML
elements either makes a browser increasingly incompatible with other browsers, or needs
to modify the standard-a painstakingly slow process led by a committee. On other
hand, since XHTML is based partly on XML, new elements can be added without
altering the DTD, which the document is based on. 48 Alternatively, XHTML can take
advantage of the Extensible Stylesheet Language (XSL). 49
Unlike Cascading Style Sheets (CSS), XSL does not deal with styling. It associates given
element patterns in an XML document with other collections of strings (or better yet,
with elements from a different XML form). For example, XSL can take an XML
document as input and convert it into HTML. However, if that HTML document is not
also an XML document, then most XSL parsers have to manipulate the HTML as strings,
which is much less efficient than manipulating the element as internal binary objects.
XSL cannot transform HTML into XML unless the HTML is a well-formed XML.
However, XHTML can transform HTML to either XML or XHTML.
For example, a XHTML document can be read through any expressions of the form
<clock:showTime format="long"/> are converted into the expression <span class=
"clock">3:25:16 PM PST</span> when displayed. The capability of creating a tag-based
system of output is similar to running Cold Fusion where all the desired actions are
explicitly defined.
XHTML blocks can be stored within an XML document to facilitate easy retrieval by
using another XML technology-XPath. XPath enables Web developers to perform
complex queries on the nodes and extract data at any level of complexity. Most
traditional index servers use a brute force method to index a site-recording the positions
of given words in their respective files. The results of such searches are only as current as
the last time the site was indexed, and proved to be problematic in dealing with
dynamically generated data.
With XHTML, the information can be retrieved topically. As long as the document
structure is known, any specified sections in the document can be identified and
retrieved. For example, only the tables in a document, or only "Table 3" in the
document, or only tables that contained Northwest Airline sales amounts for Fall 1999 in
excess of $20,000,000 dollars are retrieved. This level of specificity compares favorably
to that of SQL, without any of the headaches of dealing with JOINs50 and trying to
reconstruct hierarchical data.
Kiely, D., XHTML The Best of Two Languages?, Web Builder, Volume 5, No. 3, Fall 2000
A more detailed description of XSL is presented in the XML section.
50 JOINs allow users to link data from two or more databases together into a single query result. See
http://www.sqIlcourse2.corn/ioins.html for an explanation of how JOINs work.
48
49
76
XHTML is considered to be interoperable and portable. Refrigerators, PDAs, digital
TVs, and other alternative platforms are being connected to the Internet, in part to access
Web documents. These devices obviously would not have the processing power of a
desktop computer, and browsers on them will be less capable to render malformed
documents. XHTML is designed to make Web documents accessible and interoperable
across platforms by enforcing a rigorous coding standard.
Consider a news site such as CNN.com. The site produces basic XML information
consisting of news stories with specific key words denoted to add context to the
information, coupled with multimedia such as audio files, transcriptions, video streams
with synchronized multimedia integration language (SMIL)-based timing to handle
interactive charts rendered in Structured Vector Graphics (SVG), and dynamic links. Top
stories are dispensed into an XML-formatted document that is used to retrieve salient
information for teasers, along with a second XML document consisting of advertising
media links that are keyed upon specific elements in the stories themselves (a fashion
show might feature clothing and makeup advertisements, a football story would show
beer, a terrorist incident with life insurance information, and so forth).
When a user connects to CNN.COM, the server queries the user's browser and
determines which modules of XHTML the client supports. If the user has Internet
Explorer running on a high-end machine with a T3 connection speed, he/she will receive
the full treatment-the aggregate XML gets filtered through XSL to produce full
multimedia streams which the client browser renders and displays based upon its own
built-in XSL transforms. On other hand, if an user is on a Palm Pilot, he/she will only get
the XHTML Lite version-perhaps, the site will only give the relevant stories with
limited graphics. Cell phone users may get headlines, text, and basic links in voices with
the help of VoxML. The above scenario is not a fantasy. All of the technologies
described above are readily available.
While it is possible to build formatting software for either producing or extracting
information from regular text streams through ASP or JSP, such software has to be
custom written for every format change, typically at incredible expense. With XHTML
(and XML in general), one can specify the desired transformations, and use them in
highly modular fashions, designing only those pieces that affect a small piece of the
stream.
One can change the look of the site by changing the XSL filter. If one intends to target
the latest holographic browser, one can pull in the browser's XHTML extension from the
manufacturer's Web site (if it has not already cached), use XSL to aggregate the profile
elements into a schema, and then apply another XSL transform to output the results into
3DML (3-Dimensional Markup Language) with a side stream in XHTML for the attached
2D browser.
To purchase the cool computer shown in the holographic viewer, the forms browser
would send back an envelope of form data to the CNN XML server, and convert it into an
77
XML-based purchase order supported by the vendor of the product. The vendor would
send a payment request to your bank (which, in turn, sends more XHTML back to you for
authentication).
XHTML is useful as it becomes a part of the XML pipeline-a fairly transparent part that
does not need to be hand coded. Certainly it can be-much of the Web is still made up of
sites that are hand coded because they are expressions of art rather than commerce-but
XHTML will likely end up changing the way that most Web sites handle their output, and
free up labor from the relatively mundane tasks of formatting content for more
challenging tasks of creating content.
7.3
Final Thoughts on XHTML
The difference between HTML and XHTML raises the question of whether to translate
existing HTML codes to the new, immature, and more demanding XHTML codes.
Developers have to understand that any code upgrades have their shares of benefits and
pitfalls.
Perhaps, the most compelling argument in favor of XHTML is the speed of delivery.
Study after study has informed us that the faster a page loads, the more likely it is to hold
the visitor's attention. Web developers and business analysts have known this for years.
Jakob Nielsen, one of the Web's best-known usability experts, wrote on the topic in detail
in 1997. His conclusions are still valid today because despite the increase in highbandwidth access, our attention spans are as short as they ever were. Web pages that
conform with the XHTML Recommendation display faster because the browser has no
guesswork to do. It simply parses the document according to the rules of XHTML and
finds no place where the author's intent is unclear. These few seconds can mean the
difference between gaining a new customer and losing that visitor to a quick click of the
Back button. Even for the time-critical business applications, losing a few seconds could
make or break a business deal.
Aside from the financial consequences, there are also technical reasons why XHTML
should be pursued. Writing valid XHTML is the first step in being ready to write or
deploy XML on a company Web site. The rules for processing XML are far stricter than
the rules used with HTML. As we have known in the last chapter, XML documents must
be well formed, or the processor is required to stop with a fatal error. Validating
processors will report errors, often stopping the processing all together when a document
isn't valid. By getting into the habit of writing valid code now, company Web developers
will be one step ahead of the competition when it comes time to incorporate XML into
the development arsenal.
There are an increasing number of tools available, both commercially and as freeware, to
migrate existing HTML code to XHTML, and to author new XHTML documents.
Migrating existing code will require a conversion by hand or with an automated tool to
compile with the HTML 4.01 Compatibility Guidelines. Following these guidelines make
78
the codebase usable with XHTML-compliant browsers as well as those supporting
straight HTML, as long as new tag definition is avoided.
XHTML's ties to XML have one potentially painful side effect that will probably be the
biggest obstacle to broad acceptance. Even when an XML document is not conformingin full compliance with a DTD that describes the allowable syntax of the XML-it must
be validated. This means that the sloppy Web pages which today's Web browsers allow
would choke future XHTML browsers.
During the transition to XHTML, validating code will be one of the biggest challenges.
Validation is a process that verifies documents against the associated DTD, checking to
make sure that the structure, elements, and attributes are consistent with the definitions in
the DTD. Validating an XHTML 1.0 document involves verifying its markup against
one of the three associated DTDs: strict, transitional and frameset.
Blending HTML and XHTML means that the Web will have a better, stronger, and more
flexible markup language. Best of all, Web developers are no longer limited to a fixed set
of tags implemented by Microsoft, Netscape, or Opera. And even though it will be a pain
in the short term to tighten up non-conforming HTML code, the effort will pay off by
making your pages viewable in any XHTML browser, on a wider variety of devices.
The last problem with XHTML is the availability of Web authoring tool. While the W3C
has doggedly pursued HTML standards efforts, HTML in the Web industry has evolved
much quicker than any standards body could possibly keep pace with. As a result, any
given HTML authoring tool supports at best a snapshot of HTML tags at any given time.
Many existing visual HTML editors may not be useful for authoring XHTML documents,
because they often insert tags on their own and do not produce syntactically correct
documents. It becomes a real problem because most browsers today are remarkably
tolerant of malformed markup, but the XHTML recommendation pretty much mandates
that a browser strictly adhere to its specifications. The lack of Web authoring tool will
hinder the adoption of XHTML.
79
Chapter 8 Jave 2 Micro Edition (J2ME)
Another wireless initiative that might make an impact on mobilizing corporate data is the
Java 2 Micro Edition (J2ME) movement. J2ME is a new Java-based software that comes
into the cellphone or handheld device over the airwaves. Java, in its original version, is a
method of programming developed by Sun Microsystems. But, it is way too large to run
on mobile devices, so Sun developed a slim version of Java, J2ME for wireless networks
and devices. It is supposed to let active computer code travel efficiently over networks.
In terms of J2ME, there are two key advantages for wireless computing. The first attacks
the frustration factor. Today, if you try to buy a book from Amazon.com using a
cellphone, you might click through a bunch of pages to find the book you want, then click
through a bunch more to set up the order. Given the speed of today's wireless networks,
by the point you finish ordering, the seasons have changed already. When you are ready
to hit the last click, the connection might then get dropped. Your whole transaction
would be wiped out. To order, you have to start again from the beginning. 5 1 With J2ME,
it is different. Amazon.com could send your cellphone a little applet, a tiny book-buying
software. It would all be inside your phone. Even if your connection gets dropped, you
could still finish setting up your order and hit send. Next time your phone finds a signal,
it would send in the whole thing.
The second major bonus of wireless Java has to do with the "write once, run anywhere"
promise. In personal computers, there is only one major platform: Windows. Thousands
of developers can create programs that run on Windows and be sure to hit a huge market.
But in wireless, there are dozens of different makers and devices, each running its own
kind of OS, all with different kinds of electronic innards. It is a developer's nightmare.
Programs might be designed for one kind of phone but they would not work on others.
Bonita Software, for instance, is making tools and software that will let developers create
one Java-based program that could run on almost any wireless device, a Nokia cell phone
or a Palm VII.
8.1
J2ME technologies
J2ME technologies span a broad array of consumer and embedded electronics. These
devices can be roughly divided into two categories: connected limited device
configuration (CLDC)-devices that are mobile (such as cell phones, PDAs, etc.)s2 and
connected device configuration (CDC)-devices that typically are fixed (such as set-top
box and Internet appliances). The hardware and network resources available to mobile
devices tend to be more limited than in the case of devices with an ample supply of wallpower. Conversely, devices with easy access to power and wired network connections
can take advantage of the wires to provide more power and sophistication to the user.
Recognizing this distinction, Sun and the Java Community have worked together to
5 A company called Lobby7 has a solution for this "drop call" problem during business transactions.
A CLDC device will likely have a processor of limited prowess (in comparison to
a desktop system) and
a memory footprint of between 128 KB and 512 KB.
52
80
define two J2ME configurations addressing each of these design centers. These
configurations consist of core library sets and virtual machines optimized for the
characteristics typically found in devices in these two groups. In the case of handheld
devices the design center focuses on characteristics like:
*
*
*
"
battery operation
very constrained memory
limited processing power
low bandwidth, high-latency network connections
The design center for these smaller handheld devices is addressed by the J2ME
Connected Limited Device Configuration (CLDC). The CLDC specification was
developed in collaboration with over five hundred partners representing the wireless
handset, service provider, and point of sale terminal industries. It outlines the most basic
set of libraries and Java virtual machine features that must be present in each
implementation of a Java 2 Platform, Micro Edition environment on highly constrained
devices such as cellular phones, two-way pagers, and PDAs. To form a complete
environment for any given class of device, manufacturers add additional libraries that
address API areas, which are irrelevant for the low-level CLDC, such as the user
interface and device-specific networking. The first profile available for the J2ME
technology's mobile design center will be the Mobile Information Device profile (MIDP).
The combination of a J2ME configuration and MIDP provides a complete environment
for a given class of device.
The MIDP specification addresses issues such as user interface, persistence storage,
networking, and application model. It provides a standard runtime environment that
allows new applications and services to be dynamically deployed on the end user devices.
MIDP introduces the critical concept of a midlet, a small Java application written to the
CLDC and MIDP APIs and that runs in a mobile information device. The MIDP
specification has been developed by an expert group composed of over 20 companies
representing the wireless industry.
Each configuration (CLDC or CDC) represents a low-level, foundational API. Atop these
twin foundations are the profiles, which are additional APIs tailored for specific devices
(see Figure 8.1). The implementation of a profile will be a set of Java APIs that draw
upon the services provided by the APIs that define the configuration. A profile is a
complete environment. That is, an application written to execute on a profile needs no
additional supporting classes. J2ME defines no standard user interface that covers both
configurations because consumer devices vary so vastly. Instead, user interfaces in J2ME
are defined within a profile. 53
53 http://www.devx.com/upload/free/features/avapro/2000/1 3issOO/rgOO 13/rgOO 13.asp
81
iD
'MProfiles
Configuration Core
classes
Connectedl
Connected
Limite
Configuration
Configuratiou, Virtual
Machines
Device4
Fig. 8.1 The Architecture of Configurations and Profiles
The heart of J2ME technology in mobile devices (the CLDC) is Sun's K virtual machine
(KVM) 54. KVM is the minimal virtual machine (VM) for the J2ME platform and was
specifically developed for the CLDC configuration. 55 To address the cramped memory
spaces and limited processor power issues 56 , the KVM was written from scratch in C (not
a modification of an existing VM). 5 7 This permitted the engineers to incorporate
optimizations that would not have been otherwise possible. In addition, the KVM is
modular. It is built so that features58 not needed for a particular target implementation can
be easily excised. Since the KVM's native interface was built for portability, task
switching within KVM does not depend on hardware-generated timer interrupts. Instead,
task switching occurs after the virtual machine has executed a preset number of
bytecodes. And, as a final lunge at optimization, the KVM's garbage collector uses a
nonmoving, mark-and-sweep algorithm that implements a handle-free implementation.
Hence, object references are direct, not indirect, as in normal Java. Of course, there's
more to an execution environment than a virtual machine. On small devices, the virtual
machine must either be extended or assisted by additional tools to provide a more
complete runtime environment. The KVM 59 is attended by tools for precisely this reason.
Its name reflects its size, which is measured in the tens of kilobytes.
5 J2ME applications, however, are not restricted to the KVM; they can be used on any virtual machine that
is at least as capable as the KVM. (see Java Pro's June 2000 issue, both the "Java To Go" and "Ask the
Java Pro" columns addressed the KVM.)
56 KVM is suitable for devices with 16/32-bit RISC/CISC microprocessors/controllers,
and with as little as
160 k of total memory available -- 128 k of which is for the storage of the actual virtual machine and
libraries themselves.
5' http://www.javaworld.com/javaone00/j -00-j2me.html
5 optional features include: large datatypes (long, float,
and double), multidimensional arrays, classfile
verification, and others.
59 An optional attendant to the KVM (provided with the porting guide) is the Java Application Manager
(JAM), which is to handle the details of downloading, installing, executing, and uninstalling applications
on those CLDC devices that are so resource constrained that such functions don't exist.
54
82
8.2
J2ME Deployments
The J2ME platform (from the technical standpoint) maintains the qualities that other
editions of the Java technology has become famous for:
" built-in consistency across products in terms of running anywhere, any time, over
any device
* portability of the code
* leveraging of the same Java programming language
* safe network delivery
* applications written with J2ME technology are upwardly scalable to work with
the J2SE and J2EE platforms
Because of these (or at least, perceived) advantages, J2ME offers multiple benefits to the
players in the wireless arena. It allows device manufacturers, service providers, and
content creators to gain a competitive advantage and capitalize on new revenue streams
by rapidly and cost-effectively developing and deploying compelling new applications
and services to their customers worldwide. Developers writing Java applications can
deploy them on a wide spectrum of devices, independent of networks, operating systems
or handset models as long as those devices are J2ME technology-enabled. Thus, it is no
surprise to see that more than 150,000 developers have downloaded one of the J2ME
Reference implementations. These free reference implementations can help developers
develop applications even before physical handsets are available, speeding adoption of
the J2ME platform. Also, tools that support Java technology application development are
getting plentiful: J2ME Wireless Toolkit, Metrowerks CodeWarrior 6.0 for Java, Fortem
for Java, Borland JBuilder for Java, and Rational Rose.
On the operators' side, NTT DoCoMo, Inc. launched the J2ME-enabled i-Mode handsets
in Japan in January '0 1, and since then the number of Java-based applications increased to
more than 5,000. Japanese mobile operator J-Phone Group also announced that it is
launching Java-enabled handsets in Japan. The handsets will offer an expanded range of
interactive content and applications, including 3-D graphics. In April '01, Motorola and
Nextel launched the i85s and i50sx handsets, the first J2ME technology-enabled handsets
in North America, allowing Nextel to target key vertical and enterprise markets with
customized solutions. In Korea, LG Telecom's successful launch of J2ME technologyenabled ez-Java handsets demonstrates consumer demand for wireless devices with the
ability to support dynamic interactive content such as gaming and entertainment services.
As of today, LG Telecom has sold over 500,000 handsets, which together support over
300 Java applications.
In addition to operators' support, wireless device manufacturers 60 are either shipping or
planning to ship devices integrated with Java technologies. Manufacturers of Java
technology-enabled handset devices can offer customers personalized services and
compelling applications. As for consumers, they can choose to download new
0 including Nokia, Motorola, Siemens, Samsung, LG Electronics, Panasonic, Fujitsu, NEC, Sony,
Mitsubishi Electric, Sharp, Psion, RIM, and Inventec
83
applications as opposed to buying a device with applications pre-installed by the device
manufacturer. On the enterprise side, Sun's launch of J2ME/MIDP for Palm OS devices
brings the power of Java technologies to all Palm handheld users worldwide, expanding
an already wide spectrum of device and network coverage for content vendors. Java
technology now runs on everything from wireless handsets to PDAs, and its network
agnostic characteristics enable it to run on all the different networks around the world,
including GSM, GPRS, CDMA, and CDPD.
8.3
Hurdles for J2ME
Even though the wireless industry is showing strong support for J2ME, it is still a long
way to becoming a ubiquitous technology in mobile space. One issue critical to the
success of J2ME is the deployment of bug-free virtual machines to a wide variety of
mobile devices. Sun is in the precarious position familiar to parents of teenagers: they
have designed a solid technology, explained to vendors how to successfully implement it,
and now must watch as vendors take their first steps into the real world. Despite Sun's
high hopes, some developers wonder if such an ambitious technology will work
flawlessly across the dozens of device hardware architectures and operating systems
currently in use. A single, major implementation snarl by one vendor could damage
developer confidence in the technology, hurting all who support it. 61
An improved user interface and the ability to work offline should bode well for J2ME.
However, it still takes a high-end handset (probably one with large display, easy
navigation and sufficient memory) before enterprise applications may proliferate. To
resolve the memory issue, vendors might provide slots for plug-in memory, but doing so
would drive up the deployment cost. In the business world today when IT projects are
measured by ROI, the price point could be a hurdle--even for a global enterprise.
Another potential pitfall for J2ME could be the same mistake WAP encountered in
Europe and the United States: Operators failed to specify a minimum screen size and
graphics to handset manufacturers. If operators do not learn this lesson and just let
vendors build whatever they want to build, they are going to have the same kinds of
problems. That is the big risk.
8.4
WAP vs. J2ME
Having discussed both WAP and J2ME in this thesis, it is fair to ask the question whether
J2ME would replace WAP one day. It is important to understand that WAP and J2ME
are different technologies, and each has its place when it comes to application creation
and deployment. Instead of looking at J2ME as a WAP competitor, it should be looked at
as a complementary technology used to further expand the usefulness of wireless access
and applications. WAP (or really, WML and WMLScript) lets you build browser-based,
thin-client applications optimized for wireless delivery. J2ME lets you build "thicker"
client applications with more sophisticated logic and the ability to run in an "offline"
61
http://www.wirelessinternetmag.com/news/0106/0106featuresj2me.htm
84
mode. Having said that the original J2ME vs. WAP question is like asking: "which is
better, a page of HTML or a Java applet?" Both are different, and both have their uses.
Depending on the applications, one can leverage the strength off the other.
For example, in the area of data security, wireless applications can truly leverage the
strength of J2ME. WAP currently uses the Wireless Transport Layer Security (WTLS)
specification, which has the "gap in WAP" issue (we discussed this in an earlier chapter).
WTLS was specifically designed to conduct secure transactions over a low-bandwidth
environment without requiring PC-level processing power or memory in the handset. For
this to work, the WAP gateway acts as a translator between WTLS encryption and the
Web's standard, more robust SSL (Secure Sockets Layer) security protocol. The problem
occurs when the data is handed over from WTLS to SSL, a process in which the data is
decrypted and then re-encrypted, meaning that for a split second the data is not secure.
Even though the data translation occurs within a secure data center, it is still vulnerable
for that split second. New versions of the WAP specification are expected to address this
issue, but it will probably take a while before the problem is fully resolved.
Data security is where J2ME (or more specifically, Java) really shines. Regardless of
implementation, all Java applications are restricted by a simple principle that untrusted
code must be placed in a "sandbox", where it can play safely without doing any damage
to the computing platform. What this means is that when an applet or other piece of
untrusted code is running in the sandbox, there are a number of restrictions on what it can
do. The most obvious is that it has no access whatsoever to the local file system or system
resources. Should the users decide to allow access, a simple certificate is all that is
required. Another J2ME boost in security comes with the arrival of the much-awaited
network aware J2ME applications. These applications allow developers write code that
supports SSL data transfer. Corporate users can, for instance, access databases to look up
sensitive data, all from a secure phone-based query application.
In a sense, J2ME (or more specifically, Java technology) is very good at many of the
things in which WAP is lacking. So, indeed J2ME and WAP are complementary
technologies. One option for using the two together is to have a WAP browser in the
phone, and to have a KVM that implements the CLDC and MIDP specifications. The
WAP browser and the J2ME environment could then call each other via an API between
the two. When the device wants to run a Java application, it has the WAP browser do the
download via its standard mechanisms, and then the device manages the installation of
the Java application and its execution by the KVM. If the JVM wants to put some text up
in the device screen, it tells the browser that, "Display This" via the standard callback
mechanism.
In the longer term, there are possibilities that WAP and other microbrowsers would be
written in the Java programming language themselves.62 In most of the non-Java
technology browsers in phones now, if you want a new version or a new feature you have
to buy a new phone. A Java-based microbrowser could give users extra flexibility in that
they could update the WAP browser itself, on-the-fly, even over the air. As a result,
62
In fact, there are several Java technology based WAP micro browsers
available already.
85
users could keep the same phone and download browser updates as they become
available. This would benefit consumers by keeping their handset costs down and benefit
operators by allowing them to add new features to their service more easily and quickly.
Indeed, many industry analysts feel that the wireless world will see a combination of
these two technologies working together. Companies in the mobile data business and end
users will all benefit from WAP. The devices will cover a wide base of end-user needs,
and phone manufactures will continue to improve and develop newer and more
sophisticated devices that will continue to support and enhance their services. When
WAP and J2ME are coupled together, users can also benefit as well. They will be
operating in a full-featured Java-based application environment, and this will only
enhance their wireless experience-something that WAP could not quite achieve yet.
For example, with Java technology, users will no longer be restricted to the limited
monochromatic interfaces seen on WAP devices today, but rather, they will enjoy fullcolor, animated graphics and applications that are much easier to navigate.
8.5
Final thoughts of J2ME
There are reasons to believe that the future for both WAP and J2ME to be very bright.
Because WAP is supported by all major phone manufacturers, it is very likely to become
very successful. However, it is also fair to believe that J2ME will also triumph, as
phone-manufacturing market leaders such as Nokia, Motorola, and LG Telecom also
support it. Java is also an established platform, and J2ME will appeal to developers,
which may lead to better wireless applications. In fact, if you consider the upcoming 3G
(third-generation) standard, most vendors are already considering the use and inclusion of
the technology. Moreover, once more individuals realize the huge potential that Java can
bring not only to their tethered applications but also to those that are wireless, we should
expect to see an even bigger adoption of the technology.63
In summary, we could conclude that both technologies are "must haves" for those
venturing into the mobile space. With the simplicity of WAP, the strength of Java, and
the approaching promise of greater amounts of bandwidth, users will find transforming
content from plain to pristine something of a joy.64
There are four WAP toolkits available for software developers to use in the
development of WAP-based
services, with Dynamical Systems Research, Ericsson, Nokia, and Phone.com supplying them.
63
64
http://www.javaworld.com/javaworld/jw- 12-2000/jw- 1201 -iw-j2me.html
86
Chapter 9 Conclusions
Mobilizing corporate data help improve response time to customer needs and enhance
customer loyalty. The latest wireless technologies enable company employees to log in
and access corporate data anywhere at anytime. In today's highly competitive business
environment, users demand to take data and applications with them, wherever they go. 65
The implementation of mobile systems are no longer limited to operational workers, such
as traveling sales agents, researchers, transport operators, and journalists. Decisionmakers, such as mid-level managers visiting branch offices, or customer-care and
corporate-account managers also benefit from a versatile mobile systems.
9.1 Know the Users Needs
Before deciding how to mobilize corporate data, potential users and their needs are first
identified and defined. There are two big issues looming large in pervasive business
intelligence for mobile decision-makers. First, mobile decision-makers require different
information from traditional mobile work force. Unlike the operational users, decisionmakers usually want to see summary information by department, branch, or region. They
might also perform different operations on the information 66, such as dimensional
analysis, trend analysis, and even some data mining-type operations.
The second issue for supporting mobile decision-makers is timing. The mobile
technology has to deliver information in a timely fashion. For example, the customercare manager of a telecom company that supplies network services to other organizations
may often be confronted with problematic cases when he/she visits the customers. The
lifespans of such problems are quite short, and they tend to emerge to critical level
unexpectedly. If the customer-care manager is unaware of recent critical problems when
visiting customers, he/she may seem to be not knowledgeable.
Some mobile decision makers might even require access to up-to-the-minute information
that is not necessarily found in a data mart (or temporary data storage), but only available
in an operational data store, or can only be extracted directly from the operational
systems. The timeliness of the data in the mobile data mart is crucial in deciding what
connectivity strategy to pursue and how data transfer and loading implementation
between the mobile data mart and the enterprise or departmental data sources are
performed.
Rennhackkamp, M., Business Intelligence Hits the Road, Web Builder, Volume
5, No. 3, Fall 2000.
66 For example, a customer-care manager visiting a customer may have to drill down into the details of a
particular problematic order.
65
87
9.2 Know the Technology
Once the potential mobile users are identified, it is important to thoroughly investigate
how the mobile decision-makers and the operational users will be using the technology.
While typical mobile users relied on notebook to communicate in the past, more people
are now using other handheld devices like PDAs and cell phones. These smaller mobile
devices are popular with mobile users because they do not want to lug a notebook
computer around and go through a cumbersome start-up procedure at each site where
they have to access their information. To meet the market demand of the mobile users,
many of the leading database management software (DBMS) vendors, such as Oracle,
Sybase, and IBM, have recently released small-footprint DBMSs that run on these
devices.
9.2.1
Data Transformation and Loading
In order to support these mobile devices that are gaining market momentum everyday, the
enterprise network architect has to devise and implement a data transformation and
loading strategy. There are three basic approaches. You can load the data directly from
operational databases. Or, you can load your enterprise warehouse conventionally, and
then specialize facilities for intermittent communication. Alternatively, you can also load
the enterprise warehouse conventionally and use snapshot replication to populate data
marts from that warehouse.
Exactly which approach you should select is based on the kind of wireless network
available, whether you prefer the push or pull data strategy and the type of data (e.g. how
time critical is your data) you want to mobilize. For example, if the 3G network is
available and economically feasible to your company, sending data directly to the mobile
devices is a very good option. Alternatively, you might prefer the data warehouse
approach because it is less risky and cheaper, even though the data the each mobile user
has might be slightly old (depending on your replication process). Lastly, the third
approach is the snapshot approach, which is really a combination of the first two
approaches. In this case, the issues to consider are the size of the mobile data mart, the
selectivity of the snapshot, and again whether the entire strategy addresses the timeliness
requirements of the user.
Although backend data replication process is a complicated issue, there are strong
reasons to expect to see a growth in the use of pervasive business intelligence, especially
as roving mobile users discover the usefulness of mobile data marts and as smaller, more
convenient computing devices become more popular and readily available. Mobile users
will soon realize the value of having up-to-date decision support information readily
available at their fingertips in a query-friendly format.
However, the big technological challenge, in addition to designing the mobile data mart's
data structures correctly, is to keep the information in the mobile device up-to-date and
readily available. For this, one can use data transfer and loading facilities, transaction
replication facilities, or snapshot replication facilities. Of these, snapshot replication
88
facilities are by far the easiest to set up and manage on a day-to-day basis, but they are
only practical if the data volumes to be copied or refreshed are not prohibitively large and
if you can specify the parts of the data mart of interest to the mobile data mart user. For
larger data marts, transaction-based replication or data transfer and loading facilities must
be used. Transaction-based replication is usually more efficient in terms of bandwidth
and connection time, but we need to realize that transaction replication is a very complex
process to set up and manage.
Once the mobile data mart architecture has been defined, IT managers have to decide
whether developing in-house expertise or outsourcing. Whatever the decisions are, the IT
managers needs to keep scalability and future growth in mind. Multi-device server
solutions that can support different types of applications and devices as their mobile work
force are more flexible to accommodate any future growth. Furthermore, IT managers
should also consider the potential impacts on their existing company Web site, and
anticipate the disruptions to the backend infrastructure as a result of this wireless
initiative. Last but not the least, , IT managers should align their e-business and mcommerce initiatives and never lose site of their company's core business. A wireless
strategy is supposed to help a company succeed by improving employee productivity,
promoting synergy between business partners while enhancing customer satisfaction.
9.3
Mobilize Now!
Barpoint.com is a real world example of how a wireless initiative could go wrong. The
company is spending too much of its resources on developing and maintaining multiple
versions of its wireless Web sites. Besides severe data integrity issues associated, the
approach is deviating from its core business because instead of reaching out to customers
or business partners, it was focusing more on developing and maintaining Web sites. Not
only did the wireless initiative fail, it sucked away valuable time and resources of the
managers and their staff (network engineers and Web developers) from performing their
normal duties. As a result, it almost drove the company into the bankruptcy.
The Barpoint example outlines the problems of developing a wireless initiative. The
thesis touched on various approaches of pervasive computing. Table 9.1 summarizes the
pros and cons for each mobilizing technology. The selection is depending on the usage
environment and the organization. The thesis is written to identify winning wireless
strategies in different situations.
The first technology discussed is WAP. WAP, including WML and WMLScript, is
designed to work in a mobile environment where the device screen size is small, memory
is limited and network is slow. The current version of WAP relies on WML, a markup
language based on XML. WML employs the deck-and-cards model. Because of limited
on-screen real estate, a mobile device can only display limited amount of information at a
time. So, a card represents a cluster of data that is logically grouped together to be
displayed at the same time. A series or group of cards forms a deck, which is analogous
to a URL. Like JavaScript in HTML world, WMLScript enables client-side interactivity
89
through event and behaviors. WMLScript gets and sets WML variables and uses
standard libraries resident on the WAP client such as a string library, a dialog library, and
a floating-point library. The adoption rate of WAP has been hampered by many technical
and consumer behavioral issues, such as slow download rate, inconsistent user
experience, etc. In many ways, WAP has been the victim of its own success. Before it
was launched, WAP has been over-hyped by its developers, building up unrealistic
consumer expectations. When WAP was finally launched on the current slower 2G
platform, users could not see its full potentials. As a result, some users are disappointed
with WAP performance, and thus, further damping its adoption rate. Some users painted
i-Mode as an heir of WAP's dominance, but i-Mode has its own share of growing pains.
Nonetheless, these two mobile technologies are converging together-at least at the
language level. XHTML has emerged as the markup language of choice by both WAP
and i-Mode.
Transcoding (WAP
or i-Mode)
Advantages
Disadvantages
Comments
e
0
Possibly high
maintenance cost
Might need some
redesign to take
advantage of
specific device
configurations
Too much data
generated
0
Interoperability
issues
Robustness issues
0
"
*
Web Wrapping
.
*
*
Quick
implementation
time
No impact on
existing Web sites
WAP is a widelysupported interface
program
Short
implementation
time
No impact on
existing Web sites
Could resolve
0
0
0
9
*
0
0
Some commercial WASPs can
handle the transcoding process, and
so implementation can be
outsourced
Some resources need to be invested
to make sure user experience is
consistent
There are some interoperability
issues across different WAP
platforms
Need to build a front-end wrapper
for each specific device (unless it is
coupled with Java, in which only a
single front-end is needed)
Might be a good alternative if the
corporate Web site is monolithic
context issue
XHTML/XML
*
*
More future proof
Use of XSL
improves
*
0
interoperability
*
*
Some tools are not
well-defined
New technology
with technical risks
Need a separate
XSL for each
device type
High initial cost as
existing Web sites
0
0
Need to develop a strategy for
adopting XML variants
Good to learn XML as the
technology is gaining momentum
need to be rewritten
Table 9.1 Technology Summary Table
Another technology that is gaining momentum is transcoding. This technique can rapidly
convert the HTML-based data into WML or cHTML, so that mobile users could interact
with the backend infrastructure data with their mobile devices. There are both
advantages and disadvantages to this technique. One of the strength is that the current
Web site is not impacted because of the transcoding initiative. This is important because
90
in today's business environment, ebusiness is expected to be 24/7. Any infrastructure
down time significantly impacts a company's bottom line. There are also WASPs that
could bear the technical implementation details, so enterprises could concentrate on their
own core business. If some corporations are shy away from infrastructure outsourcing
because of data security concerns, there are tools (such as NetMorph) in the commercial
market that could provide on-the-fly transcoding. IBM's WebSphere provides an end-toend solution including mobilizing corporate data. The tools help cut down the
implementation and development time. The transcoding approach is not flawless. First,
this technique only works well if there is a common mobile platform. Even though both
WAP and i-Mode are considered dominant in their respective markets, there are still
interoperability issues, and therefore, the user experience is inconsistent. For example,
there could be different implementations of WML if one has to convert from HTML to
WML. A developer might decide to get rid of the image totally, whereas another
developer, who wants to be faithful to the original HMTL Web page, might use a tool
like bmp2wbmp to convert pictures to be displayed on a WAP browser. Furthermore,
those on-the-fly transcoding tools also tend to convert HTML generically, without taking
considerations of the exact layouts of each device type. Consequently, even those
transcoding tools claim to be useful, a team of quality assurance (QA) web developers is
still needed to make sure the WML conversion is performed correctly. In most cases, the
transcoding approach works well only in simple HTML conversions. Finally, another
disadvantage is that both WAP and i-Mode standards are evolving, and so, there is a risk
that a year from now, they could entirely be different from what they are now.
Web wrapping is similar to transcoding. It extracts data from Web pages using
declarative specification files that define extraction rules. The Cameleon model
developed by the MIT COIN team is based on the relational model and designed to work
as a relational front-end to Web sources. It treats the Web as a giant relational database
and supports SQL for querying it. ODBC drivers can be used to send SQL queries to
Cameleon. Query results by Cameleon are presented in either XML or HTML table
formats. The approach is attractive because it is simple. What it takes is probably just a
software engineer that understands how to develop a Java servlet, and create a front-end
interface for a particular type of mobile platform. However, it suffers the same problems
as transcoding. First, as useful as it is being demonstrated under the lab environment,
Web wrapping would have scalability problem when applied to the real world. In order
for Web wrapper to be effective, a specific front-end interface program has to be created
for each type of mobile device supported. The need to develop a context definition file
could get tedious in a dynamic business environment.
XML (or its variant XHTML) is another alternative. XML documents can be exchanged
and used across dissimilar platforms and applications. Two important dynamic
transformation forces are at work here. 67 The first is the dynamic transformation of data.
Using XML, data from any source can be wrapped in a data structure, which can then be
used by an application that parses the data and uses it in an application. Since the data
structure and the data itself can be combined in a document object instance, the document
"is" the database. This "database" can be processed by any application that can handle
67
Fichtelman, M., Go Wireless, Web Builder, Volume 5, No.
3, Fall 2000
91
XML, even though that application may have no knowledge of the origin of the data. The
second force is the dynamic transformation of metadata. Metadata is usually comprised
of field or variable names, formatting attributes such as text or numeric, and so on. In
XML, this metadata is used to "tag" the data, in the same way that HTML is used to "tag"
Web page content. Indeed, XML is so flexible and extensible, that it can be used to
generate HTML to browser-based clients using XSL and other transformation modalities.
XML's main purpose is the interchange of hierarchical data. XML makes it easier for
different companies, different departments within the same company, different
applications, or even different portions of the same program to communicate in a wellordered, yet flexible way. XML will also benefit the wireless initiatives because it
communicates using standard HTTP (the standard Internet Web protocol), so it does not
matter what systems the transmitter and receiver use. For this reason, a number of
vendors are entering the market for Enterprise Application Integration (EAI), linking
legacy systems on mainframes, mini computers, and Unix systems to the Web via
XML.68
The main attraction of J2ME technology is its "write once, run anywhere" concept.
Ideally, a Java applet (a browser or a database query application program) could be built
in J2ME, and it should not care what kind of computer or device it winds up on - it can
always work. This is true in the ideal world, but in reality, there are so many different
hardware and software configurations that J2ME technology may or may not be able to
work as well as it was originally intended. Thus, this is a considerably riskier proposition
from the CIO's or CTO's perspectives because J2ME could either become a dominating
platform for the next generation of wireless devices, or it could flop and venture into
obscurity. Judging from the enthusiasm amongst the device manufactures and software
developers, it is widely believed that J2ME should be here to stay. Whether or not, J2ME
will dominate other platforms is another question. Because of its "write once and work
everywhere" promise it has high potential value. Enterprises should invest some of their
resources into this technology.
Based on the analysis of this thesis effort, there are really two viable answers--one for
short-term and the other for long-term. The long-term solution (three to four years)
would be to rewrite and redesign the company Web interfaces in XML, and transform
XML to the most appropriate format of the wireless devices used by the users via XSLT.
The advantages are to expose the company IT specialists and Web designers to XML and
learn about the new wireless infrastructure, which will be becoming the next important
frontier to interact with potential customers and company employees. Accumulating
experiences in the XML transcoding techniques and wireless technologies should be
beneficial to the companies when m-commerce is bound to take off in the next few years.
Although the initial XML implementation cost could be high (due to steep learning
curve), its benefits far outweigh the pain.
Products that get at legacy data via the Web have been available for years, but
unlike XML, they have
often proved proprietary and expensive.
68
92
The short-term solution (perhaps, within the next two years) for mobilizing corporate is
the transcoding (possibly from HTML to WML) approach. It is true that this strategy
could take a lot of resources, but with careful planning and execution, this could turn out
to be a winning strategy. Companies need to understand that they do not need to
overextend their own capabilities in order to support all mobile devices. They only need
to support a selected group of mobile devices-for example, Palm m505 or Nextel i85.
Once, the companies focus their energy in specific platforms they can concentrate their
mobilizing effort. Both Palm m505 and Nextel i85 are good platforms because they have
very good user interface and screen size compared to other mobile devices. Furthermore,
for Palm m505, the data modem is external and therefore, it could be upgradeable to
other 3G networks. For i85, it is tri-mode phone with some 2.5G capabilities.
Whichever devices that the companies end up choosing does not really matter as long as
they are WAP capable, so that they could take advantage of the growing WML
popularity. Since WAP 2.0 would be XHTML compatible, it provides a nice upgrade
path for the company Web developers to ease into the XML mode.
In summary, careful management and planning can provide a reliable, secure, and
flexible mobile data solution to most enterprises and organizations--even today. The
wireless industry has been too technology-centric, and there is a lot of talking about 2.5G
and 3G, even though in reality, they will not be as quickly and as widely deployed as
people have been led to believe. IT leaders should keep this in mind when defining a
time-line to equip their mobile work forces with wireless data. Besides, there are already
new optimization options available to make significant improvements to the reliability
and speed of wireless data with the bandwidth that is currently available to them today. 69
Thus, there is really no need to hold out the wireless initiatives for NGD network.
Instead, IT managers should look at the marketplace and the health of the telecom
industry in terms of what is available. They should be focusing on helping their
companies make money today with what they have today -- rather than telling their CEOs
that they have to spend hundreds of millions of dollars before they can make more
money.
The improved efficiency of the mobile work force should show a significant ROI in the
short term, and with careful management and planning, CIOs/CTOs will see a continuing
ROI for years to come. From retail sales to publishing, businesses in many industries are
already seeing rapid, high returns on investments (ROI) in handheld computing solutions.
Helping workers manage project information remotely, access up-to-the minute
databases, capture signatures and make better-informed decisions more quickly, mobile
handheld computers are enhancing employee productivity and customer satisfaction.
The mobile wireless technology is readily available now, so companies should take
advantage of it. If they do not, there is a risk that their competition will. Companies that
have deployed Mobile & Wireless IP solutions to their mobile work force include
Carlson Hotels, Dresdner Bank, the Royal Mail, Nabisco, the Montgomery County Police
Department, Chevron, Eastman Kodak, The Seattle Mariners, Ocean Spray, Taco Bell,
Optimization and acceleration solutions providers include BroadCloud Communications,
Infowave,
BlueKite, Fourelle, and others.
69
93
and many others. Increasingly, more and more companies are recognizing the enormous
potential of handheld computers -- which cost significantly less, and are much easier and
faster to use, than laptop computers -- to improve their business productivity.
94
Appendices
Appendix I: Listing 1 WML Java Serviet Example
<?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="card 1" title="WML EC" newcontext="true">
<p>
OrderNumber:<input format="*N" name="order-number"
title="Order Num.:" value="001 "/>
<br/>
FirstName: <input format="*T" name="firstname"
title="First Name:" value="John"/>
<br/>
LastName: <input format="*T" name="last-name"
title="Last Name:" value="Smith"/>
<br/>
Street: <input format="*T" name="street"
title="Street:" value="Main St."/>
<br/>
City: <input format="*T" name="city"
title="City:" value="NY"/>
<br/>
State: <input format=="*T" name="state"
title=" State:" value="NY"/>
<br/>
Zip: <input format="*T" name="zip"
title="Zip:" value=" 10001"!>
<br/>
Product: <input format="*T" name="product"
title="Product:" value="cellphone"/>
<br/>
<do type="accept" label="Submit">
<go method="post" href=
"http://127.0.0.1:8080/servlet/WMLServlet">
<postfield name="firstname" value='$(firstname)' />
<postfield name="last name" value='$(lastname)' />
<postfield name="street" value='$(street)' />
<postfield name="city" value='$(city)' />
<postfield name="state" value='$(state)' />
95
<postfield name="zip" value='$(zip)' />
<postfield name="product" value='$(product)'/>
<postfield name="ordernumber"
value='$(ordernumber)'/>
</go>
</do>
<do type="help" label="Help">
<go href="#help"/>
</do>
</p>
</card>
<card id="help" title="Help">
<p>
<u>Order Number</u> - must be unique<br/>
<do type="prev" label="Back">
<prev/>
</do>
</p>
</card>
</wml>
96
Appendix II: Listing 2 WML Java Servlet Example
import java.sql. *;
import java.io. Serializable;
public class WMLtoDB implements Serializable
{
String theOrderNumber;
String theFirstName;
String theLastName;
String theStreet;
String theCity;
String theState;
String theZip;
String theProduct;
public WMLtoDB(Connection database,
String order number, String firstname,
String last_ name,String street,
String city, String state,
String zip, String product)
throws SQLException
{
theOrderNumber = order number;
theFirstName = firstname;
theLastName = lastname;
theStreet = street;
theCity = city;
theState = state;
theZip = zip;
theProduct = product;
}
public int dotheSQL(Connection database)
throws SQLException
int Retcode = 0;
Statement stmt = database.createStatemento;
+
String theSQL = "Insert Into Orders "
+
"(OrderNumber, FirstName, LastName,
Street, City, State, Zip, Product) "
// "(OrderNumber, FirstName, LastName, Street)
"Values ('
"+
+
{
97
+
theOrderNumber
1h1
rs11 me+
+
theFirstName
fit
III
+
theLastName
+
theStreet
+
theCity
+
theState
+
theZip
+
theProduct
{
try
Retcode = stmt.executeUpdate(theSQL);
System.err.println(
"Return Code From SQL Update "+Retcode);
}
catch (SQLException sqlex)
{
System.err.println("SQL Error "+sqlex);
}
stmt.closeO;
retum(Retcode);
}
}
98
Glossary
1XRTT: Next-generation Code Division Multiple Access (CDMA) mobile networks that
will support 144K bit/sec packet-based traffic. Synonymous with CDMA2000, this
technology is slated for deployment next year and is one of several so-called 2.5G
technologies.
2G: The currently deployed generation of digital mobile networks, also called personal
communications services (PCS) networks. By contrast, first-generation networks, known
as Advanced Mobile Phone Service (AMPS), were analog in nature. 2G in the CDMA
market is synonymous with CDMAOne.
2.5G: Packet-based networks that enable subscriber data rates of 64K bit/sec to 384K
bit/sec and support Mobile IP for always-on connections and transparent roaming. 2.5G
technologies include IXRTT and 3XRTT, as well as Enhanced Data for GSM Evolution
(EDGE) and General Packet Radio Service (GPRS).
3G: Generation of wireless networks on the drawing board that will support multimedia
and enable packet speeds to 2M bit/sec. These speeds will be supported from a fixed
point of access (vehicular speeds will reportedly reach 384K bit/sec), and usually at short
distances, such as within a building or campus. Multiple technologies will fall under the
3G banner. 3G is called IMT-2000 by the International Telecommunications Union
standards body and Universal Mobile Telephone System, or UMTS, in Europe.
Deployment time frame predictions range, unbelievably, from 2001 to 2007; some
skeptics question whether 3G will be needed if 2.5G networks should persevere.
3XRTT: A 2.5G wireless network that will deliver 384K bit/sec packet-switched speeds.
Deployment time frame predictions range from 2001 to 2004.
AMPS (Advanced Mobile Phone Service): Existing analog cellular networking standard.
AMPS operates in the 800 MHz frequency range, with a bandwidth of 30 kHz.
BizTalk: An industry initiative started by Microsoft and supported by a wide range of
organizations. BizTalk is a community of standards users, whose goal is the adoption of
XML in electronic commerce and application integration through the BizTalk
Framework, a set of guidelines for how to publish schemas in XML.
CDF (Channel Definition Format): Microsoft's XML-based file format for the
description of channel information.
CDMA (Code Division Multiple Access): A spread-spectrum method of allowing
multiple users to share the radio frequency spectrum by assigning each active user an
individual code. Current CDMA transmission protocols are specified as IS-95.
CDMA2000: A North American 2.5G technology, synonymous with 1XRTT that enables
packet-switched mobile networks.
99
CDMAOne: Currently deployed generation of spread spectrum-based CDMA mobile
technology, also called IS-95. CDMAOne is a circuit-switched scheme with a subscriber
data rate of 14.4K bit/sec.
CSS (Cascading Style Sheets): A means of defining certain document elements
(paragraphs, headings, fonts, colors, positioning, backgrounds) with style rules instead of
additional markup tags.
DOM (Document Object Model): A platform- and language-neutral interface that
allows scripts and programs to access and update dynamically the content, structure, and
style of documents. It provides a standard set of objects for representing HTML and
XML documents, a model of how these objects can be combined, and an interface for
accessing and manipulating them.
DTD (Document Type Definition): The rules that define the tags that can be used in an
XML file and their valid values.
EDGE: Enhanced Data for GSM Evolution. Third-generation (3G) technology for GSM
networks said to deliver data rates up to 500K bit/sec. EDGE data services could begin in
2002 for the GSM network and the IS-136 TDMA network.
EDI (Electronic Data Interchange): The electronic communication of business
transactions between organizations. XML complements EDI because it can be used to
exchange e-commerce information.
GPRS (General Packet Radio Service): A version of GSM airlink technology that can
combine up to eight (out of eight) time slots in each time interval for IP-based packet data
speeds up to a maximum rate of 160K bit/sec. GPRS supports IP and X.25 networking.
GSM (Global System for Mobile communications): The most mature digital cellular
standard that dominates the wireless world with over 200 million users. GSM networks
offer circuit-switched data services at 9.6K to 14.4K bit/sec speeds.
gXML (Guideline XML): A file structure supported by EDI software company Edifecs
Commerce that allows the open exchange of electronic commerce guidelines.
HTML (HyperText Markup Language): A nonproprietary methodology for creating
Web pages. HTML defines the page layout, fonts, graphic elements, and hypertext links
to other Web documents by embedding tags (codes) within the text.
HSCSD (High-Speed Circuit-Switched Data): A version of GSM airlink technology that
combines two to four of GSM's time slots (out of eight) to provide service at 28.8K
bit/sec to 56K bit/sec speeds.
100
HyTime (Hypermedia/Time-based Structuring Language): A language that specifies
the hypermedia structure of documents.
IETF (Internet Engineering Task Force): An organization of working groups that
identifies problems and proposes technical solutions for the Internet. They publish XMLrelated RFCs (Requests for Comments) and specifications.
IMT-2000: The name given by the International Telecommunication Union (ITU) for 3G
networks.
IS-95: A transmission protocol running in today's wireless networks that employs
CDMA bit-transport technology.
IS-136: A transmission protocol running in today's wireless networks that employs Time
Division Multiple Access (TDMA) bit-transport technology.
Layman-Bray: A proposal for XML namespaces (groups of names defined according to
some naming convention) that ensures that names remain unambiguous even if chosen by
more than one author (see http://www.w3.org/XML/Group/9705/namespace.htm for more
information).
LT XML: An integrated set of C++ and Java-based XML tools from the Language
Technology Group for processing XML documents.
MathML (Mathematical Markup Language): An XML methodology for describing
mathematical notations on the Web, just as HTML does for ordinary text.
Metadata: Data that describes other data. Metadata about an XML document is
described in the DTD or in the XML document itself, enabling other applications to
interact with it.
Metalanguage: A language that describes other languages. SGML and XML can be
considered metalanguages because they define markup languages.
OASIS (Organization for Advancement of Structured Information Systems): A
consortium of companies and individuals that collects and publishes XML specifications,
DTDs, and schemas. By standardizing specifications, OASIS hopes to advance the open
interchange of documents and structured information objects.
OSD (Open Software Description) Format: An XML-based specification designed by
Microsoft and Marimba to automate software distribution. OSD uses unique XML tags to
describe software packages.
RDF (Resource Description Framework): A model for describing and interchanging
metadata. It allows a Web site to describe its dynamic (user-created) content without
having to store static pages that contain that content.
101
RFC (Request for Comments): A document used by the IETF to describe the
specifications for a recommended technology.
Schema: A system of representing a data model that defines the data's elements and
attributes, and the relationship among elements.
SGML (Standard Generalized Markup Language): The "mother of all markup
languages," it's a metalanguage used to construct other markup languages. XML is
designed to be "an extremely simple dialect of SGML" (per the W3C XML specs) for the
Web.
SMIL (Synchronized Multimedia Integration Language): A language designed to
integrate multimedia objects into a synchronized presentation.
Unicode: A superset of the ASCII character set, this 16-bit character encoding scheme
includes not only the standard Roman and Greek alphabets, but also mathematical
symbols, special punctuation, and non-Roman character sets (Hebrew, Chinese, etc.).
TDMA (Time Division Multiple Access): A wireless access protocol that allows
multiple users to share a channel by chopping up the channel into sequentially accessed
time slices. GSM is one flavor of a TDMA network. In addition, there is a set of TDMA
technology specifications known as IS-136.
UMTS (Universal Mobile Telephone System): Europe's name for 3G wireless
networks,
URI (Uniform Resource Identifier): The addressing technology by which URLs
(Uniform Resource Locators) are created. Technically, http:// and ftp:// are specific
subsets of a URI.
WCDMA (Wideband CDMA): Leading contender as a 3G-standard airlink protocol
that provides 20-MHz bandwidth.
XFRML (Extensible Financial Reporting Markup Language): The new "digital
language of business" supported and proposed by the American Institute of Certified
Public Accountants, which allows the financial community to exchange and analyze a
variety of financial reports. Still a work in progress.
XHTML (Extensible HyperText Markup Language): The "XML-ization of HTML"essentially the "newest version" of HTML, which extends its functionality to support a
wider range of devices and applications.
Xlink: A package of hyperlinking functionality that comes in two parts. "X Link" governs
how links are inserted into an XML document; "XPointer" determines the identifier that
102
goes on a URL when linking to an XML document from somewhere else, such as another
Web page. Formerly known as XLL (Extensible Linking Language).
XLL (Extensible Linking Language): The standard for describing links among objects
in XML documents. (See XLink.)
XMI (XML Metadata Interchange): An open information interchange model intended
to give developers working with object technology the ability to exchange programming
data over the Internet in a standardized way, bringing consistency and compatibility to
applications created in collaborative environments. XMI is intended to be either stored in
a traditional file system or streamed across the Internet from a database or repository.
XML (Extensible Markup Language): A data format for structured document
interchange that is more flexible than HTML. While HTML's tags are predefined, XML
allows tags to be defined by the developer of the page. Thus, XML-defined Web pages
can function like database records.
XML dialect: Any "flavor" of XML defined by a DTD that is designed to support a
specialized purpose, such as BIOML (BlOpolymer Markup Language), CML (Chemical
Markup Language), MathML, CDF, TalkML (an experimental XML for voice browsers),
XFRML, etc.
XML editors: Software that allows basic data/metadata editing functions and explicit
control over XML markup. Products run the gamut from simple editors for small
documents, such as Language Technology Group's XED, to more full-featured XML
"word processors," such as Icon's XML Spy, Vervet Logic's XML Pro, and SoftQuad's
XMetaL.
XML entities: Special sets of characters that help expand document content without
increasing the overall character count. Internal entities act as typing shortcuts or macros;
external entities incorporate content from outside sources into the main document.
XML namespace: A way of defining each element type and attribute name in an XML
document unambiguously (through associations with specific URIs) so that two or more
XML-based languages may be used in that document without creating a conflict.
XML processor: A software module that reads XML documents and provides access to
their content and structure. The processor does its work on behalf of another module,
called the application. The processor reads the XML data and provides the application
with the information.
XML-QL (XML Query Language): A query language for XML, which, like SQL, has a
SELECTWHERE construct and uses features of query languages developed for semistructured data. XML-QL is a competing proposal to XPath, but is not likely to be
adopted as a recommendation by the W3C.
103
XMOP (XML Metadata Object Persistence): A set of components that allows the
interoperation between object technologies such as Java, Microsoft COM, and CORBA.
This means that objects can be transported between different object systems (COM and
Java) and different Java VMs (Microsoft's and Sun's).
XPath (XML Path Language): A way of referencing information within an XML
document, intended as a bridge between XPointer and XSLT. XPath uses a directory
notation to perform queries through the selectNodes architecture and lets you determine
which elements within an XML document satisfy a given set of criteria.
XSL (Extensible Style Language): The style standard for XML. Like CSS, it specifies
the presentation and appearance of an XML document.
XSLT (XSL Transformations Language): A language used to transform (reformat)
XML documents into other XML documents. XSLT supports both push and pull
transformations and is designed to be used independently of XSL; however, it is not
intended to function as a general-purpose XML transformation language.
104
References
Adams, M., Geolocation ofPersonal Communications Service Users, The MITRE
Corporation, 1996.
Airst, M., The MITRE Corporation, W092, personal communication, May 1999.
Allen, J., Merging Mobility and Middleware,
http://www.devx.com/upload/free/features/avapro/2000/07julOO/jaOO07/jaOO07.asp
ARC Group, 3G Mobile Handsets, http://www.the-arc-group.com/press/3G.htm.
Berck, J., A BriefHistory of PCS (DigitalCellular) Technology Development in the
United States, Intel Corporation, www.pcsdata.com/history.htm, April 1998.
Bergeron, B., The Wireless Web: How to Develop and Execute a Winning Wireless
Strategy, McGraw-Hill, 2001
Betz, J., The MITRE Corporation, D700, personal communication, April 1999.
Beveridge, J., TransportData With XML, Web Builder, Volume 5, No. 3, Fall 2000
Brock, M., The MITRE Corporation, W096, personal communication, April 1999.
Brown, B. & Brown, M., Wireless PDA Communication, PC Mag, June 16, 2000
Brodsky, I. & Kobielus J., Is Wireless Datafor the EnterpriseReady for Prime Time,
July 24 2000 Issue, Network World
Cagle, K., XHTML: HTML Merges With XML, Web Builder, Volume 5, No. 3, Fall 2000
Cagle, K., ArchitectureX: DesigningforXML, Web Builder, Volume 5, No. 3, Fall 2000
Cagle, K., Transform Your Data With XSL, Web Builder, Volume 5, No. 3, Fall 2000
CELL-TEL International, www.cell-tel.com.
CellularNetworks Worldwide, http://www.cellular.co.za, April 1999.
MITRE Technology Program, Communications and Networks TAT Overview, MII,
http://poisson.mitre.ore: 8080/comm-net.
Comerford, R., Handhelds viefor the Internet, August 2000 Issue, IEEE Spectrum
Magazine, Volume 37, Number 8.
105
Deighton, N., European Mobile Communications: Security on the Move?, Gartner Group,
April 28, 1998.
Egan, R., Fabbi, M. & Hafner, B., Wireless-The Hot Issues in Cellularand PCS,
Gartner Group, April 24, 1998.
Egan, R., U.S. Cellular and PCS Security - An Oxymoron, Gartner Group, May 23, 1997.
Eliason, J., The MITRE Corporation, G037, personal communication, May 1999.
Fichtelman, M., Go Wireless, Web Builder, Volume 5, No. 3, Fall 2000
Foster, R., The S-curve: A New ForecastingTool, Summit Books, Simon and Schuster,
New York (NY). pp. 88-111 (Chapter 4).
FONTANA, J., Is Time, 08/28/00 Issue, Network World
Gaffney, L. M.,. Giallombardo, R. J. & Hulkower, N. D., The Business Casefor Satellite
Communications, The MITRE Corporation, June 1998.
Gardner, P., Cellular Phone Handsets: Growth Market of the Nineties, Fujitsu Compound
Semiconductor, Inc., 1997.
Grygo, E., E-Business Enablers:PartnershipsEssentialfor Wireless ERP Links, May
Issue, Computerworld Magazine
GSM News, Universal Wireless Communications Consortiumand North American GSM
Alliance Sign Historic TDMA-GSM InteroperabilityAgreement, http://gsmpcs.org/pressreleases/rel29.html, February 9, 1999.
Harrison, G., The MITRE Corporation, W092, personal communication, April 1999.
IEEE Orange County Communications and Computer Societies, www.ieeeocs.org/wireless, April 28, 1997.
Jurvis, J., WAE to Go, Web Builder, Volume 5, No. 3, Fall 2000
Kahney, L., 3G Wireless Mess, Wired News, September 2000.
Keenan, R., ITU Approves IMT-2000 Specification, Wireless Design Online, November
9, 1999.
Keenan, R., 3G Causes Huge EMI HeadachesforHandsetDesigners, Wireless Design
Online, http://news.wirelessdesignonline.com/technology-today/19990428-1386.html,
April 27, 1999.
106
Keenan, R., 3G: Standardizationand the Future Wireless Market, Wireless Design
Online, December 27, 1999.
Kiely, D., XHTML The Best of Two Languages, Web Builder, Volume 5, No. 3, Fall 2000
Lawson, S., Wireless Users May Hit a Speed Bump, InfoWorld Electric, October 29,
1999.
Leibovitch, A. M, Worldwide Cellular and PCS Semiconductor Market Review and
Forecast, 1996-2002, IDC, December 1998.
Livingston, G., Third Generation Wireless Standardsto Shape Internet's Future,
WirelessNOW, http://www.commnow.com/3rd Generation.html, August 14, 1997.
Mauck, K., The MITRE Corporation, D730, personal communication, April and October
1999.
Mclndoo, P., The MITRE Corporation, W078, personal communication, April 1999.
Nighswander, P., Olson, K. & Silidiker, S., U.S. Wireless Pricing:1997-1998, The
Strategis Group, 1998.
Office of Telecommunications, U.S. Industry and Trade Outlook 1998, 1998.
Overview, http://utdallas.edu/~xu8589/cs6386/overview.htm.
QUALCOMM Inc., Worldwide CDMA Coverage, http://emediasql2.qualcomm.com.
Madnick, S., MetadataJones and the Tower ofBabel: The Challenge of Large-Scale
Semantic Heterogeneity, Sloan WP#4069, Sloan School of Management, Massachusetts
Institute of Technology, Cambridge
Miles. S., Handhelds to sharedata with new Web service, CNET News.com, May 16,
2000, 3:05 p.m. PT
Patrizio, A., XML Is Nearly Ready For Business, Web Builder, Volume 5, No. 3, Fall
2000
Rennhackkamp, M, Business IntelligenceHits the Road, Web Builder, Volume 5, No. 3,
Fall 2000
Reitman, J., Cellular/PCSDistribution ChannelStrategies, 199 7-2002, IDC, December
1997.
Reitman, J., A Profile of Cellular/PCSSubscribers by Industry, IDC, 1998.
107
Rietman, J. & Gillott, I., Worldwide Cellular/PCSMarket Assessment, 1997-2002, IDC,
June 1998.
Reitman, J., Worldwide Cellularand PCS InfrastructureMarket Assessment, 199 7-2000,
November 1998.
Schiesel, S., 'Holy War' Over the Future of Wireless, The New York Times on the Web,
February 15, 1999.
,
Sharma, C., Wireless Internet EnterpriseApplications, Wiley Computer Publishing,
2001.
Stine, L., The MITRE Corporation, W030, personal communication, April 1999.
The Strategis Group, Third Generation Wireless, Report Summaries,
www.strategisgroup.com and PR Newswire, 1999.
The Strategis Group, U.S. CellularMarketplace: 1998, Summary of Report,
www.strategisgroup.com, 1998
The Strategis Group, U.S. PCS Marketplace: 1998, Summary of Report,
www.strategisgroup.com, 1998
The Strategis Group, U.S. Wireless Pricing: 1997-98, www.strategisgroup.com, January
1998.
The Strategis Group, World CellularandPCS Markets: 1998, summary of report,
www.strategisgroup.com, 1998
Sweet, W., Cell Phones answer Internet's Call, August 2000 Issue, IEEE Spectrum
Magazine, Volume 37, Number 8.
Technological Trends in Wireless Telecommunications, http://tap.gallaudet.edu.
Tomen, D., What Are CIOs Waiting For? [Developer'sNotebook],
http://www.ayg.com/R.po?t=ww073101&1=/wireless/Article.po?id=223043, Jul 25, 2001
Torres, J., The MITRE Corporation, D730, personal communication, April 1999.
Torres, J., The MITRE Corporation, D730, COTS Wireless Communications Homepage,
http://info.itre.org/pub/proi/5 1 /MS/R86U/homepage/index 1998.html, 1998.
Vanderploeg, A., Wireless CommunicationsSecurity,
http://pw1.netcom.com/-vanderpa/wireless.htm, April 1996.
WebTel Wireless, www.webtel.net/pcs.htm.
108
Wexler. J., Network World Wireless in the Enterprise Newsletter, 08/23/00
Wexler, J., Today's focus: What's up with WAP? Part 1 of 2, Network World
Wexler, J., Screen scrapingforbasic mobilization, Network World Wireless Newsletter,
01/01/01
Wireless Communications Room Briefing Boards, The MITRE Corporation, 1999.
Wrolstad, J., Palm Devices Give Public Safety a Hand, Wireless.NewsFactor.com,
Monday October 22
The Yankee Group, Yankee Group Report: Wireless Growth Continues, Unabated3G
Uptake Begins in 2002, PR Newswire, November 30, 1999.
109