877-277-2477
info@capstonecourseware.com

Wireless Applications in J2EE Systems

Will Provost

Originally published by Object Innovations, October 8, 2002

Abstract

Networked Java applications for small wireless devices ("MIDlets") are likely to play a role — perhaps small, perhaps large — in a broader distributed software system. As such, they function as a new breed of client software. They fit very well into the modern thin-client philosophy, but if anything they are thinner than expected, requiring additional mediation to work effectively with the information provided by servlets and JSPs, and perhaps EJBs behind the scenes.

Wireless Enterprise Architecture

This article provides a summary of key Java technology for wireless application development in the enterprise. It also lays out architectural approaches to supporting wireless clients in enterprise systems.

Web services, meanwhile, may become the dominant means of support for wireless client software in the next few years. Java wireless developers can assume future support for use of Web services, through one or more current initiatives.

Java 2 Editions

The Java 2 platform is divided into three editions, each supporting a broad category of software based on a different type of system.

The standard edition, or J2SE, is the oldest and most common edition in use. It supports Java application, applet and component programming for desktop and larger systems — primarily PCs — which may or may not be networked. Common uses of J2SE are standalone GUI and console applications, middleware components and RMI services.

The enterprise edition, or J2EE, extends the standard edition with APIs for so-called "enterprise features." J2EE implementations support Web service via servlets and JSPs, persistent data with JDBC, and large transactional systems via EJB - to name a few key technologies. J2EE components are more strictly meant for the server side of large-scale systems: processing power, memory and storage space are presumed to be plentiful and expandable.

The newest of the three is the micro edition, or J2ME. This supports a variety of "micro" devices, which vary a good deal (by what J2ME calls a "profile") but all of which are less capable than a low-end personal computer. Under J2ME, CPU power, memory, storage, and connectivity are all assumed to be limited, perhaps severely.

The Need for J2ME

The world of mobile and other "sub-PC" devices does not enjoy the same consensus as the PC and server areas do on such basic choices as:

  • Hardware configuration and device "pluggability"
  • Operating system
  • Man-machine interface (MMI)

None of these things is 100% consistent over the industry for PCs and servers, either, but things we take for granted in each of these areas are notably missing from the range of micro devices. Ever worked on a PC with no typewriter-style keyboard? Since the mid-80's, at least, have you ever worked on a PC or server-level machine without a mouse or other pointing device? There is great variation in hardware design, MMI, and OS among even the market-leading products.

Also, not every device in this space is meant to do the same thing. The difference in style and purpose between PDA, phone, and pager is significant. By contrast, it's been a long time since the PC was not considered capable of handling just about any user-interactive application.

Whatever innovative things it may bring to the market, this broad diversity of target devices is a programmer's nightmare. If I want to build a standalone application for cell phones, do I have to re-code, re-build, and re-test for every device? If I want to build a networked client, what can I expect in terms of connectivity?

J2ME as Adaptor for Wireless Applications

J2ME has as its primary purpose the establishment of a single standard by which developers can create portable software for micro devices. The Java language has a natural advantage entering this space, since it is so fundamentally geared for portability. In a way, Sun is taking on the huge problem of device diversity at a collective level, so that individual developers won't have to. If every PDA, phone and pager vendor were to implement J2ME for their devices, then conceivably we might be able to "write once, run anywhere" in the micro space, just as we've become accustomed to doing for larger machines. Click here for a list of current J2ME platform implementers.

The Mobile Information Device Profile

Though they are not the only motivation for the J2ME architecture, mobile wireless devices do seem to account for much of the momentum of J2ME in the marketplace. This category includes:

  • Cell phones
  • Personal digital assistants, or PDAs
  • Pagers
  • Electronic book readers
  • Point-of-sale devices

The J2ME is organized into levels, at each of which a specification addresses an increasingly specific definition of target devices. Architectural choices exist at each level, and constrain the options at higher levels. Application programmers only need to worry about the profile, which defines an API; implementers of J2ME for a given device naturally need to focus on the VM level.

Hardware, VM, Configuration and Profile

For wireless devices the key specifications are the Connected, Limited Device Configuration or CLDC, and the Mobile Information Device Profile, or MIDP. MIDP assumes the following minimum device characteristics:

  • 128k of "non-volatile" memory (i.e. whose state is preserved when the device is off power) for the MIDP components, including the KVM and Core API and MIDP API code.
  • 8k of non-volatile memory for application-managed persistent data.
  • 32k of volatile memory as application heap space.
  • A display of at least 96x54 pixels, which may only be one bit "deep" or which may offer some color or grayscale support.
  • Input mechanisms supporting at least a numeric keypad or a configurable touch-screen supporting numeric input.
  • Two-way wireless networking capability, with "limited bandwidth" and most likely not continuously available.

So devices supporting MIDP provide a standard platform for Java software:

J2ME as Adaptor for Wireless Applications

MIDP Application Types

MIDP applications are known as MIDlets. Most MIDlets exist in one of two common shapes:

  1. The standalone application is loaded whole onto the device and can run at any time the device is powered up, requiring no outside resources. This category includes:
    • PDA and organizer applications such as address books, to-do lists and datebooks
    • Simple tools such as calculators
    • Games
  2. The networked application is federated into at least two components, one of which — the client — is deployed to the mobile device. This component is of little use without connectivity to at least one server in the system. The server most likely resides in a J2EE environment, and is available via some Web or other Internet protocol. This category includes:
    • E-mail clients
    • Mini-browsers
    • "Groupware" that allows roaming users with mobile devices to stay in sync with their enterprise-hosted schedules, business documents, contact information, etc.
    • Travel-agent systems for updated flight information, hotel and car reservations, street maps, restaurant guides, etc.
Wireless Enterprise Architecture

Let's consider the term client for a moment. We don't call a MIDlet a client simply because it uses MIDP networking and contacts another component. The question is more one of where the core application logic resides. Is the MIDlet doing most of the "thinking" and just happens to be network-aware? That's not a client, really — at least, not in a way that's meaningful in the context of enterprise software. A client is a MIDlet that relies on a server to think, store, load, process, or otherwise act on its behalf: this is how a client meets its primary responsibilities as an application. It is also reasonable to define a MIDlet as a standalone application for most purposes, but a client in some specific way, or at some specific time.

The Java 2 Enterprise Edition

Client MIDlets are not required to connect to Java-based servers; this after all is the point of standard communications protocols like HTTP. A MIDlet might be written to make HTTP requests to a pre-existing Web site, and it doesn't matter whether that site is supported by ASPs on IIS, servlets on Apache/Tomcat, etc. However, as a practical matter, when a whole new distributed system is to be developed, Java will be used at all levels (or not at all).

This brings us to the Java 2 Enterprise Edition, or J2EE - a set of standards for applying Java technology to "enterprise-class" activities, such as:

  • HTTP service, including Web applications and Web services
  • Storage and retrieval from relational databases
  • Online transaction processing
  • Distributed object computing (via CORBA)
  • Reliable messaging between servers and processes
  • XML processing

"Enterprise software" is a loosely-defined term. Generally, we define enterprise-level systems in terms of requirements, and by the demands that are expected to be made of them at runtime.

  • In whatever arena, and at whatever level, enterprise systems can expect very high loads: lots of data to process or to store, lots of requests, often coming at a high frequency, lots of work to do on behalf of clients. The system must be scalable over a range of loads, and especially must perform effectively against high loads.
  • The system must be available, a deceptively simple concept which has to do with handling system failures. Under high load, a system may need to be implemented redundantly in a cluster and may need to distribute requests over this cluster.
  • Management of application data must provide all the properties of ACID transactions: atomicity, consistency, isolation, and durability. Generally, this means that a server must support the very highest standard of reliability in handling data. (This becomes even trickier when clustering!)
  • Data and application functions must be secure: this includes the need for authentication of users and user agents, and policies of authorizaton for these users and agents to do and to see various things.
  • Messaging between components must be reliable - this is something like the ACID transaction problem for durable data, but concerned with intra-application messages instead.

Three-Tier Architecture

A J2EE application will hopefully implement a three-tier architecture, by which the broad categories of responsibility are assigned to different layers of the application model:

Three-Tier Architecture
  • The presentation tier encodes only the logic of showing information to the user and gathering user input. It does not know or care how the information is derived, although it must know something about the "shape" of the information.
  • The business logic tier (or sometimes the "domain", or simply "middle tier") holds core application functionality: features and functions for interpreting or changing data, rules that must be applied to data as it changes. This code is ignorant of the presentation style in front of it, and also of the means of storing and retrieving data behind it.
  • The persistence tier manages persistent storage and retrieval of application data. This may be application code plus a relational database manager, or possibly (arguably!) just the relational database manager.

More generally, application architects often speak of multi-tier or N-tier designs, in which additional strata are identified within or between these three main layers. This typically translates as follows:

Three Tiers for J2EE!
  • Java Server Pages and servlets, hosted by a J2EE-compliant Web server, define the presentation — this is a server-managed GUI of sorts.
  • A certain class of Enterprise JavaBean called session beans implement the business logic, delegating to each other as well as to the persistence tier.
  • JDBC code in another type of EJB, the entity beans, manages persistence, backed by some RDBMS. (More commonly the JDBC code is actually generated for the entity beans rather than written into them by the developer.)

Clients: Fat, Thin ... and Wireless

The client of a J2EE application has traditionally been hosted by a personal computer. This client software might be entirely generic, such as a commercial Web browser. It might be dedicated to the application and distributed to human users for installation on their home or office machines. This sort of client would likely take the form of a J2SE application. In this latter case the client may well be considered a significant part of the presentation tier — it may even replace the JSP/servlet component completely and speak directly to EJBs, although this usually requires proximity inside a firewall, since the transport protocol is no longer HTTP.

It is also possible that the only client a J2EE application will have is actually a "peer." For instance, the caller might be another server acting automatically, with no interactive user involved at the moment a request is made.

A major distinction between the more modern multi-tier architecture and the client/server approach that was in vogue immediately before it is the level of sophistication of client software. The client/server architecture — what we would now call a two-tier system — loaded a great deal of the business logic onto the client application. This became known as the fat client. By its terrible fatness, it imposed great burdens on developers, administrators, and ultimately users, as maintenance and distribution were difficult and error-prone. By inertial force, the client software also became a barrier to progress into new technology, new designs, etc.

In three- or multi-tier systems, a thin client relies on the middle tier for all but the presentation logic. Web applications take this a step further as even the presentation components are server-based. Software distribution becomes a non-issue.

There's been a great deal of wordsmithing over the last ten years or so as various frameworks and distributed computing infrastructures have posited new client roles. "Slim," "bloated," and even "svelte" have made various appearances as vendors have sought to position themselves "correctly" along the scale.

Where do MIDP clients fit into this picture? Clearly, a MIDP client must be thin, as the platform simply can't support the code weight of a fat client. There is an additional distinction to be made, though. Mobile, wireless clients are not like traditional thin clients in one key way: they are so limited as to require remote support just to communicate in the manner expected of a thin client. Specifically, while a MIDP device may support HTTP, it may do so only with the aid of an off-device gateway. At the application level, the MIDP device may not be able to handle the data that would be passed to a PC-based "thin" client. Point a MIDP-based HTTP browser at a Web page intended for presentation on Netscape Communicator or Internet Explorer, and you'll see the problem.

So the wireless client is a different beast altogether. It can be identified by its need for special treatment by the server: data must be specially pared down and prepared just for this sort of client.

Supporting MIDP Devices via Mediation

The special preparation of data from the middle tier for a specific presentation is known as mediation. The mediator tier is a common feature of N-tier systems, often included in an architecture to facilitate use of multiple presentation frameworks against the same domain layer.

Mediation in an N-Tier System

For MIDP clients, mediation will often take the form of a gateway of some sort, translating from PC-level content to micro-level content, and possibly switching protocols in the process:

  • HTML content may be translated to the Wireless Markup Language, or WML.
  • The basic protocol may shift from HTTP to the Wireless Application Protocol, or WAP.
  • Datagrams will be made available not via User Datagram Protocol (UDP) but rather Wireless Datagram Protocol, or WDP.
  • The Short Message Service is another approach that is being offered as a catch-all gateway solution for wireless devices.

The resulting architecture will be one of two primary N-tier variants on the J2EE architecture we saw earlier:

  • Mediation of the domain:
  • Mediation of Domain
  • Mediation/translation of the presentation:
  • Mediation of Presentation

The MIDP client will be heavily reliant on J2EE software and gateways or mediators to simplify and otherwise shape up content for presentation and manipulation by the mobile user.

WAP and WML

WAP and WML also offer the prospect of server-side definition of presentation logic, without the involvement of a dedicated MIDP application. Where MIDP is a conceptual extension of the J2SE client application into the wireless space, WAP instead reflects the browser-based approach.

The major distinction between MIDP and WAP from the perspective of distributed systems is in the weight and horizontal or vertical nature of the client. WAP offers the ability to define application logic " at all tiers " entirely on the server. It is therefore (forgive me) "wafer-thin" and relies on generic components on the wireless device. MIDP architecture assumes that at least some basic functionality is loaded onto a dedicated client application. It is still a thin client by any reasonable definition, but not so thin as a WAP client, and more importantly not so generic: a MIDlet or MIDlet suite will be written and deployed to support a specific distributed application.

Also, just as J2SE applications can incorporate HTML viewers and browsers, a MIDlet can be written to work with WML pages. Hybrid architectures that combine the power of Java programming in MIDP with the ease of development and distribution of WAP/WML have yet to emerge in standards literature, but the combination is a natural one for more sophisticated wireless client applications.

Web Services

The Web application is gradually being asked to share the stage with the Web service, which is a component that offers programmatic access directly to the business/domain layer, but still uses Web protocols to accept and to serve requests.

Web Services in the N-Tier Model

MIDlets can be clients of Web services, as well, but again there is a need for mediation. Web services are exposed via the Simple Object Access Protocol (SOAP) — which carries request and response content as XML elements — or via HTTP messages carrying raw XML content. In either case, the service client must be prepared to do a lot of XML writing and parsing. This is pretty heavy stuff for a MIDlet to tackle in a small memory space.

Two efforts are underway to facilitate MIDP access to Web services — again, note the split between mediation-based and client-side solutions:

  • A subset of the Java API for XML Processing is being formulated for inclusion in the MIDP 2.0 API. See JSR-118.
  • A specification for implementing a Web-service gateway is under development; this would obviate the need for XML processing in the MIDlet. See JSR-172.