R4 MEG

1. R4 MEG By Peter Kriens CEO aQute OSGi Technology Officer and OSGi Fellow

2. Contents • Charter • Workstreams • Context • Device Management • Montitoring • Deployment • Application Model • Meglets • Policy

3. Mobile Expert Group • Initiated by Motorola and Nokia • Charter: The OSGi Mobile Expert Group (MEG) is chartered to define the requirements and specifications to tailor and extend the OSGi Service Platform for mobile devices that are data-capable, and also capable of connecting to wireless networks. Examples of such devices include, but are not limited to, digital mobile phones, smartphones, Personal Digital Assistants (PDAs), etc. Development of the specifications and APIs entails the creation of supporting documentation, reference implementations and compatibility test suites. Technical areas addressed by the MEG will include the requirements, functional specifications, data formats, and communication protocols for the mobile Service Platform as well as defining new requirements for the base service platform. The MEG, through its members, may also cooperate with other specification bodies in the creation of data formats and communication protocols. The MEG will work closely with and cooperate with the Core Platform Expert Group (CPEG) to ensure the specifications and Application Programming Interface (API) are consistent with the overall OSGi Service Platform architecture. The MEG will take direction from the OSGi Chief Technical Officer (CTO) and the Technical Steering Committee (TSC).

4. Workstreams • Device Management • Deployment • Application • Policy • Security

5. Context Diagram

6. Device Management • Device Management is based on OMA DM (SyncML) • An abstract device tree is mapped to plugins • ./dev/battery maps to some register in the hardware • Both the DMT itself as well as the plugins are OSGi services • DMT can be implemented partly native/partly java • Access to the tree is protected by ACLs • The Framework does not always have to be running!

7. Device Management: Service View Appl. Manager Deploy Admin MIDP Contain. • The DMT registers a DMTFactory • Through the factory it is possible to create a DMTSession • The session allows transactional access to the tree ExecPlugin DMTFactory DMT DataPlugin Native State Monitor Policy Admin Config Admin Log Service

8. Device Management Class Diagram: Current

9. ACLs • The security model of OMA DM is based on Access Control Lists • An ACL allows a subject (management system) actions on a node • ACLs are inherited from ancestor nodes • Each node contains all ACL information, difficult to manage per subject/operation • A higher node can easily invalidate access from another subject to all lower nodes Node A ACL: subject=Get Node B ACL: subject=Replace Node C Only subject has Access to the replace operation

10. Monitoring • The Monitor can create jobs that regularly update the management system with Key Performance Indicators (KPIs) • Bundles that have KPIs can register them in the registry • The data is directly mapped to the DMT via the data plugin interface DataPlugin MonitorAdmin Monitor IF_EVT Monitorable Appl

11. Deployment • Deployment concerns itself with • Bundle Suite • JAD like file • Dependency Management • Initialization/Configuration • The Deploy Admin acts as the traditional OSGi Management Agent • Introduces a format that can handle multiple bundles in a single jar • Dependency management will analyze current configurations and manage the state of the existing bundles and install bundles if needed ExecPlugin DeploymentAdmin Deploy Admin IF_EVT DataCustomization

12. Bundle Suite Manifest (BAD) • A Bundle Suite contains multiple, independent bundles • The manifest contains cached information of the contained bundles so decisions can be taken without unpacking each bundle • The dependency information can be used to decide which bundles need to be installed from the suite • Bundle-SymbolicName • Require-Bundle • A Bundle Suite is not an entity on the system, it is purely a set of bundles • Makes no difference if bundles are installed via a suite or independently Bundle A Manifest Bundle B Manifest Bundle C Manifest

13. Traditional installation models use scripts to install configuration parameters in the necessary subsystems For example Testing if the dependencies are fulfilled Setup an SQL database and tables in MySQL Place the executables and files in an appropriate place Link the documentation and servlets to an Apache web server Link to the commands from the application from the appropriate bin directory Setup the permissions Uninstallation “attempts” to remove the changes Extender Model Sample RPM script

