• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Part II: Session Facade vs CommandBean

 
Alex Pakhomov
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello all SCEA aspirants!
I am trying to figure out the best architecture for my EJB front end. These are two options(patterns) I am considering:
1) Session Facade - Stateful Session Beans = actors, their business methods wrap use cases and interface with Entity Beans
2)Stateles CommandBeans perform atomic operations
depending on session context which is kept elsewhere (Servlet Engine and Swing Client)
Obviously (2) scales much better on the EJB side and extends much easier. However the architecture
for (2) is more complex and requires custom
serialization for the session context. Overall
performance gain of (2) is unclear, especially when both EJB and Web servers run on the same box.
Simply speaking, what is the best place to keep the session context:
stateful EJB or Servlet Engine?
 
Rufus BugleWeed
Ranch Hand
Posts: 1551
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I thought the web servers were tentatively
setup to be on the two 450's.
Are you moving them?
 
Alex Pisarev
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Alex Pakhomov:
Hello all SCEA aspirants!
I am trying to figure out the best architecture for my EJB front end. These are two options(patterns) I am considering:
1) Session Facade - Stateful Session Beans = actors, their business methods wrap use cases and interface with Entity Beans
2)Stateles CommandBeans perform atomic operations
depending on session context which is kept elsewhere (Servlet Engine and Swing Client)
Obviously (2) scales much better on the EJB side and extends much easier. However the architecture
for (2) is more complex and requires custom
serialization for the session context. Overall
performance gain of (2) is unclear, especially when both EJB and Web servers run on the same box.
Simply speaking, what is the best place to keep the session context:
stateful EJB or Servlet Engine?

The best place to keep session state is and always was stateful EJB. Mind the UI clients, you'll not need to create separate session storing mechanisms for them when you're storing sessions in EJB layer.
Alex.
 
Alex Pakhomov
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for your comments, guys.
I agree that stateful Session Beans are designed to keep the session context in between method invocations. But how scalable they are? Stateless session beans are usually implemented as singletons and therefore are very scalable.
Stateful session beans consume the thread pool and can seriously affect performance.
Now, HTTP connections are stateless and (in our case) slow. Why do we need to keep an active thread on the application server for each Web user (thread pool permitting)?
As for the Swing client, it can be designed to be
a bit "fatter" and keep its session context, including the "shopping cart" of itineraries.
Of course, E10000 is a quite a bit of a machine, and if it's beefed up to 64 CPUs and 64 GB of memory, it can compensate for some architectural inefficiences :-)
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic