Hi Adam there is a good book on it! http://www.corej2eepatterns.com/Patterns2ndEd/index.htm i use it very often... but more it's german version... :-) however that covers j2ee1.4 cheers,
btw. under the sun, there is a code camps, or however they call it for strtus and j2ee_patterns: http://developers.sun.com/events/techdays/codecamps/index.html (third link ;-)) cheers! Matthias -----Original Message----- From: Adam Hardy [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 17, 2004 2:08 PM To: Struts Users Mailing List 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/BusinessDeleg > ate.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]
