Platforms and tools for Web Services and Mobile Applications J2ME based Applications : Platforms and tools for Web Services and Mobile Applications J2ME based Applications Bent Thomsen
Aalborg University
3rd and 4th of June 2004
Java 2 Platform Architecture : Java 2 Platform Architecture
J2ME Configuration Defined : J2ME Configuration Defined Defines a minimum platform for a horizontal grouping of devices
Similar requirements on memory and processing power
Defines the Java Language and VM features available on group of devices
Configurations and Profiles : Configurations and Profiles “A Configuration is a specification that defines a minimum Java Platform functionality for a family of devices. It defines the minimum number of Java libraries, VM capabilities, Security specification, and a Generic Connection Framework.”
“A Profile is a collection of Java APIs that supplement a Configuration to provide capabilities for a specific device group or market type.”
Available J2MEConfigurations : Available J2MEConfigurations Connected Device Configuration (CDC)
Used by devices that are more powerful than the low end devices such as cell phones
Example set-top boxes, certain PDAs, …
Connected, Limited Device Configuration (CLDC)
Used for very resource constrained devices
Example, cell phones, two way pagers, …
CLDC Java Virtual Machine : CLDC Java Virtual Machine Sun’s Kilo Virtual Machine (KVM)
Designed for small resource-constrained devices
Small memory footprint (60K) for KVM
Minimum total memory 160K
16/32-bit processors
Processor speed 8 to 32 MHZ
CLDC Hardware : CLDC Hardware Memory size is the only requirement for CLDC
At least 128K non-volatile for the KVM and CLDC Libraries
At least 32K of volatile for KVM runtime
J2ME Profiles : J2ME Profiles Defines requirements for a specific vertical market family of devices
Extends or is Layered on top of a configuration
Defines a standard Java platform for a vertical market device family, to ensure interoperability
Includes more granular domain specific class libraries that a configuration
Available J2ME Profiles : Available J2ME Profiles Mobile Information Device Profile (MIDP)
delivers an enhanced user interface, multimedia and game functionality, end-to-end security, and greater networked connectivity to mobile phones and entry level PDAs
Foundation Profile
set of Java APIs that support resource-constrained devices without a standards-based GUI system
Personal Profile
Together with CDC and Foundation Profile, Personal Profile provides a complete application environment for the high-end PDA market. Personal Profile contains the full set of AWT APIs, including support for applets and Xlets.
Personal Basis Profile
provides a J2ME application environment for network-connected devices supporting a basic level of graphical presentation
MIDP Hardware : MIDP Hardware Memory (added to CLDC memory)
128K non-volatile for MIDP components
8K non-volatile for application persistent data
32K volatile for KVM
Display
Screen 96x54
Display depth 1-bit
Pixel shape (aspect ratio) 1:1
MIDP Hardware : MIDP Hardware Input (one or more)
One-handed keypad
Two-handed keypad
Touch screen
Networking
Two-way
Wireless
Possibly intermittent
Limited bandwidth
MIDP Architecture : MIDP Architecture Mobile Information Device (MID) CLDC MIDP Native System Software/Host Operating System MIDP
Applications OEM-Specific
Applications OEM-Specific
Classes Native
Applications
Class Libraries : Class Libraries CLDC
java.lang
java.io
java.util
javax.microedition.io
MIDP
javax.microedition.lcdui
javax.microedition.midlet
javax.microedition.rms
MIDP Application Model : MIDP Application Model MIDlet is the basic application
Similar to the J2SE applet
GUI based
MIDlet Suites – security for applications that share resources or data
MIDP Application Lifecycle : MIDP Application Lifecycle MIDP applications are known as “MIDlets”
MIDlets move from state to state in the lifecycle, as indicated.
Start – acquire resources and start executing
Pause – release resources and become quiescent (wait)
Destroy – release all resources, destroy threads, and end all activity
Typical J2ME Technology Stack : Typical J2ME Technology Stack
Tour of CLDC/MIDP : Tour of CLDC/MIDP Packages
Javax.microedition.io
Javax.microedition.lcdui
Javax.microedition.midlet
Javax.microedtion.rms
Contains user interface widgets
Form, TextField, TextBox, DateField, List, Image, Gauge, Alert, Canvas, Graphics, Display
Event handling classes – Command and CommandListener
Two APIs, high and low
High level for GUI widgets, scrolling, etc.
Low level for graphics and fine-grained UI control
Sample Code : Sample Code import javax.microedition.lcdui.*;
import javax.microedition.midlet.*;
public class HiMIDlet
extends MIDlet {
private TextBox textbox;
public HiMIDlet() {
textbox = new TextBox ("", "Hello World!", 20, 0);
}
public void startApp() {
Display.getDisplay(this).setCurrent(textbox);
}
public void pauseApp() {}
public void destroyApp(boolean unconditional) {}
}
I: Code example: Simpel GUI : I: Code example: Simpel GUI import javax.microedition.midlet.*;
import javax.microedition.lcdui.*;
public class HelloWorld extends MIDlet implements CommandListener {
private Form mainscreen;
private Form detailsscreen;
private Display myDisplay;
private Command exitCommand;
private Command resetCommand;
private Command detailsCommand;
II: Code example: Simpel GUI : II: Code example: Simpel GUI public HelloWorld(){
myDisplay = Display.getDisplay(this);
mainscreen = new Form("Hello World");
detailsCommand = new Command("Details",Command.SCREEN, 1);
resetCommand = new Command("Reset",Command.SCREEN,1);
exitCommand = new Command("Exit", Command.EXIT, 1);
StringItem strItem = new StringItem("Hello", " World");
mainscreen.addCommand(detailsCommand);
mainscreen.addCommand(resetCommand);
mainscreen.addCommand(exitCommand);
mainscreen.append(strItem);
mainscreen.setCommandListener(this);
}
III: Code example: Simpel GUI : III: Code example: Simpel GUI public void startApp() {
myDisplay.setCurrent(mainscreen);
}
protected void pauseApp() {
}
protected void destroyApp(boolean unconditional) {
}
IV: Code example: Simpel GUI : IV: Code example: Simpel GUI public void commandAction(Command c, Displayable s) {
if (c == exitCommand) {
destroyApp(false);
notifyDestroyed();
} else if (c == detailsCommand) {
detailsscreen = new Form("Details");
detailsscreen.addCommand(resetCommand);
detailsscreen.setCommandListener(this);
myDisplay.setCurrent(detailsscreen);
} else if (c == resetCommand) {
myDisplay.setCurrent(mainscreen);
}
}
}
Creating J2ME Applications : Creating J2ME Applications Identify the devices
Identify the profiles supported by devices
Develop the Application
Using the MID profile, the application will target cell phones and pagers
Write an application that displays the String “Hello, Small World!”
Requires the environment; MIDP reference implementation http://java.sun.com/products/midp/
Will run in the MIDP emulator
Developing J2ME Wireless Applications : Developing J2ME Wireless Applications Use ktoolbar to create a project
Configure the Midlet
Build and Run the project
MIDlet class, the application-level class
Abstract, need to define methods
startApp()
pauseApp()
destryApp(boolean unconditional)
Sun’s J2ME Wireless Toolkit : Sun’s J2ME Wireless Toolkit To run the toolkit itself, select the KToolbar shortcut. You should see the following screen.
Sun’s J2ME Wireless Toolkit : Sun’s J2ME Wireless Toolkit The J2ME Wireless Toolkit works with projects, where the end result of each project is one MIDlet suite. The toolkit works with one project at a time. You can change properties of the current project, build the project, and run the project in a device emulator. Several example projects come installed with the toolkit; we'll look at these later.
Let's jump right in the water by creating a new project. Click on New Project in the button bar. The toolkit prompts you for a project name and the name of a MIDlet class in the project. Fill in HelloSuite and HelloMIDlet as shown below.
Nokia J2ME SDK : Nokia J2ME SDK
Application Loading Process : Application Loading Process
Security : Security J2ME Cannot support full J2SE security model
J2SE protection domain model is larger than the entire CLDC implementation
So how’s security implemented in J2ME? Split the security model into two parts
Low-level-virtual machine security
Guaranteed by the CLDC Two-Phase class file verifier
Application level security
Sandbox model
Low-level VM Security: Two-Phase Class Verification : Low-level VM Security: Two-Phase Class Verification Off-device verification
Pre-verification tool add “stack map” attribute to each method in Java class file
Pre-verification is performed on server or desktop system before class file is downloaded to the device
This “stack map” helps to facilitate in-device verification
Faster verification process
Less VM code and memory consumption
In-device verification
Environment verification (e.g. memory req. to run app.)
Byte code check
Type check
Proper termination (no unconditional Jump instruction)
Two-Phase Class File Verification Process : Two-Phase Class File Verification Process Stack map attribute increases the size of a classfile by appro. 5%
Application-level Security: Sandbox model : Application-level Security: Sandbox model Application must run in closed environment in which app can only access those APIs defined by Configuration, Profiles and licensee open classes supported by the device
More specifically sandbox model means:
Class files have been properly verified and guaranteed to be valid
Ensures that only the mandated Java APIs are available to applications as defined by CLDC, Profile and licensee’s extension classes
Application download occurs at the native code level – JAM
Cannot override class loading mechanism
Set of native functions accessible to the VM is closed
J2ME to J2EE Overview : J2ME to J2EE Overview Data persistence possible on the client, server or both
Client MIDP Record Management System (RMS) APIs allows for data storage that is persistent on the device
HTTP provides the bridge between J2ME (MIDP) and the J2EE Platform
Both Platforms use HTTP/HTTPS (MIDP 1.0.3)
MIDP supports HTTP 1.1 and APIs for generating GET, POST, and HEAD requests
Messages may tunnel through different protocols that are transparent to the client and server
MIDlet can send any Message Format in the body of a HTTP request
XML, Text, binary, …
Mime-types are used to indicate body format/type
J2ME to J2EE Overview Continued : J2ME to J2EE Overview Continued Areas to Consider for J2ME to J2EE Communications
Session: Sequence of service requests by single user using a client to access server
State: Information maintained in the session across requests. Ex: Contents of Shopping Cart
Personalization data: Information about the user, such as address, SSN, etc… This information does not normally change from session to session, thus a J2ME application should use it to enhance the user’s experience.
J2ME to J2EE Overview Continued : J2ME to J2EE Overview Continued Managing Session States for MIDlet to J2EE Communications
HTTP is a stateless protocol. The Java Servlet API provides a HTTPSession object to work around this limitation
J2EE App Servers use 3 methods to maintain integrity of HTTP Sessions:
Using Cookies
Using URL Rewriting
Using HTTPS
MIDP Devices can use all these 3 methods
Managing Personalization Data for MIDlets
Session Management may be transient
Personalization data by nature is Persistent
Major benefit of utilizing Personalization is fewer interaction for the user
J2ME Connection Types : J2ME Connection Types HTTP/HTTPS
Very simple to use
XML over HTTP/HTTPS
Beginning to be a viable choice due to varying parsers available
Model
Creates an object representation of a document in memory (e.g., DOM)
Push
Parses through an entire document, spitting out events to registered listeners (e.g., SAX)
Pull
Parses a little at a time, returning a single element or tag
Wireless Web Services APIs (1) : Wireless Web Services APIs (1) J2ME Web Services (JSR 172)
Public review
No API available yet
J2ME Web Services specification goals
Access remote SOAP/XML based web services
Does not support web service hosting capabilities
JAX-RPC subset
Must support stub based invocation (stub created using WSDL)
No support yet for Dynamic proxies and Dynamic Invocation Interface (DII)
No asynchronous messaging with attachment support
Not required to support Java beans
Provides parsing XML data
JAXP subset
Must support SAX 2.0 (with exceptions)
Must not support DOM
Wireless Web Services APIs 1 (2) : Wireless Web Services APIs 1 (2) SOAP and J2ME
J2ME has only limited string functionalities, a problem for every wireless java XML parser
J2ME/CLDC lacks support Float datatypes
SOAP parsing requires to read the whole document
kSOAP & kXML
kSOAP
API with Small footprint
kSOAP is open source and based on kXML
Adds support for data types not supported by J2ME
kXML
Non validating XML pull parser
J2EE Architecture Including J2ME Clients : J2EE Architecture Including J2ME Clients
MIDlet, J2EE Deployment, and Provisioning to Device : MIDlet, J2EE Deployment, and Provisioning to Device On the J2EE side, the JSPs, Servlets and any other J2EE components such as EJBs are packaged in a JAR file, which along with any WARs go in an EAR file together with a deployment descriptor
You can use the many tools that many App Servers provide to accomplish the packaging
MIDP application (code and any resources)
packaged into a JAR file
a JAD file accompanies the JAR file
Over The AIR (OTA) Provisioning provides guidelines for deploying the MIDlet on MIDP devices