Proceedings of MASPLAS'02 The Mid-Atlantic Student Workshop on Programming Languages and Systems Pace University, April 19, 2002

Building Mobile Applications with J2EE, J2EE-J2ME and J2EE Extended Application Servers Ashima Hosalkar Advisor: Narayan Murthy, Pace University, White Plains, NY Introduction With the relentless surge of the Internet the software industry is now buzzing with mobile, Internet-enabled devices and Web services. This is opening up new possibilities for applications such that customers, business partners can have access to information ‘any time any where’. These new emerging technologies have introduced a new challenge for the developers. Now the developer has to take care that the application not only supports the new wireless devices but also exposes some of its functionality as a Web service. Fortunately many design principles that have served in the past are applicable to these new challenges. Most of the current application servers are either based on Java 2 Platform, Enterprise Edition (J2EE), or the Microsoft Product suite, .Net. In this paper we will examine Application servers built on J2EE standards to deliver Wireless Applications: Using J2EE application servers, Using J2EE application server and J2ME (Java 2 Platform Micro Edition) and Using J2EE extended application servers. We will discuss a demo application (Movies) built using J2EE extended Application server. Wireless Development Environment The following diagram gives a high–level view of wireless application, which can be used to deliver end-to-end solutions.

Transactions

Communicati ons

Rendering

Workflow

Security

Naming

Wireless Application Server

Tier-1

Tier-2

Tier – 3

XML

Emails,ERP,SIEBEL,SAP,Legac y Systems,CRM etc…

Notification Alerts

Application Connectors

Wireless server (gateway)

Wireless Devices

Architecture for Wireless Application :

Tier - 4 2.1

Wireless Application Development Challenges: Tier 1 : This is the primary level where the wireless and non-wireless applications differ due to the different client devices and their physical size, shape and their network connectivity. These differences in effect influence lot of factors in the application logic required to detect and format the data content for a specific device. Tier 2: The wireless gateway is responsible for providing end-to-end security, managing network connectivity, user sessions, providing optimization and reliability for wireless networks. Tier 3: The Application server renders and optimizes the data for a particular device with whom it is interacting. The process of the data transformation is broken down to a more abstract data type, XML .The data is then transformed to the desired device specific format. This level is also responsible to handle email-notifications, alerts and messages that are directed to mobile devices. Tier 4: The application layer has to be more selective when it interacts with this level of enterprise data source due to limitations of bandwidth, display size and data transfer capability. We will only focus on the Application servers, which appear to be the “heavyweight” amongst others to make a successful wireless application.

The Java Technology One can provide a complete end-to-end solution by fully leveraging its security, network awareness, portability and scalability as well as the ease to use the Java programming language. Sun has grouped its Java technologies into three basic editions, each aimed at specific area: • Java 2 Enterprise Edition ( J2EE ) – Aimed for enterprises to serve their customers, clients and employees with scalable, secure and reliable Internet business solutions. • Java 2 Standard Edition ( J2SE ) – For desktop PC computer market. • Java 2 Micro Edition (J2ME ) – Aimed for the consumer and embedded devices. Each Java edition has a set of technology and tools that can be used with any particular product: • Java Virtual Machine. • Libraries and APIs for particular type of devices. • Tools for development and device configuration. J2EE

The Java 2 Platform Enterprise Edition was primarily designed to simplify problems relating to development, deployment and management of multi-tier Enterprise

2.2

applications. J2EE is a standard and not a product. Meaning there are certain vendors like BEA, IBM, ORACLE amongst others who agree between applications and the containers in which they run.

J2EE Architecture Application Programming Model

EJBs

JSPs

Transactions Servlets Messaging

Container

Mail

Connectors

Java Beans

Tools

Applets

Java 2 Software Development Kit,Standard edition CORBA

RMI

Database

Naming/Directory

