We think you have liked this presentation. If you wish to download it, please recommend it to your friends in any social system. Share buttons are a little bit lower. Thank you!
Presentation is loading. Please wait.
Published byDavid McKnight
Modified over 4 years ago
aQute R4 MEG By Peter Kriens CEO aQute OSGi Technology Officer and OSGi Fellow
©1999-2004 aQute, All Rights Reserved slide #2 Preliminary Contents Charter Workstreams Context Device Management Montitoring Deployment Application Model Meglets Policy
©1999-2004 aQute, All Rights Reserved slide #3 Preliminary 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 Preliminary Workstreams Device Management Deployment Application Policy Security
©1999-2004 aQute, All Rights Reserved slide #5 Preliminary Context Diagram
©1999-2004 aQute, All Rights Reserved slide #6 Preliminary 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!
©1999-2004 aQute, All Rights Reserved slide #7 Preliminary Device Management: Service View DMT Deploy Admin ExecPlugin DataPlugin Config Admin Policy Admin Monitor Native State DMTFactory Log Service MIDP Contain. 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 Preliminary Device Management Class Diagram: Current
©1999-2004 aQute, All Rights Reserved slide #9 Preliminary 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 has Access to the replace operation
©1999-2004 aQute, All Rights Reserved slide #10 Preliminary 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 Preliminary 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 Deploy Admin DeploymentAdmin ExecPlugin IF_EVT DataCustomization
©1999-2004 aQute, All Rights Reserved slide #12 Preliminary 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
©1999-2004 aQute, All Rights Reserved slide #13 Preliminary 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 Sample RPM script
©1999-2004 aQute, All Rights Reserved slide #14 Preliminary 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
©1999-2004 aQute, All Rights Reserved slide #15 Preliminary Extender Model Subsystems listen to install and uninstall of applications At install, they read configuration data from the bundles 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 Permission Admin Bundle Bar Synchronous Bundle Listener Install Security Context
©1999-2004 aQute, All Rights Reserved slide #16 Preliminary 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 Preliminary 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 Bar Customizer Bundle Bar Deployment Admin Bundle Suite Install Bar Customizer DataCustomization Initializa/Prepare/Deinitialize
©1999-2004 aQute, All Rights Reserved slide #18 Preliminary Current Issues The DataCustomization interface has (also) no access to the bundles 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 Preliminary 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 Preliminary Small Planned Changes AutoClean header –Bundles with this header will be removed when there are no more dependencies to it Post-DeployState (Eclipses AutoStart) –If the bundle is deployed, should it be started?
©1999-2004 aQute, All Rights Reserved slide #21 Preliminary 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 Programmer Application Model Bundle API System Programmer
©1999-2004 aQute, All Rights Reserved slide #22 Preliminary 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 MIDPDOJAMeglets ScreenManager Containers
©1999-2004 aQute, All Rights Reserved slide #23 Preliminary 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 Manager ExecPlugin EventManager Application Container Application Descriptor ApplicationHandle Meglet Container MIDP. Container Appl. Manager
©1999-2004 aQute, All Rights Reserved slide #24 Preliminary 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 Preliminary 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 Preliminary 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 Meglet Bundle Meglet Container Application Descriptor Register Launch Installed Get configuration data Create new instance Application Handle Register stopApplication
©1999-2004 aQute, All Rights Reserved slide #27 Preliminary 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 1App 2 Meglet Context Meglet Container
©1999-2004 aQute, All Rights Reserved slide #28 Preliminary 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 Preliminary 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 Preliminary 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 Preliminary Application Containers
©1999-2004 aQute, All Rights Reserved slide #32 Preliminary 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 Manager Event Manager Event Listener
©1999-2004 aQute, All Rights Reserved slide #33 Preliminary 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 Manager App 1 Event Listener App2 Post event Handle event Event
©1999-2004 aQute, All Rights Reserved slide #34 Preliminary 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. looks like it makes the event model highly interoperable without much effort
©1999-2004 aQute, All Rights Reserved slide #35 Preliminary 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 Preliminary 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 Preliminary 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 implies Missing Permission Listener
©1999-2004 aQute, All Rights Reserved slide #38 Preliminary 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 checkTree AccessJava 2 Check Semantic interface
©1999-2004 aQute, All Rights Reserved slide #39 Preliminary 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 Preliminary aQute www.aQute.biz +15126929173, Peter.Kriens@aQute.biz
Using the SQL Access Advisor
FedEx Ship Manager® at fedex.com Shipping Administration
Shared-Memory Model and Threads Intel Software College Introduction to Parallel Programming – Part 2.
1 Copyright © 2002 Pearson Education, Inc.. 2 Chapter 2 Getting Started.
Distributed Systems Architectures
Copyright © 2003 Pearson Education, Inc. Slide 1 Computer Systems Organization & Architecture Chapters 8-12 John D. Carpinelli.
1 Copyright © 2013 Elsevier Inc. All rights reserved. Chapter 1 Embedded Computing.
Copyright © 2011, Elsevier Inc. All rights reserved. Chapter 6 Author: Julia Richards and R. Scott Hawley.
Author: Julia Richards and R. Scott Hawley
1 Copyright © 2013 Elsevier Inc. All rights reserved. Chapter 3 CPUs.
Properties Use, share, or modify this drill on mathematic properties. There is too much material for a single class, so you’ll have to select for your.
RXQ Customer Enrollment Using a Registration Agent (RA) Process Flow Diagram (Move-In) Customer Supplier Customer authorizes Enrollment ( )
Document #07-2I RXQ Customer Enrollment Using a Registration Agent (RA) Process Flow Diagram (Move-In) (mod 7/25 & clean-up 8/20) Customer Supplier.
1 Hyades Command Routing Message flow and data translation.
1 Introducing the Specifications of the Metro Ethernet Forum MEF 19 Abstract Test Suite for UNI Type 1 February 2008.
When Applications can Roam Freely OSGi Service Platform R4 Peter Kriens Technical Director OSGi
A Media Subscription Service By Peter Kriens CEO aQute OSGi Technology Officer
©2003 aQute, All Rights Reserved Tokyo, August 2003 : 1 OSGi Service Platform Tokyo August 28, 2003 Peter Kriens CEO aQute, OSGi Fellow
© OSGi, All Rights Reserved - Brussel Jan 22 Ertico/OSGi Tech Spec Overview: Introduction OSGi R3 and Remote Management Ertico/OSGi meeting Jan.
© copyright 2005 by aQute SARL All rights reserved. OSGi Basic Architecture OSGi User Group France By Peter Kriens Technical Director OSGi.
© 2018 SlidePlayer.com Inc. All rights reserved.