(http://www.jcp.org/en/jsr/detail?id=227)
Which provides, in metadata, an abstraction of the business service in terms of collections and operations. Allowing the view & controller layers can be totally agnostic of the actual source of that set of data / logic, be it EJB, a Webservice, LDAP, POJO, TopLink or whatever.
You can play with an early version of this in JDeveloper 10g Preview <http://otn.oracle.com/software/products/jdev/index.html> or wait for JDeveloper 10g Production which will be available "real soon".
Duncan
Robert Taylor wrote:
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]
