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

aQuteR4 MEG

By Peter KriensCEO aQute

OSGi Technology Officer andOSGi Fellow

©1999-2004 aQute, All Rights Reserved slide #2

Preliminar

y

Contents

• Charter

• Workstreams

• Context

• Device Management

• Montitoring

• Deployment

• Application Model

• Meglets

• Policy


Preliminar

y

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).


Preliminar

y

Workstreams

• Device Management

• Deployment

• Application

• Policy

• Security


Preliminar

y

Context Diagram

Mobile Device

Bundle(s)

MEG Env.

OSGi FrameworkBundle(s)

MEG APIs

service(s)

MEG RemoteManager

Remote Adapter

User

UI

Bundle Man.

Lifecyclepackage(s)

Native RemoteManager

NativeEnvironment


Preliminar

y

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!

Config/Managementstate.

DevDevInfo

OSGi

bund-les

c m..

0 1com.acme

DeploymentManager

OSGiConfiguration

Admin

...

com.acmebundle

CONF

DMT Admin

DMT-EXEC

DMT-DATA

Bat-tery

Level

Config/ManStateHandler

Cycles

DMT-EXEC/DMT-DATA

DevId

NativeRemoteManager

optionalmeta data

NativeEnvironment

ma

p

ma

p

ma

p ma

p

MEGRemoteManager


Preliminar

y

Device Management: Service View

DMT

DeployAdmin

ExecPlugin

DataPlugin

ConfigAdmin

PolicyAdminMonitorNative

State

DMTFactory

LogService

MIDPContain.

Appl.Manager• The DMT registers a

DMTFactory

• Through the factory it is possible to create a DMTSession

• The session allows transactional access to the tree


Preliminar

y

Device Management Class Diagram: Current

«interface»DmtFactory

«interface»DmtSession

«interface»Dmt

«interface»DmtPrincipal

«interface»DmtData

«interface»DmtMetaNode

«interface»DmtDataPlugIn

«interface»DmtExecPlugIn

«interface»DmtDataType

«interface»DmtEvent

«interface»DmtAcl


Preliminar

y

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

Node B

Node C

ACL: subject=Get

ACL: subject=Replace

Only subject hasAccess to the replaceoperation


Preliminar

y

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

Monitor

Monitorable

MonitorAdmin

Appl

DataPlugin

IF_EVT


Preliminar

y

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

DeployAdmin

DeploymentAdmin

ExecPlugin

IF_EVT

DataCustomization


Preliminar

y

Bundle Suite

• 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

Manifest (BAD)

Bundle A

Bundle B

Bundle C

Manifest

Manifest

Manifest


Preliminar

y

Extender Model

• 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

Summary: GNU indent Name: indent Version: 2.2.6 Release: 1 Source0: %{name}-%{version}.tar.gz License: GPL Group: Development/Tools %description The GNU indent program reformats C code to any of a variety of formatting standards, or you can define your own. %prep %setup -q %build ./configure make %install make install %files %defattr(-,root,root) /usr/local/bin/indent %doc /usr/local/info/indent.info %doc %attr(0444,root,root) /usr/local/man/man1/indent.1 %doc COPYING AUTHORS README NEWS

Sample RPM script


Preliminar

y

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!

Editor Installer

WindowsRegistry

C:\Editor.exe

Desktop Db:c:Editor.exe

copy regedit

[HKEY_CLASSES_ROOT\.txt]@="txtfile""PerceivedType"="text""Content Type"="text/plain"[HKEY_CLASSES_ROOT\.txt\OpenWithList][HKEY_CLASSES_ROOT\.txt\OpenWithList\devenv.exe]…

Editor.exe

APPL=EDITFILE=TXT Maintained by OS

From file

PC versus Mac


Preliminar

y

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

META-INF/Manifest

org/acme/foo/Bar.class

org/acme/foo/Bar$1.class

org/acme/foo/Foo.class

META-INF/permission.perm

PermissionAdmin

BundleBar

Synchronous Bundle Listener

Install

Security Context


Preliminar

y

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?


Preliminar

y

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

BarCustomizer

BundleBar

DeploymentAdmin

Bundle Suite

Install Bar

Install Bar Customizer

DataCustomization

Initializa/Prepare/Deinitialize


Preliminar

y

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


Preliminar

y

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


Preliminar

y

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?


Preliminar

y

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

ApplicationProgrammer

Application Model

Bundle API

SystemProgrammer


Preliminar

y

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

Generic Model

MIDP DOJA Meglets

ScreenManager

Containers


Preliminar

y

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

ApplicationManager

ExecPlugin

EventManagerApplicationContainer

ApplicationDescriptor

ApplicationHandle

MegletContainer

MIDP.Container

Appl.Manager


Preliminar

y

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


Preliminar

y

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


Preliminar

y

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

META-INF/Manifest

org/acme/foo/Bar.class

org/acme/foo/Bar$1.class

org/acme/foo/MyMeglet.class

META-INF/meglet

Install

MegletBundle

MegletContainer

ApplicationDescriptor

Register

Launch

Installed

Get configurationdata

Create new instance

ApplicationHandle

Register

stopApplication


Preliminar

y

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

App 1 App 2

MegletContext

MegletContainer


Preliminar

y

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 …


Preliminar

y

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


Preliminar

y

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?


Preliminar

y

Application Containers


Preliminar

y

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

EventManager

EventManager

EventListener


Preliminar

y

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

EventManager

App 1

EventListener

App2

Post event

Handle event

Event


Preliminar

y

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


Preliminar

y

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

Operator

ACME

Sales

Management domain


Preliminar

y

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


Preliminar

y

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

Policy

JVM

Framework

checkPermission

impliesMissingPermissionListener


Preliminar

y

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

ACL check

Tree Access

Java 2 Check

Semanticinterface


Preliminar

y

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


Preliminar

y

aQute

www.aQute.biz

+15126929173, [email protected]

z

Documents

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