Java readies itself for wireless Web services

Emerging Java platforms are well positioned for wireless Web services developers

1 2 3 Page 3
Page 3 of 3


In addition to providing a compatibility layer, the JVM also provides application security through the following ways:

  • The JVM verifies the byte-code application at class load time to ensure that the application does not do anything dangerous
  • The JVM monitors the application execution and avoids memory leaks
  • The JVM can incorporate a security manager or sandbox to verify application digital signatures and grant permissions to access specific APIs (domains) based on the signer's trust level

The three security features above prove important to wireless applications. Wireless devices usually store personal and sensitive data. Users often download mobile code from an insecure Internet. We must ensure that the downloaded application is not a virus and will not try to corrupt or even steal data from the device. To combat such attacks, the J2SE and J2ME/CDC platforms offer fully featured, secure JVMs. J2ME/MIDP uses a simplified byte-code verification scheme to minimize performance hits. Domain-based security managers are available for MIDP 2.0 VMs.

In addition to application security, Java provides excellent support for industry-strength authentication, authorization, and cryptography-based communication security protocols. The Java Cryptography Extension (JCE) and Java Authentication and Authorization Service (JAAS) frameworks are both pluggable and flexible. They provide a set of abstract interfaces of common security algorithms and concepts to application developers. Different providers supply the implementations. You can easily add new algorithms into the frameworks. Java's security framework design separates applications from security solution providers. Therefore, it allows you to choose or switch to any provider and algorithm at any stage of software development without learning new APIs or worrying about compatibility issues. We will discuss more about Java application security technologies in the following section.

Core technologies

We now discuss the core Java technologies needed to support wireless Web services. Some are already available in standard Java APIs; some are currently offered by third-party vendors and are being standardized; others are only in the planning and designing stages.

Interoperable XML standards

As we mentioned earlier, Web services are built around standard XML communication protocols. In wireless Web services applications, servers and clients are loosely coupled with XML messages. So both Web services application servers and wireless devices must support standard XML protocols.

On the server side, the J2SE/J2EE platform offers excellent support for generic and Web services-specific XML processing through the Java API for XML Parsing (JAXP). JAXP features the following:

  • Both pull and push mode SAX (Simple API for XML) parsing
  • Standard DOM (Document Object Model) and a more Java-friendly JDOM format
  • Java API for XML Binding (JAXB), which supports persistent XML mapping for Java objects
  • Java API for XML Messaging (JAXM) and JAX-RPC, which can support Web services SOAP and XML-RPC messages
  • Java API for XML Registries (JAXR), which supports XML registries such as UDDI and ebXML

On the wireless front, mainly three concerns crop up when using XML on small devices:

  1. CLDC VMs have limited string functionalities and cannot run generic XML parsers written for J2SE or any Web services XML APIs built on top of them
  2. Support for XML requires increased processing power
  3. XML formats embed data in verbose text tags, which does not conserve limited wireless bandwidth

Third-party groups offer many CLDC-based XML parsers that require little processing power. Most, such as NanoXML and TinyXML, only support the simpler serial SAX-style parsing. However, in-memory objects are required if you want to manipulate complex XML data. Package kXML developed by offers both SAX- and DOM-style parsers. A W3C (World Wide Web Consortium)-compliant DOM parser proves too heavy for small devices, so kXML uses a lightweight alternative called kDOM. In addition to generic XML parsers, kXML also has packages specialized for SOAP (kSOAP) and XML-RPC (kXML-RPC) message processing. With JSR 172, the J2ME Web Services Specification, the JCP continues its effort to standardize XML support on the J2ME platform.

XML's excessive bandwidth usage has long proved problematic in wireless application development. WAP developers use an XML compression protocol called WBXML (WAP binary XML) to compress WML communication data. You can adopt WBXML as a standard format for compressing generic XML documents. You must install matching compressor and expander modules on both wireless and server sides. kXML provides both modules.

Wireless user interfaces

The major advantage of wireless information devices is their pervasiveness; they melt into our everyday lives. This ability requires not only small, wearable devices, but also devices with nonintrusive user interfaces. The success of Palm PDAs has proven the effectiveness of touch-screen and handwriting recognition input methods. Migrating mature desktop GUIs to small devices has also proven successful since today's computer literate public needs little training to use common GUI components such as buttons, selection boxes, and textboxes. Most J2ME technologies support GUIs. The smallest MIDP has its own lightweight GUI components and event-handling models. More complex profiles, such as the PDA profile and Personal Profile, adopt GUI models commonly used in the desktop J2SE world (such as AWT) to ensure the maximum portability level.

Though convenient, GUI-based devices are still interruptive. For example, on a GUI-based device, users have to use both hands to input long text or make complex selections. By contrast, voice-navigated information services can integrate into workflows much better. We can talk on the phone while performing other sophisticated tasks (such as driving). The leading technology enabling voice-based information navigation is VoiceXML. Similar to HTML, a VoiceXML page can present information, take user input, and jump to another page based on that input. The difference: An HTML page presents and takes text information, while a VoiceXML page handles voice information. However, VoiceXML pages are written in XML text format since backend applications that generate VoiceXML pages only work with text data. Voice recognition and synthesis technology proves crucial to bridging voice and XML text formats.

