TheServerSide broaches OSGi

TSS has broached OSGi here.

To start, let me refer you to my buddy, Ales Justin's impressive interview. He clearly outlines JBoss's intentions with OSGi. Well, to the question of why JBoss does not directly use Felix but embark on its own implementation, Ales has answered it quite well.

The current OSGi service registry lacks the features we need - fine grained dependency, AOP integration, legacy JMX support, scoped metadata, open mbeans, Virtual File System (VFS), generic deployers, etc... If we were to take an existing implementation and add these features then it would probably take the same amount of effort, if not more, to put everything together. Also by building our own implementation we ensure that we have the most control over the core piece of our application server, i.e. the kernel.

We could probably use the classloading features of existing OSGi frameworks but it would again mean bending around things to make them work. As we wanted to have a bullet proof implementation, where all the nasty details were hidden away under private/protected modifiers, it was important that we could tightly control access through policies and delegation. From this perspective it made more sense to implement our own classloading layer. It also meant that things like resource lookups could be implemented using our Virtual File System which gives us really nice access to deployments regardless of their location or structure (packaged or unpackaged).

If you want to understand the security associated with bundles in OSGi, do peek at "Protecting code archives with digital signatures"

Let us take a 10,000 foot view of security in OSGi. Policy Files can guard the actions of software bundles. The bundles can be signed similar to Jar files. Additionally, the PermissionAdmin service in OSGi can be used to dynamically administer permissions (looks like a direct relation to the JACC PolicyConfiguration theory).

The key aspect of OSGi that is interesting is the isolation of the bundles, implies I can have multiple versions of the bundles working in the OSGi run time without conflicts.