BusinessDelegate implementation

[ramnna jain]

I have a Struts based project code... EJB is not used in the project... but tiered pattern is used.

In BusinessDeligate class definition, it declared static instances of all Implementer classes.
It(BusinessDeligate class definition) declared static methods. Inside those method they used the
static instances declared earlier, to invoke methods in the Implementer class definition.

I am stating the code sample below.

    
....

public class EditProfileAction extends DispatchAction 
{

  public ActionForward execute(ActionMapping mapping, ActionForm form,
        HttpServletRequest request, HttpServletResponse response)
        throws Exception 
        {

              UserDTO user = BusinessDelegate.retriveUser (userDto);
             
             ...
        }
}

    
...

public class BusinessDelegate
{
    static UserServiceImpl userServiceImpl = new UserServiceImpl();
    ...

    public static UserDTO retriveUser (UserDTO currentUserDTO)
    {
        return userServiceImpl.retriveUser(currentUserDTO);
    }
    ...
}

I want to know what would happen if users accessing the same method at the same time,
then how would it decide which response to return to whom!
Is this correct code?

[Hong Anderson]

No need to use this pattern if you're not using EJB 2.x.

[ramnna jain]

What if some one wants to separate presentation tier & business tier so that any changes in either tier need not to affect the other....!

Actually I have some confusion in above code: We have one instance of each ServiceImplementer class & the one instance is used to execute
methods of it's own, by different users simultaneously.... now if ServiceImplementer class has instance variable then the instance variable may
get changed accidentally by simultaneous access...!

[David Newton]

Patterns like this have nothing to do with EJB, and separating concerns is a good idea.

It depends on if the delegate (service) is thread-safe. If it is, then you have no worries. We don't know how it's implemented, so we can't tell you if it's safe or not.

[ramnna jain]

Thank you David, could you please tell me how we can make sure our BusinessDeligate is thread safe.

Could you recommend some manual which can help me to learn it specially when I am not using EJB.
Is it necessary to declare DTO as Serializable... when I am not using EJB?

Again thank you very much for guidance.

[Hong Anderson]

ramnna jain wrote:What if some one wants to separate presentation tier & business tier so that any changes in either tier need not to affect the other....!

What changes? JNDI names? If you don't use EJB 2.x you don't need to use JNDI/Service Locator directly much (or no need to use directly at all).

Business Delegate is merited in EJB 2.x because of the over-complicated programming model. We need to look up a EJB, get home interface, get component interfaces, handle Remote exception. Business Delegate can centralize the boilerplate code.

Regarding changes, if business service API has changed we need to change business delegate as well.
For instance, if a Business Service has 5 methods and we have 1-to-1 mapping to 5 methods of a Business Delegate, if we add 1 more method to the Business Service we need to change the Business Delegate API as well, otherwise how can we support the added method? The same goes for the case that a method's signature has changed.

[Jimmy Clark]

Using the Business Delegate is a very good design decision. It does not matter whether you are using EJB or not.

Think of the Business Delegate as an object not a class. Remove all static methods and static variables from the implementation.

JNDI lookup code should only exist in a single place in the Presentation tier, and the Business Delegate is a good place to put it.

If you are not involved in three-tier programming, then you don't need to use Business Delegate design pattern.

[Hong Anderson]

Business Delegate is suitable for EJB 2.x because the overly complicated programming model and remoteness nature.
Actually it's suitable for any distributed systems for hiding remoteness, but for Java EE the easiest and most robust way to implement distributed systems is to use EJB. Necessary to implement a distributed system for most web applications is another question.

If we're using EJB 2.x, this pattern (or workaround) is very useful because if we don't use it, we need to write code to look up service, get home interface, get component interface, handle NamingException, CreateException, RemoteException in every presentation tier (or every client) code.

However if our application is not a distributed system we don't need to handle RemoteException, and if we're using IoC container like Spring Framework, we don't need to apply ServiceLocator or use JNDI at all as Spring provides JndiFactoryBean class.

Or if we're using EJB 3.x, it introduces Dependence Injection (thanks to Spring Framework to move Java EE platform to right direction), and there are no "Home" interfaces anymore, we can inject Stateless Session Beans directly to Servlets using @EJB annotation, so it's not much useful to apply Business Delegate pattern as it introduces a consequence in adding an additional layer which add complexity to the system without adding much benefits (if any).

Regarding minimize changes when a Business Service has changed, I don't agree much as I mentioned, if the Business Service API has changed we need to change Business Delegate API as well which will impact all the client code that use the Business Delegate.

[Jimmy Clark]

... we can inject Stateless Session Beans directly to Servlets using @EJB annotation ...

LOL

[Hong Anderson]

James Clarks wrote:

... we can inject Stateless Session Beans directly to Servlets using @EJB annotation ...

LOL

I don't know what you think it's so amusing. Just in case you don't know we can inject SLSBs to Servlets using @EJB you can read the article as follows:
Using an EJB Session Bean as a Model Facade