EJB3 Business Delegates

Question

Is there any reason for making delegate when using EJB3? Because the only real benefit i see from delegate is that it allows to hide lookup and access details of EJB architecture. Well it also provides some decoupling but it's mostly unused, imho. With EJB3 we have injection so now i can just create a variable with @EJB annotation and use it as is. Do i still need delegates? Is this injection resource consuming? I mean if i use it in JSF's request managed beans may be it's still better to use delegates just to lessen these injection calls?

Thank you!

Genovera

You seem to be confused between "Service Locator" and "Business Delegate" - as the answer below suggests, there are different reasons for Business Delegate than to abstract all JNDI usage and to hide the complexities of initial context creation, EJB home object lookup etc – Goodspeed

Answer 1

Let's recap the forces of the original business delegate pattern:

• Presentation-tier clients need access to business services.
• Different clients, such as devices, Web clients, and thick clients, need access to business service.
• Business services APIs may change as business requirements evolve.
• It is desirable to minimize coupling between presentation-tier clients and the business service, thus hiding the underlying implementation details of the service, such as lookup and access.
• Clients may need to implement caching mechanisms for business service information.
• It is desirable to reduce network traffic between client and business services.

All these forces are still relevant today -- they are not necessary present in every project, but could.

The main change is that we don't need the business delegate to minimize coupling (the one in italic). Dependency injection solved the problem of lookup and access.

I like the analysis from Adam Bien: one of the point about coupling that is still not solved naturally are exceptions. Exceptions are now unchecked, but still existing. Whether the client is supposed to be completely shielded from EJB exceptions or not depends again on the forces present in the project.

In the case the business delegate pattern was introduced to solve the problem of lookup and access (which I suspect was the case for a lot of project), we effectively don't need it anymore. If the business delegate was meant for other reasons it can still makes sense.

PS: from my own experience, resource injection was never a performance problem (I always had a more serious performance issue elsewhere than the millisecond taken for the injection :)

Massorete

Answer 2

Business Delegates were just a hack to hide the whole kludge with JNDI lookups and all the related cleanup and error catching. Resource injection came into J2EE through Gavin Kings Seam which basically follows the as-few-layers-as-possible and all configuration in one place principle. So forget about those old patterns and just use normal OO think.

My 2 cents.

Billie

Answer 3

Well, actually i don't quite understand these points.

Presentation-tier clients need access to business services.

Presentation tier in case of JSF is managed bean, isn't it? If it's so then this problem is solved via injection. Right?

Different clients, such as devices, Web clients, and thick clients, need access to business service.

I don't have devices and thick clients. And what is web client? Isn't it the same presentation tier from above? If it's so then we have same situation as above.

Business services APIs may change as business requirements evolve.

I can't understand how actually delegates can help when API changes. Well, of course, if it's just some minor changes that you can handle just by changing type of some passed parameters or use only certain field instead of some parameter then it can help, but i don't think that such situations happen often, and it's not so difficult and may be even better to change method call from managed bean or whatever. While major changes will demand to change method call anyway.

Clients may need to implement caching mechanisms for business service information.

Caching is a difficult question as i don't know what to cache and how to do it :) Does it mean that i can create some variable that will store some results and use ejb call only when this variable is called for the first time? Is it good practice for such shared resources as a delegate should be?

It is desirable to reduce network traffic between client and business services.

How can delegates reduce network traffic? By the same methodics with variable that stores some values?

Genovera