Design question

[Rajesh kannan]

hi,

I am designing a web app/ Its supposed to have 500 concurrent users.

1. Module- Login
The users login using their uid/password and see the stuff in their database

I am planning to use Struts,jsp,action classes in the front end
Now, back end I am thinking about session ejbs which reads database tables. The method for getting values from database tables will be implemented in a DAO.

Now, what should I use in the middle layer ?
ie, intercation between action classes and session ejb: whos best here ?

what do u all think about this design ?

Again 500 concurrent users
Session needs to e maintained for a whole day[8 hours]

Please suggest..

Thanks

[Ilja Preuss]

I guess that means 500 users *logged in* at the same time? That doesn't say anything about the load they are producing on the server, of course. How often do you expect them to send a request to the server? What load will a typical request create?

With the current information, I seriously doubt that going with EJBs would be a good choice, by the way - it's probably overkill.

[Mark Spritzler]

I agree with Ilja, the EJBs in this case would probably be overkill. Using something like Hibernate with your DAO objects works really well.

You normally want to use EJBs when you want something else to handle your Security, Transactions, EJB LifeCycle, and Threading(?)

Mark

[Steven Dolan]

Why would EJBs be an overkill?

It is all about the data you want to retrieve from the DB. If the data is read only and there are little transactions involved then you better go with DAO. On the other hand, if your application is highly transactional in nature then EJB is your best choice.

You can use HttpSession to maintain the user session in the web tier and use SLSB in the middle tier.

Now, back end I am thinking about session ejbs which reads database tables. The method for getting values from database tables will be implemented in a DAO.

This means you are planning to use BMP which is not recommended if you can use CMP/CMR. You use DAO if you plan to implement entity beans yourself, otherwise the container will handle the DB access code for you.
[ July 16, 2005: Message edited by: Steven Dolan ]

[Rajesh kannan]

Thanks for the replies.

Yes 500 concurrent users. They will be logged into the web site which delivers messages to them. The messages which come from some external systems will be stored in the database.

The actual requirement is : whenever a new message comes to the database, this has to be delivered to the user's screen [based on the userid in the message] and it has to be a real time scenario. I still dont know how to initiate the server side calls .. Any ideas, please share.

Avoiding EJBs is what I am looking for, I have previous experiences where EJBs behaved bad.

In the middle "SLSB " - what is this ?

I plan to have DAOs where database transactions like select will be written and a session EJB[stateless] to call methods of the DAO. Will session ejbs be an overkill ? if yes, what else be a work around ?


Thanks,
[ July 18, 2005: Message edited by: Rajesh kannan ]

[Stan James]

Your last description helps. Sounds like you have two events to handle:

1) New message added to database. How will you know when this happens? If the message comes in over some program-to-program protocol like JMS or XML over HTTP and you update the database then you'll have code that is executed when they come in. If your other message sources just write to the database I'm not sure how you'll know a new message has been written.

2) Forwarding the message to the user. If each message goes to only one user I might look at the applet with server socket again. The server could open connection, send message, close connection in a couple seconds.

[Rajesh kannan]

Stan,

Your last description helps. Sounds like you have two events to handle:

1) New message added to database. How will you know when this happens? If the message comes in over some program-to-program protocol like JMS or XML over HTTP and you update the database then you'll have code that is executed when they come in. If your other message sources just write to the database I'm not sure how you'll know a new message has been written.

2) Forwarding the message to the user. If each message goes to only one user I might look at the applet with server socket again. The server could open connection, send message, close connection in a couple seconds.
-

For 1: we have a set up which exists right now in the current client/server application, there is a thread which runs for 8 hours, this thread inserts the messages to the database. There is a shell script which starts this thread every day morning. Can I have a similar J2EE implementation ?

[Rajesh kannan]

Please give me some replies..

Thanks,

[Balachandran Paranjothimani]

Architecting a J2EE application involves lot of work. If you are not familiar I would suggest that you prepare and take J2EE architect exam. Of course, this has to be combined with real world experience working under an experienced J2EE architect to learn how to solve the real world issues.