The current situation and development of J2ME
Sun China Engineering Research Institute Software Technology Center Wang Gang
Summary
This paper briefly introduces the concept and status of J2ME, the latest features of MIDP2.0, and describes and analyzes the J2ME's competitors, the compatibility of J2ME applications, and their application in Web Services.
What is J2ME?
When the Java platform has developed to Java 2, in order to adapt to the development of different levels of computer hardware, the Java platform has formed three main branches:
Java 2, Standard Edition (J2SE): It is designed for desktop, mainly running on operating systems such as Linux, Solaris, or Microsoft Windows.
Java 2, Enterprise Edition (J2EE): It is a platform for distributed, multi-user, and enterprise application systems. It is based on J2SE to increase the function of processing server-side calculations.
Java 2, Micro Edition (J2ME): Unlike J2se, it is neither a software that cannot be considered. Quantitatively, J2ME is a general name of a series of technologies and specifications that is launched by small embedded or mobile devices such as PDA, mobile phones. It borrows a part of the J2SE class library, uses fewer APIs, and its Java virtual machine (JVM) in J2ME is much smaller than J2SE's JVM.
figure 1
It should be noted that the hardware platform for J2ME to support also has a big difference, including high-end devices, such as a set-top box, network TV, etc., and a relatively low-end mobile phone, pager, etc. Therefore, in order to meet the development requirements of different hardware, J2ME specifies the concept of Configuration, and Configuration has specified for different levels of hardware in the JVM and foundation API collection. Thus, for high-end devices, a CDC (Connected Device Configuration) is used, and the JVM used is called CVM; for low-end devices, CLDC (Connected Limited Device Configuration) is used, and the JVM used is KVM (see Figure 1).
CDC and CLDC are merely a basic set of functions for the most common configuration in various devices. However, in practical applications, there are great differences before different devices. Therefore, on the basis of Configuration, we propose the concept of Profile. The content specified in Profile is a specification and API settled for a class. After the Profile, it really has a complete environment that can run J2ME applications. Mobile Information Device PROFILE (Mobile Information Device Profile or MIDP) is based on CLDC, which is the first to develop PROFILE and the first J2ME application running environment available. The content in this article will also be laminated around the MIDP.
Currently, there are many devices that support the J2ME programs, including Motorola's A388, T720, NOKIA 6800, 7210, etc., such as the mobile phone (see http://wireless.java.sun.com/Deject.java.sun.com/device/). As of February 2003, 21 manufacturers have launched more than 100 handheld devices that support Java. According to the "Wireless Java Report" of Arc Group 2002, "By 2007, almost all handheld devices will provide support for Java," It seems that J2ME will continue to heat up in the next few years. Can J2ME can provide developers and users?
As mentioned earlier, MIDP has the earliest and fastest development, and we only discuss the development of J2ME MIDP applications. In October 2002, JAVA Community Process, see http://www.jcp.org, launched MIDP2.0 specification, compared with MIDP1.0, which greatly enhanced user interface, multimedia and game function, Support for network connection functions, while the OTA application downloads are included in the specification, and the wireless information device provides end-to-to-end security mechanisms.
In order to support the processing of sounds (such as playing WAV files), an optional package ABB (Audio Building Block) is added to MIDP2.0. Previously, ABB included only in Mobile Media API (MMAPI), now incorporating it into the MIDP, and developers can do not depend on MMAPI. Of course, if MMAPI is used, more functions can be developed for mobile devices, such as playing video streams on the PDA.
Support for J2ME game development may be that developers and users are looking forward to a long time, the game API provided by MIDP2.0 enables the game itself to make more fully utilized equipment itself. Its emergence is undoubtedly simplified in the development of J2ME games, and also enables developers to more control the program's graphical processing performance.
In terms of communication, MIDP 1.0 only supports HTTP, and MIDP2.0 adds support for HTTPS, packets, socket communications, and serial communication. In addition, MIDP2.0 also supports server Push architecture so that your phone can receive alarms, messages or broadcasts from the server, and operate on the application on the phone.
Support OVER-THE-AIR (OTA) provisioning is an important new feature of MIDP2.0 that enables users to dynamically deploy and update applications on mobile devices. The new version of the MIDP specification specifies how to discover, install, update, and delete MIDlet kits on mobile devices; at the same time, the service provider that provides application downloads can also determine if the MIDlet kit can run on the app, and from Get information on installation, update, and delete on your device. The MIDP OTA Provisioning model provides a single, standard deployment MIDP application for mobile service providers. This model has been adopted by many leading mobile device manufacturers and service providers.
Since human beings enter the network era, network security is always a key issue. MIDP2.0 adds powerful "end-to-end" security models. On the one hand, MIDP2.0 supports HTTPS, encrypts the transmitted data; on the other hand, MIDP 2.0 uses different security mechanisms with MIDP 1.0, using security domains to ensure unauthorized MIDlet kits cannot be accessed Controlled data, applications, and other networks and device resources.
With the launch of new specifications, Sun, Motorola, Nokia, Borland, etc. have launched their respective J2ME development tools and integrated development environment (IDE), and have been widely praised by developers. According to statistics, from January 2003, J2ME Wireless Application Development Tools (J2ME Wireless Toolkit, see http://java.sun.com/products/j2mewtoolkit/) has exceeded 515000. In addition, the J2ME development team is constantly growing, and the total number of J2ME developers in the world has exceeded 2 million. Figure 2 is a typical Ide that supports J2ME applications developed, developers can complete encoding, debug, deployment, and complete functional tests with emulator of mobile devices. figure 2
Is J2ME competitors?
Of course. Just like J2EE from .NET competition, J2ME has BREW (wireless binary operating environment).
It is very likely that BREW really begins to gather Chinese eyeballs, in December 4, 2002, China Unicom and CDMA digital wireless technology pioneers and global leadership manufacturers QUALCOMM announced that the two sides have signed a contract to establish a joint venture company to promote the BREW platform. China's development and supports the growing China BREW developer group. In addition to China Unicom, US Verizon, Alltel, South Korea's KTF and Japan's KDDI have launched Brew's business services, and more and more operators around the world are constantly joining their ranks.
The BREW platform is a thin application operating environment that provides wireless devices with an open and standard platform. The BREW platform is comprehensive, end-to-end wireless application development, equipment configuration, application distribution, billing, and part of the payment solution. About BREW more detailed information, you can visit http://www.qualcomm.com/brew/.
So, is BREW a threat to J2ME? Statistics show that now the world can support J2ME's handheld equipment has reached 75 million, and 34 operators are using J2ME technology; in contrast, Brew is a little witch, and the equipment that can be running BREW is only available. 460,000, 6 CDMA operators are providing services. Moreover, in March 2003, QUALCOMM announced that it will provide support to J2ME in its CDMA chip, which is mainly based primarily based on MIDP 2.0 and CLDC1.0.4. This initiative undoubtedly proves that J2ME is a solution to technology-leading development and deployment of wireless data services. Since Qualcomm has almost occupied 90% of the CDMA chip market share, this will also accelerate J2ME penetration to the CDMA field. Of course, QUALCOMM is not preparing to abandon Brew, so it is very likely that J2ME and Brew co-existed on the same mobile device, and the maximum benefit is the developer and end user of mobile device applications.
Is there any shortcomings in J2ME?
Have. If you are a J2ME developer, may have encountered this situation: a program that has been developed can be running on the Motorola A388 but does not work normally on another brand, must pass some code modifications use. The emergence of this situation clearly violates the original intention of "writing once, run everywhere" in the Java platform. what is the reason behind the scene? This is because JCP has made a relatively broad provision in order to make it possible to apply CLDC and MIDP, in order to make it applicable to many manufacturers' products. Therefore, when the manufacturer is completing your own implementation, it is often in the range of specifications permitted, so that when the developer calls these functions, it is often necessary to join some sources for these extensions. Code results in the incompatibility of the development of J2ME applications. In this case, more and more mobile device manufacturers and developers have realized that a criteria need to be established to ensure the cross-platform of the J2ME application. Java Technology for the Wireless Industry, Java Technology, JSR185, is to complete this mission. Technical experts from Motorola, NOKIA, SONY and SUN, began the formulation of this norm at the end of 2002 and will be officially launched in the mid-2003. JTWI did not define a new API, but created a new handheld Profile for existing J2ME specifications (such as CLDC, MIDP, MMAPI, etc.), enabling them to effectively integrate together, for mobile phones and other mobile devices A complete Java run environment is available on the "end-to-end solution". Figure 3 is a diagram showing the relationship between the various components in the mobile phone software stack specified in JSR185.
image 3
For example, if the developer needs to call the mobile phone's SMS (SMS) function in the J2ME program, the proprietary API provided by the mobile phone is often required. In fact, today's standard practice should be the Wireless Messaging API (WMA) that calls mobile phone. So in JTWI, it will recommend the developer to use WMA, not a proprietary API.
There is no doubt that JTWI will promote all manufacturers to provide developers and users to provide standardized CLDC and MIDP implementations to overcome the shortcomings of the current J2ME application will further strengthen their usability, which promotes greater extent. The popularity of users.
What direction will J2ME eventually develop in?
With communication technology, the development of the Internet, we are not difficult to fantasize that we can use any equipment (PDA, computer, mobile phone), at any time, any place to get any services required (received emails, shopping, stock inquiry, etc.) This is the idea of providing "Service On Demand" for customers. To achieve the "on-demand service", you need to use the mechanism for web services as a technical framework. (To understand the basic concepts of Web Services, see "What is WEB SERVICES, http://gceclub.sun.com.cn)
Figure 4
How to really integrate mobile devices into the web services? This needs to make the PDA, mobile phones, etc., the client, which should be web services, then these devices should have the ability to process XML information. J2ME Web Services Specification (JSR172) is to solve this problem, Figure 4 illustrates a system architecture that combines J2ME and Web Services.
JSR172 will be released soon, let us make a preliminary understanding of it before it is officially introduced. First, the formulation of this specification is to add two major functions to the J2ME platform: First, make it able to remotely access SOAP / XML-based Web Services; second, it has the ability to parse XML data. In order to achieve these two features, JSR172 newly defines two optional packages that provide the appropriate functions. These two packages have very little memory, and the XML-RPC part requires a 25-30kb space, while the XML parser takes about 35kb. It is important to emphasize that only support for client access Web Services is provided in the specification, without giving J2ME devices as a Web Services provider, which is also available from J2ME devices with limited resources. Friends who have already used experience in J2ME may be proposed, even if there is no JSR172, KSOAP and MIDP cooperation can be used to complete the development of J2ME Web Services. KSOAP is an open source item specially developed for KVM (ie CLDC) (see http://ksoap.enhydra.org), which we can reference the third-party libraries provided in KSoAP to support Web Services. However, after the JSR-172 support, we can not use KSOAP, and JSR172 can work both in CLDC or on CDC.
Of course, J2ME Web Services also has a lot of limitations due to the particularity of their platform, and relatively "real" Web Services. For example, in the first version of the specification, only support the JAX-RPC model, that is, only supporting the synchronous access method, using the J2ME client to send RPC requests and get RPC responses to the server. And support for asynchronous message mechanisms, we can only send the future version. In addition, JSR172 has not supported UDDI (Universal Description, discovery, and integration), that is, MIDlet cannot "discover" Web Services in operation. However, this can be solved by using development tools, using the definition of WSDL (Web Services Description Language) to generate stub's way "static" place to resolve.
to sum up
J2ME provides a platform for embedded and mobile devices, providing a platform for developing and running applications. With the continuous introduction of new specifications and many manufacturers, software developers support, J2ME is developing forward. JTWI will ensure the compatibility of the J2ME application on different manufacturer's products. In the future, J2ME will use the power of Web Services to truly become an indispensable part of an enterprise-level information solution.
references
1) Wireless Java technology introduction, http://wireless.java.sun.com/getstart/
2) J2ME Datasheet, http://java.sun.com/j2me/j2me-ds.pdf
3) Core J2ME technology with MIDP, by John W. Muchow, Sun Microsystems Press
4) Java 2 Micro Edition Overview, Mei Qi, Sun Network Community http://gceclub.sun.com.cn
5) JSR-118: Mobile Information Device Profile 2.0, http: //jcp.org/en/jsr/detail? Id = 118
6) JSR-172: J2ME Web Services, http://jcp.org/en/jsr/detail? Id = 1727) JSR-185: Java Technical Specifications in Wireless Area, http://jcp.org/EN/JSR / DETAIL? ID = 185
8) CAN Sun's Mobile Posse Ease J2ME Developers' Woes? By David Berlind, January 29, 2003
9) BREW white paper, http://www.qualcomm.com/brew/about/whitepaper.html
10) Qualcomm Eats Hat in Mobile Java Deal, by Elizabeth BiddleCombe, March 13 2003, http://www.theinquident/? Article = 8304
11) What did Web Services bring, Wang Wei, Sun Network Community http://gceclub.sun.com.cn
