Hi,

I'm trying to find out the pro's and con's for using session beans (as session facades) in J2EE applications. Please provide me with any resources or comments that may help.

Lets say we are developing a J2EE application for a bookstore. We can use session beans as the sub-system interfaces. That is, any access to the business must pass throught this layer of session facades. Using session beans to implement this layer has the following pro's:

1- It provides automatic transaction handling.
2- It provides a basis for future integration with other applications, because session beans are widely used and there are minimal work can be done to expose parts of the system to interface with other systems.

On the other hand, we can do without session beans altogether and provide the set of sub-system interfaces in plain java objects, also known as business delegates. In this case, these are the pro's:

1- We don't have a heavy height container altogether.
2- The overall application architecture is simpler as it will not deal with the complexities of looking up and loading beans and handling container exceptions.
3- We can have non-transactional db access. That is, I can read from the database without starting a transaction. This cannot be done in case the container is handling transactions on behalf.

Waiting for your opinions !

Amr.

My view is very simple - does your application at this moment require the ability to remote any of its interfaces. If yes then use SLSBs if no don't. There are factors, not all technical, that will influence this answer. Just don't complicate things unnecessarily.

I do have the view that you code your system so that it would be easy(er) to modify the system to use SLSB if necessary in the future at the business logic layer. If you work in terms of layers and interfaces then this will just happen almost naturally. I also suggest you always use a transaction when accessing the database.

You can access the database without starting a transaction when you are using a container, too. But that is absolutely not recommended, you should allways use a transaction whenever you access the DB

I recommend designing your session facades as POJO business delegates. As you indicate, your overall application architecture will be simpler, and your application will be much easier to test. And as David said, you can always wrap them with SLSBs later if you need to, for example to export certain services as remote services.

The only benefit that local SLSBs really give you in the first place is declarative transaction management. Note that the Spring Framework's transaction support is intended exactly as replacement for that particular SLSB goodie: It offers declarative transaction demarcation for POJOs via AOP, typically applied at the service facade level.

Underneath, Spring uses pluggable transaction strategies: Out-of-the-box, we provide strategies for a plain JDBC DataSource, a plain Hibernate SessionFactory, a plain JDO PersistenceManagerFactory, and JTA. Changing between these is a matter of configuration. So as long as you're just accessing one database, you don't need to use JTA.

Spring also offers programmatic means of transaction demarcation, analogous to plain JTA. But declarative demarcation is pretty convenient and therefore recommendable in the general case.

Have a look at the article at http://www.hibernate.org/110.html if you're interested. For a further reference, Spring's release distribution includes the Petclinic sample app that illustrates how to apply transaction management and the Hibernate support classes in a working application.

Juergen
(Spring Framework developer)

jhoeller,
i have been using spring on my latest project and love and slowly moving away from the J2EE APIs to hibernate + POJO + spring; i still use SLSB for some use cases.
I only have a small complaint about spring, the documentation need improvement and the sample apps from CVS are too simple, and lastly the forums on sourceforge are ugly and close to useless.

tsusaka,

Your comments are much appreciated!

Regarding documentation, this is our number one priority for 1.0 RC1 (to be released in January). We will release our last 1.0 milestone release M4 within the next couple of days, introducing numerous new features, then being feature-complete for 1.0. Afterwards, our main concern will be improving the documentation.

1.0 M4 will also introduce our version of Clinton Begin's JPetStore, with Spring as middle tier backbone plus alternative web tiers on Spring Web MVC and Struts 1.1. Like Clinton's original version, it still uses iBATIS Database Layer for data access, though with Spring-managed resources and transactions.

Frankly, I don't like the forums on SourceForge either. Hibernate had to stick with them for quite a while too, having switched as recently as four months ago! We're currently putting all our effort into the framework itself: After 1.0 final, we will concentrate more on support infrastructure. Currently, the user mailing list is our preferred support mechanism.

