This week's book giveaway is in the OCMJEA forum.
We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line!
See this thread for details.
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes Do we need different Implementation of Business Delegate ? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCM Java EE 6 Enterprise Architect Exam Guide this week in the OCMJEA forum!
JavaRanch » Java Forums » Certification » Architect Certification (SCEA/OCMJEA)
Bookmark "Do we need different Implementation of Business Delegate ?" Watch "Do we need different Implementation of Business Delegate ?" New topic
Author

Do we need different Implementation of Business Delegate ?

Vinay Singh
Ranch Hand

Joined: Dec 15, 2004
Posts: 174
Hi Friends
In some of the post I had read that people had used two different implementations of business delegate for web and rich client app. My question is if we assume that rich client is within the same intranet as app server, do we still need two different implementations?
Vinay


Technical quiz and interview questions   SCJP 6 mock practice test
Ajith Kallambella
Sheriff

Joined: Mar 17, 2000
Posts: 5782
Business deligates usually live in client partition(aka presentation layer). If you have multiple client types( web, rich, pda etc.) then you may need each client type to have it's own business delegate.

However, it is important to note that functionally, every business deligate implementation will do exactly the same thing, or for most part a common set of things - such as interacting with the remote session facade, caching the results, handling remote exceptions etc. Therefore, with a bit of headscratching and refactoring, you may be able to come up with a generic implementation, and extend it to support multiple client types through specialization, packaging or a combination of both.

Hope that helps.


Open Group Certified Distinguished IT Architect. Open Group Certified Master IT Architect. Sun Certified Architect (SCEA).
David Follow
Ranch Hand

Joined: Oct 16, 2001
Posts: 223
I plan on having the same BusinessDelegate for both clients. I don't understand why I would need to have two different BD implementations? The BD hides the technology of the business-tier - in our case, it hides the JNDI lookup and to forth of the SessionFacade. From my understanding both type of clients will be able to use the same BD.

D.


SCJP, SCEA
Chintan Rajyaguru
Ranch Hand

Joined: Aug 19, 2001
Posts: 341
Business Delegates don't have to be client side components (although they could be according to the EJB Design Patterns book on theserverside.com). If you look at the business delegate design pattern
it has no mention of delegates being client side components. Since you have two (or more) different types of clients, I would put delegates in the business layer and reuse them for multiple clients. If you wanted to have client specific functionality in the delegates, you just have to take it out and put it somewhere in presentation tier.

In such a design delegates would essentially do the following:
1. Look up the EJB (you may want to maintain one to one mapping between the deletgate and the SLSB) and store a reference to the remote interface
2. Delegate method calls from the presentation tier to the EJBs
3. Catch exceptions from the EJB tier and convert them into exceptions that the client would understand
4. Provide fault tolerence (if any)

If you restrict your delegates to do just above, you don't need to repeat delegates for every client type.


ChintanRajyaguru.com
SOADevelopment.com - Coming soon!
Vinay Singh
Ranch Hand

Joined: Dec 15, 2004
Posts: 174
I agree with Ajith here that BD would be client side components, in case of rich client.For web client BD would be deployed with .war file hence they are essentially on web server.
But I am still scratching my head to why we would need 2 implementations of BD?
For web : Request Handlers or servlet call the BD which in turn call the EJB, handle exception etc.
For Rich Client : Swing client would call the same method on BD which in turn would call the EJB, handle exception etc.
Ajith correct me If I am wrong, would the calling be different ?
I looked at J2EE 1.4 tutorial at Duke Bank's application. The Data Model class is initializing the context in same way as Service Locator.
In fact both web and EJB are using EJB getter to get reference to EJB.
This is confusing me.
Am I missing some thing here ?
Vinay
David Follow
Ranch Hand

Joined: Oct 16, 2001
Posts: 223
The BD belongs to the business-tier (see J2EE pattern catalog) but the BD will be deployed in a different tier namely in the presentaion-tier.
The whole idea of BD besindes hidding technology details such as JNDI lookups in the case of a SesssionFacade BD is to give a single entry point into the business-logic and therefore the business-tier.
So to me there is no obvious reason why there should be two different implementations of a BD interface. I guess it would be even counter-productiv.

