Apache felix
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 70 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/39503 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FOSDEM 200960 / 70
3
4
6
16
17
18
19
20
21
22
23
24
25
26
27
29
30
31
32
33
35
40
41
44
46
47
48
50
51
54
55
57
58
59
60
62
65
67
68
69
70
00:00
Discrete element methodBoom (sailing)ImplementationBitCrash (computing)Connectivity (graph theory)Physical systemContext awarenessXMLComputer animationLecture/Conference
00:35
Crash (computing)Module (mathematics)Physical systemAerodynamicsContext awarenessPhysical systemBitSpring (hydrology)Gateway (telecommunications)Multiplication sign1 (number)Modulare ProgrammierungServer (computing)Connectivity (graph theory)ImplementationCartesian coordinate systemSpacetimeSoftware frameworkWebsiteStandard deviationDynamical systemProcess (computing)Centralizer and normalizerSystem administratorOrder (biology)Basis <Mathematik>Open sourceJava appletDifferent (Kate Ryan album)Service (economics)Installation artSocial classGoodness of fitComputer animationLecture/Conference
02:52
Integrated development environmentModule (mathematics)Execution unitFiber bundleProfil (magazine)SubsetDifferent (Kate Ryan album)Computer fileBitGreatest elementSoftware frameworkPhysical systemProcess (computing)Service (economics)Machine codeLatent heatCore dumpJava appletComputer animation
03:54
Module (mathematics)Revision controlInterface (computing)Service (economics)Rule of inferenceServer (computing)Repository (publishing)Data managementInterface (computing)Module (mathematics)Physical systemComputer fileFiber bundleConnectivity (graph theory)MetadataRevision controlPoint (geometry)Service (economics)CodeMultiplication signBitSoftware frameworkWindows RegistryLatent heatTelecommunicationExecution unitJava appletImplementationSocial classLoop (music)Data managementDifferent (Kate Ryan album)Normal (geometry)SoftwareRepository (publishing)TrailBootingMechanism designServer (computing)Rollback (data management)Video gameCycle (graph theory)Type theoryMetreProcess (computing)SurfaceSign (mathematics)Online helpComputer animation
08:12
Data managementMereologyFiber bundleCoprocessorComputer programmingProcess (computing)Type theoryDatabase transactionStudent's t-testForm (programming)Moving averagePhysical systemConfiguration spaceMultiplication signBitForcing (mathematics)Musical ensembleDifferent (Kate Ryan album)Open sourceStreaming mediaMechanism designRevision controlCoprocessorSoftware frameworkFiber bundleCASE <Informatik>Connectivity (graph theory)Local ringElectronic signatureWeb pageMedical imagingDenial-of-service attackQuicksortExtension (kinesiology)Online helpLatent heatFreewareSystem administratorFile formatService (economics)Set (mathematics)Integrated development environmentCrash (computing)Computer filePhase transitionRollback (data management)State of matterComputer animation
12:35
Metropolitan area networkSubject indexingBitPlanningDatabase transactionLaptopPhysical systemGroup actionSocial class2 (number)Connectivity (graph theory)Inclusion mapRevision controlMechanism designStudent's t-testSoftware developerDifferent (Kate Ryan album)Process (computing)Run time (program lifecycle phase)Virtual machineSoftware frameworkGlassFishPhysical lawExpert systemImage resolutionJava appletModulare ProgrammierungCoprocessorDemo (music)Goodness of fitComputer animation
15:29
XML
Transcript: English(auto-generated)
00:07
First of all Apache Felix is an OSGI implementation and I'd like to know who is actually familiar or heard of OSGI just to get a little bit of a feeling.
00:20
Okay, quite nice. Who has actually been using Eclipse at some point? That's even more nice. So a lot of you have a little bit of experience at least using OSGI. But I'll start out with a quick crash course of what OSGI is just to give you a little bit of context about dynamic deployment. And after that I'll
00:45
talk about both deployment admin and resource processes which are the main components of a dynamic deployment system in OSGI. So just to start out a last century, 1999, to see the birth of OSGI when a couple of
01:04
companies actually came together to think about a solution for home gateways. They were envisioning this home gateway being the central hub in everybody's home, controlling your fridge, controlling the lights and everything. And in order for that idea to work there had to be some kind of
01:25
managed framework where different parties could install and upgrade components without actually having to restart the whole system every time you do install something new or update something. Actually that idea never became a big commercial success but the framework that was developed for that
01:45
actually turned out to be useful for lots of other things. So even though the home gateway wasn't a big success, people found out other things to do with it both in the embedded space but also on the desktop and even
02:00
on the servers. I mean you have Eclipse using it as their plug-in system and nowadays you even have things like the Spring framework and Glassfish using it as the basis for the application servers. So nowadays if you look at the OSGI website it's just explained as the dynamic module system
02:22
for Java. Apache Felix is actually one of a couple of open source implementations. There are other ones out there which is a good thing for any standard to have a little bit of competition. And well actually the nice thing about OSGI is that really as soon as you start using it the
02:43
framework itself, the implementation is not that relevant anymore. You develop your components and they'll run on any implementation. So if you look at the OSGI specification there's two big books. The first is about the core specification which explains all about the framework itself and there's the
03:05
second book that's the service compendium and we'll look into that a little bit more as we get to dynamic deployment. But first I want to go quickly through the framework and the different layers of the framework and we'll start at the bottom at the execution environment. This actually
03:24
defines a couple of profiles. Some of you might have been doing Java embedded or Java on the mobile phone where you have these different profiles which basically define which subset of APIs are available. Well this is actually the same thing so you can have a very constrained profile that will
03:43
run on an embedded device or full-blown Java 6 desktop profile if you run on a system that supports that. And on top of that there's actually the module layer which is the first layer of the system and the module or bundle
04:00
as it's called in OSGI is basically the unit of deployment. Each bundle is just a jar file. It can contain Java packages, native code, other resources and the only difference between a bundle and a normal jar file is that there's some extra metadata in the manifest. This metadata actually allows you to
04:25
only share packages that you want to share. So for example you don't want to share an implementation, only your interfaces and you can simply say well I want to share or export this package and you can do the other way around to say I want to import this package from some other bundle and the framework
04:44
will then take care of the actual wiring. Nice thing of that is that you can also export specific versions of a package. So it's actually possible to have two different versions of a package run side by side in the same
05:01
Java VM without the classes interfering with each other which is a system that you cannot easily do without OSGI then you have to manually start messing with class loaders and that's tricky. So on top of this module layer there's a lifecycle layer and every bundle every component
05:20
has its own lifecycle. That starts with installation, you can install a bundle then it gets resolved, the imports and exports get wired and then you can actually start and stop a bundle and start and stop are actually two hooks that you have for starting your own code and stopping it again. At any
05:43
point in this lifecycle you can also update a bundle that means the current copy is stopped, a new copy is installed and is run without actually affecting the rest of the bundles in the system. So there's actually a nice
06:02
way to communicate, to do communication between bundles and that's through what we call the service layer. There's a service registry and each bundle can publish services there and can do lookups and since this registry is highly dynamic it's a little bit tricky sometimes because you actually
06:22
have to keep track of what services are there if they're still available they can go away at any time so that makes it a little bit harder to use but it's a very nice and decoupled way for components to interact with each other. They only look up the service interface, they don't care about who
06:42
actually implements it so you can actually exchange implementations without the rest of the framework knowing it. So that's basically the OSGI framework itself. Now onto deployment. If you look at the specification and what it describes about deployment it actually only specifies a couple of
07:06
very generic roles. It says well you have this management agent which is just a bundle that you install into your framework and it is responsible for installing and updating components. It talks over the network to some
07:20
provisioning server which has some component repository where you can get new stuff from and that's basically all that was defined about how to do deployment and how to provision components to a system. Actually that was the situation until the last version of the specification 4.1.
07:42
There were actually some new services were introduced that actually give you a little bit more help on how to do this because most people up to now are just installing individual bundles so when you would do an update you would just in a loop get all the new bundles install them and if something
08:03
fails well maybe you have some rollback mechanism maybe not was just praying that everything kept working. But since 4.1 there's a new specification called deployment admin and that actually gives you a lot of
08:21
help when doing deployment of updates or installing new stuff. It actually defines the notion of a deployment package and a deployment package is basically just a version set of artifacts, bundles and anything else you want to install. The deployment admin specification ensures that when you
08:45
install or update such a package the actual process is done in a transaction so if the fifth update fails everything gets rolled back nicely that's a good thing. You can also provide what they call fixed
09:01
packages which are sort of like a delta between two versions so you can say just give me I am I have version 5 now and I want to go to version 7 just give me the fixed package for that and then you get a package that only contains the Delta between those two versions. You can actually sign these
09:21
deployment packages to prevent tampering make them more secure and the nice thing is you can actually extend them through the use of resource processor and I'll go into that a little bit more in a couple of minutes. So looking at deployment packages they have a certain format that was designed so that they
09:44
can easily be streamed and this is done so that you can even install them without requiring too many resources on embedded constrained environments so everything in the package is laid out in such a way that the whole installation process can be done by just processing a stream so the stuff
10:03
you need first is at the front of the package manifest which basically describes what's in there then the signature files in case it's signed and maybe some localization then the actual bundles the components that you want to install and finally some other resources and it's these resources that
10:22
make it interesting because that's actually a way of sort of extending what you install. Apart from bundles you can basically add your own types of resources to these deployment packages where every type of resource is identified by its MIME type and every type of resource can have its own
10:43
resource processor. A resource processor is mainly just another OSGI bundle that gets actually gets shipped alongside these resources and it actually allows you to define some way of installing these resources on the target system so that way if you for example want to add some DBM packages or add some
11:06
images or HTML pages that you want to somehow deploy on your target system you can simply add a resource processor that knows how to deal with these resources on the target system and that makes it a very extensible format.
11:21
One of these resource program processes are actually standardized in the form of configuration admin which is a mechanism in OSGI to configure all kinds of different aspects of the framework to configure services but there are many other possible resource processors. Just a brief look at how
11:46
this transactional mechanism works it's not really rocket science it's just like a two-phase commit basically so if you install a deployment package you start at the beginning every everybody gets a chance to initialize and as soon as
12:02
that works out you go into a prepare phase again everybody is asked if they can prepare that change and if that works okay then you get the actual commit and then everybody should really commit whatever I've been doing if anything anywhere goes wrong you go into a rollback and everybody
12:24
everything gets rolled back to its original state finally this transaction ends so yeah wrapping it up gave you a crash course of OSGI I
12:41
hope you learned a little bit about it I explained a little bit about how deployment packages allow you to transactionally install and update components and how you can extend this mechanism by using different resource processors if you actually want a demo of some of this stuff just come by and
13:01
ask me I have a nice demo on my laptop or contact me after the conference and I think we actually have one or two minutes left so if anybody has a question go ahead so the question is are there any plans for
13:26
some to add any of the OSGI features to the Java runtime actually there are a couple of initiatives on that there's JSR 277 the Java module system and there are some people from the OSGI Alliance in that expert group
13:43
cooperating with them and there are some other JSRs out there basically Java 7 is targeted for inclusion of this JSR and they are working together there's a tension a little bit of politics involved because IBM is a big sponsor of
14:04
OSGI and Sun doesn't really like that so but to be honest the law over the last year Sun has joined the OSGI Alliance again they were a member when it all started out in 1999 and actually they've ported glass fish to
14:20
OSGI and that's actually running on Felix now and the main developer of Felix is actually now employed by Sun so I think they're pretty serious about cooperating with OSGI and including it in some way in the next Java version and that would be a good thing because there are some things that OSGI
14:41
cannot solve without some cooperation with the virtual machine so I think that's that's a good path forwards yeah yep how does Felix compared to Equinox well maybe I'm not the best person to ask because I'll say well
15:02
Felix is great but to be honest Equinox is a framework which is very much targeted at the desktop and optimized for that so it's a very good desktop system Felix is a little bit more lightweight than Equinox so it's more suited for embedded that's it in a couple of seconds but I can explain
15:25
thank you