OSGi: Not Easy to Use. Not as Productive as it Should Be
says Rod Johnson
Rod also clarified this statement:
"I’d like to add some clarification here, and say a little more about our experience with OSGi and my conclusions from it—note the emphasis on my, as my opinions aren’t always those of SpringSource or VMware.
"We made a major investment in OSGi in creating our dm Server product. We subsequently took that technology to Eclipse, where it continues to move forward, with our continued input. We have an ongoing revenue stream from our OSGi-related technologies,with customers including some household name companies. We plan to maintain our current level of commitment to OSGi.
"The lessons I personally drew from the experience were that:
(a) OSGi is a great solution for complex applications with stringent modularity requirements;
(b) typical business applications (from which we make the bulk of our revenue) don’t have such requirements;
(c) our efforts to reduce the complexity of writing server-side OSGi applications were promising, but the road to simplification was longer and less certain than we’d hoped.Thus continuing down that road at the Eclipse Foundation, in partnership with other companies and individuals, was a natural move.
"I don’t think OSGi is a bad technology—merely one that isn’t applicable to every application out there and one which therefore didn't belong at the core of our business. If you don’t have modularity requirements, the simplest thing that can possibly work won't have a module system. I applaud the fact that the Virgo project continues to make progress in simplifying the OSGi experience, and am proud that our engineers play a major role."
Rod
[theserverside.com]
But in some cases you do need to be able to unglue yourself from the EE spec, but still have access to it at the same time. Think about SCADA systems. They need to have constant contact with their monitoring points. If you try to do this with Java EE, then you're forced to do this in a servlet container, because you cannot spawn your own threads in the EJB container. OSGI could be useful for this, since then at least you can have the communication logic and daemon threads running in the osgi container, where there are no bounds to what one can do. This way your communication layer does not have to reside outside of the application server and you get the benefits of running inside one too. Or am I seeing this all wrong?
Posted by Poelman L. on July 10, 2011 at 02:56 PM CEST #
@L Poelman,
" If you try to do this with Java EE, then you're forced to do this in a servlet container, because you cannot spawn your own threads in the EJB container."
You should not - but it absolutely works. You can spawn as many threads you want in a Java EE container. Btw. you shouldn't spawn any threads in any managed environment. It is the beginning of the end (of robustness...)
But: is this not good enough: http://www.adam-bien.com/roller/abien/entry/fire_and_forget_without_jms
thanks for your comment!,
adam
Posted by Adam Bien on July 10, 2011 at 03:59 PM CEST #
spawning threads in javaee is the jca spec... a resource adapter is what you shiukd use to connect to external information sources
Posted by 92.251.255.11 on July 10, 2011 at 04:12 PM CEST #
@92.251.255.11,
absolutely - starting threads is trivial with JCA.
However, you can also start threads in EJB container. It is absolutely not
recommended and prohibited by the spec - but it works in all major
containers...
thanks!,
adam
Posted by Adam Bien on July 10, 2011 at 05:14 PM CEST #
I think as long as you can make sure all of your threads finish before returning from an EJB method, it's okay to do that. Actually I did this in one project, where I needed to search some text from a directory in the server. It was quite reasonable to introduce a multi-threaded solution for that.
Posted by shinzey on July 12, 2011 at 07:39 AM CEST #
@shinzey,
"...I think as long as you can make sure all of your threads finish before returning from an EJB method..."
But this could be really hard. How do you kill a thread?
The next problem is the amount of threads - you have to control it. Otherwise you will run into OutOfMemoryErrors...
thanks for your comment!
Btw. everything what is pragmatic is good. Dogmatic opinions are always harmful :-)
adam
Posted by Adam Bien on July 13, 2011 at 12:58 AM CEST #
Problem with JCA is that the spec is too bloated an confusing(imho). This is reflected by the fact that there are not a lot of JCA implementations or examples available on the web today.
JBoss released IronJacamar(http://www.jboss.org/ironjacamar) last week, I hope this will aid to the growth of JCA adaptors. Still, I think it's a bloated spec that was a bit overengineered.
Lifecycle modules could also be used for this, and they should have full accessability to the resources defined in the server + your EJB's should have access to them in a uniform way(think of how we access datasources)
Posted by L Poelman on July 13, 2011 at 03:40 PM CEST #