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.
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.
