Onward and Upward: WAP-NG Prepares for Release
By Bryan Morgan, Mon Apr 09 00:00:00 GMT 2001
WAP-NG (or WAP 2.0) greatly enhances mobile browsing and ushers in a whole new suite of services. Here's where the wired web (finally) meets wireless.
"So let me get this straight", a friend says to me as I describe the wonderful world of wireless to him. This friend has sold two successful companies and is no stranger to the computing industry's efforts to continually pursue vendor lock-in and industry "standards" set forth by one or two companies.
"You're saying that if I want my app to work for many of the phones in the U.S. today, that I need to code using HDML. However, in a few weeks months, I need to plan on using WML. Then , a few months later, I need to plan on using XHTML. Is this what I'm hearing?"
I gave him my best don't-shoot-the-messenger look and meekly tried to explain how well thought out the WAP architecture was and how great things would be once an appropriate communications infrastructure (i.e. a packet network via GPRS) was in place. I didn't bother explaining that he'd probably also need to cut a deal with several of the major carriers here in the states if he hoped to see his application actually used by the masses.
Turns out, this explanation wasn't required - like many before him, he opted to postpone the WAP development project for now until his target audience and the underlying technologies had "matured".
Wireless data proponents are now facing a classic chicken-and-the-egg scenario: how do we develop profitable wireless data services without next-generation technologies in place? At the same time, how can we justify the rapid, expensive, rollout of next-generation services when consumers (with certain geographical exceptions) are not responding enthusiastically to the services we are already giving them?
One technology that has clearly born the brunt of this uncertainty is the Wireless Application Protocol, in its version 1.x incarnation. Due to the unfettered hype surrounding the technology's first release, WAP has endured the attacks of the technology media due, in large part, to the problems surrounding wireless data services today: tiny black-and-white graphical displays, circuit-switched networking connections, difficult data entry on phone keypads, and poor bandwidth and response times.
Note that none of the problems above are in fact WAP-specific issues but end users don't want to hear the explanation: they just want things to work as advertised.
WAP moves forward
A tough situation such as this left the forces behind WAP with several choices: stick to the original plan with minor enhancements, fold up the tents and let the marketplace sort things out, or stick with the original game plan while also adding in new features and enhancements that the market clearly demands.
With WAP 2.0 (also known as WAP-NG, for "Next Generation"), the WAP Forum has chosen the latter option. Along with the proprietary, XML-based Wireless Markup Language (WML) introduced with WAP 1.0, WAP-NG includes support for XHTML Basic (another XML-based markup language that more closely resembles HTML) as well as the industry standard TCP/IP networking protocols.
The move to XHTML will allow WAP to co-exist with other wireless technologies (such as NTT DoCoMoís i-mode, which is also moving toward XHTML as its markup language) while TCP/IP support will allow WAP devices to be ready for the packet networks.
While XHTML support is likely the most widely reported capability of the WAP 2.0 platform, there are a host of other enhancements. To begin with, support for the Wireless Telephony Applications Interface, or WTAI, and Push applications (both introduced with WAP 1.2) may finally see widespread deployment when WAP 2.0-compliant browsers hit the market.
End-to-end security (long overdue) will also become a reality through the use of the Wireless Identity Module and PKI services. In fact, WAP 2.0 marks the move away from the simple thin-client/thick-server model popularized by the World Wide Web.
Instead, WAP 2.0 supports a host of client services designed to interact with server-side services. These services include support for streaming media, MMS (i.e., next-generation SMS), cookies, and data synchronization - as well as the standard "hypermedia retrieval" services (i.e. WML/XHTML content retrieval). Service discovery capabilities are included in the WAP stack to allow devices and/or applications to dynamically determine what services are available at runtime.
Keep in mind that the move to XHTML is, in and of itself, no sure panacea to the criticisms levied at WAP over the past two years. The wireless industry is being pulled between the desire to support a slimmed-down markup language for devices with small displays and the need to avoid the appearance of "reinventing the wheel".
Also, WAP 2.0 does not specify XHTML as the standard; instead, it says that WAP 2.0-compliant browsers will support both WML and XHTML - if you think this is beginning to look like a Tower of Babel, youíre not alone.
I personally believe XHTML represents an excellent attempt to right the wrongs of HTML's progress (or lack thereof) as well as eliminate the nonstandard additions and sloppy coding that resulted from the browser wars of the late 1990's. Unfortunately, due to this attempt to uphold backwards compatibility and the baggage WAP already carries with it, many developers may simply choose one of the many other options that are beginning to proliferate.
Competition is mounting
North American consumers and enterprises have numerous wireless data options, with more appearing on what seem like a monthly basis. It is important to note, however, that no single service (besides WAP) offers an open platform that can be used by any mobile consumer with a common mobile phone.
Services such as Metricomís Ricochet, GoAmerica, and OmniSky allow developers to bypass WAP completely - assuming your target users are customers of these ISPs. Mobile platforms from vendors such as @Hand, Aether Systems, and AvantGo offer the ability to deploy applications that can function in a disconnected environment as well as a wireless environment - assuming you donít mind locking your apps into these vendorsí toolsets.
The only platforms with a goal of ubiquitous deployment appear to be DoCoMo's i-mode service and Sun's Java 2 Micro Edition. J2ME is, if anything, complementary to WAP just as Java applets are complementary to HTML on desktop clients (thus the recent partnering announcements from companies like Openwave and Sun Microsystems).
As each day goes by, it becomes clear that i-mode is less about technology and more about product marketing, packaging, and business partnering. i-mode has become a sort of AOL of the wireless world in that they've succeeded where many others have failed by placing less focus on developing an overarching platform while placing more focus on content providers and ease-of-use. DoCoMo appears ready to bring i-mode to both Europe and North America later in 2001 which should prove to be a very interesting experiment indeed.
Standardization is key
Despite the obvious shortcomings to many of the initial WAP service rollouts over the past year, I believe that one thing is clear: there is a need for a standardized way to display information on (and retrieve information from) mobile handsets.
Currently, WAP is the only markup language-based solution to this need for developers wanting to target a global mass-market. WAP 2.0 promises to move the platform towards more open standards as well as introduce several exciting new capabilities.
In the technology industry, giants such as Microsoft have become known for never really getting a product completely right until the third release. If this holds true for WAP, we can take comfort in knowing that the platform is only halfway there!
Bryan Morgan was the founder of WirelessDevNet.com (The Wireless Developer Network) and is currently an independent writer and software developer. He is a columnist for Wireless Internet magazine and is also a regular contributor to WirelessWeek.com and InformIT.com.