Hibernate & J2EE

[Kelly Walker]

Where does hibernate sit in my J2EE stack. My middle tier uses Stateless Session Beans for business logic. At the moment these SLSB also contain hand written JDBC code.

What I want to do is create a DAO layer outside of the middle tier. Because other J2EE applications need to use the DAO layer as well. I want to share the DAO layer accross different applications that need to access the same RDBMS.

The applications are deployed as ear files. How should i deploy my DAO layer. Should I still use the session facade pattern to 'front' the dao layer and back this with Hibernate persistent business objects. If I deploy this as an ear file as well will this mean that the applications that need DB access will need to use remote interfaces to communicate with the Hibernate layer. Because of another question I asked at the ranch I think this is true under WebLogic because of the way classloaders are allocated to ear files.

I guess my question is can someone suggest a good architecture for me. I would be very grateful for any suggestions.

I have also asked this same question in the hibernate forum.

[Mark Spritzler]

Well, which forum do you want this thread to stand. We condone, or should I say close duplicate posts.

Your concept is correct. The JDBC would move out of the SLSB and into DAO objects using Hibernate Sessions. Your SLSB should really have absolutely no code except to create and call a Plain Old Java Object. Then you can create a jar file of "common" code like the DAO layer and include that jar in your ear. Then any other application that needs to also use that jar can include it in their ear or war.

I wouldn't expect you to just keep the DAO jar in just one ear, and force all the other applications to have to do a remote lookup.

Mark

[Mark Spritzler]

Oh, and you are correct almost all Application servers use a seperate class loader for each ear or war that you create. I say almost all appliaction servers because there might be one that does this differently, but then I wouldn't want to use that Application Server.

Mark

[Valentin Tanase]

Hi Kelly,

What I want to do is create a DAO layer outside of the middle tier. Because other J2EE applications need to use the DAO layer as well. I want to share the DAO layer accross different applications that need to access the same RDBMS.

The applications are deployed as ear files. How should i deploy my DAO layer. Should I still use the session facade pattern to 'front' the dao layer and back this with Hibernate persistent business objects. If I deploy this as an ear file as well will this mean that the applications that need DB access will need to use remote interfaces to communicate with the Hibernate layer. Because of another question I asked at the ranch I think this is true under WebLogic because of the way classloaders are allocated to ear files.

My firm answer is that you should not do anything like this. You should not expose your DAO layer through a session fa�ade at all. The fact that you want to have a standard persistence framework for all your projects is a good decision. The fact that you intend to use Hibernate for that is even better. One of the greatest assets of Hibernate (beyond its ORM capabilities) is that it doesn�t depend upon any container. This is another factor that contributed to its popularity. You can run Hibernate in every java console application and this is a tremendous advantage, since testing would be greater simplified (you don�t need to do any in-container testing at all). Hence if I were you I�d design my persistence layer as simple POJOs that delegate basic CRUD operations to Hibernate. The good news is that you need only very few generic classes for doing this since Hibernate would do most of the work for you. Even better, if you�d like providing implicit transaction services, you can use Spring and AOP to help you achieving this task. Spring also integrates very nicely with Hibernate (and not only).
Finally you�d pack your DAO layer as a jar, containing as I said only POJOs. The way other applications can share your framework is very simple and is the same principle that helps them sharing the same logging framework like log4j for example. They only need to import your dao.jar library along with Hibernate and that�s pretty much it. EJB specific applications deployed as ears, would also include your dao.jar (all ejbs would probably need to update their Manifest.mf files in order to load the dao.jar & Hibernate libraries -- This should answer to the bolded part of your question). The session fa�ade would make calls to your POJOs, which in turn would use Hibernate for persistence. All other application would follow a similar approach, by simply loading the dao.jar & Hibernate. To resume I�d recommend you the next architecture:

   Spring & AOP � (use dependency injection) -> DAO --> Hibernate -- > Database
 
   You should provide a basic dao.jar that depends upon hibernate & spring framework (no container or other server side components).

Regards.

[Michael Duffy]

I agree with the comments above, but I'd go further.

Those other apps don't "need" the DAOs, they need the data and objects they provide. Why duplicate the JARs when you can have the first app expose services that provide the data? Let the other apps request the data they need, without duplicating the code.

