A New Strategy of Language Pack Management for Wireless Appsby: Huang Chang & Tong Chun JieUse the Service Management Framework to Develop Globalized Wireless Apps Learn about a new application development paradigm that takes advantage of the Open Service Gateway initiative (OSGi) service platform to achieve globalization features in wireless applications. You'll take a look at the approach from an architecture perspective, with a focus on how to manage language packs required by wireless applications in an on-demand environment and exemplify it with an implementation on the IBM Service Management Framework. Introduction In traditional wireless solutions, device-side applications are too weak to achieve globalization completely because of hardware and software limitations. However, on-demand level globalization support is a critical requirement for global e-business clients such as PDAs, which have adequate network capacity but low storage capacity.This article describes a new application development paradigm that takes advantage of the OSGi service platform to achieve globalization features in wireless applications. We describe our approach from an architecture perspective with a focus on how to manage language packs required by wireless applications in an on-demand environment and exemplify it with an implementation on IBM Service Management Framework™. Because of the popularity of mobile devices today, the devices are always moving from one place to another, from one country to another, and even from one region to another. Interaction with users from different countries and different cultural backgrounds casts an increasing demand on globalization features for device applications. Implementation of globalization features in applications for mobile devices is quite different compared with that for desktops or servers. The primary difference is the different hosting environments in terms of hardware and software capacity. Therefore, globalization support is a critical concern in designing applications for global e-business clients such as PDAs, which have adequate network capacity but low storage capacity. The OSGi specifications define a standardized, component-oriented computing environment for networked services. Currently, a wide range of device vendors have implemented the OSGi specifications and empowered their device products with OSGi as the hosting platform for wireless applications. A remarkable feature of the advantages of OSGi is its component-based architecture, which enables device-side applications to load required components from the management sever in the run time. In this sense, application components can be customized to be on-demand in order to meet the shortage in device storage. In this article, we investigate the feasibility that takes advantage of OSGi's componentization feature to enable globalization support in wireless applications. Specifically, under the componential programming framework of OSGi, we encapsulate each language pack (LP) supported by wireless applications into different OSGi components called bundles so that they can be requested and delivered separately in the run time. Also, by leveraging the service registry mechanism in Service Management Framework, the device application, as a single executable, can switch among global users of different locales with a minimum user intervention footprint and can always keep itself on. PC Versus Mobile Devices Wireless applications differentiate from traditional PC applications in several ways. First, mobile devices rely heavily on the network connection because applications running on mobile devices usually come from a management server. This server is responsible for provisioning the devices within its management scope with various sorts of software and upgrading them accordingly. Currently, most mobile devices work under this server-based management mode. One advantage of this mechanism is that any software maintenance activities, like new application deployments or upgrades, can be validated on a group of devices simultaneously, reducing the total cost of ownership. Secondly, in traditional applications where multiple languages need to be supported, the language packs for all supported languages are normally placed in one package, shipped, and installed with the executable code. However, for the applications that run on mobile devices, the language packages have to be designed very concisely because the placement of all language packs take up a considerable amount of storage space. Considering the limited storage capacity of mobile devices, the globalization feature of a wireless application cannot be too complicated or LP support will be limited to only a few common languages. OSGi Overview The OSGi framework provides a Java technology-based, lightweight (fully Java 2 Platform, Micro Edition-compatible) container for dynamic software components. Adding an OSGi service platform to a mobile device adds the capability to manage the life cycle of the software components in the device from anywhere in the network. To enable the functionality defined in the OSGi, an OSGi service platform implementation must be installed on each device. Currently, the OSGi service platform specification has been implemented by a number of companies into their products, such as the IBM Service Management Framework. As depicted in the graph in Figure 1, the software components managed by OSGi are called bundles, which are standard Java Archive (JAR) files. An OSGi application normally has a toy trick-like structure, which means during its total life cycle it might invoke an arbitrary number of bundles. Besides reusability, the design fundamental of the bundle also takes the limited device storage into consideration. All the participating bundles are not required to be available on the device when the application is started. Instead, when a bundle is found to be missing on the device side, the OSGi service platform delegates the application to fetch the needed bundle from the management server and install it in the run time. After invoking, those bundles that are never used can be uninstalled by the invoker application to free the storage. The OSGi bundle is completely self-contained with all the necessary metadata in its manifest file. OSGi bundles can be installed, updated, or removed on the fly without ever having to disrupt the operation of the device. Figure 1. OSGi architecture
The OSGi provides powerful ways for bundles to interact with each other. Interactions between bundles generally fall into two categories: static sharing or dynamic services. • Static sharing: The OSGi container runs on a single Java Virtual Machine (JVM) instance, but has a different class loader for each bundle. That means bundle namespaces are separate. You cannot directly access objects or classes in another bundle by default. However, a bundle can explicitly export some of its Java packages through the Export-Package attribute in its manifest file. It can also import Java packages exported by others using the Import-Package manifest attribute. The export and import features allow direct sharing of Java packages. • Dynamic services: In addition to standard services provided by the container, any bundle can consume and provide services from and to other bundles at the same time. A bundle can dynamically register (or unregister) services with the container so that another bundle can find the service reference through a lookup API in the framework. For details about OSGi, please refer to the OSGI documentation (see Resources). OSGi-based LP Loading Strategy Requirement analysis The deployment policy for LP that is applied in traditional globalization applications is not feasible for mobile device environments. Preparing LP packages for all supported languages in one package and placing it with the supported application requires a considerable amount of device storage, especially for those applications in which each LP takes up a lot of space. Suppose an e-book had to be translated into several languages for reading, that's an example where the storage capacity could not handle the application. The locale setting on the device determines the language pack to be used. In most cases, only one locale is valid for end users. It is presumed that the supported language pack will continue to serve the application throughout the application's life cycle after its corresponding locale is determined. Even though there are some locale switches during the application's life cycle, such events are not meant to occur frequently. Therefore, the application typically relies on a single LP for one specific language, while leaving those for the other languages idle until a locale switch occurs. A storage-saving LP loading strategy is demanded, while still ensuring the multiple language support in one device. A reference model The OSGi's componentization architecture can be utilized to reinforce full LP support, which cannot be completely achieved due to limited device storage. The idea comes naturally from the bundle-based framework, in which required software components can be dynamically loaded to the device rather than being prepared beforehand. Figure 2 describes a possible solution that implements the dynamic LP loading strategy. Figure 2. A reference model for OSGi-based dynamic LP loading
To avoid loading/unloading all language packs in one action, each language pack in an application is packaged in a separate OSGi bundle. Instead of being downloaded to the device with the installation of the application bundle, these language packs are stored in the management server and requested dynamically. Acquiring a specific language pack can be achieved by the install bundle facility provided by the OSGi service platform. To avoid duplicate code by different applications, an application-independent LP proxy bundle delegates the maintenance work on a device LP, such as LP install/uninstall and LP pool control. The LP proxy bundle provides various application bundles with a common LP access interface. With this type of interface, applications can indirectly access LP contents transparently without worrying about the details of LP loading. Another benefit of introducing a centralized LP proxy is that it can enforce some global policies regarding LP usage on all the globalized applications. For example, device administrator can set a parameter to define the LP pool size for each application. Service Management Framework In the following sections, we discuss an implementation of the architecture described above by leveraging the IBM Service Management Framework, which is an implementation of the OSGi service platform specification. Service Management Framework is a production-ready software management framework for network-delivered applications that meets the needs of Internet-ready device manufacturers and service providers such as cable companies and power utilities. The bundle development kit for Service Management Framework, consisting of the Service Management Framework run time, Service Management Framework bundle server, and Service Management Framework bundle developer tools, is packaged as a series of Eclipse plug-ins, and can be installed in WebSphere™ Studio Device Developer (Device Developer). In addition to providing features of the OSGi service platform specification definition, the Service Management Framework bundle development kit provides a total solution for application development, deployment, and management features. Design Model for an Exemplary Implementation Our implementation consists of a few bundles described as: • LPProxy: An intelligent proxy manipulates all LP bundles and provides developers with a simple-to-access interface. • LP_en_US and LP_zh_CN: Two of the LP bundles involved in this case study. In a real environment, the number of LP bundles might vary from just one to many. • LPService: Extracts all the methods that LPProxy and LP bundles provide and presents them in an abstract manner. Additionally, it contains two Java interfaces, one for LPProxy and one for LP bundles. • LPInvoker: This simple bundle is used as a simulated bundle application that delegates the LPProxy bundle to read data from language packs. Figure 3 shows the relationship between the classes in different bundles. In detail, LPProxyService and LPService belong to the LPService bundle and are implemented by LPProxy and LP bundle respectively. In addition to LPProxyImpl, an implementation of the LPProxyService interface, the LPProxy bundle contains two other classes: LPProxyFactory, which creates the instance of the LPProxyImpl, and LPProxyActivator, which registers the bundle to the Service Management Framework run time. Each LP bundle must implement the LPService, and also includes LPServiceFactory and LPServiceActivator to register the LP bundle when the bundle starts. The LPInvoker bundle has only one class, LPInvokerActivator, which renders the localization data to you as it starts or stops. Figure 3. Class diagram for bundles ![]() Language Pack Bundle The LP bundle contains the localization pack for a certain locale. Each LP bundle complies with the naming convention; that is, a complete bundle name must have an identical suffix and end with the corresponding locale (for example, LP_en_US, LP_zh_CN, LP_fr_RF, and so on). The language pack in the LP bundle can be presented as ListResourceBundle or PropertyResourceBundle, depending on different requirements. In our case, we'll choose the latter and use the bundle name as the property file name. As you saw earlier, the LP bundle includes three classes along with the language pack file. The stub code here is necessary because the OGSi service platform uses different class loaders to load different bundles. Therefore, the language pack file packaged in the LP bundle cannot be accessed directly by the external classes from other bundles. The workaround is to add a segment of stub code to perform language pack file access and register the access operations as an OSGi service. Listing 1 shows the source code of LPServiceImpl. Listing 1. The LPServiceImpl class public class LPServiceImpl implements LPService{ private BundleContext bc; LPProxy Bundle The LPProxy bundle acts as a proxy for delegating all LP bundles-related requests. Like the LP bundle, it also registers to the Service Management Framework run time at startup. Upon receiving the getString(String key) from other bundles, the LPProxy bundle first checks whether the desired LP bundle has already existed in the Service Management Framework run time. It downloads the LP bundle from the Service Management Framework bundle server if the bundle is not available. After that, the LPProxy bundle starts the desired bundle and finds the service reference of the LPService, which provides the getString(String key) method for accessing the resource bundle, by comparing the bundle name. Finally, the LPProxy bundle creates the instance of LPService and calls its getString(String key) method for the multilingual data. LPProxy provides the following methods: • void setBaseName(String baseName): Sets the base name of the LP bundle. If a bundle is named as LP_en_US, for example, the base name should be LP. • String getBaseName(): Gets the base name of the LP bundle. • void setLocale(Locale locale): Sets the locale of the LP bundle. • Locale getLocale(): Gets the locale of the LP bundle. • String getString(String key): Gets a string for the given key from the LP bundle. The getString(String key) method is the key function, as shown in Listing 2. Listing 2. The getString(String key) method and its related methods public String getString(String key) {
LPInvoker Bundle To show how well the embodiment works, we will develop a testing bundle to simulate how a fictitious application bundle can benefit from the globalization support provided by the LPProxy. This bundle first gets the instance of LPProxyService by looking up the service registry of the Service Management Framework run time. Next, it identifies the LP bundle by specifying the base name and locale. Finally, the bundle reads the multilingual data from the LP bundle by calling the getString(String key) method. Listing 3 shows the source code of the start method. Listing 3. The start method of LPInvoker Bundle public void start(BundleContext context) throws Exception {
Finally, we submit all these bundles to the Service Management Framework bundle server and elect to install the LPInvoker bundle. In the Service Management Framework run time console, we should see the output when the bundle starts and stops, as shown in Figure 4. We can try again by switching the locale to zh_CN in the start method, and the output changes accordingly, as shown in Figure 5.
Figure 4. The output from the console with locale en_US
Figure 5. The output from the console with locale zh_CN ![]() In Summary We have described a method that utilizes OSGi to realize dynamic LP loading for wireless applications and provide a reference implementation on the Service Management Framework. This method is effective for those wireless applications that demand multiple-language globalization support and with language packs of considerable size. Resources • The article Web services globalization model (developerWorks, June 2003) describes the base elements of a globalization architecture and then applies them to the Web services architecture. • Find the latest OSGi Service Platform Release 3 specification from OSGi Alliance Web site. • The IBM Service Management Framework is an implementation of OSGi that provides network delivery and management to applications and services. • Download the IBM WebSphere Studio Device Developer IDE free evaluation. This page also contains a link to download the latest IBM Service Management Framework software for a free evaluation. • Learn more about Developing Java OSGi applications for PDAs and other embedded devices (developerWorks, December 2003). • The article Considerations of globalization solutions in J2ME (developerWorks, April 2004) explains globalization trends and requirements in the J2ME environment. © 2008 NetVisits, Inc. All rights reserved. |