OSGi Users' Group France
OSGi Users' Group France
OSGi™ Users Group FranceRéunion du Vendredi 16 Octobre 2009La prochaine reunion du OUGF a eu lieu le Vendredi 16 octobre 2009 à Grenoble, Campus Universitaire, Amphi de la Maison Jean Kuntzmann, de 9H30 à 17H00. Accès ProgrammeSpecial issue on OSGi and isolation Les vidéos sont en ligne ICI.
Multi-tasking the Java(TM) virtual machine was pionnered by Sunlabs' barcelona Project as early as 2000 primarily as a way to address a number of performance issues (namely, startup, memory footprint and dynamic loading and compilation overhead) by exploiting the safety features of the Java programming language in order to provide strong but lightweight isolation. Lightweight isolation also provided a mean for platforms with minimal operating system support (i.e., without hardware-based protection) to elegantly and efficiently runs multiple applications, and to write application management systems entirely in the Java programming language. In this talk, I will first detail these issues and describe how the various Sunlabs prototypes addressed them. I will then contrast lightweight isolation via multi-tasking with other lightweight isolation mechanisms (primarily, class loader based isolation). I will also discuss the issues faced by an industrial-strength implementation of multi-tasking and the current limitation to the approach. I will conclude with a brief summary of similar efforts, both academic and industrial.
(  )
abstract soon
( and video soon)
When dealing with dynamic component environments such as the OSGi Service Platform, where components can come from different sources and may be known only during runtime, evaluating third party components trustworthiness at runtime is difficult. The traditional namespace based isolation and the security mechanisms provided in the Java platform (the base platform for OSGi) can restrict the access of such components but can not provide fault isolation. In this paper we present a dynamic component isolation approach for the OSGi platform, based on a recently standardized Java mechanism. When an untrusted component is activated during runtime, it is isolated in a fault contained environment but it can still collaborate with the application. If it is observed that the untrusted code does not bring any threat to the application, at runtime it can be dynamically promoted to the safe environment. Tests have been performed in a controlled environment where misbehaving components hosted in the sandbox were not able to disturb the main application.
( and video soon)
OSGi promises the make applications extensible at runtime, enabling a bunch of potential innovative use cases in diverses environments such as management of web servers, 'autotainment' embedded systems in cars, eHealth, etc. However, dynamicity breaks the classical security model of Java, first designed to sandbox one single application from its environment rather that isolating several applications. Risks implied by this evolution are identified, from deployment to execution, and appropriate solutions are presented. The require access isolation between the bundles through suitable access control models and proper coding, and should be assiciated with a strong resource isolation.
( )( and video soon)
The OSGi platform is increasingly being used inside complex middlewares. However, we reach a point where both the middleware and the hosted applications want to profit from OSGi features. Using one OSGi framework may lead to issues such as: (1) services used by the middleware not intended to be used in other contexts, (2) conflicts between libraries used by the middleware and the one used by the application, (3) conflicts between two applications willing to use "private" services. The OSGi R4.2 defines mechanisms to deal with such issue by allowing nested frameworks definition. A nested framework is a "complete” OSGi framework started by an OSGi bundle deployed in the hosting/parent framework. This presentation describes this RFC. It first introduces the problematic and the reasons to define nested frameworks. Then, it presents a language to define nested framework (Composites) and the relationship between children and parent frameworks (Surrogate bundle).
( and video soon)
The ROCS (Remote OSGi Caching Service) framework is a proposal which relies on a heavy-weighted standard Java/OSGi stack. It is distributed between class servers and ambient devices to provide full functionalities for resource constrained environments. The ROCS framework provides improvements in two areas. First, it de nes a minimal bootstrap environment that runs a standard Java/OSGi stack. Secondly, it provides an architecture to load the necessary missing classes from remote servers into memory at run-time.
( and video soon)
VESPA is an application developed for vehicles to share information about different types of events occurring on the roads (e.g., an emergency braking, an available parking space, a vehicle with a non-functioning brake light, etc.) using V2V communications. The objective is to facilitate the dissemination of information between vehicles when they encounter each other, taking into account the relevance of the data to the drivers. Moreover, relevance must also be considered to inform drivers only with events interesting for them. Because VESPA is designed to be embedded inside vehicles, it has to deal with a very mobile and dynamic environment. Software updates, communication, resource sharing or service deployment are subject to the specific constraints of the vehicular domain. This presentation gives an overview of the VESPA project. It also presents ongoing developments and the problems tackled in the VESPA project using OSGi.
( and video soon)
Quelqu'uns ont pu suivre les présentations à distance grace à 3 webinars DimDim (malgré quels plantages de la machine)
''N'hésitez pas a nous proposer des présentations (y compris pour les prochaines réunions) !" Annonces diverses
Assemblée générale de l'association OSGi™ Users Group France (16H00-16H30)
InscriptionInscription gratuite mais requise par simple envoi de mail à X.Y AT imag.fr (X=Didier Y=Donsez). Etaient présents
N'hésistez pas à nous signaler un oubli ! ContactsDidier Donsez, Stéphane Frénot, Nicolas Le Sommer : Photos, PhotosQui en a fait ? |
|
|
Home | Trademark Policy | Privacy Policy Copyright © 2010 OSGi™ Alliance. Comments about the site? Send them to: OSGi Alliance WebMaster. |
