Two J2ME architecture:
Since the inventions in 1995, Java has undergone great changes, from the earliest for the Applets running in the slippet, to Server / EJB Server programming, and now the MIDlet is the programming of the wireless information device. It has developed a platform for developers to provide one-end to-end programming development, that is, the three platforms we often say, J2SE / J2EE / J2ME, Java's three platforms (Fig1). Since wireless programming has its entirety of traditional programming, such as the diversity of running devices, device processing power is not as different as server and microcomputer, user interface differences. In addition, in the rapid development of wireless technology, the J2ME architecture is completely different from the characteristics of J2SE / J2EE.
Figure 1: Three platforms of Java
The J2ME architecture is to change our traditional Java architecture: hardware / OS / JVM / APIS / application, becoming: Hardware / OS / Configuration / Progile / Application. The reason why this architecture is used is related to the particularity of J2ME we talked above.
Figure 2: Architecture of J2ME
J2ME / CLDC / MIDP as a version of J2ME, which is designed for wireless mobile communication devices, and below we briefly introduce its architecture. From the picture below, we can see:
Figure 3: CLDC / MIDP architecture
There are two types of API: -midp apis on CLDC: These APIs are the APIS. - OEM-SPECIFIC APIS: MIDP specification varies a variety of wireless communication devices, so it is impossible to involve The needs of all devices. So this category API is a specific feature provided by OEM vendors to access specific devices. But applications based on these APIs may not be able to run on other MIDS devices. Type of MID applications: -midp: A MIDP app or called MIDET, it is required to use only the APIs defined in the MIDP and CLDC specifications. This type of application can be the most common application on the MID device. -Oem-Specific: An OEM-SPECIFIC application uses some PIS (Oem-Specific Classes) that is not defined in MIDP. These applications cannot run on different MIDS devices. -Native: A local application makes it refer to applications that are directly running on the device operating system with non-Java language. The application of OEM-SPECIFIC and NATIVE is not involved in the MIDP specification.
The range involved in the three MID V2.0 specification:
We all know how many functions of wireless information devices (MIDS). But MIDP specifications are not to be defined for all functions of these devices, and provide API programming. Interphaby MIDP V1.0 and MIDP V2.0 expert group Agree to form the corresponding APIS only for the needs of the function with universal and successfully implemented features. These features in MIDP V1.0 include:
- Application download
- The life cycle of the application
- End-to-end transmission (HTTP)
- Network connection
- Database Storage
- Timer
- User Interface
Through the user's experience and feedback of MIDP V1.0, the expert group of MIDP V2.0 adds the following APIs on the basis of the MIDP V1.0 APIS:
- Application download and billing
- End-to-end secure transmission (HTTPS)
- Application digital signature and domain security mode
- MIDlet's Push Registration (Server Push Model)
- Sound
Based on the same reason, some functions are not within the definition of MIDP, including:
- System layer APIS: MIDP API's focus is for developers for applications, rather than system development. Therefore, some bottom-up APIs involving the system interface, such as power management of wireless information devices, voice encoding modules belong to the system layer API, not within the scope discussed by MIDP. - Bottom security: The MIDP specification does not involve the function of the underlying safety, which only uses the underlying safety mechanism provided by CLDC.
We do not introduce this new API in this article about MIDP V2.0.
Safety mechanism for four MIDP V2.0:
We know that the Java language is used as a network programming language, which has a lot of features to meet the needs of network programming, which is the most people who are here to run everywhere, and its security. Especially its security, from its invention, the current 7 years has proved to count countless facts. Java language security, security mechanism also has the process of development, and we will briefly introduce the following Java security mechanisms.
Java1.0 sandbox mechanism:
Fig 3: Java1.0 security sandbox mechanism
The above figure is described in Java1.0's sandbox mechanism, which is the first for Applets running in the slippery. Since the operating code of the applet is transmitted to the user through the network, in order to prevent malicious code, the mechanism is simply divided into local application and network applications (Applet). Applying it to the web application can only ask some secure APIs to ensure security. But the mechanism is too simple and cannot meet the needs of developers.
Java1.1 security mechanism for trusted code:
Fig 4: Security mechanism for trusted code
The safety mechanism is only based on the Java1.0 sandbox security mechanism, introduces a new network application, trusted network application, but does not have a good partitioning of the resources accessed. Everyone can see that the application is subject to the constraint of the sandbox, and only the limited resources can be accessed, or all resources can be accessed.
Domain security mechanism of Java 1.2 / 2:
Domain safety mechanism of Java1.2 / 2
The security mechanism configures a very refined security mechanism through the configuration file to Java's application and the resources accessed.
MIDP security mechanism and its development:
The MIDP 1.0 specification is in the development phase of the wireless network at the time, so there is no much consideration of the security settings during the network transmission during the safety mechanism of MIDP V1.0, but focus on wireless Apply security during the running process on the device. Therefore, the MIDP1.0 specification provides the safety mechanism of the sandbox to provide the MIDlet Suite runtime, which ensures that the APIT can call the APIs that cannot access the sensitive information and functions of the device. During the development of the MIDP2.0 security mechanism, the expert group adopted the user's opinion on the MIDP V1.0 security mechanism: the 1.0 version of the security is too "strong" makes many wireless devices
Cannot be used by MIDP programming. For example, the address of the address in your phone, etc. If you want to open these sensitive APIs to allow users to access, you must introduce a new security mechanism. This mechanism is the security mechanism of the domain of Java1.2 / 2 as described earlier. In MIDP V2.0, the MIDlet that is not trusted can only be run in the sandbox security mechanism. Any MIDP V2.0 is implemented, and it is necessary to support non-trusted MIDlet running on the MIDS device.
MIDP2.0 introduces a new concept of a trusted MIDlet, which can use some sensitive and restricted APITs for trusted MIDlet. When the wireless information device detects that a MIDlet SUTE is trusted, it is accessible to the APIS. The corresponding security domain policy definition. We will be introduced in the following chapters. When verifying if a MIDlet Suite can trust, the MIDlet Suite must be rejected.
MIDP2.0 domain security mechanism:
Non-trusted MIDlet Suites
One non-trusted MIDlet Suite refers to the device that MIDLET Suite's download source and JAR file integrity cannot be downloaded. For non-confident MIDlet Suite, you can only run in a non-confident security domain, in which protected APIs or functions cannot be accessed or can be accessed or not accessible by the device user. Any MIDP 1.0 compatible MIDlet Suite can run with non-trusted mode on the implementation of MIDP V2.0. For non-credited MIDlet Suites, it can access its Jar Manifest and Application DesctiPtor files and the APIs below: - javax.microedition.rms
- javax.microedition.midlet
- Javax.Microedition.lcdui
- javax.microedition.lcdui.game
- javax.microedition.media
- javax.microedition.media.Control
Non-trusted security domains to access the following APIS or functions must be determined by the user or not:
- javax.microedition.io.httpConnection
- javax.microedition.io.httpsConnection
Trusted MIDlet Suite Security:
Trusted MIDlet Suite's security is based on the mechanism of protection domain. Each protected domain defines access to MIDlet Suite in this domain. The definition of the protection domain can define how the device confirms and verifies the MIDlet Suite it can trust and binds the protected APIs and features that the domain allows and authorized to use the protected APIs and features used to the MIDlet Suite. The definition of the verification and trust MIDlet Suite used by the device is separated, which is advantageous for people to choose according to the device, network, and business model. Trusted MIDlet Suites uses the X.509 PKI signature and verification mechanism to determine the trustedness of a MIDlet Suites.
In the security mechanism of the domain of MIDP2.0, everyone mainly returns the following concepts:
Protection Domain: It is a collection of permissions allowed by MIDlet Suite
Permissions Access: means an API or function that must be used by authorization
Trust MIDlet Suite: Refers to the MIDlet Suite to be guaranteed by verifying and its JAR file is guaranteed, and can be trusted by a certain guard field on the device.
Profile: A definition of many domains or aliases in a configuration file. Each domain is constructed by the permissions included with the assigned permissions and user operations.
Example of the configuration file:
Domain: o = MIDlet underwriters, Inc., c = US
Allow: javax.microedition.io.httpConnection
Oneshot (oneshot): javax.microedition.io.commconnection
Alias: client_connections javax.microedition.io.socketconnection, javax.microedition.io.secureConnection,
Javax.microedition.io.httpConnection,
Javax.microedition.io.httpsconnection
Domain: o = acme wireless, ou = Software Assurance
Allow: Client_Connections
Allow: javax.microedition.io.serversocketConnection, javax.microedition.io.udpdatagramconnection
Oneshot (onshot): javax.microedition.io.commconnectionDomain: Allnet
Blanket (session): Client_Connections
Oneshot: javax.microedition.io.commconnection
5. Summary:
MIDP V2.0 is an open Java platform provided for the majority of developers on wireless mobile communication devices, which has open, versatile, and more security features than MIDP V1.0. It is developed by about 50 vendors around the world, so the application based on MIDP V2.0 has a wide range of application prospects in the future.
Appendix 1: Group of MIDP V2.0:
the company:
4thpass Inc, AGEA Corporation, Alcatel, Aplix Corporation, AromaSoft Corp, Baltimore Technologies CELLon France, Distributed Systems Technology Centre, Elata PLC, Esmertec, Espial Group Inc, France Telecom / Orange, Fujitsu Limited, German Aerospace Center (DLR), Institute of Communications and Navigation, Hitachi Ltd./Digital Media Group, In Fusio, J-PhoneEast Co. Ltd, Logica Mobile Networks, Mitsubishi Electric Corp, Mobile Scope AG, Mobilitec, Motorola, NEC Corporation, Nextel Communications Inc, Nokia, NTT DoCoMo, INC, Omnitel Pronto Italia Spa, One 2 One, OpenWave Systems
, Inc, Orange (UK), Palm, Philips Consumer Communications, Philips Semiconductors, Research In Motion (RIM), Samsung Electronics Co., Ltd, Sharp Labs, Siemens AG, Siemens ICM, Smart Fusion, Sony Ericsson Mobile Communications, Sun Microsystems , INC, SYMBIAN LTD, TELEF'NICA M'Viles Espa'A, Vaultus, Inc, Veloxsoft, Inc, Vodafone Global Platform & Internet Services, Vodafone Group Services Limited, Vodafone MultiMedia, ZuCotto Wireless,
personal:
Fabio Ciucci, Glen Cordrey, Jon Eaves, David Hook, Myank Jain, Neil Katin, Steve Ma, Ravi Reddy Wai Kit Tony Funghttp: //gceclub.sun.com.cn/staticcontent/html/java/midp/index.html
