BD and SL Design Patterns discussion

[Marc Peabody]

I hit a question in an interview recently that I thought could generate a good conversation here. Initially, I'd like to step back and let my friends (you!) share their thoughts.

Statement:
Your application is split into two tiers that reside on separate machines. Machine A provides RMI services via Stateless Session EJBs (which act as Session Facades). Machine B has your web application framework with Servlets and JSPs, intecepting filters, and all that yummy front-end stuff.

Question:
Which machine contains the Business Delegates? What about Service Locator? Does it matter? Why?

[nitin pai]

Originally posted by Marc Peabody:
Question:
Which machine contains the Business Delegates? What about Service Locator? Does it matter? Why?

My answer:

Business Delegate should be on the other machine which contains the EJB's and Service Locater should be on the machine which contains the web application.

This is because a Service Locater would store the EJB accessing code and the web components can easily use this Service Locator whenever required. Whereas a Business Delegate helps in making calls internally to different EJB's and hence it should not be made to make multiple remote calls by keeping it on the web tier. Making a Business Delegate lie on the same machine as the EJB's would make remote calls lesser and the web tier too would have to make a single delegation call and collect the required data via a Transfer Object.

[Marc Peabody]

But wouldn't the web client then be making remote calls to the Business Delegate? And doesn't a Business Delegate often use the Service Locator? How could it access it then?

[Christophe Verré]

I'd make one library for both business delegate and service locator, and deploy it in both machines. They both need it, don't they ?

[Marc Peabody]

Originally posted by Satou kurinosuke:
I'd make one library for both business delegate and service locator, and deploy it in both machines. They both need it, don't they?

Very interesting, Satou. Why might they both need it?

[Christophe Verré]

Marc, don't be so scary I feel like I'm failing at an interview.

Well, the Service Locator, you definitly need it botn in A and B. You want to access EJBs from both A and B. If the Service Locator is common, which it probably is, it has to be in both machines.
I'm a bit perplex about the Business Delegate. I still think there's one in A and one in B, but they are different.
One for EJBs but you may not need it, and one for servlets, which you really need to access EJBs in A.

So :
Service Locator : both in A and B. EJBs accesses other EJBs via the SL.
Business Delegate : A. But an other one in B if EJBs are accessing remote EJBs.

Don't torture me like that I've scored very poorly at patterns. But that's a good exercise.

[D.R.Vinayak]

I think both Business delegate and service locater should be on same machine where servlet and jsp's are kept.Since Business delegate uses service locater so they should be on same machine to avoid network traffic.
and service locater will do costly lookup to JNDI.

correct me if i m wrong

[Marc Peabody]

Originally posted by Satou kurinosuke:
Marc, don't be so scary I feel like I'm failing at an interview.

I simply didn't want to taint the discussion with my own opinion and observer where it would lead. I'm liking what I see, by the way.

I found a similar discussion in the SCEA forum.

[Christophe Verré]

I'm actually considering to give SCEA a try.

[Oliver Rensen]

I would put the Business-Delegates only into the presentation-tier, because the Business-Delegates should decouple the presentation-tier-developers from the business-tier-developers. The Business-Delegates will be written from the business-tier-developers and used from the presentation-tier-developers. The Business-Delegates shield the EJB-source-code from the presentation-tier-developers.

The Service-Locator is used in both tiers. The presentation-tier needs it to locate the Session-Facades, and the business-tier needs it to locate the entity-beans, JDBC-connections or JMS-queues.

I would write separate Service-Locators. One for the presentation-tier and one for the business-tier, because the Service-Locator for the presentation-tier does not need to locate the entity-beans, and the Service-Locator for the business-tier does not need to locate the Session-Facades, because the Session-Facades are the entry-point for the business-tier.

[Marc Peabody]

Originally posted by Oliver Rensen:
... because the Session-Facades are the entry-point for the business-tier.

True, and you would essentially have a Service Oriented Architecture (SOA). But, assuming you are exposing multiple service methods together (across multiple Session Facades), isn't it possible that one service method will need to in turn call another service method? It will still need to find the other service method somehow.

[nitin pai]

I have not studied Session Facades and I know only the patterns included in SCWCD.

SO according to the best of my knowledge and the base requirements as mentioned by marc what I feel is -

1. If business delegate (BD) is located in the presentation tier (PT) then it will try to make multiple remote calls as required by the logic.
2. Now our goal will be to reduce multiple remote calls . So if i make the BD lie on my EJB tier then from the PT then i will make a call as in

getServieLocator.getBD.invoke();

3. This invoke will be a remote call made with the Service Locator (SL) and the BD will then make multiple local calls on the EJB tier (please note I am not considering distributed EJB tier) and then fill a Transfer Object (TO) and send back this transfer object to PT.

Conclusion
I still say BD with TO on EJB tier and SL on presentation tier.

Am I selected for the job ?

[Marc Peabody]

You're saying that the Service Locator should be making remote calls which is actually the job of the Business Delegate. The Service Locator should merely locate services. The Business Delegate should be the one that takes the services returned by the Service Locator and invokes methods on the services.

I do agree that business logic can require interaction with many business components (like multiple entity beans) and we should limit the number of remote calls. However, Session Facades solve this issue. They can hold all of that business logic and interact with the other business components locally on the Business Tier. The Session Facades would then be the only business components exposed to the Presentation Tier, limiting the number of remote calls needed (and those remote calls are made by the Business Delegate).

Session Facades will typically pass along a Transfer Object and I am confident by your description that you understand the importance of the Transfer Object.