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
http://java.sun.com/blueprints/corej2eepatterns/Patterns/BusinessDelegate.htmlwhich 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://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]
