You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomee.apache.org by recursion <ba...@yahoo.com> on 2009/06/16 10:30:37 UTC
Flexability of OpenEJB integration
Hi all,
I was wondering to what extent can OpenEJB be integrated with some other
vendors' implementations of standard J2EE modules/services. I mean, if i
want to make OpenEJB run for example, with TopLink Essentials as a JPA
provider, with Jetty as a web container, with SimpleJNDI as a JNDI
implementation and with "My-neighbour-Frank-Smith's" JMS-provider, with MX4J
as JMX provider, and so on, how easy would be that integration ?
As an EJB server, OpenEJB needs JMS implementation, JAX-WS support,
TransactionService, JNDI implementation, and so on. It even provides JCA
support as i can find from the home page.
So my question is regarded with the extent, to which OpenEJB is decoupled
from those enterprise services. If it communicates only through the
specified in the specification interfaces with those APIs, then ideally it
would integrate with arbitrary implementations. So, you simply take OpenEJB,
and plug your standalone JNDI, JAX-WS, JPA, JMS, JTA implementations, and
everything works fine together. But this is just ideally.
In reality, even a single integration can be hard to achieve.
So, to summerize, my question is: is OpenEJB integrated with its inner J2EE
APIs implementations, as loosely coupled as possible (Apache Geronimo's
transaction service, J2EE Connector, Java Mail; CXF, WSS4J, ActiveMQ, SLF4J)
? Can they be substituted with other spec-compliant implementations easily ?
Or it is the case that OpenEJB relies on particular out-of-spec behaviour
and properties of its inner parts, and its impossible to easily replace them
?
Thank you in advance!
recursion.
--
View this message in context: http://www.nabble.com/Flexability-of-OpenEJB-integration-tp24049853p24049853.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: Flexability of OpenEJB integration
Posted by David Blevins <da...@visi.com>.
On Aug 21, 2009, at 8:01 AM, recursion wrote:
>
> Hi David,
>
> I was wondering about your note on the JNDI impl:
>
>>> JNDI implementation
>>
>> Not easily. In Tomcat we use Tomcat's JNDI impl, in Geronimo we use
>> Geronimo's impl, but it's tricky to pull off.
>
> Can you elaborate a bit on that? I mean, JNDI has a well-defined SPI
> so it
> shouldn't be that tricky to achieve this, isn't it?
>
> Furthermore, as long as Geronimo uses OpenEJB as its EJB container,
> and can
> use Tomcat as its web container, they should be made possible to use a
> common JNDI provider in Geronimo.
> Now, AFAIK standalone Tomcat uses the org.apache.naming impl
> (http://directory.apache.org/subprojects/naming/) while Geronimo
> comes with
> xbean-naming (http://geronimo.apache.org/xbean/). OpenEJB seems to
> have its
> own JNDI impl although I noticed the xbean-naming bundle inside as
> well.
> Is the above correct or am I totally missing something here?
We were going to use the xbean-naming implementation, but it turned
out to be far slower than our own implementation so we opted to stay
with what we had. Bottom line is that there is no compliance test
suite for JNDI implementations and all of them are slightly different.
If you're looking for details, this dev@ thread is full of them:
http://www.nabble.com/jndi-independence-and-dependence-on-special-features-tt22878940.html
If you're still curious we should move this thread over to the dev list.
-David
Re: Flexability of OpenEJB integration
Posted by recursion <ba...@yahoo.com>.
Hi David,
I was wondering about your note on the JNDI impl:
> > JNDI implementation
>
> Not easily. In Tomcat we use Tomcat's JNDI impl, in Geronimo we use
> Geronimo's impl, but it's tricky to pull off.
Can you elaborate a bit on that? I mean, JNDI has a well-defined SPI so it
shouldn't be that tricky to achieve this, isn't it?
Furthermore, as long as Geronimo uses OpenEJB as its EJB container, and can
use Tomcat as its web container, they should be made possible to use a
common JNDI provider in Geronimo.
Now, AFAIK standalone Tomcat uses the org.apache.naming impl
(http://directory.apache.org/subprojects/naming/) while Geronimo comes with
xbean-naming (http://geronimo.apache.org/xbean/). OpenEJB seems to have its
own JNDI impl although I noticed the xbean-naming bundle inside as well.
Is the above correct or am I totally missing something here?
Thank you in advance!
recursion.
--
View this message in context: http://www.nabble.com/Flexability-of-OpenEJB-integration-tp24049853p25081540.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: Flexability of OpenEJB integration
Posted by recursion <ba...@yahoo.com>.
Hi, David,
Thank you for your precise and detailed answer! It seems that OpenEJB has
been developed with great flexibility in mind, considering the fact that it
communicates with API providers via the standart SPIs, as much as possible.
This is really great, since it gives you the possibility to experiment with
different combinations, and choose the most appropriate one, depending on
your needs.
Best Regards,
recursion.
--
View this message in context: http://www.nabble.com/Flexability-of-OpenEJB-integration-tp24049853p24161461.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: Flexability of OpenEJB integration
Posted by David Blevins <da...@visi.com>.
On Jun 16, 2009, at 1:30 AM, recursion wrote:
> I was wondering to what extent can OpenEJB be integrated with some
> other
> vendors' implementations of standard J2EE modules/services. I mean,
> if i
> want to make OpenEJB run for example, with TopLink Essentials as a JPA
> provider, with Jetty as a web container, with SimpleJNDI as a JNDI
> implementation and with "My-neighbour-Frank-Smith's" JMS-provider,
> with MX4J
> as JMX provider, and so on, how easy would be that integration ?
>
> As an EJB server, OpenEJB needs JMS implementation, JAX-WS support,
> TransactionService, JNDI implementation, and so on. It even provides
> JCA
> support as i can find from the home page.
>
> So my question is regarded with the extent, to which OpenEJB is
> decoupled
> from those enterprise services. If it communicates only through the
> specified in the specification interfaces with those APIs, then
> ideally it
> would integrate with arbitrary implementations. So, you simply take
> OpenEJB,
> and plug your standalone JNDI, JAX-WS, JPA, JMS, JTA
> implementations, and
> everything works fine together. But this is just ideally.
>
> In reality, even a single integration can be hard to achieve.
> So, to summerize, my question is: is OpenEJB integrated with its
> inner J2EE
> APIs implementations, as loosely coupled as possible (Apache
> Geronimo's
> transaction service, J2EE Connector, Java Mail; CXF, WSS4J,
> ActiveMQ, SLF4J)
> ? Can they be substituted with other spec-compliant implementations
> easily ?
> Or it is the case that OpenEJB relies on particular out-of-spec
> behaviour
> and properties of its inner parts, and its impossible to easily
> replace them
> ?
There's definitely lot's of flexibility in the platform. Just to give
some input on the things you mention:
> JMS implementation (ActiveMQ)
Yes, any JMS iml can be plugged in via the J2EE connector API.
> JAX-WS support (CXF)
No standard API for this yet, so our integration is with CXF
specifically. Could support Axis2 if there was the demand for it --
the code exists in Geronimo and we'd simply need to port it. There
are internal APIs for adding a new "server" of any kind, but code must
still be written to integrate it. By server we mean anything that
wishes to listen on a socket and send calls into EJBs, etc.
> TransactionService
Anything that implements the JTA API can be plugged in. Declare it in
a service-jar.xml in the jar, add it to the lib dir, reference it from
openejb.xml
> JNDI implementation
Not easily. In Tomcat we use Tomcat's JNDI impl, in Geronimo we use
Geronimo's impl, but it's tricky to pull off.
> J2EE Connector
Sure, any J2EE connector can be plugged in via the Connector API; rar
files and such. The actual Connection Manager itself can be replaced
as well: declare it in a service-jar.xml in the jar, add it to the
lib dir, reference it from openejb.xml
> Java Mail
Sure. Declare it in a service-jar.xml in the jar, add it to the lib
dir, reference it from openejb.xml
> JPA (OpenJPA, TopLink Essentials)
Yes, any compliant JPA provider can be plugged in via the standard
approach: including that provider's jars in the classpath and
referencing the provider in your persistence.xml file. We have
examples of using Hibernate and EclipseLink. Usually the provider
will require you to set some flag or factory that let's it get a
reference to the TransactionManager. We will do this automatically
for you for TopLink, EclipseLink, and Hibernate. OpenJPA does it by
itself. Any other provider should plugin fine.
> Web Container (Jetty)
Somewhat. Our Tomcat integration is very Tomcat specific and no
similar integration exists for Jetty. That said the OpenEJB
standalone server does have JAX-WS support via CXF and a small HTTP
implementation we wrote. You can easily replace our small HTTP
implementation with Jetty by simply adding the Jetty jars to the
openejb.home/lib/ directory. This is recommended for production.
Note this will only affect HTTP and does not give you servlet or jsp
support in OpenEJB standalone.
> JMX (MX4J)
I'd guess this is in the same ballpark as other vm level APIs like
JAXP, JAXB, etc. If there's a standard way to configure a provider at
the vm level, then yes. We certainly don't have any code specific to
a particular JMX implementation.
> WSS4J, SLF4J
Both of these are used only by CXF, so can't really comment on their
pluggablility.
- - - -
As a general rule, anything declarable in the openejb.xml is being
plugged in and can be swapped out if the related APIs are satisfied.
You can also use the service-jar.xml to add new resource types
declarable with <Resource id="My Foo Resource" type="Foo"/> and usable
in code as "@Resource Foo myfoo;" Additionally you can add a
java.beans.PropertyEditor for any type you want to be injectable via
"@Resource MyCustomType myCustomType;"
That's not the entire scope of things that can be swapped out in
OpenEJB, but hope it gives you an idea.
-David