General design questions

[Marcelo Ortego]

Hi All,

I will not mention the assignment which I am working on for obvious reasons. All questions are general design questions only. The reason for these questions is that I have not designed / worked with JSF / EJBs commercially.

General design:

- BusinessDelegate lives on the client side (in this case the web tier) – only one type of BusinessDelegate exists.
- JSF ManagedBean uses BusinessDelegate to access the business tier
- BusinessDelegate uses a ServiceLocator to access a SessionFacade found on the business tier
- SessionFacade centralizes transaction management and security, then uses DAOs for CRUD operations
- DAO uses JPA EntityManager to store / retrieve Entity objects

Given the above design:


1) First and foremost, does the above design look like a standard design, or am I completely off track?

2) Where does the FacesServlet (FrontController) fit into all this? Cade’s design shows the JSP pages use a controller, which inturn uses the manager classes. Using JSF and the above design, would the flow look like: JSF --> FacesServlet --> ManagedBean --> BusinessDelegate.? Wouldn’t the JSF page have a dependency to the ManagedBean… like: JSF --> ManagedBean (see below – doesn’t seem right to me):

JSF page -----------------> FacesServlet
|            <<uses>>              |
|                                  |
|                                 \|/
|-------------------------> ManagedBean
      <<uses>>                     |
                                   |
                                   |
                                  \|/
                           BusinessDelegate

3) Cade’s design shows that the controller accesses the managers. Are these managers the SessionFacades in the business layer?

4) In general, would we normally have a SessionFacade per “service” / “business area”? Or one monolithic one which encapsulates access to all services? (I’m thinking the first approach).

5) Lastly, would there only be one BusinessDelegate which accesses many SessionFacades, or many BusinessDelegates?


Any help would be GREATLY appreciated! I hope the questions make sense - I will clarify if needed.


Many thanks,
Marcelo

[Jeanne Boyarsky]

Marcelo,
Welcome to CodeRanch!

1) Why do you need a service locator in JEE5? Can't you just inject the bean?

2) The four step flow is valid. I chose not to show all the JSF layers in my submission and wrote as an assumption that I assume the developers know how JSF works. That let me focus on the point instead of the flow of JSF.

3) Not sure. I lent someone my book and can't check the diagram.

4) Either approach is valid. I prefer the first as it is clearer and more common. And better design in my mind.

5) Again, either is ok. One question though - why do you need a business delegate? Do you have clients other than JSF?

[Marcelo Ortego]

Thanks so much for your prompt reply Jeanne!

Although currently there are no requirements for different client types - the business delegate is used mainly to access the business tier in a uniform way and to decouple the presentation logic from the business logic (apart from handling exceptions, helping with performance, etc). I'd like to hide remoteness from managed beans.

I feel that having the business delegate will help with maintainability and the system will be able to cope with changes more easily.

Please correct me on the above.

Regarding the service locator... The reason I thought to use it is basically because the presentation and business tiers will be on two separate machines (across a network). My understanding is that injection will only work when deployed within the same ear file.. So this raises a few more questions..

1) Is this statement true? (injection will only work when deployed within the same ear file)
2) Is it possible to have an ear file separated into physical tiers - presentation (war file), business (jar file), etc
3) If question 2 is true, can I have Server2 (business tier) inject resources into Server1 (presentation tier), transparently?

Thanks again.

[Marcelo Ortego]

Can someone please clarify?

[Rajan Choudhary]

Marcelo,
Did you peek in my initial design magically and how are you stealing my questions/thought? Just kidding - We have so much in common.

I agree with you, Service Locator still makes sense as there are plenty of things you could lookup like email sessions, web service end points, LDAP context, JMS Queues, QueueConnectionFactory etc. I have it in my design.
Moreover, I had Business Delegate in Web tier but I noticed in Patterns catalog, it's shown in Business Tier and I put a question in the forum. Somebody blasted me, how could the BD be in web tier? so I changed BD from web to business tier.

Also, why do you need DAO between ejb and JPA. To me it didn't make sense so I use DAO between EJB and DB only when fast lane reader and/or value object handlers are required. Let me know your thoughts about it.

Let me share my thought about your questions. (I may be wrong)
1) Yes
2) Definitely possible to deploy EJB at app server in a separate ear and web file in different server. I like this approach BUT still, I would go with single ear deployment at all app servers (clustered horizontally and vertically) and static contents at web server which is in DMZ.
3) I think, NO. Lookup is best.

Anybody, please feel free to correct me. This will help me as well.

[Rajan Choudhary]

Please share your comments.

[Marcelo Ortego]

To me it makes more sense to have the business delegate on the web tier. The reason is that a primary goal of the BD is that it hides remoteness. Having said this, if the BD is on the business tier, then the web tier would have to perform remote lookups (if we didn’t use injection). The part of BD which makes me think it should reside on the business tier is the “uniform interface to business tier” – but this could be both on web and business tiers.

Please take a look at the following URLs and advise. The second URL shows the code of a business delegate. Take note in the package name. Also, look at the first URL (not sure if they’re out of date). Any corrections / clarifications would be appreciated.

http://java.sun.com/blueprints/patterns/BusinessDelegate.html

http://download.oracle.com/docs/cd/E17802_01/blueprints/blueprints/code/jps131/src/com/sun/j2ee/blueprints/admin/web/AdminRequestBD.java.html

[Marcelo Ortego]

Anyone?

[Rajan Choudhary]

Looks like BD and ServiceLocators can be in web and/or business tiers as per the Link

Now to me, if web and ejbs are delivered in the same bundle (deployed in same container) then location of BD or SL would not matter. The app will work fine.

If the web and ejbs are deployed in separate containers then BD and SL should reside in web tier so that it can look up the remote services.

Does this make sense?

[Marcelo Ortego]

Sounds right to me Rajan.

[Usman Ibrahim]

2) Definitely possible to deploy EJB at app server in a separate ear and web file in different server. I like this approach BUT still, I would go with single ear deployment at all app servers (clustered horizontally and vertically) and static contents at web server which is in DMZ.

Rajan,

Regarding static contents at web server and other resources in app servers, will you show the HttpClusterServlet in any of the diagrams?

[Rajan Choudhary]

I am not using HttpClusterServlet at all. Planned a different approach.

[Saurabh Deshpande]

Marcelo Ortego wrote:Sounds right to me Rajan.

I think you are doing over solution. If your scope is design a web application and if you are going to use JSF then you can access EJBs / WSs POJOs through Managed Beans dependency injection. This eliminates BD and SL and you can assume your EJBs POJOs are on the same local.

SD

[Marcelo Ortego]

I think you are doing over solution. If your scope is design a web application and if you are going to use JSF then you can access EJBs / WSs POJOs through Managed Beans dependency injection. This eliminates BD and SL and you can assume your EJBs POJOs are on the same local.

Totally agree with you. In particular the SL isn't actually needed. But... I'm thinking of using the BD on the web tier for one main reason.. It will provide a uniform interface to the business tier. All Managed Beans will access the BD. This will basically embrace change on the business tier. If the business method signatures change, we will only need to change the BD, rather than all Manged beans. The Managed beans (client code) will be shielded from how and what to invoke on the business tier (depends on the change of course).

Please feel free to persuade otherwise - constructive criticism is always good!

[Saurabh Deshpande]

Ok heres my point of argument. I have been also back and forth but I did a lot of reading on this topic.
1. Managed Beans are not client code. They are server side code.
2. Managed beans are actually part of Model in the MVC framework. Same layer as BDs :-)
These 2 points convinced me not to use BDs and SLs especially considering my EJBs or POJOs were going to be local so I can do DI in the Managed Beans.
Ofcourse you want to solution for multiple clients (remote as well) then we can use BDs.
Read this article which explains what gets avoided if we use DI
Read this article for BD the context and problem. Are you trying to solve this? If answer is yes use BD. :-)

