Design Issues

[Nadeem Awad]

Dear All,
We have the following design for our application:

Presentation Tier    |          Business Tier             |      Database
                     |                                    | 
  JSP and Struts     |    Statless Session  Beans         |   Stored Procedres
                     |____________________________________|
 Struts Action class | Facade with       | other local    |
         |           | remote interface  | beans to hold  |
         |           |                   | business logic |
         |           |                   |(also Stateless)|
         |           |                   |                |
         |---call--------> forward ----------> call --------------->

As you can see, the flow of the system is as follows:

The Struts action class locates the fa�ade remote interface through the service locator, and calls the desired method.

The fa�ade delegates the call to the appropriate local stateless session bean.

The local bean calls the corresponding stored procedure from the database, wraps the result in the appropriate value object, and hand it back to the caller.

I have two questions:

1. The fa�ade methods are duplicated in the local beans, the only difference is that the local beans categorizes the methods in terms of functionality, otherwise they are exactly the same. Therefore, I feel that the fa�ade layer here is unnecessary; it should be removed and replaced by a Business Delegate at the client side. The local session beans interfaces should be converted to remote to be accessible to the delegate. Is this correct?

2. I can�t see the point of EJBs existence here at all, since their only functionality is to call the stored procedure and wrap the result with the appropriate value object, and we are not using any of the features that the EJB container provides, such as transactions and security. So I think that the EJB tier should be replaced by DAOs, which are POJOs of course, to do this job. Am I right?


Best regards,
[ March 28, 2006: Message edited by: Nadeem Awad ]

[Mattias Arthursson]

1. In my opinion you should think very carefully about whether you actually need to have remote beans at all. There are very few cases in which that is necessary, and performance will definitely be affected negatively. If you eliminate the remoting, you can modify the business tier to be POJOs as well; in which case the need for a facade will probably also be eliminated.

2. Again, the only reason to use EJBs in this kind of solution would be if you absolutely want to have the business tier on another machine than the web tier. As stated above, this should very seldom be the case (remember Martin Fowler's First Rule of Distributed Computing: 'Do not distribute').

All in all: yes, I would probably eliminate the EJBs and add a thin business layer which in turn calls DAOs that perform the database work. POJOs everywhere.

[Nadeem Awad]

Thanks for your reply Mattias.
Let's say that we need the EJBs at this point and we can't eliminate them. Is the current design the best that can be done? Or it should be modified to what I stated in my first point?

Best regards,

[Mattias Arthursson]

Well, you would benefit from creating a business delegate on the client, in that your Struts implementation becomes completely independent of the underlying implementation of the business layer. If you then decide to get rid of the EJBs later on you won't need to change anything in the Struts code - you just replace the business delegate implementation with one that works against your new POJOs.

If you have a Business Delegate, the EJB facade pretty much only becomes another level of indirection, so I guess you might as well program directly against the individual beans.

However, if you really want to make a difference with the system, one that matters, you really shouldn't use remote beans at all; you should be able to do everything in the same virtual machine (programming against local interfaces). I'm quite confident that this would improve your performance, whether you use an EJB facade or not.

[Stan James]

I like the Business Delegate a lot here. If you have any doubt about the future of the technology on the backend it sounds good to hide the tricky bits inside the BD so the client won't be hurt by changes. We use a vendor framework with a proprietary BD that can plug in remote EJB, raw sockets or XML/HTTP protocol to call any particular service. It would be easy to provide a "null" protocol that just calls POJO services.

You could go for the simplest possible solution until some kind of tests prove that something else is needed. If you have solid POJO services it will be easy to put them behind stateless session beans if and when you can prove they solve some problem.

[Padma Lalwani]

I agree.
We are using stateless session beans to avail the Container Managed transactions service. This enables us to rollback across multiple data sources

In CMT, we will need to use session beans for components whose atomicity needs to be independent of calling component
In these cases when we are certain it is a local call on same JVM, the business delegate can get handle to local interface rather than remote interface. This should avoid overhead, though I am not certain if this is same as a POJO call

And yes, business delegate is adding a layer of transparency over the ServiceLocator. ServiceLocator will do the jndi lookup, but the Struts controller is still aware of home and remote interfaces, whereas in Business Delegate, the controller is unaware it is talking to session bean

Padma

[Stan James]

the controller is unaware it is talking to session bean

That's a spicy meatball!

If you haven't been steeped in the most inane American pop culture for enough decades, that was from an ancient TV Commercial, but it still means that's A Good Thing.
[ March 29, 2006: Message edited by: Stan James ]