Thank you for the clear and good description reply.
We are getting closer to the real problem that I addressed.
As you said :
facade can exist of several session beans, each session bean is a facade to it's business objects. So there is no big/fat facade.
This can be right, but I see in my experience that there is a trend to avoid using so many EJB / session beans or I would like to say a trend to avoid using so many (expensive) components.
This approach then put all business objects together under one big facade. Big here means these facades handles many business objects as possible, and simply delegates the request, and these business object should not be Session beans and should be just simply Java class... The reason is because the big facade handles all your need includes transaction, pooling, security and etc.
It seems to be right approach but addressed some problems, and I like your reply about to build a prototype to evaluate the performance/scalability requirements. But sometimes we cannot perform this prototype due for some reasons (like doing SCEA exam part II).
[ February 23, 2003: Message edited by: Alex John ]