JSF and SessionBean

Hi,

It sounds like your application is not using EJBs. Basically, when you build an app you can choose whether to have a web-only architecture or whether to use the EJB container.

1) EJB style architecture for your app

If you choose the EJB style of architecture then you app might be like

JSFPages-->ManageBeans-->SessionBean>>Java Persistence(or in your case hibernate)

For simple cases, the Session Bean can seem like an extra class but for more complex cases it can be a facade and be a benefit.

2) Web-only style architecture for your app (not using any EJBs)

For web-only, you could have something like this for simple cases

JSFPages-->ManageBeans>>Java Persistence(or in your case hibernate)

For this Web-only style, as an application gets a bit bigger and more complex you might want to use the facade pattern to clean it up a bit. In this case you might add a web component as a facade (instead of a Session Bean) . For a web-only application, you could have a facade class and it does not have to be an EJB.

JSFPages-->ManageBeans>> Facade (POJO or web component) --> Java Persistence(or in your case hibernate)

So bothe styles, 1) and 2) may use a facade.

The facade pattern in Java EE 5 is discussed in https://blueprints.dev.java.net/bpcatalog/ee5/persistence/facade.html

There are pros and cons to whether you choose a web-only architecture or an EJB style arcitecture. Most of it has to do with developer skills and preferences(what technologies you are comfortable with) .

Here are a couple pros/cons between choosing 1) or 2)

--Cons of using EJBs: you have to know another technology and learn EJBs. Learning another adds to complexity of getting started. The app must run on an EJB container so cant run on just Tomcat for example.

--Pros of using EJBs (in EJB 3 part of Java EE 5)have some services that make developing an app a bit easier, like container managed transactions, container-managed entity managers, dependency injection, some Java EE annotations, and a few other services. Easier integration with Java Persistence APIs.

--Cons of using web-only are that you have to write code to use JTA APis to manage transactions, and code to managed entity managers (part of Java Persistence)

Also, Java Persistence APIs http://java.sun.com/javaee/overview/faq/persistence.jsp are a newer technology in Java EE 5 that is sort of a standard version of hibernate capabilities. You could use hibernate with new Java Persistence but in a Java EE 5 application you might not need hibernate, especially if you are using EJBs and Session Beans.

hth,

Sean

> I am having an application that uses JSF and

> hibernate. I would like an advice for its

> architecture. In JSF we have the managed beans.Lets

> say I

> want to call a method createUser(). I would call it

> from the managed bean and then?I should use a

> delegate-->SessionBean-->DAO?

> Or is it ok if I call this method from the managed

> bean and then go directly to the DAO? What is the

> benefit of using a SesssionBean?

>

> Thanking you in advance.

seanbrydona at 2007-7-9 0:07:15 >

Hi,

Yes, the benefits of container managed transactions and container-managed entity managers are part of the Java EE application server. But you can not use them on every type of class. In Java EE app servers, the standard way to use these services is on EJB components. JTA provides the transaction management under the hood, and using deployment descriptors or annotations on an EJB component such as a Session Bean is how you use the container managed transactions(which use JTA under the hood).

There may be some non-standard frameworks that could extend that capability and offer cantainer managed transactions and container managed entity managers on web components or other types of Java classes. But they are only available on EJB components in standard Java EE. Hopefully, IMHO, that will be available in Java EE 6 in the future as a stnadard service, but it is not in Java EE 5.

So for web-only applications with no EJBs, there is no container managed transactions, and instead you have to use JTA calls in your code (application-managed transactions)

public class MyServlet extends HttpServlet {

@Resource UserTransaction utx; //or JNDI lookups

and then in some method you begin,commit, rollback or close a transaction like this

public void doGet(....)

try {

utx.begin();

......//do something

utx.commit();

} catch(Exception exe){

System.err.println("Error persisting item: "+exe);

try {

utx.rollback();

} catch (Exception e) {

...

} finally {

em.close();

}

}

So for web components you have to write the JTA code to manage the transaction.Whereas with container managed transactions you do not have to write the code for JTA, it is done under the hood by the container. But this can only be done for EJB components such as Session Beans

hth,

Sean

seanbrydona at 2007-7-9 0:07:15 >

First thank you for your answers. So from what I have understood the benefits that Jboss for example offers for managing the transactions can be used when Session Beans are used otherwise the developer has to take care of it by himself.(eg beginTransaction())

What I did not understand is when you are saying that we have Remote calls when the web container and the application server are on different machines?How can this be happening? The web container and the application server are not the same such as JBoss?

juanitaJa at 2007-7-9 0:07:15 >