Note: Have a service layer use the DAOs. Clients don't go directly after the DAOs themselves.

%

[Devender Thareja]

Valentin,

Does that mean, goin forward EJB is good for nothing? What's in store for this technology?

Regards.

Originally posted by Valentin Tanase:
Hi Kelly,

   Spring & AOP � (use dependency injection) -> DAO --> Hibernate -- > Database
 
   You should provide a basic dao.jar that depends upon hibernate & spring framework (no container or other server side components).

Regards.

[Valentin Tanase]

Hi Devender,

Good for nothing is definitely too much to say. EJB2.0 still has a lot of value and I would really expect EJB3.0 to be a great success. As a matter of fact here there are (in my opinion) the most important reasons to go with EJB2.0 at this time:

Need to implement the business tier as distributed components.

Providing implicit middleware services.

Support for other non-web clients (RMI-IIOP).

Great support for messaging.

Need for a standardized component-based architecture.

The Spring & AOP approach is a very good competitor for 2 and it also provides the advantage that it doesn�t require an EJB container (actually there is no need for any container at all). This is a great �break-through� though, since couple of years ago 2 was the unbeatable argument for using EJBs. It was nothing else available to implement 2. 1 on the other hand is at this time the strongest argument towards EJBs. There are also several technical requirements that enforce 1. One is for example the desire to extra-secure the business components using an architecture like this:

Firewall | Web Server | Firewall | EJB Container.

Another reason is for improving performances. For applications which are process intensive, deploying the business tier on different boxes might scale better (the same way you have a database always running on its own box. Of course database is very process intensive and it usually requires 3-4 times more hardware power than the app server). In other words the fast server processing will overcome the extra RMI overhead. As you can see 1 is very likely to happen too. 3 is also a pretty frequent requirement and EJBs are still an acceptable decision. 4 is my favored and out of all EJB types MDBs are definitely the best choice. I�m not sure if there is any serious drawback for using MDBs. 5 is a political decision and usually there is nothing we can do about.
However for the largest majority of applications, where web components and EJB components are collocated, using EJBs is an unnecessary overhead. Spring + Hibernate + Tomcat (or other web server) should be the way to go.
Regards.

[Mark Spritzler]

simple POJOs that delegate basic CRUD operations to Hibernate.

That is exactly what a DAO is. So you contradict yourself. saying not to use DAOs then say that you should create POJOS as quoted above. They are one and the same thing in the definition of a DAO.

Also, EJBs are not over because of a framework like Spring. There are drawbacks to Spring, like more XML to maintain. But I am not trying to knock Spring, I love Spring and its advantages.

In EJB 3.0 you will see it being more like Spring in the sense that your EJBs are now just POJOs.

Mark

[Valentin Tanase]

Hi Mark,

That is exactly what a DAO is. So you contradict yourself. saying not to use DAOs then say that you should create POJOS as quoted above. They are one and the same thing in the definition of a DAO.

Sorry for any misunderstanding but I didn�t say that. Develop and test the persistence layer like simple POJOs, there is no point in having any container dependencies here. That was my advice.

Also, EJBs are not over because of a framework like Spring. There are drawbacks to Spring, like more XML to maintain. But I am not trying to knock Spring, I love Spring and its advantages.

Did I say that?
Regards.

[Devender Thareja]

Originally posted by Valentin Tanase:
Hi Devender,

As a matter of fact here there are (in my opinion) the most important reasons to go with EJB2.0 at this time:

Need to implement the business tier as distributed components.

Providing implicit middleware services.

Support for other non-web clients (RMI-IIOP).

Great support for messaging.

Need for a standardized component-based architecture.

Valentin,

Thanks for detailed reply. It's clearer now. However, I don't completely understand the reason 2. What you mean by implicit middleware support?
I am preparing for SCBCD, and I was having doubt that should I take the trouble of studying it or not. Good to know that technology is not completely obsolete yet.
Thanks a lot again.

[Kelly Walker]

Thanks for the advice. I like the sound of creating the DAO layer as POJO Hibernate business objects distributed as a jar file for use by applications (just like log4j.jar as was pointed out).