14. Extender Model • Scripts are error prone because they must make a lot of assumptions about the environment • Another issue is that uninstallation is hard to do right • Many files without owner on a PC due to failed installation scripts • Likely some applications that are uninstalled are unstable, bad to rely on the • The direction is wrong, the subsystems should get the information from the bundle! PC versus Mac

15. META-INF/Manifest META-INF/permission.perm org/acme/foo/Foo.class org/acme/foo/Bar.class org/acme/foo/Bar$1.class Install Synchronous Bundle Listener Security Context Extender Model • Subsystems listen to install and uninstall of applications • At install, they read configuration data from the bundle’s JAR file • R4 has support for introspecting the JAR file without creating a class loader • At uninstall, they clean up any data they have about the uninstalled bundle Bundle Bar Permission Admin

16. Initialization Service • The need for initialization scripts is not completely gone according to MEG • Extenders have • No Access to the private bundle area • Security issues, extenders run in their own security context • This might actually be an advantage as well • Where, when and how should these scripts be run?

17. Bundle Suite Install Bar Install Bar Customizer Initializa/Prepare/Deinitialize Initialization Service • The Deployment Admin will be aware of the life cycle of all bundles as management agent • It will therefore be able to signal bundles that can perform initialization • MEG therefore proposes a DataCustomization service • Special bundles can perform necessary initialization • INSTALLED, WILL_UPDATE, UPDATE, WILL_UNINSTALL, UNINSTALLED • The interface supports a transactional model Deployment Admin DataCustomization Bundle Bar Bar Customizer

18. Current Issues • The DataCustomization interface has (also) no access to the bundle’s private data area • Security issues must be handled at the bundle level. • The customization bundle must have appropriate permissions • The Deployment Admin must be aware of the relation between the customizer and the target

19. JAD File • A JAD file is interesting because it is small and can be downloaded fast • The user can then decide to download the whole application • There are discussions to add a similar file to the MEG

20. Small Planned Changes • AutoClean header • Bundles with this header will be removed when there are no more dependencies to it • Post-DeployState (Eclipse’s AutoStart) • If the bundle is deployed, should it be started?

21. Application Programmer System Programmer Application Model • The Bundle programming model is • Powerful • Difficult for normal programmers due to dynamics and flexibility • “Always runs” • A simpler model is needed for application programmers • Convenience API to make code smaller and simpler. • Remove some of the dynamics • Also, MEG wants a more traditional “launch” model • Compatibility with DOJA, MIDP, and GUIs Application Model Bundle API

22. Containers Generic Versus Convenience Model • There are actually two application models • The first is a generic model that is intended to abstract different application models so they can be treated as one • Screen Manager • The second is a convenience model for the Application Programmer ScreenManager Generic Model MIDP DOJA Meglets

23. Generic Application Model • The APIs must be fully compatible • Applications are contained in a bundle and fully act • The service registry is used to contain descriptors that describe an application • The application manager or screen manager listens to the registrations and unregistrations Application Descriptor Application Manager Meglet Container Application Container EventManager Appl. Manager MIDP. Container ApplicationHandle ExecPlugin

24. Generic Application Model • Launching an application is done via the descriptor • Descriptors can be obtained via the Application Manager or via the registry (issue) • A Screen Manager can obtain all relevant information from the descriptor • Icons • Names • Priority • The container (issue) will then create an ApplicationHandle that is also registered • This represents a running application • The ApplicationHandle can be used stop or pause/resume the running application • It should be possible to map these operations to other application models like MIDP

25. Generics • There is an Application Context that contains parameters and that may contain • User ID • Terminal ID • Other context information • The Application Container service allows deployment managers to install different types of applications