The J2EE architecture gives a framework and the corresponding services that simplify the development of web based applications. These are packaged into J2EE application servers. The developer can then use these server utilities and Application Programming Interfaces (APIs) for any web application. The most important feature of J2EE is it’s Model View Controller (MVC) pattern approach. It separates the presentation layer from the underlying business logic layer, allows multiple views to share the same enterprise data model. J2EE application are developed and deployed on any web server using any Java application servers such as JRUN, which in turn provides services necessary for enterprise applications such as transactions, security and persistence service amongst others. J2ME

The Java 2 Platform, Micro Edition (J2ME) gives businesses the ability to serve enterprise clients like cell phones, pagers, and palmtops. These Internet-ready devices can be programmed using the Mobile Information Device Profile (MIDP), a set of Java APIs which, together with the Connected Limited Device Configuration (CLDC), provides a complete Java runtime environment. These devices are diverse in the sense of form, function and features .To address these diversities J2ME has to take care of the size, modularity and customizability. J2ME supports minimal required configurations of the Java virtual machine and APIs that embody just the essential capabilities of each kind of device. J2ME is built on three important aspects: • Java Virtual Machine: The Java virtual machine layer is an implementation of JVM that is customized to target resource-constrained device’s host operating system and supports a particular J2ME configuration. • Configuration: It defines minimal platform for a group of devices each with similar requirements on total memory footprint and processing power. A configuration defines

2.3

the Java language and Java virtual machine features and minimal class libraries that a device manufacturer or service provider can expect to be available on all devices of the same category. • Profile: A J2ME device profile is layered on top of a configuration. A profile addresses specific demands of a certain device family. They ensure portability by defining a standard Java platform for that device family. Profiles typically include class libraries that are domain specific. J2ME Architecture J2ME architecture comprises of Profiles, Configurations, Java Virtual Machine and Host Operating System. The J2ME currently has two configurations. • Connected Device Configuration – Commonly referred to as CDC technology, uses the Java virtual machine that includes all functionality of a virtual machine residing on a desktop system. This configuration is intended for devices with at least a few megabytes of a memory footprint. • Connected Limited Device Configuration – Commonly referred to as CLDC technology, is meant for resource-constrained devices each with a small memory capacity. CLDC is primarily is composed of K Virtual Machine (KVM) and the core libraries that can be used on a variety of wireless devices. Devices built on KVM typically contain 16 to 32 bit processors and a minimum total memory footprint of approximately 128 Kilobytes. Building Wireless Applications Using J2EE and J2EE/J2ME The J2EE approach Wireless applications can also be developed and deployed by using just J2EE application server, by using services like JSP and Servlets/EJBs. However the process is quite tedious and time consuming to develop Wireless applications with J2EE. Hence we will discuss only some of the important issues here instead of a walk through the entire application development. J2EE Architecture for Enterprise Applications

Client Tier

Businesspartner/ other Systems

Applets,Appli cations

Browsers,PDA, Wireless devices Http(s),IIOP,Web Services technologies

Web Container Or Web Tier

J2EE Application Server Servlets/JSP

EJBs Connectors or Web services tech/SQL/Proprietory Protocol

Back-End System

BusinessPartn ers Or other System

Existing System, ERP system,Legacy System

2.4

Databas es