My next question is what about transaction demarcation? My ejb applications use container managed transactions (WebLogic 8.1 transaction manager). Can the ejb transactions be propagated to the hibernate POJO updates? All the example Hibernate code I have seen always shows explicit COMMIT after the update. Can this be left to the container?

Also does Hibernate support XA transactions? I will need to do something like so:

begin txn ---> update Oracle RDBMS ---> add msg to JMS queue ----> commit

How can I get this working? Does Spring help with this?

Different client applications might want to include the DAO layer in transactions in different ways.

P.s. I really appreciate all the help I find at The Ranch.

[Valentin Tanase]

Hi Devender,

However, I don't completely understand the reason 2. What you mean by implicit middleware support?

In a nutshell you don�t need to write to any API in order to implement such services. Imagine you run a Java client-server application that need to start/commit transactions. Within your code you�d have to use either JTS/JTA or JDBC api in order to demarcate the transactions (using the UserTransaction object, or calling start/commit/rollback methods of the SQLConnection object). With servlets you�d have to do the same since they don�t provide any middleware services. Using EJBs on the other hand you just specify appropriate transaction attributes within your deployment descriptors and that�s it. Magically the container will know when to start/stop or suspend your transaction. If you look at the CMT beans you�ll notice that they�re not using neither one of the transactional API. Actually using UserTransaction object and transaction specific methods of the SQLConnection are forbidden with CMT. The same with other services like security, pooling or concurrency. The implicit middleware services concept was introduced by Microsoft in 90s, after they released the MTS & COM+ technology. It is still a great concept which didn�t have any rival for a while, but these days AOP is quite a good competitor. I�d say that open source community deserve an A+ for its great contribution in simplifying J2EE development and they won the first round of the �cold war� against the big software guys. It�s my believe that EJB3.0 will turn the battle around and it will be a great success.

am preparing for SCBCD, and I was having doubt that should I take the trouble of studying it or not. Good to know that technology is not completely obsolete yet.

Go for it. Is not only that the technology is far from being obsolete; it�s also about the valuable concepts that the technology introduced. Some of them might be deprecated in the near future, but they still represent valuable software concepts that will help you to better comprehend similar technologies.
Regards.

[Valentin Tanase]

Hi Kelly,

My next question is what about transaction demarcation? My ejb applications use container managed transactions (WebLogic 8.1 transaction manager). Can the ejb transactions be propagated to the hibernate POJO updates? All the example Hibernate code I have seen always shows explicit COMMIT after the update. Can this be left to the container?

The answer is Spring. As far as I know (and without being a Hibernate expert) Hibernate cannot do this by itself, but I might be wrong though. Spring on the other hand can integrate very nicely with Hibernate. For better understanding imagine any of those Hibernate classes without the transactional part. (no commit, no rollback or any implicit/explicit way to start the transaction). Just a class that executes bunch of SQLs. In Spring land you can define aspects, joint points and apply advices appropriately. You also need to register appropriate beans using configuration files, but this is the heart of any IoC. At run time Spring will delegate all request not to the original class, but a special proxy. This proxy will contain the appropriate transactional code (as defined by the advice) along with the original business operations. It basically �inject� the transactional logic at runtime.

Also does Hibernate support XA transactions? I will need to do something like so:

begin txn ---> update Oracle RDBMS ---> add msg to JMS queue ----> commit

How can I get this working? Does Spring help with this?

Different client applications might want to include the DAO layer in transactions in different ways.

Absolutely. With Hibernate you can easily plug in any transactional api you�d like. Both JTS and JDBC are supported but it can integrate with Corba OTS as well, for example. Spring can help again, providing a standard way of managing all configuration files.
One thing you should notice about Spring and Hibernate: they were thought as a way to simplify J2EE development, without restricting the technology�s generality in any ways. Hence most of the things that you can do using an EJB container you should be able doing with Spring. It�s only much simpler.
Regards.

[Roger Chung-Wee]

Also does Hibernate support XA transactions? I will need to do something like so:

begin txn ---> update Oracle RDBMS ---> add msg to JMS queue ----> commit

This is how you would do it.

1. Set up the JMS transaction, creating a non-transacted session.
2. Do a JNDI lookup to get a UserTransaction.
3. Start a JTA UserTransaction.
4. Perform operations.
5. Commit ot rollback the JTA transaction.

