• 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
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Do Business Delegates Provide Total Decoupling?

 
Ranch Hand
Posts: 268
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I ran into an issue using Business Delegates (BDs) at the last place I worked, and it left me wondering if this pattern is usable at all.
In our situation, we had EJB developers writing an EJB layer for several different front end clients (each developed by a separate group of non-EJB developers). Now, as I understand it, one of the main advantages of using the BD pattern is that the front end developer doesn't need to know a lick about EJBs, how to look them up or work with them. This implies to me that the EJB developers should be the ones to implement BDs, and these BDs should be packaged in the EJB client jars and distributed. This also makes sense because each EJB accessible to the client has a corresponding BD, and each front end client doesn't have to write and maintain BD code that does essentially the same thing.
Here's the problem, though--by providing the BDs that do all the JNDI lookups, the EJB developers are mandating that all of the front end clients have their environment set up in exactly the same way. What if one client is using a different initial context factory than another, and they require different configurable information provided in different env-entrys?
To overcome this problem, we had to move the BDs out of the client jars and onto the front end. Now we have front end developers writing the BDs, and suddenly they have to know how to deal with EJBs anyway.
So, did I miss something, or do BDs actually rely that the declarative configuration set up in the client-side deployment descriptors be the same for all clients? Forcing this requirement onto different clients is not always possible, and even when it is, it doesn't provide the degree of decoupling that ought to be present in a robust distributed system.
I can't help but feel I must be missing something here...any thoughts?
sev
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by sever oon:
To overcome this problem, we had to move the BDs out of the client jars and onto the front end. Now we have front end developers writing the BDs, and suddenly they have to know how to deal with EJBs anyway.


Well, the latter doesn't have to follow from the former, as I see it. The EJB developers still could provide the BDs, package them into their own jar and provide it to the front end developers.
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You might wind up with exactly one developer knowing EJB and the rest only knowing the delegate. That's not too bad. Until he wins the lottery.
Now, if I was a client developer and the server developer never mentioned BDs, might I still decide to write my own? It might be a good place to hide the protocol in case the server decided to change to web services or I might change my naming service down the road, or a dozen other things. It's good to isolate and hide potential sites of change. You have to weigh likelihood and impact of change to decide how much effort is warranted.
My own slant: I hate housekeeping code. When I look at code every line that is not informing me about insurance or customer service is noise, every line developers write that is not about the business goal is, well, not moving the project toward the business goal. Write the EJB housekeeping once or every time you need an object? Easy answer, no?
[ March 03, 2004: Message edited by: Stan James ]
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic