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
