ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.


AddThis Social Bookmark Button

Extending J2EE for Mobile Application Development
Pages: 1, 2

Session Management

Intermittently-connected wireless networks require programmable session timeouts and cached session data, enabling users to resume where they left off when connections are lost and then reestablished. Management of the additional session data and the lack of cookie support on mobile devices also require a mobile-specific software infrastructure resource. Since no information can be stored in most mobile devices, the developer is burdened with URL abbreviation, rewriting, storing, retrieving, modifying, and passing an enormous amount of session data throughout the application. For example, the server-side stored content and the links among the pages must be passed around concurrently. Multi-modal sessions require the flexibility to swap from a data device (e.g., WML) to a voice device (VoiceXML) in the middle of a session, thus requiring the developer to obtain a new device profile and update the session data, which in turn needs to be passed to the transformation engine for proper rendering.

Conceptually, session management can be extended to cover wireless synchronization. Wireless synchronization requires application logic and/or data to be shared between the server and the mobile device. If the user is disconnected due to lack of wireless coverage, he/she can continue using the application, and all actions and incremental changes to data can be stored locally on the mobile device. When a connection is reestablished, the data is synchronized over the wireless link in the background. Although conceptually trivial, synchronization involves many implementation and architectural nuances.

Mobile Messaging and Notifications

Compelling mobile applications require utilization of different unified messaging resources typically found around a mobile user. These applications require robust messaging interfaces that enable push/pull functionality in a synchronous or asynchronous manner. Messages need to be routed to the right delivery channel (e.g., voice, SMS, pager) and to be asynchronously queued until delivery, and the queue itself needs management. In case of failures, the message and transaction integrity must be preserved. Successful message delivery return receipts, as well as unsuccessful attempts, need to be recorded and administered.

Open API-Level Access to J2EE Resources and Services

Solving mobile application challenges "in an island," using custom coding or proprietary black box interfaces and tools, does not simplify mobile application development due to a lack of tight integration with a J2EE infrastructure. Since many of the mobile application challenges (e.g., session management) have a J2EE Web counterpart (e.g., HTTP session), a well-designed mobile solution will extend the J2EE services and resources and integrate tightly at a Java API level. The tight API-level integration will provide the architect and the developer the ultimate flexibility and control over the design, applications, and integration options. If all such software services and resources were encapsulated in a container, one would achieve not only the API-level integration, but also a consistent approach to mobile-enabling the J2EE infrastructure.

The J2EE Mobile Action Container -- A Next-Generation Approach

J2EE in its existing state requires custom coding to support the development of mobile applications. By arming the developer with the right set of resources at the J2EE infrastructure layer and eliminating the need to write custom code and patches, we can resolve a large part of the mobile application challenge. J2EE technology can be extended with the following services to dramatically simplify and speed mobile application development:

  • Device Profiling and Personalization Manager: A device profile and personalization manager that can model devices using a set of attributes (e.g., memory, screen size, keyboard layout, display capabilities) and a capability to provision content and applications.

  • Transformation Engine: A scalable transformation engine that utilizes features and attributes of devices such as device profiles. This transformation engine may have an XML or DOM interface and must also allow for overriding the look and feel.

  • Memory and Caching Manager: A robust memory and caching manager to optimally partition and cache content based on mobile device profiles with the links to the server-side cached content.

  • J2EE Standardization: Support for existing J2EE standards and development methodologies such as Servlets and JSP.

  • Session Manager: A session manager that addresses the requirements of mobile devices and accommodates multi-modal sessions, and handles the intermittent connectivity of wireless networks.

  • Message and Notification Manager: A message and notification server that facilitates synchronous and asynchronous notification generation, transmission, reception, and administration.

  • Data Access Manager: A data access manager that leverages the existing J2EE data access methodologies and integrates to existing Java middle-tier tightly at the API-level.

There is significant value in building a container that provides components to satisfy all of these requirements in an integrated fashion. Even if these components/services were independently available, there still would be a significant amount of coding needed to integrate these APIs in a servlet and use them in standard development methodologies. For example, the servlet developer would still be responsible for retrieving the device profile and personalization objects, storing them in the session, calling the transformation engine, passing the session information (including the device profile object), and then calling the cache manger, creating the appropriate links, and storing this additional content in the session as well.

The real power of these services is harnessed by providing a container that manages these services and provides support for standard J2EE development methodologies. For example, a container can allow for the development of "actions" or content in the form of XML or Java (DOM). In any action that resides in the container, the session information would be managed and readily available. The profile object and device personalization objects would be instance variables in the container, so the developer would just create an action in JSP or Java and need not manage the calling of the services. The mobile action container would also pool objects, such as the transformation engine, and may distribute and manage the service across different JVMs or even across different servers. Each server could be dedicated to providing a specific service; for example, there could be a server devoted to performing transformations and another devoted to managing memory.

The container would provide a clean separation between the application and server code, making the application future-proof. The container may be implemented within the servlet or EJB containers, or be developed as a new J2EE container.

Figure 2: J2EE Mobile Action Container

Taking the Next Step

The J2EE standard is powerful and widely accepted. Its power and acceptance stems from its sound architecture, openness, flexibility, and extensibility. We have an opportunity to augment the J2EE technology to support mobile application development with carefully thought-out software that provides not only the right set of services, but also the containers to standardize mobile application development. Augmenting the J2EE technology will propel the progress of mobile application development, and help enterprises accept mobile applications as a necessary part of their infrastructure.

Related Reading

Java and XSLTJava and XSLT
By Eric M. Burke
Table of Contents
Sample Chapter
Full Description
Read Online -- Safari

As technologies evolve and standards are updated, there is no need for enterprises to delay projects or spend development time reinventing the wheel to roll out J2EE-compatible mobile applications. Solid and powerful 100% Java products with open APIs exist that are built on the J2EE extension notion. Companies such as mine, Aligo, have strived to develop products that allow enterprises to extend their J2EE infrastructure to the mobile environment.

The Java development community can also be a strong influencer of standards that can take the mobile application development to the next level. It is important for developers to speak up about their needs, and one great avenue is to participate in the Java Community Process, an open organization of international Java developers, and to spearhead efforts to extend and expand J2EE to support, simplify, and enhance mobile application development.

Jeffrey M. Capone, Ph.D. is a noted author and frequent speaker on Mobile and Java Technology. He is currently CTO of Aligo, Inc.

Return to ONJava.com.