As 2003 approaches,the point at which wireless Web users are expected to outnumber wireline users, there's little talk of the challenge to build wireless applications for them, applications to reach reach all of these users (as opposed to segments of these users whose devices support proprietary protocols).
Open source tools, apps, and projects are expected to consume the proprietary, wireless Internet, just as they consumed the wireline Internet with implementations of TCP/IP and HTTP. Further, the combination of open Internet standards and open implementations of these standards will fuel the convergence of the wireless and wireline Internet.
There are two major wireless Internet technologies in broad deployment today,WAP and i-mode, with a third, Java 2 Micro Edition (J2ME), being adopted by PDA and handset manufacturers. The analyst group Eurotechnology reported in November 2000 that the global adoption rate of these technologies was about 60% for i-mode and 39% for WAP. 81% of these wireless Internet devices are in use in Japan today, with the rest scattered throughout Korea, the European Community, and a very tiny percentage in the United States.
By "proprietary", the author means that there is no mechanism that exists for a corporation, non-commercial entity, or individual developer to contribute, implement, or extend these technologies without licensing or payment. Thus, proprietary is contrasted by "open", which implies that such a mechanism exists.
A handset or PDA manufacturer that intends to implement any of these technologies must obtain licenses from Sun, the WAP Forum, or NTT DoCoMo. In the case of WAP, developers are further threatened by patent litigation by Geoworks, which claims to have a patent on WML, and is pursuing patent license royalties from all companies that implement the language.
Each of these wireless technologies today is proprietary and offers dramatically different implementations. Clearly, this presents a daunting challenge to any entity hoping to provide either content (news, sports, stocks, etc.) or applications (games, entertainment, corporate field force automation, etc.) to a global audience. i-mode, which has 21 million subscribers as of this writing, uses Compact HTML (cHTML) for its presentation technology. WAP devices use the Wireless Markup Language (WML) for their presentation technology. The J2ME presentation technology is not a mark up language like cHTML or WML but, rather, Java code. In each of these cases, the technologies are copyrighted and licensed to device manufacturers (both handset and PDA vendors), and there are no open specifications or implementations of them.
The global wireline Internet, however, is built around non-proprietary standards and open implementations. History demonstrates that the underlying data transfer protocol (TCP/IP), the presentation and file transfer protocols (HTTP, FTP), and even the presentation technologies themselves (HTML 1.0, 2.0, 3.0, 4.0 and its successor XHTML 1.0) were successful precisely because they were open standards, which any vendor, non-commercial entity, or developer could implement.
Today's nascent wireless world reminds one of the Internet's early days: instead of conflicting implementations by Netscape and Microsoft of HTML and associated scripting facilities, we have WML/WAP, and cHTML/i-mode for Web phones and handhelds, and SMS for pagers . Like the early days of the wireline internet, wireless internet developers struggle to test their code on as many phones and devices as possible. The implementations of proprietary technologies are so inconsistent as to force a "write once, test everywhere" strategy. Indeed, an entirely new industry has sprung up, as a result of these conflicting implementations, which promises to test and then certify that content or applications that one develops will actually run on implementations of the intended protocols and devices. (See http://www.anywhereyougo.com/, a firm offering to certify that content and applications written to the WAP specification actually function on devices that claim to implement the WAP specification.)
As in the wireline Internet, however, proprietary and conflicting implementations are unsustainable. To succeed, the wireless Internet will move to open standards, and this migration has begun already.
The goal of this paper is not to harangue the existing wireless Internet implementations. The early presentation technologies and protocols substantially improved the wireless landscape by demonstrating to the world technologies and business models that were valuable and, in some cases, valueless.
Lessons from WAP
WAP is something of a contradiction in its technology, implementation, and intent. WAP is nearly open in its intent, with a strong leaning toward heterogeneous carrier networks and handsets. WAP is carrier and handset independent, meaning that any carrier can implement the specification and any handset manufacturer can implement the presentation technology inside a WAP browser. The size of WAP Forum, more than 500 members, demonstrates the compelling benefits of an open handset and carrier approach. However, this openness is clouded by a closed WAP Forum which only gives rights to its paying members, and which hose a technology implementation that worked with no existing tools and no existing development paradigm. I list below some of the compelling technology advantages, most of which were re-implementations of existing wireline Internet standards, as well as the technical and business flaws.
WML is an XML language, which provides an outstanding mechanism to ensure that a document is well-formed, valid, and portable. Dominant Internet technologies such as Java and corresponding .NET technologies from Microsoft completely embrace an XML approach to application development.
WAP, as demonstrated by the chart above, has strong adoption among carriers and handset manufacturers, and holds second place in terms of handset units deployed.
It has high carrier and developer Costs, requiring a gateway to transcode Internet content and protocols into WAP content and protocols. These gateways are costly, inconsistently implemented, and offer no compatibility test suite to ensure that applications and content are predictably transcoded by the competing vendors who implement the gateways, which leads to high deployment and debugging costs.
Application and Content developers must acquire new, or upgrade existing, tools in order to author WML pages, as traditional web development tools are generally incapable of properly authoring and checking the syntax of WML documents. They must learn new application development concepts (cards, decks, etc.) that are non-trivial.
Due to the necessity of the WAP gateway to transcode content and protocols, there are security concerns about data being decoded and re-encrypted between the server of origin, hosting the application, and the WAP gateway as it transforms HTTPS to WAP/WTLS.
Lessons from i-mode
In the i-mode implementation by NTT DoCoMo, carriers and businesses around the world have witnessed the first viable wireless Internet business model for developers of wireless content and applications. Not surprisingly, NTT learned most of these lessons NTT by observing the wireline Internet.
Under the i-mode network, content and applications developers are able to sell their content for a monthly fee. All three elements of the network are satisfied: the end user receives the content they require; the developer is compensated for creating the content; and the carrier derives income from a commission drawn from the developers' fees, as well as per-packet network revenues.
Further, i-mode has taught carriers and businesses the technical benefits of a nearly open wireless implementation. Specifically, the i-mode network's use of cHTML has resulted in three key business technology benefits:
Rapid Application and Content Development -- because existing HTML developer tools easily author cHTML pages, existing skilled employees can rapidly create i-mode content and applications.
Reduced Costs of Implementation -- because no gateways are required to transcode content or applications in order for that content to reach end users' devices, carriers need not purchase gateways, nor absorb the costs of testing an application to determine its compatibility with different gateways.
i-mode also taught a rather significant lesson, the impact of which is only now being realized:
Note, NTT DoCoMo has purchased a 16% interest in AT&T Wireless. The i-mode protocol will be brought to the United States and rest of world via the AT&T network as well.
Renegade Implementation -- a proprietary network protocol like cHTML/PDC-P is not easily shared by other carriers, and thus even a handset capable of viewing cHTML cannot access cHTML content if the end user is a SprintPCS, Nextel, or KDDI subscriber. NTT DoCoMo has exclusive control of the protocol, the presentation technology, and the billing mechanisms. Thus, for all the benefits listed above, these benefits can only be realized on the NTT network; developers who want to contribute to, implement, or modify the specifications cannot.
Surprisingly, for a company that learned so many lessons from the wireline Internet, i-mode does not implement any scripting language. The end user experience is limited by the static nature of the pages.
Finally, although NTT DoCoMo was the first to implement Java on the i-mode network, the implementation is a proprietary derivation of the Java 2 Micro Edition specification and not compliant with the tests that Sun provides to ensure application portability between handsets and carriers.
Lessons Learned from Java 2 Platform, Micro Edition
Sun, with its "the network is the computer" approach, handles wireless development in a way that demonstrates its background in enterprise application development and deployment platforms. Sun's historical strength within the telecommunications marketplace was not lost on the Java team, and all of the expertise of Sun has been brought to J2ME. Indeed, with J2ME, Sun has completed the evolution of the Java 2 Platform. Java, first implemented as a client technology, then embraced as a portable server technology, has come full circle to find a place on wireless Internet client devices in the form of J2ME.
Benefits of the J2ME platform include the following.
J2ME applications persist on the client -- the single greatest asset to the J2ME approach to wireless applications is the fact that J2ME applications reside on the client and can function on the client device even when the device cannot connect to the network. Network dropouts are inconsequential when the application can persist on the device, capable of caching newly entered data until a new connection is established.
J2ME applications are secure -- the J2ME application developer has full access to HTTPS for end-to-end application security.
J2ME applications are cost effective to carriers -- like i-mode, J2ME requires neither transcoding nor gateways, thus lowering infrastructure costs and simplifying testing.
J2ME applications are pervasive -- nearly every handset, PDA, and carrier has adopted the J2ME specification.
Applications are far more graphically rich, with far higher control of the end user experience (full-motion graphics, business logic executing on the client, etc.)
Constraints of the J2ME platform are as follows.
J2ME in not yet pervasive -- while every manufacturer has licensed the technology, there are precious few devices on the market today (approximately 1 million). New cellular phone adoption has been extremely rapid, however, although with current market conditions this is unknown.
J2ME designers are not HTML/WMP/cHTML designers -- J2ME requires that a content or application developer re-author their application to target J2ME devices (a problem shared with WAP and i-mode). However, a designer can purchase an upgraded tool to author WML and learn these skills. In contrast, a designer is unlikely to take a crash course in Java programming to learn to design presentations in Java, thus forcing the designer to work with Java developers in order to implement their application.
J2ME applications may have installation overhead -- in the USA, carriers have commented that J2ME/MIDlet applications must be installed on the device via a process of connecting to a PC (not unlike how Palm Pilots are synchronized with their PC hosts). This overhead will be costly for large organizations. Note, this is a choice of the carriers, however, as the J2ME applications rolling out in Japan install dynamically over the network.
A proprietary wireless Internet is no more viable than the failed attempt by vendors to keep the wireline Internet proprietary. It is not in the interest of the consumer, nor the carrier, to have any barriers to adoption of new content and applications. If content and applications are not accessible, then there are precious few business models that are viable. Application and content developers are compensated for their applications, and they require the widest audience of end users in order to maximize their financial gains from their investment in. Carriers themselves generate annuity revenue via the provisioning of packets and airtime minutes, and if applications are inaccessible, airtime and packet revenue is lost.
Detailing the apparent absence of annuity revenue for device manufacturers is beyond the scope of this article, but certainly a compelling question to ask, since application developers, as shown by i-mode, receive annuity streams monthly from their visitors and carriers receive month annuity streams from their subscribers.
Thus, the proprietary implementations of WAP and i-mode were not viable from the outset, and with the release of the new WAP 2.0 and i-mode 3.0 specifications, dramatic steps have been taken by both organizations to better follow the successful path of the wireline Internet. Specifically, both WAP 2.0 and i-mode 3.0 have adopted the XHTML 1.0 standard as the foundation of their upgraded platforms (targeted for release in the third quarter of 2001).
This migration to XHTML is both a realization of the inevitable as well as a technologically brilliant choice. XHTML is an XML re-implementation of HTML. Since it's an XML language, it's easy for developers to extend, to program to, and for tools vendors to support and automate. As the successor to HTML 4.0, which all PC browsers support today, XHTML is or will be the de facto presentation technology for all new PC applications. Thus one standard presentation technology will provide comprehensive support for every network, for every carrier, for every developer. In the very near future, only the form factor (the size of the mobile device's screen) will determine the difference in the presentation delivered to phones, PDAs, and PCs.
See http://www.jdom.org, http://zeus.enhydra.org, http://kxml.enhydra.org for details. Sun is incorporating JDOM as part of Merlin, the Sun Java Development Kit (JDK) 1.4, and redistributes the kXML parser on their Sun Wireless CD.
But where does this leave Java and devices? Since Java presentation isn't a markup language, but rather Java code, Java devices cannot make use of the XHTML standard for their presentation capabilities. However, the evolution of Java/XML binding specifications, currently driven via open source projects such as JDOM, Zeus, and kXML, provide a clear and easy mechanism for Java client devices to request the exact same XHTML stream that a PC browser requests, and parse it locally on the device for presentation to the J2ME client (frequently called a MIDlet).
Just as the specifications for wireline and wireless presentation technologies have converged on open source standards, so too in parallel have open source infrastructure projects evolved to implement these standards. Thus, while the W3C has provided a home for XHTML and other XML standards like VoiceXML, so too have open source implementation projects at Apache.org and Enhydra.org begun to implement these standards for developers to employ.
The infrastructure of a wireless or wireline implementation is generally made up of 5 components:
It is currently unlikely that the first of these will be offered freely to the world, although it is clearly the strategy of companies like Intel and AMD to commoditize the hardware platforms and force their way into datacenters and enterprises.
However, next on the hardware stack required for Internet applications is a multi-threaded operating system. With Linux 2.4, Windows NT 2000, and the family of UNIX operating systems, developers are free to choose among operating systems. At this level open source offers a compelling alternative to commercial operating systems, and even Sun has begun to open source some of the Solaris operating system in response to the growth and adoption of Linux. And with 60% of all web servers now running Apache, open source is the dominant solution for this tier of the stack. Indeed, IBM has adopted Apache as its software product and resells it under its own brand to customers.
The database tier is a place where open source is struggling to demonstrate its viability. Fear, uncertainty, and doubt about performance, stability, and maturity of open source database implementations have hampered their widespread adoption within enterprise applications. Increasingly, PostgreSQL is emerging as a viable departmental SQL database, although its portability to operating systems other than Linux remains to be seen.
Finally, at the application server level, developers have one of two architectures to consider: the proprietary Microsoft .NET implementation, currently still in development, and the Java 2 Enterprise Edition (J2EE). Currently, J2EE is the dominant platform for enterprise applications and is the foundation of all ERP solutions from Oracle and PeopleSoft, as well as many other enterprise application companies. Due to the open nature of J2EE, and the ability of any firm to implement it, open source projects implementing the J2EE abound, with early market leadership going to the Enhydra project.
Lutris Technologies, with support from developers in more than 50 countries, contributes to the open source Enhydra application server. Primary project sponsors include France Telecom and BullSoft/Evidian. Lutris brings a very practical business approach to the implementation and development process. Many wireless projects employ Enhydra for multi-device, multi-protocol application development, including an open source XML engine called Enhydra XMLC.
Enhydra XMLC was first launched in the open source community in April 1999 with the goal of reducing programmer-designer interdependency. Its features reflect two waves of evolution. Initially, XMLC was designed as an alternative to JSP to allow nontechnical designers and Java developers to work independently in optimizing user interfaces for PC browsers, freeing designers to use their preferred tools such as Macromedia. Then, Enhydra XMLC was improved by input from the Enhydra development community and the open source process. During that phase, David Li of DigitalSesame in Taiwan and others worked with Lutris developers to expand XMLC's support for page development from HTML to its current support of all wireless markup languages (WML, cHTML, and XHTML). Lutris has also worked with Sun to enhance Enhydra XMLC support for VoiceXML and J2ME. A new subproject in the Enhydra community focuses on XML parsers for the J2ME platform, called kXML. Concurrent with this innovation in the open source community, Motorola iDEN recently announced that Enhydra, XMLC, and kXML would be the development platform for their new J2ME phones, demonstrating that the premier USA provider of handset technology understands the value of open source implementations and the open source development methodology.
Enhydra XMLC is a Java technology that eliminates the need to include Java code in web pages (regardless of whether those pages are HTML, cHTML, WML, XHTML, VoiceXML or arbitrary XML for J2ME and Flash clients). It uses a W3C standard, cascading style sheet ID attributes, to identify areas of dynamically delivered content, and to associate each area with the Java method that will deliver its content.
The XMLC compiler reads HTML, WML, or *ML template files to generate two types of output. The first is a Document Object Model tree (DOM) using one of the included XML parsers, like the Apache Xerces XML parser. The DOM tree is a Java class, representing the XML page as a hierarchical data structure. A programmer can now introduce code into his or her application that uses the Java DOM library to manipulate the tree. When the tree manipulation is complete, the DOM is converted back to HTML and streamed to the client by the writeDOM method. Enhydra XMLC recently added lazy DOM support to enhance performance and reduce the DOM memory footprint.
Secondly, Enhydra XMLC generates convenient setter and getter methods that are created as the compiler detects ID attributes. These methods relieve the developer of the need to add logic for traversing the generated DOM to find the node in question. The name associated with the ID is used to create the method name.
Designers can leave mocked-up data, such as "John Doe," in the HTML page. That's a huge benefit for designers because they can use the same document for both the mocked-up storyboards of a web presentation and the production development environment. The XMLC engine can be instructed to remove mocked-up data by referencing the class name.
As XHTML becomes the dominant presentation technology for all devices, the design community and the developer community have an easy means of targeting all mark up languages. Additionally, as mentioned above, J2ME client developers benefit from XHTML and XMLC to easily send XML data down to the Java device, which then parses the stream using the kXML parser.
As a pure Java implementation, developers can use Apache, PostgreSQL, Enhydra, Enhydra XMLC, kXML, and XHTML with any standard Java application server, including BEA WebLogic and IBM WebSphere, and indeed even with non-Java application servers, such as ones written in Python or Perl. In this manner, open source implementations and open standards actually bring to the wireless Internet the exact commodity nature of the wireline Internet that's made it so ubiquitous.
As of this writing, Nokia just launched an XHTML initiative for their new handsets, Motorola just launched their new J2ME handsets, and RIM and Palm have just provided developers with Beta SDKs for their J2ME implementations. Ironically, the only application server available today with full support for J2ME and XHTML is from the open source community. Open source and open standards continue to tear down the proprietary walls that inhibit the adoption of a wireless Internet.
Keith Bigelow is an expert Java and XML developer, trainer and lecturer focused on wireless issues and applications.
Return to ONJava.com.
Copyright © 2017 O'Reilly Media, Inc.