Plans for EJB3 support?

[hen...@googlemail.com]

Hi,

Modulefusion looks rather promising. Are there any plans to support
EJB3, for example through EasyBeans (http://
wiki.easybeans.objectweb.org/xwiki/bin/view/Main/OSGi)?

Joerg

[Roman Roelofsen]

> Modulefusion looks rather promising. Are there any plans to support
> EJB3, for example through EasyBeans (http://
> wiki.easybeans.objectweb.org/xwiki/bin/view/Main/OSGi)?

ModuleFusion already has support for JPA entity beans by providing
Hibernate and the JPA frontend. Adding a complete EJB stack by using
EasyBeans is certainly doable. We are already thinking about to add
several "feature packs" in the future. In this case, you could
download a "EJB pack" that contains the EJB stuff, transactions, etc.

However, the overall goal of ModuleFusion is to promote the OSGi
programming model and not the EJB one. So we would always prefer to
use e.g. the OSGi service registry instead of EJB session beans. One
of the upcoming challenges of OSGi is to find a way to deal with
existing technologies and how to map them to OSGi constructs. This is
what we do in the Enterprise Expert Group of OSGi (among other
things ;-))

ModuleFusion, for example, automatically creates the
EntityManager(Factory) depending on the started bundles and register
the instance in the OSGi service registry. This behavior is clearly
not part of the JPA spec, but makes a lot of sense in OSGi. The next
version of OSGi (4.2) will allow to use things like @Transactional
method annotations for registered service and may therefore reduce the
need to use the full EJB spec.

For now, we could add this for Guice Peaberry. So what is your
motivation to use EasyBeans? JPA? Declarative transactions?

[J.H.]

Roman Roelofsen schrieb:

> For now, we could add this for Guice Peaberry. So what is your
> motivation to use EasyBeans? JPA? Declarative transactions?

Going the "traditional" route of using a full-blown JEE stack covers
quite a lot of possible requirements at once, at the price of committing
oneself to a juggernaut of a platform. Going with OSGi, on the other
hand, gives you almost the same benefits, but on a much lighter,
cleaner, sleeker platform. This is fine, in most cases, but I suspect
that what holds quite a few, currently suffering, JEE users back from
buying into OSGi is the what-if factor: will a OSGi solution scale (both
performance and feature-wise) as we know that JEE solutions do (if done
right)?

I am not currently using EasyBeans, just considering OSGi for future
projects, with EasyBeans playing the role as a transition helper. I am
well aware that EasyBeans may mean to do many things the JEE way on OSGi
instead of doing them the OSGi way right away. So I'd be more than happy
to hear suggestions for doing the stuff mentioned below the OSGi way.
But anyway, to finally answer your question: what I currently miss most
with the OSGi approaches I had a look at is:
- declarative (XA-style) transactions (you guessed right)
- a transparent remoting model with optional session management (akin to
EJB3 Stateful/Staleless Beans)
- declarative integration with messaging systems (akin to MDBs)

Joerg