aqute r4 meg by peter kriens ceo aqute osgi technology officer and osgi fellow
TRANSCRIPT
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
©1999-2004 aQute, All Rights Reserved slide #3
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).
©1999-2004 aQute, All Rights Reserved slide #4
Preliminar
y
Workstreams
• Device Management
• Deployment
• Application
• Policy
• Security
©1999-2004 aQute, All Rights Reserved slide #5
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
©1999-2004 aQute, All Rights Reserved slide #6
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
©1999-2004 aQute, All Rights Reserved slide #7
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
©1999-2004 aQute, All Rights Reserved slide #8
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
©1999-2004 aQute, All Rights Reserved slide #9
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
©1999-2004 aQute, All Rights Reserved slide #10
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
©1999-2004 aQute, All Rights Reserved slide #11
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
©1999-2004 aQute, All Rights Reserved slide #12
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
©1999-2004 aQute, All Rights Reserved slide #13
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
©1999-2004 aQute, All Rights Reserved slide #14
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
©1999-2004 aQute, All Rights Reserved slide #15
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
©1999-2004 aQute, All Rights Reserved slide #16
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?
©1999-2004 aQute, All Rights Reserved slide #17
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
©1999-2004 aQute, All Rights Reserved slide #18
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
©1999-2004 aQute, All Rights Reserved slide #19
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
©1999-2004 aQute, All Rights Reserved slide #20
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?
©1999-2004 aQute, All Rights Reserved slide #21
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
©1999-2004 aQute, All Rights Reserved slide #22
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
©1999-2004 aQute, All Rights Reserved slide #23
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
©1999-2004 aQute, All Rights Reserved slide #24
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
©1999-2004 aQute, All Rights Reserved slide #25
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
©1999-2004 aQute, All Rights Reserved slide #26
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
©1999-2004 aQute, All Rights Reserved slide #27
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
©1999-2004 aQute, All Rights Reserved slide #28
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 …
©1999-2004 aQute, All Rights Reserved slide #29
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
©1999-2004 aQute, All Rights Reserved slide #30
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?
©1999-2004 aQute, All Rights Reserved slide #31
Preliminar
y
Application Containers
©1999-2004 aQute, All Rights Reserved slide #32
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
©1999-2004 aQute, All Rights Reserved slide #33
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
©1999-2004 aQute, All Rights Reserved slide #34
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
©1999-2004 aQute, All Rights Reserved slide #35
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
©1999-2004 aQute, All Rights Reserved slide #36
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
©1999-2004 aQute, All Rights Reserved slide #37
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
©1999-2004 aQute, All Rights Reserved slide #38
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
©1999-2004 aQute, All Rights Reserved slide #39
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
©1999-2004 aQute, All Rights Reserved slide #40
Preliminar
y
aQute
www.aQute.biz
+15126929173, [email protected]
z