Hi Robert and Adam...
Guess I am paranoid or prepared.. :-)
I use nearly the approach Robert described, using a Factory for the
delegate....although the purpose is not the same..
I use the Delegate as the "web tier view" of the business logic/services in
the system. That becomes important, when different business rules/logic
applies to different modules/plugin.
In my scenario I call the business delegates for business plugins because of
the dynamic plugable nature. Plugins are hosted by a plugin manager (the
factory), and access the plugin interfaces always goes through the plugin
manager.
You get an interface to a plugin (ie. web tier view of a business service),
not an implementation...that's important as you state correctly Robert.
The difference is that I don't care if it is a POJO, EJB, whatever I am
talking to "behing the scenes", I care about HOW the business service is
implemented...
Let me give you an example:
Way through system is:
Action->Plugin->Facade->Entity
Pseudo code for action execute:
AccountManagement plugin =
pluginManager.getPlugin("core.account.management");
What I get here is an interface (AccountManagement) of a business service
plugin. Behind the interface, one specific implementation of it resides.
WHAT implementation to use is decided by the plugin manager. I my scenario
it is based on a customer, which have a certain business role. But it can be
whatever logic to decide which implementation to use.
Now I use the the plugin business service interface from my action
plugin.createAccount("001", "Hans Gruber");
With this one call a specific implementation of the Management interface is
called. What happens behind the scenes is not important from the actions
point of view. Maybe different business rules/logic applies for different
implementations of the AccountManagement.
What actually happens is that the plugin service implementation calls a
facade to fulfil the business action of creating an account.
This approach is highly flexible...You have the possibility of hosting
different customers (with different needs) under the same application
constrcuted using business plugins building blocks.
It also (like other business delegates as you stated Robert) promotes
loosely coupling between the web tier and EJB or whatever tier is behind.
With this clean interface it is very very easy to provide an additonal XML
WebServices interface (maybe though Axis) that makes your business services
accessible from other platforms, systems, whatever...
My few bucks...Anyone has comments...they are welcome...
Regards
Henrik
----- Original Message -----
From: "Robert Taylor" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Wednesday, March 17, 2004 2:51 AM
Subject: RE: action - delegate - facade
> Adam, IMHO the Business Delegate pattern abstracts the client from knowing
> your business implementation, whether it be EBJ, JDO, POJO, roll your own.
The
> client interfaces with the Business Delegate and not its implementation.
> For example, if you have an Action (client) interface with the Business
Delegate
> instead of directly with a SessionFacade, then you can change the
underlying implementation
> of the Business Delegate without changing anything in the client.
> If your really paranoid (or prepared), you can use the Abstract Factory
pattern which you could then
> initialize/subclass to create the appropriate Business Delegate
implementations (EJB, JDO, main frame).
>
> Also by using a Business Delegate the client isn't exposed to
implementation details
> such as (if your using EJB) looking up the appropropriate EJB or handling
implementation
> specific exceptions. The Business Delegate becomes a high level
abstraction of the
> business rules raising application level exceptions when error occur to
which the client
> can respond appropriately.
>
> So, you wouldn't necessarily have to modify the Delegate-Facade interface.
The interface
> itself remains unchanged. You have to use a different implementation. That
is where the
> factory comes in. I imagine you could do something like the following:
>
> Properties props = // get initialization properties
> // to initialize factory to return EJB BD
implementations
> BusinessDelegateFactory bdf = BusinessDelegateFactory.init(props);
>
>
> In your client, suppose AccountBD is your BusinessDelegate interface:
>
> BusinessDelegateFactory bdf = BusinessDelegateFactory.getInstance();
> AccountBD accountBD =
(AccountBD)bdf.createBusinessDelegate(AccountBD.BD_NAME);
>
> So you just end up "plugging" in new implementations as needed.
>
> Anyhow, that's my interpretation of the some of the forces behind the
pattern
> and an idea on implementing it.
>
> Here's more information:
>
http://java.sun.com/blueprints/corej2eepatterns/Patterns/BusinessDelegate.html
> http://www.developer.com/java/other/article.php/626001
>
> robert
>
> > -----Original Message-----
> > From: Adam Hardy [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, March 16, 2004 6:26 PM
> > To: Struts Users Mailing List
> > Subject: action - delegate - facade
> >
> >
> > I've just been perusing the archive to check out what people have been
> > saying about struts to EJB interfacing.
> >
> > One thing that occurs to me is that the only reason mentioned for having
> > a business delegate layer between the Actions and the Session Facade is
> > to allow for loose coupling of the struts-dependent code with the EJB
> > dependent code.
> >
> > How necessary is that? If you choose to drop EJB and go with, say
> > Hibernate, you would have to modify the interface, whether it is the
> > Action - Facade interface or the Delegate - Facade interface.
> >
> > Or have I missed an important other reason for the existence of the
> > Delegate layer?
> >
> > Adam
> > --
> > struts 1.1 + tomcat 5.0.16 + java 1.4.2
> > Linux 2.4.20 Debian
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
