Q:	Q: This whole discussion has assumed RMI; what if our company is using CORBA?
A:	A: All of the patterns we’re discussing can be implemented more or less independently of J2EE technologies. Admittedly, they will be easiest to implement in J2EE, but they do apply to other situations.
Q:	Q: Is the same thing true for JNDI?
A:	A: Well, there are other Java-related registries besides JNDI—RMI and Jini come to mind. Of those three, JNDI is probably the best choice for most web apps, it’s easy and powerful. (Although the authors would personally love to see Jini take its rightful place in the distributed world.) You might also be dealing with non-Java registries like UDDI. In any case, the patterns will still work, even though the code changes, of course.
Q:	Q: It seems like these patterns are forever adding a new layer of objects to the architecture. Why is this approach so common?
A:	A: You’re right that this is a common part of a lot of patterns. Assuming that your design is good, think about the software design benefits inherent in this approach...
Q:	Q: OK, well, cohesion comes to mind...
A:	A: Right! Both the Business Delegate and the Service Locator increase the cohesiveness of the objects they support. Another driving force is network transparency. Adding a layer often shields existing objects from being network aware. Then of course, closely related to cohesion is separation of concerns.
Q:	Q: Separation of concerns buys me...?
A:	A: Let’s take the Service Locator as an example. In the event that your registry gets a new network address and/or registry interface, it’s far easier to modify a single Service Locator than change a whole flotilla of Business Delegates. In general, separation of concerns buys us a lot of flexibility and maintainability.
Q:	Q: In your examples so far, you’ve taken POJOs that were local, and made them remote. Isn’t it more likely that I’ll be faced with integrating existing EJBs into my web app?
A:	A: By POJOs, we assume you mean “Plain Old Java Objects”, of course. And yes, it is likely that you’ll be integrating EJBs into your app. And in fact that’s yet another reason to use these two patterns... your controller (and view) should never have to care whether the model is a local JavaBean, a remote POJO, or an enterprise JavaBean (EJB). Without using ServiceLocator and Business Delegate, that difference means a lot—enterprise beans and plain old remote objects don’t use the same lookup code! Using these patterns, you can encapsulate the issues related to how and where the model is discovered and used, and keep the controller happy and clueless, so that you won’t have to change your controller code when the business guys change things and move things around on the business tier. You’ll update only the Service Locator and (possibly) the Business Delegate.