Win a copy of Design for the Mind this week in the Design forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Managed Bean as service locator

 
Prashant Purkar
Ranch Hand
Posts: 84
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello ,

This is with reference to Amar's post "SCEA Assignment: JSF Vs Struts "

Because managed beans are container managed , is it a good idea to use Application level managed bean
as a service locator to locate resources, beans?

New features java has provided in recent times are targeted at less code. So this might be a good idea.

Thanks
Prashant
 
Hong Anderson
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am not sure what does that mean, it seems that you understand, can you explain more? What are the benefits in doing that?
 
Amar Thia
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Prashant,
My posting was targeted more towards Business Delegate pattern than Service Locator - although it seemed like a service locator question. So, I believe I am the culprit and I must make reparations to your

Here is my 2 cents (or less) on the idea of using Managed Beans as Service Locator: Service Locator is a Business Tier pattern. Managed Beans are Presentation tier items and they should be left there. Why? Lets say, you have created and delivered your project and gone on to do better things - Whats to stop the next guy who has taken over your application to use your Managed Bean Service Locator as a presentation tier bean - Your Managed Bean Service Locator will appear in the faces-config.xml - It seems logical to conclude that it is used as a presentation tier item. And that is why it is not advisable to do.

Having said that, what was my question on Business Delegate: It was a very short-sighted, very shallow question on Business Delegates - In the core j2ee patterns book the first line about Business Delegate was
You want to hide clients from the complexity of remote communication with business service components.
My mind was only focusing on "complexity of remote communication" of Business Delegate and thinking in Java EE5 there are annotations and the remote communications is not so complex. So there is no need for Business Delegate. But, actually if you take a Business Delegate is like a proxy for your Session Bean EJBs, etc. Now, several screens in an application can access the same Session Bean EJBs. So, if you change a Session Bean EJB, you will have to change all those screens if you did not have a Business Delegate. If you have a Business Delegate, you can make changes to Business Delegate to match the changes in Session Bean Interfaces and keep your Presentation tier interfaces intact and have no changes to your screens or the presentation tier.

HTH

Thanks,
Amarnath.
 
Hong Anderson
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks, I just know managed beans you are talking about mean JSF managed beans.
 
Hong Anderson
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Amar Thia wrote:
But, actually if you take a Business Delegate is like a proxy for your Session Bean EJBs, etc. Now, several screens in an application can access the same Session Bean EJBs. So, if you change a Session Bean EJB, you will have to change all those screens if you did not have a Business Delegate. If you have a Business Delegate, you can make changes to Business Delegate to match the changes in Session Bean Interfaces and keep your Presentation tier interfaces intact and have no changes to your screens or the presentation tier.

About changing screens, I think it's depends on how screens depends on Business Delegate or Business Interfaces. Even if you use business delegates, you might need to change screens anyway.
 
Amar Thia
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Kengkaj,

About changing screens, I think it's depends on how screens depends on Business Delegate or Business Interfaces. Even if you use business delegates, you might need to change screens anyway.


Yes, you are absolutely right - I've also seen some business delegates that were written long ago which exhibit this behavior. All I am saying is that I thought the Business Delegate pattern was obsolete with the advent of Java EE5 annotations - But after much deep thinking, I concluded that Business Delegate pattern as a best practice is still alive and valid. What do you think (Please note: I am pretty good at coming to wrong conclusions - so please feel free to correct me if you feel I have concluded incorrectly)

Also, what do you think of Prashant's idea of using Managed Beans as Service Locator? I think he is also interested in using DI in JSF Managed Beans - Is it better to use Spring framework? BTW, thank you very much for your Spring framework documentation link - My love affair with Spring has been initiated. I blame you for it

Thanks,
Amar.
 
Hong Anderson
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
When I read again about changing screens, I'm not sure what exactly did you mean.
If requirements were changed (I guess it would be the reason to change business interfaces), we might need to change UI as well, regardless of whether we use business delegates or not.

About Business Delegate pattern, I personally don't like it, because IMO, it's too much to abstraction between UI layer and business interfaces, if changing business interfaces make UI to change, just let it changes.

However, Business Delegate would help if we may want to change technology from EJB (2.x) to POJO (how ironically).
You can read an article about this on http://www.ibm.com/developerworks/java/library/j-ejb1022.html.

Regarding JSF Managed Beans, currently I don't have enough knowledge about JSF, so I don't yet have opinion. If I have time, I may read about it and discuss more.
Anyway, as I know, JSF manage beans can use DI, but limited to managed resources (EJBs, JMS resources, Data Sources, Mail Sessions, etc.). If we want to inject POJOs to JSF manage beans, Spring is a better option.

It's good to hear that you love Spring, it's a great Java framework .
 
Prashant Purkar
Ranch Hand
Posts: 84
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Amar, Your idea that Service Locator is a Business Tier pattern & Managed Beans are Presentation tier items and they should be left there is quite convincing.

Prashant
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic