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.