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]
