• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

Do we need different Implementation of Business Delegate ?

 
Ranch Hand
Posts: 174
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Sheriff
Posts: 5782
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 223
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 341
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Vinay Singh
Ranch Hand
Posts: 174
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 223
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 1183
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 https://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
 
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 174
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 311
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes, BusinessDelegate is a Business Tier design pattern.

But all the same its instance does normally not reside in the business tier, see https://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 https://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 ]
 
Too many men are afraid of being fools - Henry Ford. Foolish tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic