Platforms and tools for web services and mobile applications j2me based applications
This presentation is the property of its rightful owner.
Sponsored Links
1 / 41

Platforms and tools for Web Services and Mobile Applications J2ME based Applications PowerPoint PPT Presentation


  • 73 Views
  • Uploaded on
  • Presentation posted in: General

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. J2ME Configuration Defined. Defines a minimum platform for a horizontal grouping of devices

Download Presentation

Platforms and tools for Web Services and Mobile Applications J2ME based Applications

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Platforms and tools for web services and mobile applications j2me based applications

Platforms and tools for Web Services and Mobile ApplicationsJ2ME 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 hardware1

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

Native

Applications

OEM-Specific

Applications

MIDP

Applications

OEM-Specific

Classes

MIDP

CLDC

Native System Software/Host Operating System

Mobile Information Device (MID)


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

Pause

pauseApp

startApp

Active

destroyApp

destroyApp

Destroyed

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

Your

MIDlet

Yellow Pages, train schedules and ticketing, games…

Mobile Information Device Profile

UI, HTTP networking...

J2ME core APIs

CLDC = KVM + J2ME Core APIs in this example

Threads, no Floats…

KVM

32-bit RISC, 256K ROM, 256K Flash, 64K RAM

DSP chip(e.g., ARM)

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 toolkit1

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

Advertise

App on

Web Page

User

Selects

App

JAM

Downloads

App

Web Page

(Name,

Version,

Size,

…)

Java Application

Manager

Descriptor

File

Network Transfer

Jar File

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 continued1

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


  • Login