26. META-INF/Manifest META-INF/meglet org/acme/foo/MyMeglet.class Get configuration data org/acme/foo/Bar.class org/acme/foo/Bar$1.class Installed Install Register Launch Create new instance Register stopApplication Meglets • (Very Preliminary and Meglet is working name) • A Meglet Container listens to the installation of Meglets in bundles • Meglets are declared in a file in the bundle (Extender model) • The Meglet Container registers an Application Descriptor for each Meglet Application Descriptor Meglet Bundle Meglet Container Application Handle

27. Meglets • When the Meglet is launched, the Meglet Container will create a class from the bundle that contains the Meglet • The Meglet will be a base class that takes a MegletContext as parameter • The MegletContext is implemented in the Meglet Container • The methods of the MegletContext are implemented on the Meglet class as well for convenience Meglet Meglet Context App 1 App 2 Meglet Container

28. Meglet API • Lifecycle methods • Start/stop/pause/resume • Convenience Access to registry (must handle created dependencies) • Locate service • Convenience access to event manager • Post events • Subscribe to events • Handle events • And what further comes to mind …

29. Meglets • Meglets will not run unless their pre-conditions are fullfilled • Required services are present • Package Import/Export • Required Bundles • The requirements of Meglets are very similar (if not identical) to declarative services

30. Meglets and Declarative Services • Unfortunately, neither the ApplicationDescriptor, nor the ApplicationHandle is eligible • The ApplicationDescriptor could be a declarative service for Meglets but it would introduce an unnecessary indirection, complicating the picture for programmers • For other application models, this would not be possible because the manipulation is done by the container • The ApplicationHandle cannot be used because an application can be launched many times and a declarative service only once • Do we have to revisit declarative services? Align the APIs?

31. Application Containers

32. Event Manager Service • The Event Manager is a simple publish and subscribe model • Events are posted through the Event Manager service, either synchronous or asynchronous • Events are identified by a string • Event delivery is protected by an EventPermission Event Listener Event Manager Event Manager

33. Event Manager Service • Event Listeners are registered in the registry with a list of matching prefixes • All matching listeners are notified • Events may be prioritized, which means they may jump the queue Event Event Manager Event Listener Handle event Post event App 1 App2

34. Event Manager Issues • There is a proposal allow event listeners to cancel further deliveries of the event • This will introduce an ordering in Event Listeners and can introduce unreliability • The string based typing could maybe be changed to filter based typing • Mapping of framework events • Translating service events to a type of <service name>.<operation> looks like it makes the event model highly interoperable without much effort

35. Policy • Provide a flexible policy management for a delegated management model • An Operator must be able to sell a phone to an Enterprise and be assured the enterprise can not do anything the operator does not want • The Enterprise administrator must be able to give the phone to a person and restrict the possibilities further Management domain Operator ACME Sales

36. Policy • Policies are statements like • ACME may install bundles signed by ACME or Operator • Al Bundle may install bundles over low cost connections and when signed by ACME

37. Conditional Permissions • MEG needs permissions that are dependent on conditions • Java 2 does not provide a mechanism for this • OSGi R4 will add a MissingPermissionListener • This will allow the Policy to extend the basic security behavior • However, missing permissions must fall within the permissions given by the signature but that are not in the bundle permission file • MEG will use this to implement conditional permissions and confirmed permissions client server checkPermission JVM Missing Permission Listener implies Policy Framework

38. ACL check Tree Access Java 2 Check Semantic interface ACLs versus Permissions • Access to the DMT is protected by ACLs • ACLs are a simple protection mechanism • The semantics of the ACL depend on the tree • Complex policies make the DMT unwieldy • There is also access to the functionality via the semantic interface • Final operation is always checked by Java 2 permissions Management System Impl. Bundle JVM OSGi

39. ACLs versus Permissions • ACL will be used as first line defense against external attacks • All fine grained checks are done by Java 2 • There is a DMTPermission planned so the permission check can be done in Java 2 • This might be used from the management system

40. aQute www.aQute.biz +15126929173, Peter.Kriens@aQute.biz