Win a copy of Five Lines of Code this week in the OO, Patterns, UML and Refactoring forum!
  • 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 all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
  • Piet Souris
  • Frits Walraven
  • Carey Brown

Business Delegate with JSPs

Ranch Hand
Posts: 154
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Could someone confirm my thinking on this or shoot me down in flames.
I've been reading the Sun "Core J2EE patterns book and others". One of the patterns is Business Delegate, which I can see its use.

The book and other articles describe this as a "Client-Side Abstraction of the business processes".

When you have a JSP/Servlet based architecture, i.e where the actual java code runs as Servlets on the server.

a)I assume the Business Delegate is a Client Side abstraction but is physically located on the server.

b)Is there any place for this pattern (maybe as a helper bean in the JSP or Class in the Servlet or as a class delegated to from helper beans). If you are also using Session Facade EJBs do these take the place of the Business Delegate?

(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I see one role of business delegate as hiding complexity from the client. Say I'm coding an EJB server and you're coding a Servlet client. Without the delegate I'd have to explain EJB home finders and caching homes and remote exceptions and all kinds of stuff. With the delegate, I just give you a jar and say you can use the java classes in that jar and they'll do all the tricky bits. If you aleady know all that stuff and you're willing to do the code to use them the delegate has a less value for making your life easy.

But it still has value as an abstraction. Without the delegate, if I change my server from EJB protocol to web services or REST protocols you would have to change every reference to my server. With the delegate, I could just give you a new jar and you'd never know what changed.

I work with a vendor product that generates business delegates from Rose models. The client code has no idea they're dealing with an EJB server. In fact the delegates appear to the client to be identical to a previous release of the product that used sockets to talk to a Forte 4GL server.

For these benefits I don't think "business delegate" was a very good name. It looks more like some kinda abstract remote proxy thingy to me.

Oh, and regarding session facades ... business delegate simplifies and abstracts technical stuff about the protocol while a facade simplifies and abstracts the application objects and methods a client can see. You could surely use both - a business delegate to make it easy to code calls to a session facade.
[ January 18, 2005: Message edited by: Stan James ]
Is this the real life? Is this just fantasy? Is this a tiny ad?
Thread Boost feature
    Bookmark Topic Watch Topic
  • New Topic