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]
