This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
It is not clear to me how to make decision when (at what situation) to use session facade versus when to use business delegate ? It seems to me that whenever we can use session facade we should use a business delegate The business delegate seems not only solve the problem that session facade can do, but also it hides the lookup and access details. Should we use business delegate rather than session facade ? Or should we use session facade from client to business delegate then connect to various EJB's ?
My understanding is that of course you can have one and only one object to perform both Business Delegate and session facade functions. But my opinion is that it is better to decouple it into several objects (scalability). Moreover, the Business Delegate is more a presentation Tier Object (java class) while the facade is a business Tier (EJB session). Depending on the functionnality you want to implement, you can also introduce a third object, the service locator, to perform the jndi lookup stuffs. The architecture can be a kind of : B.Delagate ---> Service Locator ---> Facade Correct me too ...
/ JeanLouis<br /><i>"software development has been, is, and will remain fundamentally hard" (Grady Booch)</i><br /> <br />Take a look at <a href="http://www.epfwiki.net/wikis/openup/" target="_blank" rel="nofollow">Agile OpenUP</a> in the Eclipse community
Joined: Jan 06, 2002
Bill, The architecture you point out is what I am thinking to use. My next question is which object will take care of the caching (session tracking). If the business delegate do it, then I can use a stateless session bean for the session facade. Which object to do the caching is the best design ? Please comment Thanks Ruilin [ January 17, 2002: Message edited by: Rulin Yang ]
A lot of times I place Business-delegate objects in the HttpSession. They're generally fairly small and don't carry a lot of state, but are useful across many servlet interactions. That makes it possible for me to use stateless beans. Kyle
Kyle, Great inf. I am reading your paper. For using Web tier to access EJB, I understand using your approach to put Business delegate objects (including service locator) in httpSession and keep session inf. in the business delegate (or effectively in the httpSession)and so only use a stateless session bean as session facade is a good idea. Please correct me: If I use a stand-along javaUI client to use business delegate to keep session inf may not be a good idean since a lots information have to pass network causing performance problems. In this case, it is better to use the session facade stateful session bean to track the session which is in the server side. I am still talking about the architecture: client-->business delegate-->service locator-->session facade
Please correct me or elaborate. Thanks, Ruilin [ January 17, 2002: Message edited by: Rulin Yang ]
Joined: Aug 10, 2001
Actually, I prefer not to keep that kind of state on the server at all. When building a Java client I still keep the info in the Business delegate on the client. It does increase network communication, yes, but I've seen that the safety aspects (safe from crashes) and workload management aspects more than make up for that. Kyle