SFSB vs. JavaBean

[mschmidke]

Hello all,

I am wondering which advantage I have from using SFSB as Seam Components compared to POJOs as Seam Components.

As far as I understood Seam manages everything for me what usually the SFSB container would manage for me (persistence context, transactions).

When using Seam, especially the Seam managed persistence context, is there still any advantage for SFSB?


Marcus.

[joeyxxx]

I was told that in JBoss anyway, the developers have spent a lot more time optimizing EJBs. I haven't run any tests yet to confirm this though.

[mars1412]

I'm not sure, if I understood that:

AFAIK:
If you annotate any Java class with @Name, then it's a Seam component.
If you also add @Stateless: its a stateless Seam component - otherwise it's a stateful component.

How would you declare (annnotate) your POJO-Seam component?

[pmuir]

Just with @Name (see many examples).

To answer the original question - yes, EJB3 provides other things - better performance in a cluster, provision of MDBs...

Also, running in an EJB3 container with Seam POJOs is good, as you get container managed transasctions running behind Seam.

[mars1412]

I don't see how a component could be something else than statefull or stateless.

quote from the book: "JBoss ® Seam: Simplicity and Power Beyond Java EE"

we would not need the @Stateful annotation on the POJO. Seam POJO components are stateful by default. And it has the default conversation scope (see Chapter 7, Conversations) if the @Scope is not specified

http://safari.informit.com/search?isbn=9780131347960&searchfor=SearchForCurrentBook&searchmode=simple&searchtextbox=scoped&searchview=summary

well, maybe it's just a matter of definition
Do you I maybe mix it up with 'scope'?

[pmuir]

@Stateful or @Stateless make it an EJB3 Seam component. It can be a plain Seam component without them. Yes, you are mixing up the defaulting rules for scope that come with @Stateful/@Stateless and the scope fo the Seam component.

[mars1412]

thanks, pete
I'll try to sum up and clarify:

• this is a stateless EJB3 Seam component - it is stateless
  

  @Name("slsb")
  @Stateless
  class Slsb {}
  

  
  
• this is a POJO Seam component - it is stateful
  

  @Name("pojo")
  class Pojo {}
  

  
  
• this is a stateful EJB3 Seam component - it is stateful
  

  @Name("sfsb")
  @Stateful
  class Sfsb {}
  

  
  
  in my last posts, I did not differentiate between pojo and sfsb (since both are stateful)
  
  the default scopes are explained in the seam reference @Scope annotation: http://docs.jboss.com/seam/latest/reference/en/html/annotations.html#d0e14787

[pmuir]

This is scope to the request scope by default - so it is stateful across the request but its *not* conversational.

@Name("pojo")
class Pojo {}

[joeyxxx]

Which will provide better perfomance pojos or ejbs if both are being run in JBoss AS?

[ericjava]

This is scope to the request scope by default - so it is stateful across the request but its *not* conversational.

@Name("pojo")
class Pojo {}

Wait, I thought conversation scope was the default scope? It is for SFSBs, right? If I annotate my bean with @Name @Stateful, I get a conversation-scoped bean. If I put just @Name, it's a POJO, and you're saying it's request scoped?

This still doesn't fully answer the question. Most things can be done with POJOs. For example most beans aren't message-driven. For many simple things there is no performance benefit to clustering beans. So, should we be using EJBs or POJOs? POJOs have a benefit of simplicity: no need to write an interface.

[pmuir]

@Name @Stateful (default scope is conversation)
@Name @Stateless (default scope is event, but the bean is truly stateless)
@Name (default scope is event)

If I put just @Name, it's a POJO, and you're saying it's request scoped?

Yes.

This still doesn't fully answer the question. Most things can be done with POJOs. For example most beans aren't message-driven. For many simple things there is no performance benefit to clustering beans. So, should we be using EJBs or POJOs? POJOs have a benefit of simplicity: no need to write an interface.

You've summed up the arguements well, and so can now make an informed decision for which to use ;)

[vladimir.kovalyuk]

At the time of starting new project I used POJO beans with ease. At some point simple things ceased to work and got to work only after moving toward SFSB.

When I employed EntityHome I obtained "stale object" exception. If I understand correctly it happened because persistence context was not propagated and method parameters became detached from context.
It was possible to put merge() calls left and right but code would have became too complicated.

Now I normally handle UI actions by SFSBs that acts as facades and invokes several SLSB in order to access data. Normally I have several SFSB facades working with single SLSB service. In such a case tiered design helps.

I came to conclusion that Seam greatly helps to start up a project with ease using such sort of components like Home, Controller and later grow up to sophisticated application with architecture you like. For me the subject of the thread is not a choise - it's evolution of your project.

Seam is permanently under development and I'd like Seam experts to clarify the following questions for latest version:
1. Does JPA persistence context propagation rules work for Seam-managed conversation-scoped Beans?
2. Is there exceptional behavior in the case of EntityHome?

[pmuir]

"vladimir.kovalyuk" wrote:
1. Does JPA persistence context propagation rules work for Seam-managed conversation-scoped Beans?

No, they are different. JPA persistence context propagation rules are complex. SMPC propgation is simple. You will get the same PC for the length of that conversation injected into the bean. So if you aren't in a long running conversation, it will be the same PC for the whole of the request.

2. Is there exceptional behavior in the case of EntityHome?

No

[ericjava]

If I put just @Name, it's a POJO, and you're saying it's request scoped?

Yes.

Ok, that clarifies things. I was using EntityHome, which is conversation scoped (in Home.java superclass). Then I was using other POJOs and wondering, why are these things not starting conversations? Now I see. I need to put @Scope(CONVERSATION) on them.

This still doesn't fully answer the question. Most things can be done with POJOs. For example most beans aren't message-driven. For many simple things there is no performance benefit to clustering beans. So, should we be using EJBs or POJOs? POJOs have a benefit of simplicity: no need to write an interface.

You've summed up the arguements well, and so can now make an informed decision for which to use ;)

Ok, now I'm getting it. I'll use POJOs. Are there any other limitations on POJOs that are significant for routine use? For example, I assume I can do all the same Seam security stuff on POJOs that I can on SFSBs? And I assume that POJOs can be members of long-running conversations, and can use @Begin and @End on them? This last factor (being in long-running conversations) is the most important.

Thanks

[ericjava]

If I put just @Name, it's a POJO, and you're saying it's request scoped?

Yes.

Waitaminute, looking at the JBoss Seam book (an official JBoss publication), by Michael Yuan and Thomas Heute, on page 320:

However, Seam POJO components are stateful and have a conversational scope by default.

When you say "request scoped" maybe you mean "temporary conversation scoped"?