WIRELESS ENTERPRISE APPLICATION DESIGN USING J2ME

Overall Enterprise Application Architecture

An enterprise application usually does not consist of the wireless module alone. A wireless application usually acts as an interface module that connects to an existing or running system. This section examines the overall enterprise architecture, including the wireless component.

The design architecture that will be described below uses J2EE for the back-end system (Girdley, Woollen, & Emerson, 2002). The use of J2EE for the back-end system is of course optional; the J2ME MIDP is flexible enough to talk to any back-end system that supports HTTP transport.

Figure 4 shows the overall logical architecture of a typical Java wireless enterprise application, spanning a J2ME device and a J2EE application server.

Figure 4: High-level architecture of a Java wireless enterprise application

The logical architecture of an enterprise application serving wireless clients is similar to that of a canonical J2EE application:

An application client implemented using MIDP, or a MIDlet client, provides the user interface on the mobile device. This MIDlet communicates with a Java servlet, usually via HTTP, and over a secure channel (HTTPS) when necessary.
The servlet interprets requests from the MIDlet and, in turn , dispatches client requests to EJB components (Adatia et al., 2001). When the requests are fulfilled, the servlet generates a response for the MIDlet.
The EJB components, or enterprise beans , encapsulate the application's business logic. An EJB container provides standard services such as transactions, security, and resource management so that developers can concentrate on the business logic.
The servlet and EJB components may use additional APIs to access enterprise information and services. For example, they may use the JDBC API to access a relational database or the JavaMail API to send e- mails to a user.

Developers can write networked application clients that connect to wireless services using standard networking protocols. MIDP requires all devices to support HTTP, the same protocol that Web browsers use (Mahmoud, 2000).

The physical architecture of an entire enterprise application (e.g., customer support system) is shown in Figure 5. Client entities (e.g., support engineers ) access the system through the wireless modules while the help desk, system administrators, and managers access the system through the Web modules. The back-end system uses Web servers, application servers, and database servers.

Figure 5: Architecture of enterprise applications

The wireless module (J2ME) runs in a J2ME-enabled cell phone on GPRS or other similar packet data network. It accesses the back-end system using HTTP (Hypertext Transfer Protocol).

The back-end system architecture follows the J2EE (Java 2 Enterprise Edition) solution. The back-end system is deployed in three machines:

Web server : handles requests from the intranet modules and hosts the customer support management Web site. It also hosts the JSP and servlets layer.
Application server : handles requests for the logic of the application. This machine hosts the EJB layer.
RDBMS (database server) : hosts and manages the database of the system. The database is accessed by the EJB layer via a JDBC bridge.

Designing the J2ME Wireless Module

Considerations in the wireless application design

Enterprise applications usually impose a requirement on the client devices to communicate with the servers to query and manipulate data. In a wireless scenario, the wireless application presents new problems to database query management due to the mobility of the users, power and resource restrictions, and the limited bandwidth of the wireless connection. These challenges are the major issues in designing the architecture of the application and are summarized below:

Limited bandwidth : The wireless network operates at a much lower rate than a wired network.
Network disconnection : The wireless network is also more susceptible to network disconnections compared to a wired network. The framework must therefore provide a way to ensure that data in the mobile devices will not be lost due to this.
Limited computing power and memory resources : Mobile devices have much lower computing power than a stand-alone PC. Therefore, operations that require a lot of computing power must be distributed to other nodes in the system.
Working online and offline : There are many reasons that require the application to be able to work offline. Some of the reasons are network interruptions and weak signals. One of the more economical reasons is to save airtime charging.
Synchronization and data consistency : The framework must also provide a way to maintain the consistency of the data in the mobile device and the server.

Client-server model: Study of thin, fat, and medium client

Mobile devices have much less power and resources compared to the servers; hence, the obvious architectural choice for an enterprise application is the client-server model. The mobile device, which acts as a client, makes request of service to the server that has a larger capacity to perform the service. The next step is therefore to define the degree to which the server performs the service.

Thin client

The term thin client (see Figure 6) refers to a software layer that only handles the user interface on the client side. All the other logic and processing are done in the server. This model seems appropriate for a mobile device application because of the scarce resources it holds. However, the disadvantage of thin clients is that the application requires more communication with the server, resulting in greater network usage. Communication through a wireless network is expensive and less reliable than a wired network.

Figure 6: Thin client architecture

Fat client

As microprocessors become faster and more powerful, the client machines have proven to be valuable resources. By leveraging some of the processing to client machines, the system requires less powerful servers and therefore reduces cost. This distribution of tasks to various components in the network also increases the overall computation speed. However, fat client (see Figure 7) is not suitable in mobile device applications due to the limited power and resources in the client side.

Figure 7: Fat client architecture

Medium client

The architecture that is preferred is called medium client (see Figure 8; Nelson & Pilone, 2002). It combines the advantage of leveraging most of the work in the servers but at the same time exploiting more of the local computing power. The client is no longer a simple data display; it can present an applicationspecific interface to the user, perform basic data validation, cache data, and so on.

Figure 8: Medium client architecture

Implementing a Local Database in the J2ME Module

From the discussion in the previous section, the client device must have a local database in order to allow the user to work on the data without a network connection. This section describes the database architecture design in the mobile device.

Database design for wireless applications

The information that is stored in the device database has these characteristics:

Information that needs to be accessed frequently : Storing this type of information in the device database will speed up interaction and save network bandwidth. An example of information in this category is "task" and "product info ".
Information that needs to persist upon program's termination : This type of information includes information about a specific user, such as username, user preferences, etc.

Figure 9: Proposed application layers

Another type of database design is to use object-oriented DBMS (ODBMS) instead of relational DBMS (RDBMS). ODBMS stores objects rather than simple data types and it is capable of handling image, graphics, and audio/video data elegantly. However, in our wireless application there is no need for image/ video capability as the resources on the client devices are limited. We chose to use RDBMS because it is still the most popular database management system on the market (Kachina Technologies, 2001). Most large-scale commercial applications are built upon relational database systems, typically in client/server models device (Bukhres et al., 2002).

Figure 10: Device database schema

Assumptions and constraints

J2ME offers local database support designed for the devices' memory and processing power constraints through the javax.microedition.rms package.
The local device database has a different format from the server database. The schema of each record consists of an integer recordId as the primary key and a byte array as a record field.
The device uses its own internal record identification scheme. The primary key of a tuple of database in the server and the device may not be the same.
The database in the company may already be in existence and running. Therefore, its schema must not be changed in order to avoid changes in other existing applications that may be using them.

Comparison with existing mobile database applications

The problems of accessing and manipulating mobile databases have been extensively explored. The CODA project (Kistler & Stayanarayanan, 1992) is one of the earliest works which addressed the issue of manipulating data, and the Bayou project (Petersen et al., 1997) develops a general architecture for mobileaware databases. However, in our application, we are not attempting to design a different kind of database system. We need to be able to reuse the existing enterprise database with our application.

The algorithm proposed by Zondervan and Lee (1998) supports the synchronization of handheld devices (PalmPilot) and the Lotus Notes database. The algorithm is designed to work in limited memory, and it allows the data to be replicated and updated, and synchronized at a later time. In our application, we borrowed this idea to solve problems (2) and (3).

Using XML in the J2ME Application

Overview of XML

In recent years , the eXtensible Markup Language (XML) has been adopted as an industry standard for data exchange and sharing (Castro, 2001). XML is a markup language for documents containing structured information, and it provides a facility to define tags and the structural relationship between them. Some useful definitions related to XML are given below:

Element : This is the most common form of markup and is delimited by angle brackets. A nonempty element begins with a start tag and ends with an end tag. It describes the nature of the contents it encloses.
Attribute : This is the name-value pair that occurs inside the start tags after the element name .
Document type definition (DTD) : This contains the meta-information (i.e., allowed sequence and nesting tags, attribute values and their types) of a document. This is necessary to ensure syntactic correctness of the document.
XML document : This is the document that is constructed in accordance to the DTD definition.

There are two significant impacts of XML that are useful for an enterprise application:

Standard format for exchanging data : XML provides a system-independent format for specifying the information to be exchanged over the network and between applications. Using XML, the J2ME application is able to talk to any back-end applications that support XML. This makes the data portable and it improves the interoperability and flexibility of the J2ME program.
Defining structured documents: XML is suitable to represent a richly structured document. For easy browsing and reading, documents such as user manuals and technical specification are required to be composed in a structured format. Hypertext Markup Language (HTML), a common language for defining documents in the Web, is too verbose and lengthy for wireless application. Furthermore, the rendering capabilities in cell phone devices are too limited to display HTML.

Using XML as the data exchange format

To allow interoperability with the back-end system, XML is used to wrap the information to be transmitted. First, a set of data type definition (DTD) that is publicly known to the J2ME application and the back-end system is defined. Therefore, both applications can agree upon what format of messages will be used and therefore they will be able to handle them accordingly . The XML parser parses the document according to the DTD and creates the objects that can be handled by each application.

Figure 11: Flow of data between device and server

XML Parsing and Handling in the J2ME Environment

Transmitting, storing, and parsing XML data may not be an issue for traditional applications running on desktops and servers, but it is an issue for J2ME applications where resources are scarce. Parsers are traditionally bulky, featuring lots of code and hefty runtime memory requirements. In MIDP devices, the memory available for code is usually small and individual applications may have a maximum code size .

Two types of interfaces are available for parsing XML documents:

Event-based XML parser : This parser reports parsing events directly to the application through callback methods . SAX (Simple API for XML) is an industry standard for this kind of parser. SAX parsers are faster and consume less CPU and memory. But this parser only allows only serial access to the data.
Tree-based XML parser : This parser reads an entire XML document into an internal tree structure in memory so that an application can traverse through the data quickly and easily. DOM (Document Object Model) is an industry standard for this kind of parser. However, a DOM parser requires more processing power and memory.

Table 2 summarizes the current XML parsers that are appropriate for MIDP.

Table 2: XML parsers that are appropriate for MIDP
Name	License	Size	MIDP	Type
ASXMLP 020308	Modified BSD	6 kB	yes	push, model
kXML 2.0 alpha	EPL	9 kB	yes	pull
kXML 1.2	EPL	16 kB	yes	pull
MinML 1.7	BSD	14 kB	no	push
NanoXML 1.6.4	zlib/libpng	10 kB	patch	model
TinyXML 0.7	GPL	12 kB	no	model
Xparse-J 1.1	GPL	6 kB	yes	model

M-Commerce Considerations in the J2ME Application

The J2ME module can easily be extended to transfer financial transaction information on the move (m-commerce). The bank account information and the instruction to transfer funds, etc., are all treated as data to be sent over the wireless network.

However, as in the case of electronic commerce (e-commerce), the security of the transaction is the primary concern (Claessens, Dem, Cock, Preneel, & Vandewalle, 2002). The following general security requirements apply to m-commerce applications:

Confidentiality : This is the need to ensure that only authorized entities have access to the content of the exchanged information, e.g., an eavesdropper should not be able to find out what transactions a particular user is executing.
Entity authentication : The client entity should be sure that they are communicating with the real back-end entity before sending sensitive information to it, while the back-end entity should also know the identity of the client entity before processing its transactions.
Data authentication : This involves data origin authentication and data integrity. The back end (at least) should be able to detect manipulations (e.g., insertion, deletion, and substitution) and replay of data by unauthorized parties.
Non- repudiation : This is to prevent an entity from denying previous commitments or actions, e.g., the back-end entity should be able to prove to a third party that a client entity performed a certain transaction in case the client entity denies having performed it.

To achieve the above requirements, cryptography techniques (Jon, 2001) should be used. Cryptography allows information to be sent in a secure form such that only the intended recipient is able to retrieve the information. Practically all modern cryptographic systems make use of a key to encrypt the information. There are two types of key-based cryptography: symmetric key encryption and public key encryption:

Symmetric key encryption : Symmetric algorithms use the same key to both encrypt and decrypt the plaintext. Hence, both the sender and the receiver need to have a copy of the same key. The key is often called a secret key as it can only be known by the communicating parties in order for the ciphertext to be secure.
Public key encryption : Public key cryptography, also known as asymmetric cryptography, involves a pair of keys called the public key and private key (Benantar, 2002). The encryption key (public key) is used to encode a message, but this message can only be decoded by using the corresponding decryption key (private key). Conversely, a message encrypted using the private key can only be decrypted by the public key. This system allows the recipient to make the public key widely available so that anyone can send an encrypted message to the recipient.

In J2ME, crypto-APIs such as the Rivest-Shamir-Adleman (RSA) algorithm (RSA Security, 2002) are already available. This greatly reduces the time for developing secure m-commerce applications.