Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

BusinessDelegate and ServiceLocator pattern

 
Joshua Antony
Ranch Hand
Posts: 254
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am very much confused regarding the distinction between these two patterns, because Business Delegate uses Service Locator as well.

Is there a need for seperate ServiceLocator Pattern ?
 
Christophe Verré
Sheriff
Posts: 14691
16
Eclipse IDE Ubuntu VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Did you read this document ?
 
Shruthi Karthick
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Even Transfer Object Pattern is used with Service Locator only. It cant operate independently if iam not wrong.
So all these Bussiness tier patterns are inter related?
cant it be used individually?
 
Narendra Dhande
Ranch Hand
Posts: 951
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
 
Marc Peabody
pie sneak
Sheriff
Posts: 4727
Mac Ruby VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Shruthi:
Even Transfer Object Pattern is used with Service Locator only.

No no no no. The Service Locator is one of the only parts of an architecture that should never know anything about Transfer Objects!

Maybe I can help the Service Locator/Business Delegate confusion. It is possible for a Business Delegate to hold the code that locates backend resources. But sometimes finding the backend resources (like remote Session EJBs - see the Session Facade pattern) can be nontrivial. You don't want to load your Business Delegate down with tons of JNDI lookup code, so you extract all that to some other class. That other class is called a Service Locator because all it does is locate services.

Extracting the service lookup logic into its own class is a great example of the "separation of concerns" principle. You don't have to do it (or any other pattern for that matter) but in some cases the overall architecture would benefit by putting all the locator code in a single, concise, DRY class.

As you try to learn patterns, don't study the pattern. Instead study the problem. "Pattern" does not mean "always do this". Patterns simply solve a particular problem in a particular context. If you don't have the problem, don't use the pattern. If you don't fully understand the problem, you'll never understand the pattern.
 
Narendra Dhande
Ranch Hand
Posts: 951
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
 
Aditya Singh
Ranch Hand
Posts: 62
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jst to add to marc's reply serviceLocator job is to identify service and bussinessDelegate job is to use serviceLocator to find service and then call that service on behalf of some remote object. Marc Pls correct me, if i m wrong.
 
Marc Peabody
pie sneak
Sheriff
Posts: 4727
Mac Ruby VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Aditya Singh:
Jst to add to marc's reply serviceLocator job is to identify service and bussinessDelegate job is to use serviceLocator to find service and then call that service on behalf of some remote object. Marc Pls correct me, if i m wrong.

Pretty much. You said "on behalf of some remote object", however the "remote object" is typically the service object itself. You're right that the BD says to the SL, "I want XYZ Service so I can ask it to do something. Gimme XYZ!"

An analogy:
Picture yourself running your own business. If you're just starting out, you can probably run a lot of your own errands because you aren't terribly busy. But after your business grows, things get hectic. You need to put some of the grunt work on others so you can focus on what you do best.

When you're a big shot you say: "Charlie, get Mr. Davenport on the phone for me right away!" Charlie is your service locator. You, as the business delegate, don't have to know Mr. Davenport's phone number - you don't even have to worry about dialing the phone! Charlie does it for you. All you have to do is: 1) Ask Charlie for Mr. Davenport 2) Close the million dollar deal with Mr. Davenport.

Does every business need a Charlie? Not really. If you only make a couple phone calls a day, having a Charlie will only make things more complicated... although it would be nice to have someone to boss around.
[ March 14, 2008: Message edited by: Marc Peabody ]
 
Joshua Antony
Ranch Hand
Posts: 254
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks all for your replies, got the point.
 
Ashok Kumar Babu
Ranch Hand
Posts: 129
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Marc... Your second explanation is very good. Thanks for that
 
ross Bertonoli
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi
What about the case where a client needs to call 2 EJBs deployed on different application servers (different URLs) and we want to use service locater with caching.
Shoudl we create 2 different service locator classes or can we use just one ?


Thanks
R
 
Marc Peabody
pie sneak
Sheriff
Posts: 4727
Mac Ruby VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'd stick to using just one Service Locator. It's really like having your own personal assistant. There's not much reason to hire a second personal assistant to dial Australian business contacts simply because it's a different continent.

But this brings up a good point (for those really interested in learning this stuff). Your Business Delegate really shouldn't be calling two EJBs because a Business Delegate typically won't care about transactions. If one of the two EJBs fails, we'd probably need the other EJB to rollback its changes. Otherwise... yikes!!!

Instead, you'd want your Business Delegate to make a single call to a Session Facade (implemented as a Stateless Session Bean in EJB or a Service POJO in Spring). Your Session Facade class would worry about calling the two finer grained EJBs and manage the overall transaction.

Session Facade hasn't been on the SCWCD exam for years, so don't worry about it for the exam... but it doesn't hurt to learn about it anyway!
 
anil pamidi
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Marc,
Your explanations are really helpfull.
Thank you very much.
 
ross Bertonoli
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
March
In order to use only one service-locator to lookup to 2 EJBs deployed on different application servers (different URLs), could you please suggest how I sholud initlize the provider URL in the InitialContext with different URL ?

Thanks
Ross
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic