Actually this is a pattern mentioned in "EJB Design Patterns - Advanced Patterns Processes and Idioms" called Data Transfer HashMap. You can download the pdf from TheServerSide.com. It's a pretty good read. The book goes into detail on the pros and cons of this pattern.
http://www.theserverside.com/books/wiley/EJBDesignPatterns/downloads/ejbdesignpatterns.pdf robert > -----Original Message----- > From: Adam Hardy [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 17, 2004 4:00 PM > To: Struts Users Mailing List > Subject: Re: action - delegate - facade > > > The advantage of this approach, the way I see it, is that it allows you > to declare all your 'views' or 'transfer objects' in xml, and have them > strongly typed (as opposed to formbeans) - and that it works well with > BeanUtils.copyProperties. > > Are there any disadvantages at the back-end because of the map-backed > nature? I mean in the EJB layer? > > > > I have been doing this but using a xml configuration file, using a Struts > > plugin. It falls on something like this: > > > > <?xml version='1.0' encoding='utf-8'?> > > <!DOCTYPE views PUBLIC "-//04Web//DTD Horizon Configuration 1.0//EN" > > "http://www.04web.com/dtd/horizon-config_1_0.dtd";> > > <views> > > > > <view name="usersView"> > > <dyna-property property="users" type="java.util.Collection"/> > > <dyna-property property="flag" type="java.lang.Boolean"/> > > </view> > > > > </views> > > > > (similar to struts-config) > > > > I did this because I found it a bit confusing mixing bean attributes to > > retrieve html form data and attributes to deliver the intended presentation. > > > > I use a "view" factory to retrieve the bean definitions and then do > > something like: > > > > view.set("property", object); (I extended the DynaBean and implement the > > Map interface to achieve this - much simpler and JSTL friendly) > > > > ...you could also use BeanUtils for setting the properties. > > > > > > A simple module aware configuration: > > > > <!-- HORIZON PLUGIN --> > > > > <plug-in className="com.ohforweb.horizon.HorizonPlugin"> > > > > <set-property property="config-files" > > value="/WEB-INF/horizon-config.xml"/> > > > > <set-property property="parser-validate" value="true"/> > > > > <set-property property="module-aware" value="true"/> > > > > </plug-in> > > > > When I send the request I usually send a "view". If aa prepopulated html > > form is to be presented I send a "view" and a form bean. > > > > Voila :) > > > > Pedro Salgado > > (http://www.04web.com/) > > > > > >>----- 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] > > > > > > > > --------------------------------------------------------------------- > > 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]