You can also use a message-driven bean to process messages. This must be a CMT bean in order for the incoming message to be enrolled in the transaction. The container will run the bean's onMessage() method in a JTA transaction.

I don't think that there is a Hibernate issue, as this is just a persistent technology which your DAO will, in any case, be hiding from the business logic layer in which the EJBs run. Later, you can substitute Hibernate for JDBC or JDO without affecting your EJB or JMS code.

[Devender Thareja]

Appreciate your response Valentin and others. This is very interesting thread.

[Valentin Tanase]

You're very welcome Devender

[Kelly Walker]

Thanks for the response.

I'm not sure I am clear on the answer to my second question regarding CMT and Hibernate. We have a lot of existing logic in SLSB and have invested a lot of money in Weblogic server. I really need the Hibernate code to be able to participate in a global transaction and participate in the WebLogic CMT. It seems it might only be possible by using Spring rather than just Hibernate alone. It may or may not be possible for me to introduce Spring to this project but it seems odd that Spring should be a 'must have' to get Hibernate to work in a EJB environment. Can anyone clarify this? Maybe I should ask in the Hibernate forum?

[Valentin Tanase]

Hi Kelly,

Let me rephrase this again:

My next question is what about transaction demarcation? My ejb applications use container managed transactions (WebLogic 8.1 transaction manager). Can the ejb transactions be propagated to the hibernate POJO updates? All the example Hibernate code I have seen always shows explicit COMMIT after the update. Can this be left to the container?

I actually didn�t comprehend your question exactly and I provided you a different answer. I�ve been mostly answering to a topic about using AOP with Hibernate, which I realize now is not the essence of your question. Sorry for the confusion.
You�re very right though and you don�t need Spring at all. It�s also true that what you�d like to achieve could be easily solved using Hibernate. I also understand that you need clear steps, guidance and probably some code excerpts in order to take a design decision at this time. This is smart and I really respect that. However because the time is short and I�m anyway no Hibernate expert I can indicate you the source of my answers. If I would decide to describe you the steps for implementing the solution I would mostly copy them from the book I read couple of months ago, in order to get acquainted with Hibernate (which by the way is an excellent book and it�s not even very expensive). Hence if nobody on this forum (or Hibernate forum) can convince you about your solution then I�d advice you to read Hibernate in Action by Christian Bauer & Gavin King. There is a subchapter there Using Hibernate in an EJB container starting from page 311 that will guide you through the steps you should follow. Either way in my opinion this is a very useful book for every developer/architect that wants to get started with Hibernate.
Regards.

[Roger Chung-Wee]

My understanding is that Spring is a poor man's alternative to fully-fledged J2EE server such as WebLogic Server. If you use WebLogic Server, then your transactions should propagate into Hibernate. There should, theefore, be no need to complicate matters by introducing Spring.

I suggest you carry out a simple test consisting of a CMT bean which updates your DB via Hibernate. That should work well, with WLS either doing a commit or rollback at the end of the EJB method call.

[Kelly Walker]

Thanks to Roger Chung-Wee.

This is as I though too. I will try some EJB CMT examples with Hibernate and see how I get on. I will post the results once I have them.

I think Spring will still offer some benefits even to those using a commercial strength application server such as WebLogic but I do not think the spring transaction mechanism is for those who run an EJB container?

Spring DAO as an extra layer of abstraction looks useful for when/if we might go to EJB3 from Hibernate3. Will minimise the impact.

Also the bean factory IoC DI looks useful maybe.

[Kelly Walker]

I also would like to thank Valentin Tanase.

I have a copy of the book you recommend on order from amazon!!! So maybe it explains everything nicely.

This forum allows me to bounce my design decissions off you experts. Since no one suggested I was crazy I hope I have made the correct decission and now just need to iron out the low level details.

Thanks to everyone who responded.

[Valentin Tanase]

You're very welcome Kelly

[Mark Spritzler]

Did I say that?

Looking at it again, i must have misread that paragraph, because it doesn't look to me now that you said that. Sorry.

Mark

[Valentin Tanase]

Thank you Mark, you�re apologies are gratefully accepted.