Posted by ss141213
on March 24, 2010 at 12:17 AM PDT
As promised earlier , I am going to quickly go over the key points I gathered from the talks I attended at eclipsecon and I also want to brief you about my topic at the conference. Because of a migrane attack earlier today which I firmly believe was caused by severe jat lag, I could not attend as much on day #2 as I had earlier decided to, and that's the very reason why I will keep this entry as short as possible. First and foremost, the big news of course is that jdk7 will have a module system which will be able to interoperate with OSGi module system. I know there must be a lot of literatures already written about it, so I won't spend any more time talking about it.
On day #1, there were two talks scheduled right after each other in post lunch session and they were about two projects in incubation: first one called Apache Aries, primarily contributed by IBM engineers, and the second one was Eclipse Gemini project, contributed by Oracle and VMWare (read SpringSource). Both the projects have to do with use of Enterprise OSGi, which encourages use of an “alternate” component model. As an enterprise Java user and developer, I would also like to see more natural support for EE component model. I know some of you reading this piece may already be classifying this into "what a crap" category. I know it is hard to fight perception, but I will try now that we have the right ingredients in the platform. As a platform provider, I feel obliged to send the right message to our users. The fact that there is a notion of what a profile is and an agreement on definition of two standard profiles (viz: web profile & full profile), is good enough start. The profile definition is not just in paper, but there is a reference implementation (see GlassFish Web Profile) of the same and support for seamless upgrade from one to other is proof of the fact that EE platform is not as monolithic as has been portrayed. Add on top it, starting with EE5, there was always an SPI for JPA providers to work in any compatible EE container. With all the hard work experts have put into EJB 3.x spec, the new avataar of EJB looks really interesting. We have seen a lot of enthusiasm about these features among our users in various GlassFish forums. I will rather trust EE platform experts coming up with profile definitions than creating too many fragments and the confusion created thus.
At the same time, I think more can be done to enable modularity in EE applications. And that's where we see OSGi as a value addition. Modularity has a cost too, so striking the right balance is going to be a key challenge. Modularity just does not mean breaking your big apps into smaller modules; service layers play a very important part as well, and of course with modularity comes the extra attention that application developers have to pay to dynamic behaviors (e.g., modules/services can go and come in any order.). Trust me, it is not easy to write such applications for production use. That's where we feel it is not a all or nothing world. You not only need a migration path, you also need mixed environment. That's what we are experimenting at GlassFish. We enable interaction between OSGi components and Java EE components. Interaction automatically means bi-directional communication. e.g., we can seamlessly export EJBs as OSGi services without user having to write any OSGi code. That allows any pure OSGi component, which is running without EE context, to discover the EJB and call it. That in turn allows users to write business components as EJBs so that they can take advantage of things like declarative security, transaction, context dependency and injection, etc., and yet allow them to be accessible to non-EE components. And yes, you can do distributed transactions as well. Since we also make various EE infrastructure services like TransactionManager, Data Sources, as OSGi services (some of this is already being covered by OSGi Enterprise spec), one can start a transaction in your pure OSGi bundle, invoke an EJB as an OSGi service, and the transaction context will propagate. The same holds good for security or persistence context propagation as well. In fact, we allow mix and match in the same application as well. If you still don't like EE component model, GlassFish is extensible enough to be augmented with blueprint containers or something else to support their model. By default, we ship declarative services bundle.We are inclussive. The support for such hybrid applications is not just limited to EJB applications, there is support for hybrid web apps as well. Some of the aforementioned features are already in v3 release, some are in trunk and some are still being baked.
If you are interested in knowing more about these or have different opinions and are present at eclipsecon, then I would be happy to see you at my talk details of which is given below. I hope to demonstrate some of these during the talk:
OSGi & Java EE in GlassFish
Grand Ball Room, Santa Clara Convention Centre
24 Mar 2010 at 1400 PDT
I hope you find the information useful,
Statutory Warning: Opinions presented here are my own.