Hi Sahoo!
> By the way, may I ask why you want to use remote EJBs
> if you are bundling your EJBs in an OSGi bundle? You
> can actually make them local EJBs and access from
> another WAR via OSGi service mechanism.
There are many reasons for different projects:
One project is JFire -
http://jfire.org - where we already have heaps of EJBs and see no reason to change this. Additionally, the EJBs must be available to remote clients just as if they were deployed "normally" (in EARs). At the moment, JFire uses JBoss with its ability to share classes across EARs - thus the EARs serve as different modules. That's not possible with GlassFish and of course it's not nice, either. We're using OSGi already in the JFire rich client (Eclipse RCP based) and want to use OSGi in the server, too, as soon as it is properly supported.
A second project (proprietary for a customer) is just starting and we thus still have the choice. In this project, we want to keep all options open as we don't know yet, how the final deployment will look like. Exposing the API primarily as EJBs makes it easily possible to deploy the WARs on a separate web server, which might become necessary. AFAIK, there are OSGi remote services available with the Riena project, but I don't see why that should be better than using "ordinary" EJB-API (which is IMHO really nice since EJB 3).
Actually, we want to provide various possibilities to access the API (e.g. classical JNP+RMI, JNDI+RMI-over-HTTPS or REST). IMHO, using EJBs keeps us all imaginable options open for the future.
And if we're really going to use local EJBs (not sure yet), I think dependency injection is easier and less code than OSGi services.
Best regards, Marco :-)
[Message sent by forum member 'nlmarco']
http://forums.java.net/jive/thread.jspa?messageID=408092