Published on ONJava.com (http://www.onjava.com/)
 See this if you're having trouble printing code examples

Extending J2EE for Mobile Application Development

by Jeffrey M. Capone, Ph.D.

The mobile environment has a unique set of attributes not found anywhere else. From intermittently-connected wireless networks to the ever-increasing diversity of mobile devices, the mobile environment has introduced many new challenges to building software applications. The impact of these challenges on server-side software development requires a systematic resolution at the software infrastructure level. Without such a resolution, application developers will be forced to produce point solutions, custom code, and patches, creating convoluted legacy architecture that will result in exorbitant maintenance costs.

J2EE is a server-side technology originally designed to meet the challenges of Web-based application development. Although it was designed to be flexible and extensible to meet the future requirements of new technology paradigms, no augmentation of the J2EE standard has yet occurred to address the challenges of developing mobile applications. The market pressure to get mobile applications out to the enterprise workforce, combined with the lack of de facto architectural leadership from the technology giants in the space, have made point solutions and custom coding the common practices. J2EE technology, however, will help to extend support to and standardize mobile application development.

In this article, I will explore the fundamental architecture of J2EE and how to capitalize on its flexibility, extensibility, and openness by proposing a new server-side J2EE component model to drastically simplify, standardize, and enhance mobile application development.

Understanding Mobile Application Development Challenges

New mobile devices continue to rapidly enter the market, each consisting of varying configurations. Some devices, such as PDAs (personal digital assistants) and Pocket PCs, have ample memory, large color displays, and sound capabilities, while others have black-and-white displays and limited memory. Some devices are shipped with browsers, while other devices focus on client-side applications. Even devices with browsers that may support the same markup language will often interpret the markup language quite differently.

Many mobile devices can support Java through a micro version of the Java Virtual Machine called KVM (Kilo Virtual Machine). KVM can not only run Java applications built for mobile devices -- the so-called J2ME (Java 2, Micro Edition) applications -- but also supports a superior user interface and off-line functionality during instances of intermittent wireless network connections.

In any case, the common characteristic of these applications is their server-side interaction. They all rely on server-side logic to supply them with the appropriate data and communicate via Internet standard protocols such as HTTP. This shifts a large chunk of the coordination burden to the server side; the server-side application logic must be designed to support each of these devices while fully utilizing all of the device's features. In the case of browser-based applications (e.g., WML, c-HTML), the content needs to be formatted properly for the mobile device display and browser. Even in the case of J2ME applications, a significant amount of server-side intelligence is required. For example, the proper J2ME application must be provided -- i.e., the right application must be chosen for the requesting wireless device, and the version must be checked before delivery.

The wireless network also implicitly affects the development of the applications. Limited bandwidth, high latency, and intermittent connectivity often plague wireless networks. Design efforts to combat network challenges, such as high latency, may involve delivering the maximum amount of content supported by each device, reducing unnecessary requests (or chattiness) over the high-latency wireless link. This so-called "forward-caching design" relies on a forward-caching software infrastructure resource to intelligently detect the memory of the device making the request, estimate compiled size of content, paginate the content, deliver it, and transparently maintain the links among the pages. In the case of J2ME, even greater sophistication is required, since the software must provide code as well as data. The cache manager ultimately decides what parts (classes) can be delivered to the mobile device.

The mobile environment also creates a new application paradigm that may involve multi-modal device access, where a user can swap devices and access methods such as voice and data in the middle of an application. The application may require non-HTTP messaging models for notifications, location-based services, and potentially even a new security model. This new application paradigm affects server-side development by requiring multi-modal session managers and access to non-HTTP messaging channels.

Mobile Application Development with J2EE -- First-Generation Approaches

J2EE defines a standard for developing multi-tier enterprise applications by not only basing them on standardized, modular components, but also providing services (e.g., secure transactions) to those components. In other words, J2EE gives the developer a framework and a set of services that simplify the development of Web-based applications. The framework and the associated services are implemented and packaged as products called J2EE application servers. The developer extends the application services (e.g., Servlets, Java Server Pages, and Enterprise Java Beans) and writes to a set of APIs that solve a significant portion of the underlying software challenge for Web-based development. The J2EE application server allows the developer to focus on application development while providing a clean separation between the application server and the application code. In the application code, the developer is encouraged to keep the presentation layer code as separate as possible from business logic to reduce the maintenance cost.

Some of the basic building blocks of J2EE are:

Figure 1: Standard J2EE Architecture

Each of these building blocks comes in a container that offers APIs, which manage a set of services for the building block. J2EE developers use the container and application server APIs such as JDBC and JNDI to build their applications. Since J2EE was specifically designed for Web application development, most of the containers are specific to Web applications. Since out-of-the-box containers are insufficient for mobile application development, the developer must write extensive custom code to deliver on the mobile application requirements. Typically, a sound mobile solution must consist of the following elements:

Each requirement of this mobile solution requires a significant amount of customization work. The J2EE architecture's presentation layer, for example, is primarily HTML-based, thus limiting the target mobile devices to mostly Web browsers. Mobile devices and wireless networks, on the other hand, are much more diverse. Since different devices have different capabilities and may utilize different markup languages (HTML, WML, HDML, cHTML, VoiceXML), a developer may choose to build many different presentation layers for the different devices, or build one presentation layer and apply a transformation for each device. This problem is commonly called the "Mobile Presentation Challenge." In either case, device-specific information (i.e., a device profile or device model) is required in order to choose a presentation layer or a transformation. Developers typically follow one of these two paths in trying to solve the Mobile Presentation Challenge.

The Basic Content Transformation Problem

The first route often chosen to overcome the Mobile Presentation Challenge is called "screen scraping" or transcoding; this requires repurposing and reformatting HTML presentation content. Transcoding involves taking in the dynamic HTML pages, removing the tags (i.e., scraping the page), storing the data in a Meta format, and retagging the content in a different markup language. This can be achieved with a combination of servlets and JSPs. It is not scalable, though, due to the time required. In addition, the tightly interwoven design of the presentation and application logic increases the ongoing maintenance cost exponentially as the number of supported devices rises.

The second route involves first defining an XSL (Extensible Style Sheets) library, which is used to transform the single XML presentation layer into a markup language suitable for each client device. Although this approach has better separation of application logic from presentation logic, the XSL presentation logic becomes so complex that it soon requires its own application logic, written in XSL command sequences. This basic approach of building style sheets for each device becomes costly to maintain and upgrade as new devices become available, since the embedded conditional presentation logic needs reworking each time.

A more effective approach might be to model each device by specifying its features (e.g., display size, supported markup language, etc.), develop a set of style guides for each device feature, and dynamically assemble the style sheets based on the features of the device making the request. Although you would be authoring a significant amount of presentation conversion logic, you may, in this way, be able to avoid some of the maintenance time of updating a style sheet library as new devices become available. XSL, while well-positioned to process text and convert among XML trees, is not a structured programming language. Thus, XSL is not the ideal choice for creating the complex presentation conversion logic required to dynamically assemble style sheets. If this route is chosen, mixing and matching with different programming languages may be required, presenting the familiar burden of ever- increasing complexity and maintenance costs.

After the first step of defining the XSL library, the developer builds a servlet and within it constructs a string buffer of the XML or a DOM (Document Object Model) for the presentation. The developer must then pass the string buffer or DOM and the appropriate style sheet (which may or may not be dynamically assembled based on device features) to an XSLT (XSL Transformer), which then passes the device-specific markup language in the servlet request. This development is typically intricate enough that in most implementations there is a significant amount of integration and coding that must occur within the servlet. For example, you would be required to identify the appropriate device, identify the relevant features, and assemble the style sheet based on these features. A more elegant approach simply uses JSP to lay down the XML and automatically call the right tranform, so that you focus more on building the application and less on building and tweaking the presentation look and feel.

Although challenging on its own, as seen in the two route choices above, basic mobile presentation is only the beginning of a long, circuitous journey as far as mobile application challenges are concerned. Unfortunately, neither approach has the capability to solve the more perplexing problems that one may face ahead.

Advanced Mobile Presentation -- Content Pagination and Caching Challenges

Neither of the basic content transformation methods described above addresses the memory issues of the device or the latency issue of the wireless link. Consider one scenario: If the content is dynamic, applying a straight transformation of the XML in a target device's markup language will often result in a document that is too large for the device to properly display.

One patch is to "page" the data at the data source (i.e., the data access layer) based on the lowest-common-denominator device to be supported, which will result in small pages. Unfortunately, this process will lead to burdensome delays for devices without memory or display restraints, since they will be making repeated requests for the small pages over high-latency wireless links, introducing unnecessary chattiness into applications.

Another option inserts logic at the presentation layer based on the memory attribute of the device and "pages" the resulting XML at this appropriate layer. This option requires introducing yet another layer of complex application logic at the presentation layer, violating a basic principle of sound J2EE design and increasing the maintenance cost. In either case, the paginated content on the server would have to be stored and appropriate links between the pages would have to be created. This problem is even more complex than meets the eye, because some pages may have been served to the mobile devices, and the rest will be stored on the server.

Comment on this articleWhat are your experiences with using J2EE for wireless application development?
Post your comments

It is crucial to note that this scenario again increases rather than decreases complexity, if the developer wants to add functionality to the patch that paginates the content at the application and/or presentation layer. Let's assume the developer obtains a device profile for the device making the request to identify the optimal size of the content pages. The developer can use this information to write custom presentation logic to paginate the content and reduce the probability of memory overflow. From the device profile, the developer may also choose to further customize the XML based on other device features and attributes to improve the user experience beyond optimal content pages. That is, the developer may personalize the application flow and content based on how the device accesses the application, inserting ad hoc application logic into the application and presentation layers in addition to implementing a proprietary methodology to handle different device attributes.

The maintenance cost of this custom coding approach will be an eye-opener. Developing a custom transformation engine that dynamically assembles a library based on device features makes adding devices easier, but in itself can be an extensive development project that still faces scalability and reliability issues. The picture is further complicated in the common scenario in which the developer needs to override the automatic transformation for a specific set of pages and devices. For example, customizing a branding page's size, shape, and logo color for a certain set of devices are common requirements, and the transformation engine should allow for overriding and providing full control over the look and feel.

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:

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.

Copyright © 2009 O'Reilly Media, Inc.