• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

SFSB behing SLSB session facade?

 
D. Rose
Ranch Hand
Posts: 215
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi ,

Can I have a stateful session bean behind Stateless session facade?
I think as long as I do not need to maintain state across my methods, it should be OK.
 
H. Hafer
Ranch Hand
Posts: 108
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I do not understand: why should this be a problem?

regards,
harbo
 
Kris Melotte
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by D. Rose:
Hi ,

Can I have a stateful session bean behind Stateless session facade?
I think as long as I do not need to maintain state across my methods, it should be OK.


Is it really an alternative to have a SFSB behind a SLSB? How do you transfer the reference of the SFSB to the client? I think that in this scenario the SFSB must have a remote interface as you cannot pass a local reference to the client.

Any comments?

Kris
[ February 21, 2006: Message edited by: Kris Melotte ]
 
Peer Reynders
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Kris Melotte:
How do you transfer the reference of the SFSB to the client?


Originally posted by D. Rose:
I think as long as I do not need to maintain state across my methods, it should be OK.


If you don't intend to maintain state between method calls you don't need to hand out a SFSB reference to the client. However the actual intent of the "SFSB behind SLSB" isn't clear in this case; the original post is 18 months old, so it�s not likely that any additional information will be forthcoming. The only scenario that I can imagine is where the SFSB methods implement the various steps of a business process, some of them optional, while others may be performed multiple times within a single transaction. Then one or more (depending on the number of permutations) SLSBs are used to orchestrate the process for their particular methods and parameters. So in each SLSB method call the SFSB is created, worked on and finally removed before returning.
 
Required Field
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Can you explain why you need to do this? I don't see any reason to ever do such a thing!

The fact that you are hiding a stateful-bean behind a stateless-bean, renders the statefulness of your stateful-bean useless. You could easily achieve the same with a stateless bean, unless you are planning to do some custom hacking to preserve conversation state between the stateful-bean and end-client thru the stateless-bean!

It just sounds like a hack to me, IMHO.



Originally posted by D. Rose:
Hi ,

Can I have a stateful session bean behind Stateless session facade?
I think as long as I do not need to maintain state across my methods, it should be OK.
 
Kris Melotte
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Akshay Shrivastava:
Can you explain why you need to do this? I don't see any reason to ever do such a thing!


I did not like the idea either. But I have seen a similar discussion somewhere else but cannot find it anymore. The idea described in that discussion was to have a lightweight stateless session facade as main entry point for all clients and still having the possibility of storing state in an SFSB in the business tier.
I think that for such a scenario I would use both a statefull and stateless session bean facade or rework the architecture towards a SLSB-only approach.

Kris
 
Peer Reynders
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Akshay Shrivastava:
Can you explain why you need to do this?

Well, apparently I'm not the first one to come up with this kind of a scenario, see:
Andreas Schaefer's Blog: SLSB -> SFSB: Meaningless?
And to whether or not its a hack - we simply do not have enough information on the original poster's intentions.
Originally posted by Akshay Shrivastava:
I don't see any reason to ever do such a thing!

Apparently you still need to be exposed to leviathan, seemingly incongruent, utterly bizarre business processes (at least from a technical person's point of view) that only a lawyer could enjoy.
It�s all a matter of granularity. If your bean method does the equivalent work of your regular run-of-the-mill plain object method then it�s pointless. But that is also the level of granularity that has caused EJB applications a lot of bad press. The bigger the job for a bean method, the better. (However this can also lead to procedural-style rather than object-oriented applications.)
Some business processes are too big for a single SLSB (e.g. too much code, not enough reusability), so any sane person would partition the business logic into plain-old-Java domain classes and save state within the objects - but there are exceptional circumstances where a SFSB may come in handy (as described in the above blog).

In any case, be very sure that you need a SFSB if you plan on using one:
Stateful Session EJBs: Beasts of Burden
  • Just because the EJB spec used a SFSB as a shopping cart, doesn't mean it's a good idea in a real application.
  • For user session management prefer HttpSession over a SFSB.
  • SFSB can be used to track session-oriented state for non-Web systems. However carefully consider that a "thick client" (rather than a browser) can handle structured data (limited by bandwidth) that represents the current state of a "conversation" especially in the form of a custom context object. The primary benefit of a SFSB is that the client's dependence to the context data is hidden in the SFSB (at the cost of the server having to deal with it). If you find yourself storing a lot of session-data that represents a lot of "work" you may want to persist it anyway, so that this "investment" can be recovered after a server crash. The client will then only need a correlation identifier rather than a SFSB as you are persisting the data anyway.

  •  
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic