This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
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
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).
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.
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.
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
Joined: Oct 16, 2001
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.
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.
William Butler Yeats: All life is a preparation for something that probably will never happen. Unless you make it happen.
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.
Joined: Dec 15, 2004
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
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.
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 ]