Since J2EE containers are specific to web applications this leads to custom coding to deliver on the mobile applications. Presentation layer: The J2EE architecture’s presentation layer is primarily HTML-based. Mobile devices and other network-enabled devices are much diverse in the sense that they have different capabilities and may use different mark-up languages (e.g, CHTML,VoiceXML,WML). To tackle the diversities on the client side, the developer can build different presentation layer for each devices or have one presentation layer and apply transformation for each device. This requires reformatting the HTML page, storing the required data from it and again retagging the contents in a different mark-up language, which leads to unscalability. Most popular way of transforming the data is using XML i.e., the data is formatted into XML and then transformed into desired markup language using Extensible Stylesheet Language (XSL). However XML messages can be of larger magnitude, consuming bandwidth and time for which the user may be billed. Also one has to define XSL to transform XML into the desired markup language using XSLT(Transformer). But defining XSL for each and every device can be difficult if the presentation is complex because this will make the style sheet even more complex. Session Handling: Not all mobile devices support session management and have cookie support. This gives rise to using URL rewriting, modifying and passing an enormous amount of session data throughout the application. To support the multimodal sessions, that is, to enable the user to change from one device to another device while in the session, the developer will have to again detect the new device profile and update the session data, which in turn will have to coordinate the presentation layer for the new device. Intermittently connected Network: If the user is disconnected due to loss of the connection he/she can continue using application, and all actions and changes to data can be stored on the mobile device. When the connection is established the data is synchronized over the wireless link in the background. Synchronization however is not recommended as it makes implementation complex. J2EE limitations a) J2EE requires special techniques of screen scraping/ transcoder to handle non-browser clients. b) Requires lot of custom coding to handle diverse client environment. c) Cannot handle session management, data recovery due to network glitch efficiently. d) Does not support multimodal sessions. e) The server scalability, performance and latency can be at high stake if the application is not handled properly due to sloppy coding and bad architectural design. The J2ME MIDP addresses many of the limitations of microbrowser-based solutions that are faced in J2EE. MIDP addresses programming issues such as user interface, networking, persistent storage, and application model.

2.5

J2ME MIDP provides the following advantages: In a microbrowser-based solution; the server is responsible for generating display markup. This requires a round-trip every time the interface changes. In contrast, a MIDP client's interface is contained within the device, so it can operate even when disconnected. On the occasions the device does interact with a server, it incurs less network traffic, because it downloads only application data, as opposed to application data plus interface markup. Markup languages such as WML and CHTML are, by design, restricted in the types of interactions they can offer. With the MIDP GUI APIs, it is easy to implement customized widgets and event handling, opening up unlimited possibilities for mobile client interfaces that are easier and more interesting to use. The J2EE – J2ME Approach This architecture follows MVC (Model-View-Controller) Pattern, separating the logic layer from the presentation layer. The controller logic can be distributed between the server and client making development, testing and maintenance easier. J2EE-J2ME Architecture The basic Implementation is as follows: On the server side, you can develop and deploy the J2EE applications using any application server, which fits one’s businesses strategic purpose and needs. On the client side, you can develop your MIDP or MIDLET application using the J2ME wireless Toolkit and provision it onto any MIDP –compliant device(e.g mobile phone, palmtop etc).This gives the flexibility to serve a large diverse wireless audience.

MIDLet

Wireless Device

Client Tier

Http(s)

Web Tier

Servlets/JSP

EJBs

J2EE Application Server

Back-End Tier

Database server

As shown in the figure the Midlet, which is actually a java class, developed and compiled using any J2ME Wireless Toolkit (such as Forte or KtoolBar), is installed onto any wireless device using Application Management Software. The MIDLet in turn then communicates with the Servlet or JSP in the Web Tier to access the business logic in the EJB tier. These services then communicate with the back-end systems like Databases Context Repository or existing system, ERP system, Business partners etc., J2EE as well as MIDP support HTTP protocol. MIDP has APIs for generating GET,POST and HEAD requests, header manipulation and stream–based consumption and generating messages. In MIDP and J2EE applications, JSP and Servlets can be used to send any type (i.e any markup language) of data in the body of an HTTP response. Data is flushed out using XML.J2EE supports XML by providing a rich set of XML APIs. MIDP device secures

2.6

sensitive data like credit card number and so on as it supports can support Secure Sockets Layer (SSL) protocol. Since MIDP has a generic Connection Framework, making HTTPS connection does not require any special customize code. J2EE and MIDP supports cookies, URL rewriting and HTTPS to maintain the session state. The data can be persisted on the server, or the client or both. The MIDP Record Management Store (RMS) API, stores data that persists on the device between the use of an application, while J2EE can use other information systems to store and retrieve user information and preferences. This optimizes the application such that it leads to fewer interactions between the client and the server for completing the task improving the latency. One can also take care of the user preferences to streamline the application flow. This preference will significantly influence the network or the performance of the device, and should be stored on the device itself. Benefits of J2EE-J2ME a) Presentation layer is separated from the underlying logic; controller logic can be distributed amongst client and server b) The server side is not overloaded; this minimizes the latency resulting in good performance, improves scalability and throughput at the server end. c) Since the application is built for a specific client whose profile is well known, there is no overhead defining multiple presentation layers. d) In case of loss of connection data can be cached onto the client side, which is then retrieved and synchronized once the connection is re-established. Limitations of J2EE-J2ME a) The user will have to download the application for the first time from the J2EE server exclusively if he/she does not want to pre-install JAR. b) The user will have to install an XML parser for the data to be in the XML format. Which increases MIDLet’s size by 15 to 30 Kilobytes. These parsers also do not have utility to validate or report error since they offer only SAX for processing XML document. c) Care has to be taken that the software must provision not just data but also code since it depends upon the memory of the device. d) If the user wants to switch between wireless devices he will also have to switch to the appropriate device specific Millet along with some changes at the server end. e) With every new device coming into market with a new JDK version will make harder to run old J2ME applications. Every J2ME program will not run on J2SE, and within J2ME, programs written for certain classes will not run on others. f) Configuration and Java virtual machines are closely related and are complex pieces of software. Even small differences in a configuration’s specification can require large modifications to the internal design of a java virtual machine.

Building Wireless Application using Extended J2EE Application Server The need for extended version of the J2EE application servers came up from the shortcomings of the J2EE Application servers to handle Mobile Applications for the everchanging client environment. In this paper we have focused on one such server, Aligo M2.7

1 Mobile Application Server, a pursuit by Aligo.Inc to ease the development and deployment of Mobile applications, making the out of box solution easier to implement. M –1 J2EE extended Server Architecture The M-1 server is a servlet-based container, which is composed of three layers: • Delivery Suit • Processing Suite • Integration Suite M-1 Enabled J2EE Application Server Data Access Layer

Mobile Actions Container Browser Client SWAP, CHTML, HTML, VoiceXMl

Mobile Actions

JSP,Servle ts/EJBs

J2ME Clients M – 1 Server Services Renderin g Engine

J2ME & Sync Engine

Cache & Session Manager

Device/User Profile Manager

The Delivery suite consists of Presentation Engine, J2ME, Synch and Messaging Engines. The Processing Suite consists of the Control and Personalization Engine. The Integration Suit is made up of Data Access and Connectors layers. The Delivery Suite: To simplify the overhead of defining XSL for each and every wireless device the server has an automatic engine, which automatically renders the dynamic content, formatted for every device. It is also capable of handling VoiceXML enabled browsers. It also handles Midlet enabled clients through its J2ME engine. The application is written once as J2EE server-side application, which automatically generates J2ME applications. J2ME client-side application can synchronize through it’s synch engine and caches the back-end data objects once the connection is established which helps the application to function even in the disconnected mode. Finally the messaging engine provides the messaging capabilities to every mobile device through Email, FAX or SMS (Short Message Service). The Processing Suite: The processing Suite comprises of Presentation Engine. The presentation engine plays a significant role in detecting the wireless devices that access the application through User /Device personalization manager. This gives flexibility to enhance the application using the user preferences and device features. The Integration Suite: It helps in integrating the back-end systems like database and other Enterprise Integration System like ERP, SAP, and CRM etc. The Data Access Layer manages the pool of connectors to backend information sources in a thread –safe manner for fast data access, and provides recovery in

2.8

the event of incomplete transactions. The Connectors help to connect to the in-house systems and other enterprise software. Demo Application The demo application was built using Aligo M-1 server primarily to see the ease of implementation and the features of the server. It is a simple application by the help of which anyone can select the type of movie he /she wants to watch and get the directions to the selected movie theatre either through Fax or Email mode of communication. Application Flow: Asks the user to enter his/her name. There are Four Movie Categories Children, Suspense/Thriller And Comedy. Select the desired category. Each category has some movies listed under it. Each Movie has Name of the Movie, Name of the Theatre, Phone Number of The Theatre and Cost of the movie (Adult and Children). Select the desired mode of communication i.e. Email Direction or Fax Direction. The user is notified with a thank you note.

