As a solution to this problem I can think of one more pattern which I've used. This pattern basically uses business delegate pattern with a deviation that, the client code can use factory pattern to get the name of business delegate class dynamically without hard coding the nameeven need not hard code the business delegate name.
In short the combined pattern is like this
1. Every request is mapped to a request id.
2. An interface, namely Controller, is there which has a method execute()
3. There are number of BusinessDelegate classes which implement this controller interface. The execute() method in every BusinessDelegate class is implemented differently calling the appropriate Session Bean.
4. In another supporting simple singletone Java class, namely ControllerManager, all the request ids are mapped to the name of one or other BusinessDelegate class.
5. The client, based on the request id dynamically gets the name of the BusinessDelegate class to be called from the ControllerManager and dynamically instantiate one object of that class. After that the client calls execute() method of that object.
I think this pattern is also used in Java PetStore application. I'm suprised why this pattern is not covered in EJB Design patterns book in the section Client Side EJB Interaction patterns
It looks to me you're talking about plain Command objects, each implementing the famous old execute() method.
IMHO one of the main advantages of the Business Delegate should be to have a semantically rich interface, leading to a much more readable code. The best would be to have a Business Delegate 'implement' (perhaps not in the Java term) a common Business Interface with the EJB it proxies. This helps coding the different calls to the Business Layer as one can use the code completion tool provided by almost every IDE when invoking method on the Business Delegates.
It looks more like a sphagetti code to me . Isnt what we do for Front Controller Pattern when the client calls the main servlet and the servlet depending upon a ID , instantiates a Action class and calls its execute method . You can use the same logic wherever you want . I am not sure what was new about this .
I played with this idea and finally decided because of reasons cited in the other reviews that the facade should expose the actions performed by the commands as actual method calls. Each method would then use the command pattern to execute the action. The action is found through a factory using the action keyword. This gives you the best of both worlds. A clear interface to the external world mapping action keys to methods and a very flexible implementation. The actual action class name executed can be placed in a property file allowing for plug and play functionality. The actions can be cached or not depending on the performance versus scaleability decisions. Actions can be combined to build complex behaviors allowing for modular code design and a great amount of code reuse.
This is not actually the business delegate pattern at all. A business delegate usually acts as a proxy for the session facade, encapsulating the remote/EJB logic and JNDI lookup. Business delegates usually expose the same methods as the session facade and simply DELEGATE (hence the name) the call to the session facade that it represents.
The pattern that you are describing is actually covered in Sun's J2EE patterns and is called the Service to Worker pattern. In this pattern requests are mapped to command objects that are executed by the Front controller/dispatcher. These command objects may then make use of the business delegates to perform the business logic they require. In this way many different commands may make use of the same business delegates.
I agree. This is command pattern. Command pattern takes on these roles & eliminates the need for separate 'Business Delegate' & 'Facade' classes.
Also, there are several variations of command pattern implementations around.
You say Business Delegate class is instantiated every time a request is made. Is it not better to keep the Business Delegate class in some scope e.g. application or session in order to avoid the over head of lookup and getting remote stub ?
If you have an application in which you've decided to use an MVC
design can anyone tell me how Business Delegate and Session Facade patterns
fit into this?
please ,does someone have the code source of the ejb design pattern book.
really I need it.
thanks for your help