SLSB remote pratice.

[djeang]

Hello, i'm pretty newq in EJB.

I'm currently working on a project that extensly use remote EJB session. I plan to use Spring to warp these ugly components both on server and client side.
what code do i must produce ? my tought is :

- a POJI interface of my buisness service, without remoteException (this interface would be use on the client side)
- a POJO that implements this interface (my service implementation)
- another POJI interface that is the same as the first one, but with RemoteExceptions.
- An EJB remote interface that extends the remote POJI interface.
- An EJB session bean that implements the remote POJI interface.

Am i doing it rigth ?
Is there a simpler way to accomplish this ?

Thanks.

[Andreas Senft]

I suggest, you implement the following:

1) Your business interface [used on client and server; this one does not declare remote exceptions and does not depend on EJBObject or the like]

2) Your EJB remote interface [the declared methods are the same as in 1) but with "throws RemoteException"]

3) A POJO-implementation of 1). This is the actual handler, where the business logic belongs to.

4) An EJB implementation [implementing 1) and ideally extending AbstractStatelessSessionBean]. The methods do just delegate to the POJO Implementation 3) via its implemented interface 1). That means the EJB-Implementation does not need to know the concrete type of the POJO handler.

The assignment of the handler can easily being achieved by spring, possibly adding transaction interceptors or the like.


Hope that helps,
Andreas

[djeang]

thanks andreas,

But i'm in trouble with your 4) point. I want a remote bean, Shouldn't My EJB bean implements 2) instead of 1) ?

[JMahoney]

Session beans cannot directly implement remote interfaces. The business interface pattern was created to address this issue.

[Andreas Senft]

Session beans cannot directly implement remote interfaces. The business interface pattern was created to address this issue.

Actually, EJB implementations could implement their remote interface. But this is generally considered bad practice, since it would allow for the subtle error of returning this from within a method (instead of a handle).
The connection between the implementation class and its remote interface (and also its home interface) is established in the deployment descriptor.

The usage of a POJO business interface allows Spring to provide a true transparent business delegate pattern, thus decoupling the client from knowledge of the EJB technology (which it shouldn't be aware of).
The drawback is, that you have to maintain two interfaces in parallel: the POJO business interface and the remote interface. You cannot inherit one from the other because of the declaration of the required RemoteException in the remote interface.

Regards,
Andreas

[dejanp]

thanks andreas,

But i'm in trouble with your 4) point. I want a remote bean, Shouldn't My EJB bean implements 2) instead of 1) ?

Remote interfaces, home interfaces and deployment descriptors are normally generated (by your ide or xdoclet) from EJB classes and not hand written, so you can't use them to implement EJBs themselves.

As Andreas already wrote, even if you hand write them, there are good reasons not to do it because it allows you to treat server-side EJB instances as remote instances and that can never, ever be a good thing.

[mickknutson]

Does someone have some sample code for 1 through 4?
I am just starting to use Spring.
I currently have my Struts actions calling a ServiceLocator, that instantiates my SLSB's. I want to remove the dependacy of my actions from the my EJB's. I am also hoping to allow for a easier migration from Struts to JSF in the near future.

thanks andreas,

But i'm in trouble with your 4) point. I want a remote bean, Shouldn't My EJB bean implements 2) instead of 1) ?

Remote interfaces, home interfaces and deployment descriptors are normally generated (by your ide or xdoclet) from EJB classes and not hand written, so you can't use them to implement EJBs themselves.

As Andreas already wrote, even if you hand write them, there are good reasons not to do it because it allows you to treat server-side EJB instances as remote instances and that can never, ever be a good thing.