1 / 37

MEG & VEG Architecture

MEG & VEG Architecture. Peter Kriens, CEO, aQute. Contents. Why a Mobile Specification? Overall Architecture Profile Deployment Device Management Application Model Foreign Applications Relation to JCP Road Ahead. Why a Mobile Specification?. MIDP is very successful for mobile devices

darice
Télécharger la présentation

MEG & VEG Architecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. MEG & VEG Architecture Peter Kriens, CEO, aQute

  2. Contents • Why a Mobile Specification? • Overall Architecture • Profile • Deployment • Device Management • Application Model • Foreign Applications • Relation to JCP • Road Ahead

  3. Why a Mobile Specification? • MIDP is very successful for mobile devices • Over 200 million devices sold • Multi billion dollar market • Highly Profitable • So who needs an OSGi handy?

  4. Why a Mobile Specification? • Mobile Devices are becoming very powerful • 200 Mhz+ Processors • Flash has become very cheap • End user street prices1 Gb $68, 128 Mb $13 • Displays become bigger and more useful • Networked • Wifi, GPRS, 3GT, UMTS • Are games the market for such powerful devices?

  5. Why a Mobile Specification? • The next generation of mobile devices brings Enterprise Applications into range • Sales Support, Expert Systems, Administrative, Data Acquisition, … • Enterprise Applications • Are exponentially more complex than games • Require high security for all facets • Require collaboration between different applications • Will connect to a myriad of devices • Require lots of middleware • Is MIDP up to this?

  6. Why a Mobile Specification? • Additionally there is a silent software crisis at device manufacturers • Operators require their devices to be heavily customized • Managing all these configurations is a tremendous task that negatively influences: • Product development cost • Technical support • Developing new features • Is MIDP really the solution here?

  7. Don’t think so …

  8. Over Architecture • What are the required features for a Mobile Software Platform? • Very High Security • Protects against viruses • Allows mixing and matching applications from different sources • Strong modularity support • Applications from different sources can coexist • Share libraries in a controlled way

  9. Why a Mobile Specification? • Collaboration Model • Smaller components: easier to develop • Mix and match: more flexible procurement • Plugin model widens the scope of devices • Remote Management • Maintain quality of service • After sales applications • Low maintenance cost • Management by Enterprises • Allow Enterprise to manage part of the device

  10. Overall Architecture Developers Enterprise Devices Operator

  11. Mobile Architecture Overview OSGi Service Platform DmtAdmin Monitor Admin EventAdmin Start Level Package Admin management server Services Download Agent Services Appl Container Foreign Applications Application Admin Deployment Log Config Admin Cond. Perm Admin

  12. What Was Missing In OSGi R3 • End-to-end Deployment • Device Management • Device Monitoring • Application Model • Foreign Application support • Security Policy Model based on mobile conditions • Subscriber (IMSI) • Device Type (IMEI)

  13. Security • Java 2 Permissions • Per Bundle Permissions • Each Bundle carries its own permissions • This set of permissions can never be exceeded • Bundle Signing is completely specified • Authentication of bundles • Permission Management via: • Signers • Location of origin • Custom condition • R4 Core Security is equipped to handle MEG Requirements

  14. Security • Provide a flexible policy management for a delegated management model • An Operator must be able to sell a device 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 device to a person and restrict the possibilities further • Bundles must be restricted to only the permissions they need Management domain Operator Enterprise Sales Bundle

  15. Security Layer • Signing based on Public Key Cryptography • Operator signs signing certificate of Deployer • Developer adds a local permissions file to the bundle • Easy to read • The local permissions are audited by the Deployer • Deployer signs the bundle • The bundle gets deployed on a Service Platform • The permissions of the bundle are the intersection of: • Local permissions • System permissions for that signer • Operator remains in full control at all times Developer Enterprise Bundle A local permissions signature Operator controls OSGi Service Platform S system permissions

  16. Security Layer • Permissions can be assigned based on: • Signer • Location (Channel) • Custom Condition • Multiple signers are possible • Bundle gets union of signer permissions • No partial signing, all signers must sign all content • Flexible management API for permissions • Dynamic • changes take effect immediately • Compatible with standard Java 2 VMs • Take advantage of optimizations Bundle A Location, signer, custom OSGi Service Platform local permissions & system permissions

  17. Security Layer • Signer requires coarse grained to be feasible • Bundle can use very fine grained • Standard Permissions • FilePermission • RuntimePermission • SocketPermission • … • Framework permissions • AdminPermission • ServicePermission • PackagePermission • BundlePermission • Service Permissions • ConfigurationPermission • EventPermission • ApplicationPermission Fine grained local permissions Coarse grained system permissions

  18. Deployment Admin • Deployment Admin • Adds new deployment artifact: Deployment Package (DP) • Groups bundles, resources and other artifacts Flexible Deployment format for • Bundles • Meglets • Configuration data • Custom types with Resource Processors • Signed • Tamper proof • Security

  19. Deployment Admin • Run custom code at installation, updated, and uninstallation • Database conversion • Installation scripts • Fix Packs, a delta format • Reduce download time • Deployment Packages are first class citizens • Extensive information is available to troubleshoot

  20. Deployment Admin Service • Deployment Admin provides the possibility to install and update Deployment Packages • Deployment Packages are • A set of bundles with associated Resource Processor • Transactional • No sharing with other Deployment Packages • Resource Processors provide the semantics for the bitsof the resources in the JAR file • Process (install) • Drop (uninstall) • Security based on the permissions associated with the signer of the Deployment Package DmtDataPlugin DeploymentAdmin Depl. Admin EventAdmin Resource Processor Autoconf Rrsrc. Proc.

  21. Deployment Admin Service • Deployment Package • Based on JAR Format • Manifest describes the resources and associates them with a Resource Processor • Fix Packages • Provide only updated contents Global section Name: bundle-A.jar SHA1-Digest: RTasy&yasi987iasj= Bundle-SymbolicName: com.acme.a Bundle-Version: 2.1 manifest.mf signer.sf Name: certificates.cr SHA1-Digest: lkMjUasm87asj&jasloe DP-ResourceProcessor: com.acme.c509 signer.rsa bundle-A.jar bundle-B.jar autoconf.xml certificates.cer Resource Processor Certificate Processor

  22. Deployment Admin Service • Customizers • A Deployment Package can contain its own Resource Processor bundle • This customizer is installed and started before other bundles in the Deployment Package • It registers a Resource Processor service • The Deployment Admin will only allow contents from the correct DP to be processed by the customizer • The customizer gets access to the private data area of its related bundles Customizer DP Depl. Admin bundle A

  23. Device Management • The basic OSGi architecture is management protocol agnostic • Provides a model where many parties can participate • What is missing is an abstraction to manage a device in detail • The OMA DM protocol is dominant in the mobile device market • Will be supported by a wide range of devices • The MEG therefore supports the OMA DM management model with the Dmt Admin Service

  24. Dmt Admin • Generic API to manipulate the Device Management Tree • Single consistent API for applications to interact with the configuration of the device • Seamless interaction with the management of the native device • Tree can be partly implemented in the native device, partly in Java . OSGi Device Battery cfg log Level query1 query2 Config Admin Log Native code

  25. Dmt Admin • Implementation of the tree nodes can be provided by downloadable services • Useful for extensions, accessories, options • Extensive Meta model • Provide rich GUIs with very little effort • Validation and this reliability • Transactional • Reliability • Partly implementation specific • API based on OMA DM • Supports other protocols

  26. Monitoring • Light weight solution for bundles to provide status variables to the management system • Free space, thread usage, database usage • Status Variables are mapped to the DMT • Provides unified access by the management system • A schedule can be created to query the variables at a regular interval • Debugging • Performance tuning • Optimizing Data Plugin Monitor Admin Monitor Admin Monitorable Any Bundle …

  27. Generic Application Model • A generic model that is intended to abstract different application models so they can be treated as one • Provides for third party screen managers • Provides for rich GUIs • Icons, help, etc. • Can monitor the state of running instances • Applications can be scheduled for execution when a specific event arrives • Calendar notification • Interacts with JSR 211 Content Handlers Screen Manager Application Model Symbian MIDP 1.0 MIDP 2.0

  28. Foreign Applications • MIDP, BREW, Symbian, DOJO, XLet, Applet, … • An OSGi Mobile Device is required to provide application containers for different application models. • The Application Model manages these applications • Some models use Java • Why not provide access to OSGi functionality • The Foreign Application Model defines how non-OSGi Applications can access and provide services • Header usage • Access to Framework class MIDP 2.0 MIDP 1.0 XLet org.osgi.application Framework

  29. VEG

  30. OSGi Vehicle Architecture • The OSGi Vehicle Profile shares its architecture with the Mobile Profile • The Vehicle Profile provides specific vehicle oriented services • The Vehicle Profile uses many more of the Core Compendium Services because it is more mature • It is likely the vertical profiles will come closer in the future

  31. Vehicle Profile • Start Level Service • URL Handlers • Package Admin Service • Permission Admin Service • Log Service • Http Service • Device Access • Configuration Admin Service • Metatype(2) Service • Preference Service • User Admin Service • Wire Admin Service • IO Connector Service • Declarative Services • Event Admin Service • Power Management Service • Diagnostic Service • Service Tracker Utility • XML Parser Utility • Position Utility • Measurement and State Utility

  32. Power Management • The power management service makes power management pluggable • The system power state can be set externally • Full Power • PM Active • Suspend • Sleep • Power off • is mapped to different device power state • D0-D3 power states • Power manager can take device specific capabilities in consideration • An observer bundle can follow the transitions in the system and device power state System Power System Power Observer System Power State Listener Device Power State Listener Power Manager Device Power State Device Power Impl

  33. And now for something completely different …

  34. Relation to JCP • The relation to the JCP is troublesome • Several JSRs overlap with JSR 232 • JSR 277 Modularization • However, long way off from J2ME • JSR 271 MIDP 3.0 • Is addressing some of the solutions that MEG provides • JSR 246 OMA DM Access • Based on JSR 232 Dmt Admin, but slightly different • Needs to be merged • JSR 249/248 MSA CDC/CLDC • Must select JSR 232 to make MEG viable JSR 277 Modules JSR 232 OSGi MEG JSR 271 MIDP 3.0 JSR 246 OMA DM JSR 248/249 MSA CDC/CLDC

  35. Conclusion • The Mobile and Vehicle Profiles are taking advantage of the powerful OSGi R4 Service Platform • The Mobile Platform focuses on deployment and device management • Applications will be foreign applications • Mobile APIs will be derived from JCP JSRs • The Vehicle Platform provides a more extensive application environment • Both platforms provide share more than they differ • The OSGi Service Platform provides therefore many opportunities for applications that can live in both markets.

More Related