Hi Adam..
Well, I haven't experienced any problems whatsoever with this approach...so
I guess it is safe.
Sometimes I use BeanUtils to copy attributes but not very often...in my
opinion DTOs (or Value Objects) and the form bean is two totally different
concepts..therefore I like to keep them separate and sometimes with
different attribute names...Just my way of doing it ..might be silly...I
dunno..:-)
----- Original Message -----
From: "Adam Hardy" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Wednesday, March 17, 2004 2:07 PM
Subject: Re: action - delegate - facade
> Is it safe? I really don't know. You'd have to ask someone else.... or
> wait until I've got a couple of years experience with the service
> locator pattern, and I'll let you know ;)
>
> but regarding value objects - you use BeanUtils to copy the properties
> into the form beans?
>
>
>
> On 03/17/2004 12:34 PM HG wrote:
> > 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]
> >
> >
>
>
> --
> 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]