BTW, we've recently switched to JIRA (thanks to Atlassian!) to get rid of the not-so-decent SourceForge bug tracker. We're also about to adopt a proper Wiki: probably Confluence, the new product from Atlassian, which is built on Spring itself (with WebWork2 for the web tier).

Juergen

If you do decide to go the BusinessDelegate POJO approach, make sure that your BusinessDelegate interface methods throw RemoteException (although you don't have to extend Remote).

Otherwise, if you later decide to migrate to SLSBs, you will have to add that signature to your BusinessDelegate interface. (The other alternative would be to create an adapter around the SLSB that converts the RemoteExceptions to some form of RuntimeException.)

Good point: It has to be noted that it just applies to remote SLSBs, as local SLSBs can easily implement a plain business interface without any RemoteException.

BTW, the Spring Framework offers EJB access classes to plugin in local or remote SLSBs into Spring application contexts, exactly for the purpose that you refer to: seamless switching between local business objects and SLSB that implement the same business interfaces. See the "Using EJB" section in http://www.theserverside.com/resources/article.jsp?l=SpringFramework for some details.

Client objects simply receive a reference to the desired business object via IoC: The local business object definition or the JNDI reference to an SLSB plus the home interface handling are completely hidden in the Spring context definition: The client object just receives an implementation of the business interface, not caring where it came from.

As of the upcoming Spring release 1.0 M4, you can also use a plain business interface that does not throw RemoteExceptions with Spring's SimpleRemoteStatelessSessionProxyFactoryBean: The method calls on the plain business interface will be delegated to matching methods on the remote SLSB proxy, converting an underlying RemoteException to Spring's unchecked RemoteAccessException.

In the latter case, the component interface of the remote SLSB cannot be derived from the plain business interface because the latter doesn't declare RemoteException. But the SLSB implementation can still implement the plain business interface, to let the compiler check them being in synch. You've got two interfaces for your SLSB then: the RMI-aware component interface, and the non-RMI business interface.

Juergen

There's one _big_ caveat if using session beans. I learned this while moving my code from using only Hibernate beans to using Hibernate beans plus sessions beans.

Essentialy the problem lies in the fact that using J2EE/RMI your objects from the client will _not_ get updated by Hibernate because they are sent by value to the server and, of course, when you save an object to the db the object's ID will still be unmodified (value=zero) in the client.

This can be quite problematic if you have large object graphs. Say you want to add an object to a collection of the parent and then you update the parent to make the change persistent. Unless you _return_ the parent object in the session bean call, your parent object from the client will contain a child with id=0 although that child is now saved in the database!

This could lead to problems when you next time try to persist the same (parent) object 'cause it will think it has to save again the child in the DB.

So, you have to return objects in the bean methods or at least to return somehow the modified IDs.

--steve p.

Well, that caveat applies to all remote services that transfer persistent objects: You've got call-by-value instead of call-by-reference then, not propagating changes from the service back to the caller. Not only remote EJBs but also plain RMI, Hessian, Burlap, SOAP Web Services, etc are affected here.

However, this does not apply to logical services that are by their nature kept locally within the same VM, be it local EJBs or Spring-managed business objects. Their service interfaces can assume call-by-reference, and be as fine-grained as appropriate from a business perspective. Why worry about remote semantics as long as just calling objects locally anyway?

So what I usually recommend is to define everything as logical POJO business objects in the first place, as many applications will never need to export a remote service. If you ever encounter the need for remoting, export a corresponding business object as remote service (provided that its natural interface already matches remote semantics), or implement a thin remote service wrapper for corresponding business objects.

As you might have guessed, this middle tier design philosophy is central to the Spring Framework: It provides all the means necessary for it, from wiring POJO layers and declarative transactions on POJOs to remote exporters and remote proxy factory beans. Currently, the out-of-the-box remoting options are Hessian, Burlap, JAX-RPC, and RMI - as illustrated by our new JPetStore version.

Juergen
(Spring Framework developer)