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.

Where is Li Gong now?

I am not talking about the Chinese Actress, Li Gong. I am referring to the main architect of the Java 2 Security Architecture. I knew that he had left Sun to head Microsoft Security. But somewhere on the web I read that he was the head of the Mozilla Foundation in China.

Here is Li Gong's blog at Mozilla Foundation. Welcome back from the Dark Side of Security.

Security is way underspecified in Java EE

With all the talk on the profiles in Java EE 6 harping around whether the basic profile should be equivalent to just the tomcat container services or there is a need for an additional profile to incorporate EJB3, JPA and Web Beans, one has to understand that very limited progress has been made at extending security in Java EE 6. Well, JSR-196 is a welcome change. But it mainly deals with the externalization of the authentication aspects. Plus JASPI took years to complete. We have suddenly screeched to a ground halt as far as authorization needs of the modern enterprise is concerned.

Ok, my personal take on the profiles. I vote for the one with web beans. A simple web profile (with just servlets and JSPs plus adornments) is not really fit to be termed Java EE 6. Modern web developers need web frameworks (just not JSPs and Servlets) to do their development. Web Beans with a mix of EJB3.1 and JPA certainly meets the need of these web developers. Now come on, since when developers are doing just JSPs and Servlets? For web development, you need a persistence layer at all times. Since the Java world has converged on JPA, why not include it in the profile? We are talking about the EE space, so naturally your web components (my hands itched to say, beans) will want to talk to some enterprise components aka EJBs. Since you need the feather-lite version of the EJB specification (we are talking about simple profiles, right? Hence the lite version) which will be the EJB 3.1 version. Now for those morons who equated CMP beans to EJBs, you can stick to your EE profile consisting of just servlets and JSPs (with some insignificant step children of course). There is no need to drag sane people to your bandwagon.

Authorization has totally taken a back seat with the cumbersome JACC (JSR-115) as the only specification that is mandated. We have already seen with JBoss Portal that JACC needs to be extended to incorporate portal needs (remember, JACC just deals with web and ejbs). JACC is not totally intuitive to developers/implementers.

There has been new directions with JBoss with initiatives in Instance Based Security (Rules, Portal and jBPM demands), XACML (fine grained authorization) and the Authorization Framework (Pluggable authorization modules). I would love to see some additional work done in this regard in the JCP.

Time to ping Ron Monzillo at Sun. He is the main security spec lead from Sun (JACC, JASPI).

I will be with Hal Lochart(BEA) and Tony Nadalin(IBM) this week at the IDTrust 08. We are on the same panel from Oasis. It will be interesting to brainstorm ideas with them. My presentation at the panel (I will post the link to the presentation after the workshop is over) is about extending Java EE to incorporate the identity and access control needs of the modern enterprise.

What bothers you as a Java EE user?

UPDATE: Do not forget to check out the comments for this post....