JSR 113, the Java Speech API 2.0, proposes a set of standard Java APIs for voice recognition and synthesis. But voice algorithms still prove too computationally intensive for small handheld devices and require expensive software. Current VoiceXML applications require gateway servers to perform voice recognition and synthesis. Those voice gateway servers could become parts of voice portals, similar to WAP portals. The voice portals act as information call centers for customers: they contact Web services on behalf of users and translate information back and forth among voice, text, VoiceXML, and SOAP messages. However, with the exclusive voice portal model, the mobile application can only access the portal through a voice phone line/channel, and all information must be presented in voice format.

For many applications, we want to mix voice information with other forms of digital information, such as graphics, text messaging, and streaming video. One way to integrate voice into TCP/IP network-based applications is through Voice over IP (VoIP). VoIP specifies how we should transport voice on a data network. VoIP-enabled VoiceXML gateways can respond to voice streams from the Internet instead of a phone line. A VoIP server can be just a hub service in the vast network of backend Web services.

Figure 3 illustrates the architecture of a smart wireless application that uses both voice and common GUIs.

Figure 3. Mix voice, text, and graphics in one wireless application


As discussed previously, Java supports cryptography and mobile code security. However, securing Web services proves more challenging than securing traditional Internet applications. Web services are designed to improve productivity and interoperability; security comes as an afterthought and is largely vendor-specific. Yet, Web services run outside corporate firewalls and can potentially expose an internal network to the outside world. As a result, security concerns provide major obstacles in deploying Web services. Security is also a chief challenge for wireless applications due to radio signals' vulnerability to interception and the lack of computing power for performing strong cryptography operations on small devices. In this section, we discuss Java technologies on both server and wireless ends that improve wireless Web services security.

Web services require end-to-end security for XML messages traveling across multiple intermediaries, thereby making traditional point-to-point secure communication channels (such as HTTPS) inadequate. Secure XML protocols such as XML Digital Signature and XML Encryption can bind with Web services communication protocols (such as SOAP) to secure XML contents. JSRs 105 and 106—the XML Digital Signature APIs and XML Digital Encryption APIs, respectively—propose Java APIs to support XML Digital Signature and XML Encryption. However, on the wireless front, most standard Java security and cryptography APIs are only available to J2SE and J2ME/CDC applications. Due to small devices' limited computing power, J2ME/MIDP only officially support HTTPS secure connections from the upcoming MIDP specification version 2.0. Only third-party vendors provide support for general cryptography algorithms on the J2ME/MIDP platform. One such lightweight CLDC-compatible cryptography package is the Bouncy Castle Crypto APIs. To learn how to use these APIs, please refer to Michael Yuan's developerWorks article, "Securing Your J2ME/MIDP Apps," (June 2002).

Another vitally important security feature in Web services is single sign-on, required for keeping multiple service vendors transparent to users. Sun's Liberty Alliance Project promotes single sign-on services based on federated identity. The alliance will probably base the implementation on Kerberos technology. You can deploy Kerberos plug-ins for JAAS for tight integration among Web services. You can also embed Kerberos-like security tokens in SOAP message headers as SAML (Security Assertion Markup Language) elements for loosely coupled solutions. JSR 155, the Web Services Security Assertions, proposes Java APIs that support SAML. IBM and Microsoft's WS-Security, another set of XML protocols, competes with SAML. The IBM Web Services Toolkit offers Java solutions for WS-Security.

When approved, JSR 177, the Security and Trust Services API for J2ME, will provide Java APIs to SIM (Subscriber Identity Module) cards embedded in wireless devices. SIM cards usually store identity and cryptography keys. They provide automatic authentication and authorization on wireless phone networks. Together with SAML or WS-Security, JSR 177 APIs could enable automatic single sign-on services for SIM-enabled wireless devices.

For more discussion on J2ME and Web services security, please refer to our article "Securing Wireless J2ME" (developerWorks, June 2002).


One of the biggest problems with smart wireless applications is performance. As alluded to earlier, Java's development productivity and cross-platform compatibility take priority, and, thus, the JVM cannot benefit from many hardware-specific optimizations. However, advanced security and application data-processing features require high performance on the wireless end. Efforts such as JSR 177 are underway to make special hardware features available to standard Java APIs. Technologies such as Java-optimized CPUs and coprocessors, and just-in-time Java compilers are already available. For many applications, Java programs run as fast as C/C++ applications. Sun's project Monty promises to deliver CLDC and CDC VMs that run 10 times faster than current VMs with small footprints.

Go wireless

In this article, we introduced wireless Web services and the Java technologies that could power them. Current and emerging Java platforms are well positioned to help develop pervasive wireless solutions. Today's buzz phrase, wireless Web services, is becoming tomorrow's exciting reality!

In subsequent column articles, we will discuss specific techniques to implement wireless Web services applications.

Michael Yuan and Ju Long are PhD candidates at the University of Texas at Austin. They are both research associates in the Center for Research in Electronic Commerce. Their main interests are mobile commerce and wireless-based marketing research.

Learn more about this topic

This story, "Java readies itself for wireless Web services" was originally published by JavaWorld.

Copyright © 2002 IDG Communications, Inc.

1 2 3 Page 3
Page 3 of 3