The Symbian OS (779886), страница 66
Текст из файла (страница 66)
Complex system interactions are required between the two, andindeed requirements originating from the successive Java implementationshave had significant impact on the evolution of some fundamental featuresof the operating system, including the native Symbian OS applicationmodel, inter-process communication (IPC), and the thread and processmodels.
In particular, the different threading models of Java and SymbianOS posed particularly thorny issues for the early Java implementations,which in turn influenced later design decisions.At a high level, the architecture (see Figure 12.3) can be broken downas follows:• the SystemAMS server, which is responsible for the lifecycle of MIDletsand VM processes, and static and dynamic resource management forJava applications• the SystemAMS plug-ins for licensee customizability (i.e. customizedsecurity policy)• the SystemAMS extension plug-ins that extend internal AMS frameworks• the VM executable, which includes the VM, MIDP APIs and frameworks• the VM plug-ins for licensee customizability (i.e.
graphics customization)308THE JAVA ME SUBSYSTEMMIDP 2.0CLDCCLDC RuntimeClient-sideSystem AMSVMLCDUILCDGRRuntimeplug-inSecuritypolicyClient-sideRecognizers,installersFigure 12.3 Internal architectural view of Java ME on Symbian OSJava ME Applications Management SoftwareThe System Application Management Software (SystemAMS)) operatesas a managing agent between Symbian OS and the Java ME run-time(see Figure 12.4) for all stages of the MIDlet lifecycle from installation,launching and stopping MIDlets, controlling execution and launchingVM processes as required.
SystemAMS also manages static and dynamicpush connections and alarms registered by MIDlets, which is the basisfor the MIDP 2.0 ‘push’ support.SystemAMS is implemented as a server which is run from device boottime. From an application perspective, the MIDlet can initiate some statechanges itself and notify the MIDP run time, which eventually notifiesSystemAMS of those state changes by invoking the appropriate methods.From a system perspective, SystemAMS provides client-side interfacesused by the VM and the Java installer to support MIDlet recognition,installation and launch; manages resources such as registered push connections and Symbian OS alarm notifications; and is responsible formanaging the MIDP policy-security model.The CLDC Configuration LayerAn important feature of Symbian’s CLDC implementation is its support forvarious VMs.
For example, in earlier versions of Symbian OS, the KVMwas used and later replaced by the CLDC 1.0 VM which was eventuallyreplaced by the CLDC 1.1 VM. As VMs may change, an abstractionlayer is required between the VM and the various CLDC and MIDPARCHITECTURE309System AMSProfile APIsBTCLDCWMAetc.CoreClassesVMMIDletlifecycleLaunch andreclaimRecognizersInstallerAlarmsSymbian OSConnectionsSystem AMSFigure 12.4 SystemAMS Architecturelibraries to avoid dependencies between them and any particular VM.The abstraction layer also interfaces Java event-handling with the nativeevent-handling model.CLDC-HI is designed as a high-performance JVM and run-time environment for resource-constrained small devices, in particular mobilephones and communicator-style devices, and is optimized for performance, footprint, and efficient resource management, with a specializedJust In Time (JIT) compiler for the ARM processor architecture. Sun claimsan order of magnitude improvement over the performance of the olderKVM, for example.The MIDP Profile LayerLCDUIMIDP is specifically targeted at small, mobile devices.
It includes theLCDUI specification, which is optimized for this device class. LCDUIdefines both the UI event model and the standard GUI widgets available to MIDlets (lists, forms, textboxes, and so on). LCDUI thereforerequires integration both with the native UI Framework and ApplicationArchitecture.In order to make MIDlets (as far as possible) indistinguishable fromnative applications, LCDUI uses the native widget set as peers for theJava widgets.
A MIDlet runs as a single native application owning its310THE JAVA ME SUBSYSTEMown window group, listed in and launchable from the task list (if theuser interface variant has a task list) and integrated with the save notifierframework, power events, and foreground/background notification. Inputmethods are also inherited from the native widget set so that all nativefunctionality is available to MIDlets, for example, mechanisms suchas T9, handwriting recognition and non-keyboard character set input(e.g. Chinese), which are all based on the Front End Processor (FEP)framework. This also harnesses the native locale support, for example forbi-directional text and capitalization.The LCDUI implementation consists of a framework that implementsthe core user interface functionality and provides the high-level interfacebetween Java ME LCDUI APIs and the concrete user interface platformimplementation areas that are implemented in separate graphics plugins (which licensees customize to provide integration with the graphicssystem of their specific user interface platform).GCFThe MIDP Generic Connection Framework (GCF) provides the genericmechanism for creating a connection from a URI and enables a widevariety of connections including networking connections such as HTTPand HTTPS, sockets and server sockets, secure sockets and datagrams,as well as support for ‘push’ connections and on-device mechanisms forlocal file and directory access (which is known as ‘File GCF’).The MIDP GCF design maps the Java class interfaces to the underlyingSymbian OS communications models and provides core communicationsfunctionality for MIDlets including:• opening, closing, and disposing of connections• opening Java streams for appropriate types• a server connection pattern for types capable of receiving incomingconnections.Symbian’s Java ME implementation enables all the relevant MIDP 2.0GCF protocols and its framework is intended to be used by extensions thatprovide support for future protocols.
In particular, it supports push connections, using the SystemAMS dynamic and static resource managementfor managing the registered connections.Mobile MultimediaMobile Multimedia implements access to the multimedia support provided in the underlying Symbian OS, enabling MIDlets to play andrecord audio and video data from a wide range of inputs using aCOMPONENT COLLECTIONS311range of possible mechanisms, including streaming. The design follows aframework-plug-in architecture:• the framework provides the high-level interface to MIDP Multimediafunctionality• the reference DLL contains all dependencies on the underlying nativemultimedia services and can be customized.PIM and RMSPIM support is provided for accessing native Symbian OS contacts (i.e.phone book or address book) and agenda (i.e. calendar) entries, includingEvent and ToDo classes.Record Management System (RMS) support, which enables MIDlets tostore persistent data, is implemented over the native Symbian OS DBMSAPIs, using the DBMS in client–server mode and thus enabling databaselike functionality including transaction integrity and sharing betweenmultiple clients for Java applications.SecuritySystemAMS and the MIDP run-time are responsible for supporting theMIDP security model, through static (at installation time) and dynamic(at run time) checking of permissions, which provides for trusted anduntrusted MIDlets, and for protection based on security domains.Licensees implement specific security policies by customizing the MIDPsecurity plug-ins.12.6 Component CollectionsThe system model divides the Java ME block into a number of separatecollections (see Figure 12.5), broadly layered to reflect the conventionallayering of the Java ME software stack.The foundation is provided by the core Java class implementationsand the CLDC-HI VM, together with the low-level plug-ins that integratethe MIDP frameworks with Symbian OS.
The MIDP profile and packagescollections are layered over this foundation.MIDP 2.0 Profile CollectionThis collection (see Figure 12.6) implements the Java ME MIDP 2.0 Profile.• The MIDP MIDlet component implements the MIDlet lifecycle, whichdefines how MIDlets are started, paused and destroyed and how theyinteract with the host environment.312THE JAVA ME SUBSYSTEMMIDP 2.0 ProfileVirtualMachineMIDP 2.0 PackagesBluetooth &SMS PushLow LevelCLDC 1.1Java J2MEFigure 12.5Java ME BlockMIDP 2.0 ProfileMIDPLCDUIMIDPRMSMIDPMIDletMIDPDeviceControlMIDP IOSecurityPolicyMIDPGSMSecurity RPFigure 12.6 MIDP 2.0 Profile components• The LCDUI component is specifically designed with small LCDscreens in mind and provides compact, device-independent controls that can respond to user input ranging from keyboards to phonekeys to touch screens.
MIDP graphics APIs are implemented in termsof generic native controls which acquire platform-specific look andfeel through the UI Application Framework implementation, which iscustomized by the UI variant.• The RMS component provides MIDP persistence APIs. RMS is implemented internally over Symbian OS native DBMS, using the DBMS inclient–server mode.• The I/O component provides MIDP high-level input–output APIs,including networking support and HTTP connections.COMPONENT COLLECTIONS313Table 12.1 MIDP 2.0 Profile ComponentsComponent NameDevelopment NameMIDP MIDletMIDP2MIDP LCDUIJAVAX.MICROEDITION.LCDUIMIDP RMSJAVAX.MICROEDITION.RMSMIDP IOJAVAX.MICROEDITION.IOMIDP Device ControlMIDP2Security Policy ReferencePlug-inMIDP2SECURITYMIDP GSM SecurityRecommended PolicyMIDP2SECURITYRP• The Device Control component provides an interface for implementations of MIDP device control APIs, for example controlling devicevibration.• The Security Policy Reference Plug-in provides a reference implementation of Java security policy, implemented as a replaceableplug-in.• The GSM Security Recommended Policy component adds specificprotection domains to the security model (for example ‘manufacturer’,‘operator’, ‘third-party’ and ‘untrusted’).
Licensees should customizeand provide their own concrete implementation plug-in to be used bythe framework.MIDP 2.0 Packages CollectionThe Java ME MIDP 2.0 packages components (see Figure 12.7) extendthe MIDP 2.0 Profile implementation with additional APIs.MIDP 2.0 PackagesMobileMediaAPI1.1Mobile3D1.0JTWI1.0Figure 12.7MIDPFileGCFMIDPPIMBtooth.1.0MIDP 2.0 Packages componentsWMA1.1314THE JAVA ME SUBSYSTEMTable 12.2 MIDP 2.0 Packages ComponentsComponent NameDevelopment NameMobile Media API 1.1MMAPI11Mobile 3D 1.0M3GIOJTWI 1.0Java ME9.12MIDP File GCFGCFMIDP PIMMIDP2Bluetooth 1.0BLUETOOTHWMA 1.1WMA• The Mobile Media API 1.1 component comprises Mobile Media APIs(JSR-135).• The Mobile 3D 1.0 component comprises 3D-graphics APIs for scalable, small-footprint devices (JSR-184).• The JTWI component implements the JTWI specification, whichimproves the compatibility, interoperability and completeness of JavaME technology implementations in mobile phones by reducing APIfragmentation and raising the bar of functionality to specify a commonset of APIs and standards such as MIDP 2.0 and including optionalAPIs (WMA 1.1 and MMAPI 1.1).• The MIDP PIM and File GCF components support MIDP personalinformation-management (PIM) and file-connection APIs (JSR-075),enabling reading and writing of event, contact, and to-do items,and file system access.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