D.
Dan Drillich
Ranch Hand

Joined: Jul 09, 2001
Posts: 1176
Vinays,

You asked:

But I am still scratching my head to why we would need 2 implementations of BD?


Parag Doshi explained very nicely how he designed his solution using two BDs at http://www.coderanch.com/t/152921/java-Architect-SCEA/certification/Cleared-Part-II-III

I used the Front controller for the web tier. It communicated with a web based implementation of the business delegate and my swing client communicated with a standalone client based implementation of the business delegate. Both the clients used different implementation of business delegate. The swing client communicated directly with the ejb tier (via the swing business delegate). I had only 1 business delegate (it didnt end up looking very gigantic as the methods were pretty coarse grained) per client, but several session facades.


-- Dan


William Butler Yeats: All life is a preparation for something that probably will never happen. Unless you make it happen.
Marie Pierre Courbevoie
Ranch Hand

Joined: Aug 01, 2005
Posts: 32
Hi Vinays

A Swing BusinessDelegate may:
-be a singleton (i think should be), i have only one client and one connection to the server!
-no need for a ServiceLocator, the delegate may, at startup or first connection, look up references to remote facade(s) homes and cache them (almost if you have only one facade)
-cache results: think about a composite DTO: list products/products details, system may display a list of products at first request and from the same DTO display details for a selected product, i don't need a second round trip to the server for retrieving products details.

Regards

Marie Pierre
Vinay Singh
Ranch Hand

Joined: Dec 15, 2004
Posts: 174
Dan
I had read this thread of Parag's but frankly speaking I could not understand why.
Marie, I now put myself in developers shoes and see how would we would implement this.
Service Locator is a pattern , we may use it or not irrespective of being it a swing BD or web BD.
Singleton is again not good enough reason to go for another implementation of BD.
BD is only for connecting to EJB not for caching.Caching is advisable to be done behind EJB.
So I am still looking for answers...
Vinay
Vishwa Bandhu
Greenhorn

Joined: Jul 05, 2005
Posts: 12
I think, in a Java client connecting directly to the EJB, the Business delegate handles all the connections and the business tier details. This can very well do a client side caching as Java client can have the session handling locally. In this case Java client connects to a EJB through a Stateless session facade implementing remote interface.

For the web user, if you use plan to share JVM for the servlet container and the EJB container, same server, then the Servlet client can have a seperate BD that connects to the EJB via a statefull session bean,( session stored in the business tier). Clearly the BD for this scenario cannot be the same.

On the otherhand, if the client talks to the Business tier via a servlet front controller, then I don't see why one would need a seperate BD for two interfaces. I would rather use a HTTP proxy at the client tier and the BD would be the same for both the web client and the java client at the web tier.
Thomas Taeger
Ranch Hand

Joined: Dec 16, 2002
Posts: 309
Yes, BusinessDelegate is a Business Tier design pattern.

But all the same its instance does normally not reside in the business tier, see http://www.coderanch.com/t/99742/patterns/Command-BussinesDelegate for more information.

The term "client" is not reserved for the Client Tier only in J2EE. Servlets may be clients of EJBs, JavaClientApps may be clients of EJBs, (session...) EJBs may be clients of other (entity...) EJBs, EJBs and DAOs may be clients of EISs, and so on, see also http://www.coderanch.com/t/150685/java-Architect-SCEA/certification/Java-or-ee-client .

So without optimizations (collacated Web/EJB-Container ...) you probabely can use the same Business Delegate for both types of clients, JavaClientApps and WebComponents, because both access the same business methods, that are probabely provided by the same facade.
Even the ServiceLocator most often being part of the Business Delegate might be the same as long as both client types use remote calls and JNDI.
Maybe via an adapter for specific technologic concerns like for J2ME.

To be more exact: Regard the Business Delegate as an _interface_, regardless of who and what implements it and how.
The question of _where_ it is _instantiated_ is easily answered: in the JVM of the (web, app, ...) client. So you need one instance per JVM - but not necessarily one implementation per JVM or client type.

Thomas.
[ September 15, 2005: Message edited by: Thomas Taeger ]

www.classic-and-class.com - www.evalulearn.com
Interfaces are the glue of OO.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Do we need different Implementation of Business Delegate ?