Java readies itself for wireless Web services

Emerging Java platforms are well positioned for wireless Web services developers

Convenience is the major motivation behind our adoption of wireless technology. The ability to access information anytime from anywhere drastically increases our productivity as well as our quality of life by allowing us to work from home, car, school, or vacation resorts, and manage time more flexibly. Besides the unprecedented convenience, a wireless Internet also improves the quality of the information services. By taking advantage of wireless devices' pervasive nature, you can dynamically customize information services for each user based on her location, mood, or other real-time data.

The wireless Internet's dynamic nature requires a new breed of dynamic services, which likely involves many service providers. Even simple mobile commerce tasks require much expertise. For example, a straightforward stock trade application necessitates services such as user authentication and authorization, customer relationship management, stock quotes and tracking, trade executing, and fund transfer. Those services are built upon more basic services, such as Internet connectivity, security, and transactional reliability monitors. The IT industry's history has shown that a single vendor cannot offer the best expertise or services in all fields. The best economic model features small vendors providing modularized service components, each serving its core competency. Those modularized reusable software components are called Web services. To minimize bandwidth and CPU usage, wireless users can selectively use only the core services they need. Applications that utilize a wireless front end for pervasive human interfaces and Web services on the back end to leverage the Internet's vast information resources are called wireless Web services applications.

Web services from different vendors must interoperate from machine to machine to provide transparent services to customers. Distributed computing services have long been able to work with each other through remote procedure calls (RPC) and remote object frameworks. However, building such an interoperable network on an Internet scale requires industry-wide standardization of communication protocols. We have XML-based protocols to standardize Web services' dynamic discovery processes (UDDI, or Universal Description, Discovery, and Integration); service interfaces (WSDL, or Web Services Description Language); and asynchronous and synchronous messaging (SOAP, or Simple Object Access Protocol, and XML-RPC). On top of those communication protocols, other protocols provide more enhanced functionalities, such as the XML Encryption and XML Digital Signature protocols for improving security. For instance, you can embed an XML digital signature in a SOAP message to guarantee that message's integrity.

Throughout this article, we explain wireless Web services' network architectures, how Java fits into the wireless Web services picture, evolving technologies, and future trends. Since much literature already discusses server-side Java platforms and Java-based Web services, we focus only on Java's role in wireless application development.

Wireless Web services architectures

A wireless Web service can feature one of the following architectures: wireless portal network, wireless extended Internet, or wireless ad hoc network.

Wireless portal network

In a wireless portal network, the wireless information devices connect to the Internet backend services through portal entry points. The portal creates a "walled garden" and controls access to Internet contents. Wireless portal networks support widely deployed thin-client wireless technology, such as WAP (Wireless Application Protocol). In general, a WAP-based Web services portal works like this: The wireless device sends an information request embedded in a WML (Wireless Markup Language) form. The portal receives the message, checks the user's privilege, and then translates the request to a SOAP message or an XML-RPC call to an appropriate partner Web service. The Web service replies, and the portal translates the response back to a WML document. The portal sends the WML document back to the wireless device for display. In this way, the portal works as a proxy for wireless users. The portal operator provides user authorization and management services. Many partner vendors can provide real application Web services under the ASP (application service provider) model.

The advantages of thin client-based portal networks include:

  • The technology is mature, widely deployed, and well supported. If you require immediate wireless capabilities, you should investigate this option.
  • Thin clients require little computing power and therefore can run on small, light devices.
  • Only server-side computers can handle many computationally intensive application functionalities—such as voice recognition engines, as we will discuss later.

However, wireless portal network combined with thin clients might not fit best for dynamic wireless Web services for the following reasons:

  • From the business viewpoint, the portal architecture requires a central entity to control all user data. Backend service providers must rely on the portal architecture to access users. The portal provider decides what services can access its walled garden and demands a profit share from partners. That could cause serious business concerns if an untrustworthy, insecure, or abusive monopoly controlled the portal.
  • The portal architecture has a central failure point, which exposes the whole network to attacks.
  • Thin clients offer limited user interfaces. They are not pervasive.
  • Thin clients do not remember complex application state information; thus, the user must navigate through multiple pages to complete complex tasks, such as transactions. Not only is that inconvenient to the user, but it is also slow and uses precious wireless bandwidth. Moreover, it renders thin clients vulnerable to network interruptions.
  • Thin clients only support limited and predefined security protocols, such as HTTPS secure connections. We cannot have application-specific flexible security policies. In case of a WAP portal, a misconfigured gateway can easily cause security gaps.

New advances in wireless devices technology allow small devices to run more sophisticated client software, or fat clients. A network structure designed for fat clients can eliminate many problems of the thin-client portal network solution.

Wireless extended Internet

Wireless extended Internet is the wired Internet's expansion to wireless devices. Today's handheld devices have more computing power than many desktop PCs did 10 years ago. Wireless information devices can have their own IP addresses (through Internet Protocol 6) and full network functionalities. Those devices usually run smart, fat clients that interact with multiple backend services simultaneously and store/process application data on the device.

Smart devices support sophisticated user interfaces, offline processing, and automatic transactions. They can also implement flexible, application-specific security policies. Like the Internet itself, the wireless extended Internet architecture is decentralized (without a controlling business entity) and eliminates any single point of failure. However, as you will see later, centralized Web services hubs are still required to support advanced security schemes (such as single sign-on authentication) and user interfaces (such as VoiceXML engines). Unlike the portal architecture, the hubs themselves can be decentralized. Different vendors can provide similar hub services that can interoperate with each other. Figure 1 shows a topography diagram for such networks.

Figure 1. Wireless Web services architecture. All communications use XML-over-HTTP protocols. Server-side Web services group into single sign-on security realms. In reality, hubs other than single sign-on authenticators exist.

The extended wireless Internet architectures blended with decentralized hub Web services will provide the foundation for future wireless Web services applications, an approach we focus on throughout this article. Since most of the supporting technologies are just emerging, many challenges prevail. In later sections, we will discuss those challenges and suggest solutions.

Wireless ad hoc network

The wireless ad hoc networks allow wireless devices to become servers to peers. Wireless peers can provide content, network traffic routing, and many other services. The ad hoc network truly leverages wireless networks' dynamic nature. However, because wireless peer-to-peer technology is still embryonic, its many performance and security issues must be solved before it can be widely used.

We do not discuss wireless ad hoc networks in detail in this article. Readers interested in Java-based peer-to-peer frameworks should check out Jxta, Sun Microsystems' open source peer-to-peer framework. Jxta can run on both server computers and handheld devices.

What is Java 2 Platform, Micro Edition?

In addition to choosing the most appropriate wireless Web services architecture, we must also choose the most powerful and flexible development platform. In this section, we examine the Java development platform for wireless applications—Java 2 Platform, Micro Edition (J2ME).

Though a lightweight version of Java 2 Platform, Standard Edition (J2SE), J2ME is not exactly a subset of J2SE. J2ME keeps some of the J2SE core library APIs, but substitutes others with lightweight components through the javax.microedition package. Sun, understanding the large variety of wireless devices and realizing that one size does not fit all, divided the J2ME platform into several layers and groups.

At the bottom of the J2ME hierarchy are two configurations that provide JVMs and core language libraries. Connected Limited Device Configuration (CLDC) is for the smallest wireless devices with 160 KB or more memory and slow 16/32-bit processors. CLDC has limited math, string, and I/O (input/output) functionalities and lacks features such as JNI (Java Native Interface), custom class loaders, and reflection. As a result, CLDC virtual machines cannot support most J2SE standard libraries.

Connected Device Configuration (CDC) is for more capable wireless devices with at least 2 MB of memory and 32-bit processors. CDC supports a fully featured Java 2 VM and therefore can take advantage of most J2SE libraries.

Configurations provide the most basic and generic language functionalities. On top of each configuration are multiple profiles targeted at specific devices. The profiles provide more advanced APIs such as a graphical user interface (GUI), persistent storage, security, and network connectivity. Mobile Information Device Profile (MIDP) and PDA Profile, two profiles based on CLDC, target cell phones and PDA devices, respectively. Based in CDC, the Foundation Profile provides more utility, network, and security functions for embedded devices, but no GUIs. The Personal Profile sits on top of CDC and the Foundation Profile. It provides J2SE Abstract Windowing Toolkit (AWT)-compatible GUI APIs for high-end PDAs and wireless Internet appliances. Figure 2 illustrates the J2ME platform architecture.

Figure 2. J2ME components and architecture

Though a lighter version of Java, J2ME still retains the language's underlying benefits.

The Java advantage

We all know the benefits of the Java platform; let's see how they translate to wireless Web services development.

Advanced language features and standardization process

Java's modular nature allows it to expand and develop solutions for new computational problems. It has evolved from a popular client applet language, to a cross platform GUI builder, to an application server platform. This same modular nature now allows Java to drive wireless and Web services applications.

Java also offers a democratic standardization process. To attack specific problems, individual vendors often initially develop Java libraries, which can result in inconsistent APIs for similar functionalities. To keep Java applications interoperable and Java code portable in the future, we must consolidate and standardize APIs. The JCP (Java Community Process) ensures that all interested parties voice their concerns and that no standard API unfairly benefits any one vendor. Standardization proves especially important for wireless Web services, due to the large number of vendors and providers involved. Many organizations have already started developing major JSRs (Java Specification Requests) that will standardize important new tools and APIs for wireless and Web service Java applications. We will mention those ongoing efforts later in this article.

Cross-platform compatibility

Windows-dominated desktop computers might not leverage Java's Write Once, Run Anywhere compatibility, but Java's platform-independence could benefit both wireless frontend applications and Web services backend applications.

Multiple hardware and OS platforms have and will continue to share the wireless information devices market for the following reasons:

1 2 3 Page 1
Page 1 of 3