I am using a Business Delegate to successfully hide a local / remote / or custom (http proxy for example) client to the ejb business tier. The business Delegate can also intelligently try and find the services, trying local home lookups first.
For example, a B2B client adapter or heavy applet would instantiate the Business Delegate and tell it to be in "Remote Mode" or possibly a custom mode. The Adapter then consults a factory of "Business Service Locators" and gets the proper interface to the ejb service tier (usually session facades).
Since they are almost always Facades, the business services are implemented with stateless session beans, and the delegate acts as an abstraction layer, hiding all EJB level and remote exceptions from the user of the business delegate.
So, the business delegate is being created by whatever application wants to access the business tier. My JUnit test cases for example use the Remote Version of the business delegate. Only one instance of the delegate is needed and is kept around till the test cases end on that business service.
Where I am confused is in my Web App. Now, I am creating new instances of a local Business delegate whenever I need access to the local tier. My question is should this Delegate Object only be created ONCE for each Http Session, or ONCE per request (like in a struts action), or ONCE per Web Application.
I guess I am confused on the contract for an instance of a remote Session Bean object. Am I guaranteed that multithreaded calls to the same SessionBean EJBObject (hidden inside the delegate) will be executed concurrently, where the container smartly associates a new bean to that EJB Object? Or do I really have a scalability issue where now I need to even pool my delegates, making use of the Delegate object more difficult.
Thanks for any advice...