Benefits of using J2EE extended Server a) Separation of presentation layer from that of business logic layer. b) Supports a wide range of mobile devices and offers the flexibility to add new mobile devices. c) Solves intermittent wireless connectivity, session management, and data synchronization problems and maintenance. d) Ease of application development with J2EE architecture. Utilizes abstract presentation objects to appropriately format and deliver information to a mobile device by using specific device profile information. e) Multi-modal session management allows users to switch devices or modes (e.g., voice to data and vice versa) without interrupting a session. The other end a) The J2ME portability issue along with it’s half hearted support for J2SE with every new JVM version might raise some key internal architectural issues for the extended J2EE application servers, specially since J2EE is tightly integrated with J2SE. b) One has to be well versed with the underlying APIs to take full advantages of the underlying engines. c) The server seems to be more overloaded than in the case of just J2EE or J2EE-J2ME applications. The primary goal of developing J2ME was to distribute the server load on to the client side amongst other things like user preference and to handle multi client environment. d) Chance of high latency because server handles every thing from data processing to presentation.

2.9

e) If the Synch engine fails to perform it will reduce the scalability of the applications by forcing serialization of all concurrent threads of execution. Also setting up of synchronization requires nontrivial resources of JVM. f) M-1 server has it’s own set of JSP custom tag. Although this approach is an effective tool, every time a custom tag is used on a page, the web container has to create a new Tag Handler object or fetch it from the tag cache, leading to unnecessary processing overhead.

Conclusion The need for more sophisticated wireless devices will never end and so will the pursuit to develop wireless applications. This will give birth to even more sophisticated and intelligent Application Servers. Currently Wireless technology faces a lot of challenges, not only in its overall infrastructure but also in the application development meant for it. Web Application servers based on J2EE standards have become important part of the multitier application architecture for wireless Applications. Simplicity, portability, scalability and legacy integration all these features makes them an ideal candidate for all the applications. Many of these have been extended to support the new mobile, wireless clients. For a traditional application server to act as a wireless application server, additional capabilities are required: • Providing and rendering centralized services to a much diverse wireless audience. • Understanding the capabilities (memory, size, etc) and limitations (e.g. screen size, keyboard restrictions, etc) that are accessing the application content. • Understanding the available network bandwidth and accordingly processing the contents to be served. (E.g. avoiding huge data interaction, graphics etc). • Reliable and secure transactions. • Intelligent handling of the data to and fro, from intermittently connected clients. This paper discussed the essential benefits and also the downside of using various J2EE-centric technologies by which one can develop wireless Applications. Though they have many pit falls, when it comes to developing and deploying wireless Applications, much of the responsibility relies on the vendor selection for Application servers, developers, architects and the business

requirements to make the Application successful.

References 1) Addressing the Mobile Application Development and Deployment Challenge with J2EE. http://www.onjava.com/pub/a/onjava/2001/10/17/mobilej2ee.html 2) Barish, G. (2001). Building Scalable and high – performance Java Web Application: Using J2ee Addison Wesley Longman, Inc. 3) Cattell, R. , & Inscore, J. (2001). J2EE in Practice: Building Business Applications with the Java 2 Platform Enterprise. Addison Wesley Longman, Inc. 4) Designing Wireless Enterprise Applications Using JavaTM Technology http://java.sun.com/blueprints/guidelines/designing_wireless_enterprise_applications/main.html 5) The Java Blueprints for wireless Program Charting the Wireless Way http://java.sun.com/blueprints/guidelines/designing_wireless_enterprise_applications/main.html 6) M-1 Server Developers reference Aligo Inc .,M-1 Server reference document 7) Riggs, R., Taivalsaari, A., & Vandenbrink, M. (2001) Programming Wireless Devices with the Java(TM) 2 Platform (Micro Edition). Addison Wesley Longman,

2.10