SD

[Antoni Mysliborski]

Marcelo, I don't really see how BD would protect you from changes in business interface. I mean, if you make change in BI, it is usually because you need to add/change parameters (which means you need more/different information from the client), and BD will have no way to provide those informations "automagically" (if it has, then it's an obvious sign that there was no point of changing BI).
If you change your BI just because you want to clean up some mess, it's better to do refactoring than to keep this mess in client (what would happen if you have just changed the internals of BD, without changing its interface).
If you will ever develop another client, having BD in the old one wouldn't be of any help. It would be if you decide to use existing client with different business tier, but it's very unlikely (unless in some specific case).

The only case I can imagine where BD would do something more then simply delegate the requests is if we have Session Facade with parametrized behavior, and you want to hide this complexity within BD (with adding default parameters depending on the usage), but in such case I believe it's better to prepare different versions of SF for different cases.

[Chaminda Amarasinghe]

Rajan Choudhary wrote:Marcelo,
Did you peek in my initial design magically and how are you stealing my questions/thought? Just kidding - We have so much in common.

I agree with you, Service Locator still makes sense as there are plenty of things you could lookup like email sessions, web service end points, LDAP context, JMS Queues, QueueConnectionFactory etc. I have it in my design.
Moreover, I had Business Delegate in Web tier but I noticed in Patterns catalog, it's shown in Business Tier and I put a question in the forum. Somebody blasted me, how could the BD be in web tier? so I changed BD from web to business tier.

Also, why do you need DAO between ejb and JPA. To me it didn't make sense so I use DAO between EJB and DB only when fast lane reader and/or value object handlers are required. Let me know your thoughts about it.

Let me share my thought about your questions. (I may be wrong)
1) Yes
2) Definitely possible to deploy EJB at app server in a separate ear and web file in different server. I like this approach BUT still, I would go with single ear deployment at all app servers (clustered horizontally and vertically) and static contents at web server which is in DMZ.
3) I think, NO. Lookup is best.

Anybody, please feel free to correct me. This will help me as well.

Hi Rajan,

I have doubt about your answer to #1, For my understanding this is not true. If I can remember correctly JEE spec only noted "Same JVM" not "Same application or EAR". Actually I have personal experience that we have deployed separate EJBs and WARs on JBOSS (Single Node) and injection works fine.

Regards

[Rajan Choudhary]

Yes, injection works fine within same JVM but I said if you deploy ear file of your ejb in one container and then war file of (web contents) in different node, then injection might not work as the JVMs are different so we 2 are saying same thing here. I am not getting what's the confusion.

Secondly, about the point#1: Yes, I consider JSF and it's components including Managed Bean and JSPs as client of Business Tier (EJB). Managed beans are packaged into war files which are essentially clients of EJB (ear) or another war components.

[Marcelo Ortego]

Antoni / Saurabh,

Your comments make sense and I appreciate them. I will consider them closely. I may not have given my full intentions though (like the possibility of different client types). I believe the Business delegate still has it's place in JEE - we just need the correct requirements.

[Antoni Mysliborski]

Well, in case of completely different clients, that would have different requirements when it comes for services of business tier, I believe it's better to create specialized Session Facades for each client than to expose "super SF" that can handle all cases, and have lots of redundant methods and parameters.
The only case I would agree BD may be useful, is if you add another client type to the existing business layer, and don't want to change anything in existing functionalities. Still Session Facade would be much better place to provide different set of functionalities than BD. BD in original had the role of containing in it all the "nasty" EJB code, like EJB checked exceptions, lookups etc.

BD could be useful if you don't control the server code (another party is implementing it) and therefore the protection from frequent server API changes is indeed desirable.

[Kumar Amit]

Another option here is to use Managed beans as Web tier's Business Delegate i.e.
JSP-> BackingBean (<<ManagedBean>>) -> BusinessDelegate/Coordinator (<<ManagedBean>>) -> SessionBean

For example:
CreateProject.jsp-> CreateProjectBackingBean (<<ManagedBean>>) -> ProjectCordinator (<<ManagedBean>>) -> ProjectManagerSessionBean

This will decouple backing beans from invoking ejbs and @EJBcan be injected in the Coordinator managed bean. Is this a correct approach?

[Chaminda Amarasinghe]

Hi Rajan,

For my understanding purpose of building ear is to bundle 2 or more of ejbs, wars, jars and app-clients to deploy on one node.. of course we can deploy them in different server like ejbs on jboss and wars on tomcat connected them via j_mod. But in that case we no need ear.

Regards

[Ranganathan Kaliyur Mannar]

I am also using JSF and I decided against having BD and SL. And, I think if you decide to use BD, SL automatically comes in. This is bceuase of the restrictions on the usage of dependancy injection outside of JEE components (I am not 100% sure about this). But, if this is true, BD is not a 'container managed' component - so, DI may not work from BDs - so, you are kind of forced to use SL.
I just thought with JEE 5 making things simpler, BD and SL are not needed. Also, my thinking was heavily influenced by the JBoss Seam framework. In Seam, the session bean is directly invoked from the '.xhtml' layer - and at a practical level, it works well in JBoss.

I included 'FacesServlet' only in the component diagram. In the class and sequence diagrams, I am just showing:
JSP-->Managed Bean-->Session Bean.

[Antoni Mysliborski]

Please note that the whole concept of DI is about separation of concerns and providing abstraction. You are not accessing EJB directly by any means, you are doing it through the business interface (and from the client point of view, it could have been POJO as well behind), and creation of the actual object is managed through the container (and depends on easy to change configuration - annotations are not the only way of telling container what exactly should be injected).

[Usman Ibrahim]

http://download.oracle.com/docs/cd/E17802_01/bluep...n/web/AdminRequestBD.java.html

Hi Marcello,

Can you please provide the link to the main page of this java code where you can navigate to other classes.

Many thanks

Usman.

[guru prasanth]

So the final sequentce looks like this

JSF-->Validator/Convertor-->MANAGED BEAN-->SESSION FACADE-->Entity Beam

Of course depending on complexity we have also have a view helper and/or composite entity.
Also we can have Managed Bean DTO also.One more thing we can add is Validator/Convertor class
of JSF.Can any more combination be thought.

[Nilessh Ganu]

Ranganathan Kaliyur Mannar wrote:I am also using JSF and I decided against having BD and SL. And, I think if you decide to use BD, SL automatically comes in. This is bceuase of the restrictions on the usage of dependancy injection outside of JEE components (I am not 100% sure about this). But, if this is true, BD is not a 'container managed' component - so, DI may not work from BDs - so, you are kind of forced to use SL.
I just thought with JEE 5 making things simpler, BD and SL are not needed. Also, my thinking was heavily influenced by the JBoss Seam framework. In Seam, the session bean is directly invoked from the '.xhtml' layer - and at a practical level, it works well in JBoss.

I included 'FacesServlet' only in the component diagram. In the class and sequence diagrams, I am just showing:
JSP-->Managed Bean-->Session Bean.

Considering the performance impact, it is better to to keep the .war files at webserver and moving the .ear(EJBs stuff) to the application server. right ?

But if we want to use DI(Managed Bean injecting the SLSB), whether it will limit us to deploy .ear at each of the servers(each web server in cluster + each application server s in cluster) since we need to have same JVMs for DI to work ??

I am not so sure about above performance impact if any as I don't have any practical experience regarding the same.
So comments on above would be much helpful.

[Nilessh Ganu]

Can someone please comment here, I am stuck on it?

Question in brief:

I am using DI to inject SLSBs in JSF managed beans. In this case, I may not be able to separate out webserver and application server on two separate machines ?
With requirement of response in ~5 seconds, serving static pages or combining responses it will be better to put webserver and application server on separate machines.

Thanks in advance.