 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 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 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 little bit of history we have to go back to the last century 1999 for to see the birth of OSGI when a couple of companies actually came together to think about a solution for home gateways they were envisioning this home gateway being the central hub in 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 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 was actually turned out to be useful for lots of other things so even though the home gateway didn't what 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 on the service I mean you have Eclipse using it as their plug-in system and nowadays you even have things like the spring a framework and glassfish using it as the basis for the application service so nowadays if you look at the OSGI website it's just explained as the dynamic module system 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 framework itself the implementation is not that relevant anymore you develop your components and they'll run on any implementation so 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 second book that's the service compendium and we'll look into it a little bit more as we get to dynamic deployment the 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 defines a couple of profiles some of you might have been doing J2 Java embedded or Java on the mobile phone where you have these different profiles which basically define which subset of API's are available well this is actually the same thing so you can have a very constrained profile that will 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 as it's called in OSGI is basic 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 only share packages that you want to share so for example you don't want to share your implementation only your interfaces and you can simply say 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 will then take care of the actual wiring nice thing of that is that you can also export a 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 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 it has a lifecycle layer and every bundle every component 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 actually two hooks that you have for starting your own code and stopping it again and at any 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 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 have to keep track of what services are there if they're still available they can go away at any time so that that makes it a little bit harder to use but it's a very nice and a decoupled way for components to to interact with each other they only look up the service interface they don't care about who actually implements it so you can actually exchange implementations without the rest of the framework knowing it so that's that's basically the OSGI framework itself now onto deployment if you look in the at the specification and what it describes about deployment it actually only specifies a couple of 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 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 there 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 failed 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 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 versioned set of artifacts bundles and anything else you want to install the deployment admin specification ensures that when you 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 that's a good thing you can also provide what they call fixed 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 deployment packages to prevent tampering make them more secure and the nice thing is you can actually extend them through the use of resource processes 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 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 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 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 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 resources identified by its mime type and every type of resource can have its own 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 images or HTML pages that you want to somehow deploy in 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 one of these resource program processes that actually standardize in 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 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 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 what they have been doing if anything anywhere goes wrong you go into a rollback and everybody everything gets rolled back to its original state and finally this this transaction ends so yeah wrapping it up gave you a crash course of OSGI I 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 to demo of some of this stuff just come by and ask me I have a nice demo on my laptop contact me after the conference 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 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 are some people from the OSGI Alliance in that expert group 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 little bit of tension a little bit of politics involved because IBM is a big sponsor of OSGI and some doesn't really like that so but to be honest over the last year some has joined the OSGI Alliance again they were a member when it all started out in 1999 and actually they've ported glassfish to OSGI and that's actually running on Felix now and the main developer 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 cannot solve without some cooperation with the virtual machine so I think that's that's a good path for us yeah yeah how does Felix compare to Acronox well maybe I'm not the best person to ask because I'll say well Felix is great but to be honest Acronox 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 Acronox so it's more suited for embedded that's it in a couple of seconds but I can explain some more thank you