Originally posted by Raj Bhalla:
1)Session beans limit the number of stubs used on the client memory and processing cycles.??
It may or may not, depending on the application. It's really hard to say, given that we don't know anything about your application.
But I will say this: what you're worrying about here is a minor implementation detail. It is far less important than getting the design right.
Use session beans if they make sense in the design of your app. You could design session bean interfaces with methods that are more or less coarse in their behavior - and this might affect performance - but even this is a detail, when compared to the overall design.
Originally posted by Raj Bhalla:
2)Session beans reduce network traffic and thin down clients.?
Without knowing any more details about your app than what you provided, one cannot know about the network traffic issue. If part of your business logic involves validating user input - and you could have done that in Javascript on the client side - then no, you probably will
not reduce network traffic. But in other cases, the answer might be yes. We really need to know more about your application.
WRT thinning out clients: yes, obviously session beans would do that because they encapsulate your business logic on the server side, not on the client side. Thus, it follows that client side logic will tend to be smaller.
I will also add this: one of the benefits of using session beans is that you can centralize your logic and appeal to many types of clients. Suppose you had a voice interface and a web interface to your application. If you put the business logic in the clients, you will have to replicate logic - always a dangerous game because of the error and inconsistency you invite. Also, it may not be possible to code the business logic in some of your clients, forcing you to use a session bean anyway.
Anwyay, if you provide more detail about your application, we might be able to help you better.
