All, In the latest podcast (Feb 21?) I believe Tor made a statement of surprise that OSGi released a distributed reference implementation (Apache CXF). Shortly there after, I was talking to someone who is using OSGi as an out-and-out replacement for EJB. I wanted to spark a discussion based on what I see as a coming challenge between the OSGi and the JEE communities.
It is my opinion that the OSGi users/community is taking "the good" pieces of JEE and reimplementing the stack (for OSGi) in a much more friendly, re-usable way. I believe sun made a good decision when trying to make EJB "simple". You have four types of "modules" you can create in your system -> Message-Driven, Stateful Sessions, Stateless Facades and Entities. While in theory this is handy, in practice it can be downright painful. There are thick layers of functionality that get rolled in each EJB. One of the premises of EJB was that you should be able to swap out each layer with an alternative/better implementation. In practice, that rarely happens, as you usually choose a full stack. Also, there are many many times where I wish to create a "enterprise bean" of some sort, that *doesn't* have all the features of one of the above beans (or doesn't fit into any of the four categories). I mostly want to compose a subsystem of functionality that eventually gets promoted to "stateless facade". I'm currently forced to use external libraries (usually spring) that build this subsystem which is exposed via a stateless session bean. When trying to use the pure spec, I often wind up with too much code in lone stateless session beans, too much code in my entities, or just too many stateless session beans altogether. I see OSGi as a budding replacement for this. It is very modular, can support multiple versions of libraries at runtime, enabled hot-swapping of code AND allows you to compose software layer-by-layer. There are also pieces of JEE available on the OSGi runtime now. Combined with an IoC container like Spring, you can slowly build your EJB stack as needed. If your DAOs only need transactional support: you can make that happen. If your Remote Facades need to be highly available/transactional/uber-awesome: you can make that happen. If you have things in the middle that don't need all this cruft, just some of it: you can make that happen. And in a manner that is still "declarative". I'm fairly certain that things like Servlets and JSP will still remain as core low-level technology (although continuation-based request handlers may become more popular). However I see the EJB spec either having to morph, or be overwhelmed by the coming surge in more robust module-based distribution/management/design. I wanted to hear what the JavaPosse community thought of this, and where they see the two technologies going. I know from what I hear in my circle (which are indeed not a true smattering of the Java world), it seems certain the OSGi/JEE will merge, I only wait to see which community "takes the lead" afterwords. -Josh --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
