6 Java MExE devices

03.573GPPFunctional descriptionMobile Station Application Execution Environment (MExE)Release 1998Stage 2TS

Java MExE devices shall be based on the MExE API for Java, which defines the required and optional components of Java APIs that shall be used to realise a MExE compliant device.

The MExE API for Java primarily defines the functions available to a Java-based MExE device such that services (specified in the form of Java classes and interfaces) can control such a device in a standardised way.

Many aspects of the MExE API specification are optional. Services and applications shall be able to determine the presence of optional parts of the functionality. When optional parts of the functionality are implemented, the MExE API shall be supported.

6.1 High level architecture

Figure 4: Basic functional architecture of a Java MExE device

The functional architecture of a Java MExE device is shown in figure 4. Java applets, applications, and services access functionality via the MExE API for Java. The MExE API is based on a combination of optional Java APIs approved by Sun Microsystems and the Wireless Profile of the JavaPhone API [4] as defined by the JavaPhone Expert Group. The JavaPhone API is based on the PersonalJava API [3] defined by Sun Microsystems.

6.2 High level functions

6.2.1 Optionality

The use of Java encourages development of modular interfaces and minimal required functionality. Additional functionality is provided by optional APIs specified in terms of the Java language. In general, optionality is specified in terms of Java packages. Packages are containers for the highest level of functionality in the Java language. In some cases, optionality is specified in terms of Java classes and interfaces. Classes and interfaces are elements contained inside packages.

The following table 1 specifies the Sun Microsystems defined optionality of the Wireless Profile of the JavaPhone APIs. Within some of the packages, certain classes and methods may be individually specified as optional by the JavaPhone API specification.

Where a mandatory package is identified, it is implicit that any packages called by that mandatory package are also mandatory.

Table 1: Optionality of the Wireless Profile of the JavaPhone APIs

JavaPhone API

Java package

Optionality

Addressbook

Javax.pim.addressbook

Mandatory

User Profile

Javax.pim.userprofile

Mandatory

Calendar

Javax.pim.calendar

Mandatory

Network

Java.net

Mandatory

Datagram

Javax.net.datagram

Mandatory

Power Monitor

Javax.power.monitor

Mandatory

Power Management

Javax.power.management

Optional

Install

Javax.install

Optional

Communications

Java.comm

Optional

SSL

Javax.net.ssl

Optional

JTAPI Core Package

Javax.telephony

Mandatory

JTAPI Core Capabilities Package

Javax.telephony.capabilities

Mandatory

JTAPI Core Events Package

Javax.telephony.events

Mandatory

JTAPI Call Control Package

Javax.telephony.callcontrol

Optional

JTAPI Call Control Capabilities Package

Javax.telephony.callcontrol.capabilities

Optional

JTAPI Call Control Events Package

Javax.telephony.callcontrol.events

Optional

JTAPI Phone Package

Javax.telephony.phone

Optional

JTAPI Phone Capabilities Package

Javax.telephony.phone.capabilities

Optional

JTAPI Phone Events Package

Javax.telephony.phone.events

Optional

JTAPI Mobile Package

Javax.telephony.mobile

Mandatory

Java.math

Optional

Java.rmi

Optional

Java.rmi.dgc

Optional

Java.rmi.registry

Optional

Java.rmi.server

Optional

Java.security

Optional

Java.security.interfaces

Optional

Java.sql

Optional

Java.io

Optional

6.2.2 Required and optional PersonalJava APIs

Java MExE devices shall support the PersonalJava specification [3]. The PersonalJava APIs provide a standardised and readily implementable execution environment as a means for applications, applets, and content:

  • to access and personalise the user interface via the java.awt packages
  • to utilise both Internet and Intranet connections via the java.net package

6.2.3 Required and optional JavaPhone APIs

The JavaPhone APIs extend the PersonalJava APIs to provide functionality unique to telephony devices. Java MExE devices shall support the Wireless Profile of the JavaPhone API specification [4]. Java MExE devices shall support all APIs specified as required by the Wireless Profile in the JavaPhone API specification. All APIs that are optional in the Wireless Profile shall be optional in Java MExE devices.

6.2.3.1 Application installation

Java MExE devices shall support the following JAR file manifest entries (as described in the JavaPhone specification) as described below:

  • Implementation-Title

the Implementation-Title shall be used in any textual description of the application which is displayed in the UI element used to launch the application. E.g. the text displayed with an icon.

  • Main-Icon

if icons are used as elements to launch the application, then the icon file within the JAR file named by the Main-Icon attribute shall be displayed, and may be scaled if desired.

  • Main-Class and Class-Path

when the application is launched, the MExE Java VM shall be supplied with the classpath and shall call the main() method in the class named by the Main-Class attribute.

6.2.3.2 Power

Java MExE devices shall support the Power Monitor package (javax.power.monitor) as specified by the JavaPhone API to access the power level of the device and receive notifications concerning changes in power states.

Note that the Power Monitor package does not specify the minimum required events that should be generated under certain circumstances. A MExE Java device shall at least implement the following event generation:

  • BatteryCritical

shall be generated when the battery is at a critically low level.

  • BatteryNormal

shall be generated when the battery is no longer low.

All the other event generation should be supported by the implementation.

6.2.4 Required and optional MExE APIs

A Java MExE device shall not be required to support any other Java APIs.

A Java MExE device may optionally support any other Java APIs which comply with the MExE security requirements in table 3, such as:

  • OCF SmartCard API OpenCard, available from [21]. If the ME supports smartcards other than the SIM, and the smartcard is open to 3rd party applications, then the opencard.core.terminal section of the OpenCard API may be used to access the card.

6.2.5 Mandated services and applications

6.2.5.1 WAP browser support

To provide backward compatibility to MExE classmark 1, i.e. allow access to services designed for MExE classmark 1 devices, classmark 2 devices must feature a pre-installed or pre-loaded WAP browser that is capable of rendering at least the following content formats:

  • tokenised WML documents (“WML decks”)
  • WMLscript bytecode
  • A WAP service in a MExE classmark 2 MS shall execute in the same manner as it executes in a MExE classmark 1 MS.

Other WML formats (such as textual WML documents or textual WMLscripts) are optional.

The pre-installed/pre-loaded WAP browser may be upgraded, replaced or extended by transferring, a replacement, extension or plug-in mechanism to the MS. Depending on user preferences identified in the user profile and the terminal capabilities, the pre-installed or pre-loaded WAP browser may be overwritten or the new browser stored in a different location.

6.2.5.2 Network protocol support

Support for network protocols in Java MExE devices is specified in the following table 2:

Table 2: Support for network protocols

Protocol

Optionality

HTTP/1.1 [9]

Mandatory

HTTPS

Mandatory

Gopher

Optional

ftp

Optional

mailto [25]

Mandatory

File

Optional

6.2.6 Datagram recipient addressing

The Datagram API (as specified by JavaPhone) may resolve server/service names using a name resolution service. The MExE Java implementation shall at least be able to resolve names using the addressbook.

The implementation of the Datagram API shall support use of the addressbook to resolve names: The addressbook entries shall be searched for items whose name matches the server/service name by the Datagram API implementation in order to resolve names to actual addresses. It shall look for an item of type “FN" with a value equal to the server name, using the following syntax:

server_name: *mostchars

e.g. "The PIZZA Hut".

Then it shall search for aggregate fields named by the service name concatenated to "X-DATAGRAM-", the field name which is named according to the following syntax:

field_name = "X-DATAGRAM-" service_name

service_name = *mostchars

Then it shall use the value of the aggregate attributes which use this field. These strings shall specify in order, the preferred and available protocols and addresses for the named server/service. The string value in each X-DATAGRAM… field shall be formatted as so (inspired by RFC 1738 [22]):

address = primary_name "{" primary_addr "}" *[ secondary_name "{" secondary_addr "}" ]

primary_name = wdp_name | udp_name | sms_name | any_name

primary_addr = internet_addr | phone_number | port | httpurl | *unreserved

secondary_name = sms_name | url_name | sms_center_name | ip_name | any_name

wdp_name = "WDP"

udp_name = "UDP"

sms_name = "SMS"

url_name = "URL"

sms_center_name = "CENTER"

ip_name = "IP"

any_name = 1*alphadigit

secondary_addr = internet_addr | phone_number | port | httpurl | *unreserved

internet_addr = hostname | hostnumber

phone_number = *phonechar

httpurl = "http://" host [ "/" hpath [ "?" search ]]

host = hostname | hostnumber

hostname = *[ domainlabel "." ] toplabel

domainlabel = alphadigit | alphadigit *[ alphadigit | "-" ] alphadigit

toplabel = alpha | alpha *[ alphadigit | "-" ] alphadigit

hostnumber = digits "." digits "." digits "." digits

port = digits

hpath = hsegment *[ "/" hsegment ]

hsegment = [ "~" ] *[ uchar | ";" | ":" | "@" | "&" | "=" ]

search = *[ uchar | ";" | ":" | "@" | "&" | "=" ]

lowalpha = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" |

"i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" |

"q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" |

"y" | "z"

hialpha = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" |

"J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" |

"S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z"

alphadigit = alpha | digit

alpha = lowalpha | hialpha

phonechar = "+" | digit | "#" | "*" | "C" | "D" | "c" | "d"

digits = 1*digit

digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |

"8" | "9"

safe = "$" | "-" | "_" | "." | "+"

extra = "!" | "*" | "’" | "(" | ")" | ","

hex = digit | "A" | "B" | "C" | "D" | "E" | "F" |

"a" | "b" | "c" | "d" | "e" | "f"

escape = "%" hex hex

unreserved = alpha | digit | safe | extra

uchar = unreserved | escape

mostchars = unreserved | " "

As a minimum, the following transport/bearer combinations shall be supported if the device supports the bearer/transport combination:

Transport/bearer combination

Value of primary_name

Syntax of primary_addr

Value of secondary_name

Syntax of secondary_addr

WDP over SMS

WDP

port

SMS

phone_number

SMS

SMS

phone_number

WDP over HTTP

WDP

port

URL

httpurl

UDP over IP

UDP

port

IP

internet_addr

For example:

WAP Datagram over SMS: "WDP=358,SMS={+358503583862}"

SMS: "SMS={+358503583862}"

WDP over HTTP: "WDP={1234},URL={http://somewhere.on.the.web/path/name}"

UDP over IP: "UDP={1234},IP={147.23.120.2}"

If the service centre number is specified for SMS, then the secondary_name shall be "CENTER" and secondary_addr shall be the phone number. If it is not present, then it shall be derived from the default service centre.