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 2 years ago
aQute R4 MEG By Peter Kriens CEO aQute OSGi Technology Officer and OSGi Fellow
© aQute, All Rights Reserved slide #2 Preliminary Contents Charter Workstreams Context Device Management Montitoring Deployment Application Model Meglets Policy
© 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).
© aQute, All Rights Reserved slide #4 Preliminary Workstreams Device Management Deployment Application Policy Security
© aQute, All Rights Reserved slide #5 Preliminary Context Diagram
© 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!
© 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
© aQute, All Rights Reserved slide #8 Preliminary Device Management Class Diagram: Current
© 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
© 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
© 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
© 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
© 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
© 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
© 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
© 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?
© 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
© 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
© 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
© 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?
© 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
© 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
© 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
© 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
© 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
© 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
© 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
© 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 …
© 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
© 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?
© aQute, All Rights Reserved slide #31 Preliminary Application Containers
© 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
© 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
© 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
© 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
© 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
© 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
© 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
© 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
© aQute, All Rights Reserved slide #40 Preliminary aQute ,
© copyright 2005 by aQute SARL All rights reserved. OSGi Basic Architecture OSGi User Group France By Peter Kriens Technical Director OSGi.
AQute Inside OSGi By Peter Kriens CEO aQute OSGi Technology Officer and OSGi Fellow.
aQute Bundle Programming By Peter Kriens CEO aQute OSGi Director of Technology & OSGi Fellow.
AQute R4 By Peter Kriens CEO aQute OSGi Technology Officer and OSGi Fellow.
AQute Eclipse Environment By Peter Kriens CEO aQute OSGi Director of Technology and OSGi Fellow.
Silberschatz, Galvin and Gagne ©2013 Operating System Concepts – 9 th Edition Chapter 2: Operating-System Structures.
©2003 aQute, All Rights Reserved Tokyo, August 2003 : 1 OSGi Service Platform Tokyo August 28, 2003 Peter Kriens CEO aQute, OSGi Fellow
Chapter 2: Operating-System Structures. 2.2 Chapter 2: Operating-System Structures Operating System Services User Operating System Interface System Calls.
OSGi Component Programming By Peter Kriens, OSGi Evangelist.
1 Note content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004 M. E. Kabay. All rights reserved. Software Re-use IS301 – Software.
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition, Chapter 2: Operating-System Structures.
Copyright 2004 Bernd Brügge TUM Software Engineering WS TUM System Design II Bernd Brügge Technische Universität München Applied Software Engineering.
1 SYSTEM MODEL From Chapter 2 of Distributed Systems Concepts and Design,4 th Edition, By G. Coulouris, J. Dollimore and T. Kindberg Published by Addison.
1 GREY BOX TESTING Web Apps & Networking Session 3 Boris Grinberg
AQute Bundle Programming By Peter Kriens CEO aQute OSGi Technology Officer and OSGi Fellow.
MEG & VEG Architecture Peter Kriens, CEO, aQute Contents Why a Mobile Specification?Why a Mobile Specification? Overall ArchitectureOverall Architecture.
7- Sicurezza delle basi di dati. 2 Sommario 1 Database Security and Authorization 1.1 Introduction to Database Security Issues 1.2 Types of Security 1.3.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Chapter 10 Architectural Design.
Software Engineering Model Driven Architecture Software Engineering 2011 Department of Computer Science Ben-Gurion university Based on the book: MDA Explained:
Architectural Design IS301 – Software Engineering Lecture # 14 – M. E. Kabay, PhD, CISSP Dept of Computer Information Systems Norwich University.
1 Dr. Xiaohui Wei College of Computer Science and Technology, Jilin University, China CSF4 Tutorial The 3rd PRAGMA Institute, Penang Malaysia,
1 GREY BOX TESTING Web Apps & Networking Session 10 Boris Grinberg
1 Note content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004 M. E. Kabay. All rights reserved. Distributed Systems Architectures.
SharePoint Governance Questions January 2014 ©2014 SUSAN HANLEY LLC.
©Silberschatz, Korth and Sudarshan8.1Database System Concepts, 5 th Ed, slide version 5.0, August Chapter 8: Application Design and Development.
© 2016 SlidePlayer.com Inc. All rights reserved.