Thanks for the reply. I believe that you are right.
use a Business Delegate to reduce coupling between presentation-tier clients and business services. The Business Delegate hides the underlying implementation details of the business service , such as lookup and access details of the EJB architecture.
Related Patterns:
Service Locator:
This pattern may be used to create Business Delegate's Service Locator, hiding the details of implementation
Proxy:
A Business Delegate may act as a proxy , providing a stand in for objects in the business tier
Adapter:
Business Delegate may use the Adapter Pattern to provide coupling for disparate systems
Broker:
A Business Delegate performs the role of a broker to decouple the business tier objects from the clients in the other tiers
I think I fooled myself by thinking that I could do that using Facade but it is not the standard way of doing it !
Another tricky one
Session Facade
use a session bean as a facade to encapsulate the complexity of interactions between the business objects participating in a workflow . The session facade manages the business objects , and provides a uniform coarse-grained service access layers to clients
Related Patterns:
Facade :
Session Facade is based on it.
DAO :
One of the strategies for the business component in the Session Facade pattern is to use the DAO.
Service Locator:
Session Facade can use this pattern to reduce the code complexity and exploit the benefits offered by the Service Locator.
Business Delegate:
Session Facade is used by Business Delegate when the client requests access to business services .The Business Delegate proxies or adapts the client request to a session Facade that provides the requested service.
Broker:
Session Facade performs the role odf a broker to decouple the entity beans from their clients.
Quotes are from the
great bookcalled Core J2EE Patterns . I just bought it and started to read it few hours ago.
[ January 08, 2002: Message edited by: ersin eser ]