ehh..Correction to third answer...
Actually the plugin caches the reference to the EJB Facade and the Service
Locator caches the home looked up from JNDI...
Is this really safe..?? :-)
----- Original Message -----
From: "HG" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Wednesday, March 17, 2004 12:31 PM
Subject: Re: action - delegate - facade
> Hi Adam.
>
> Your first question, regarding packaging
> I keep that part simple, so I place all value objects in a model package,
> say "com.mycompany.myproduct.model". Both the ejb-jar and the web-jat
> contain these classes.
>
> Your second question, regarding generation value objects
> I use xDoclets facilities to generate value objects. If I need special
> services/attributes in the value objects I subclass the one generated by
> xDoclet and roll my changes.
>
> Your third question, regarding home lookups.
> I use the ServiceLocator pattern from my business delegates(plugins). The
> service locator is implemented as a Singleton and contains only Facades. I
> have antoher another singleton ServiceLocator for Entities.
> Each plugin caches the home of the "Business Services" it uses (ie. the
> Facades).
>
> Hope to help...otherwise....feel free to ask.
>
> Best regards
>
> Henrik
>
>
> ----- Original Message -----
> From: "Adam Hardy" <[EMAIL PROTECTED]>
> To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> Sent: Wednesday, March 17, 2004 11:01 AM
> Subject: Re: action - delegate - facade
>
>
> > I am surprised to see that the xpetstore @ sourceforge has a direct
> > interface between Actions and the session beans.
> >
> > The delegate does make sense to me now and I'm going to implement it.
> >
> > One think I've been wondering is about packaging all the classes. Do you
> > put the delegate classes and the transfer / value object classes in a
> > seperate jar file from the action classes, and from the EJBs?
> >
> > While on the subject, what do you use for value objects? Form beans or
> > something generated by xdoclet? I've been using an xml schema to
> > generate my value objects so far (not with EJB) via JAXB, but this isn't
> > going to work with EJB because the things aren't serializable.
> >
> > Another question (my last!): what is the best way to handle home
> > interfaces in the delegate? Do you cache them? Do you treat them like a
> > logger object or a singleton? Or do you just instantiate them fresh each
> > call?
> >
> >
> > Thanks!
> > Adam
> >
> >
> > On 03/17/2004 09:22 AM HG wrote:
> > > 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]
> > >
> > >
> >
> >
> > --
> > 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]
