• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Move Session State Away from EJB-layer for SLR?

 
Rudi Vaum
Ranch Hand
Posts: 59
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Context:
- having a J2EE app, including ejb-layer,
- one web-client,
- one rich intranet client, a for limited nummber of users;
- and one service-level-req.:
under heavy load:
the rich client must outperform the web-client
Proposed architecture:
I thought I can keep the ejb layer... aaa.. lighter, by moving state-logic & computing towards the client.
The further this logic from the ejb layer, the better application performace get, especially under heavy usage.
Under heavy load, the web-server will eventually work slower, having to serve lots of clients and process session state themselves.
The intranet clients would only access business objects in the ejb layer, and process session state themselves - therefor beeing quicker.
Agree?
And how can I justify this better?
(blueprints team strongly recomends keeping state on EJB-layer as SFSB - this is a "best practice")
Rudi
 
patrick jiang
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If your business logic is on client side, how does the client retrieve the data? Business logic has to be processed on data from database or other EIS/Legacy system. So, the more business logic code on your client, the more dat a transmitted between your client and server. How can a system like that be better performance?
 
Rudi Vaum
Ranch Hand
Posts: 59
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
well, there is a difference between managing session state and "business logic"(this term is as big and triky as ".NET" or "WEBSPHERE" ), in some respect.
Remember the MVC pattern?
->The Model is composed of Data and Business Logic to handle that data.
->The Controller has got the inteligence to get the requests from from the view, transform them into calls to the Model, and give the info back to the views.
As the blueprints book says, the controller of a web app might use some cache objects to keep a part of the model that was retrieved throgh calls duplicated on the web-layer (this would answer one of your questions)
Managing session state, is something that a controller does (see 4.4.7.3.1, same book)

In the case of a multitiered MVC, i choose to move controller functionality (including session state management) out of the ejb-layer. Under heavy-load, the clients themselfes (a few Standalone Apps running on separate machines in the intranet and the Web Container(s)) would do this.
hope this clears my ideas to you,
please comment my design
Rudi
SCJP, SCEA I
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic