Vic, You should not extend the form bean for Data access as it is part of the View of MVC. The data Access should follow on of two Patterns DAO which allows for EJB or JDBC or the following:
To implement a screen of the particular Use Case, the following artifacts should be created: 1. Action class handles logic of that particular screen, errors and, probably, validation. 2. ActionForm class stores and validates the data presented on the screen. 3. BusinessDelegate class is responsible for finding and performing inter-tier method call of the Stateless Session EJB façade object that resides on the business tier. The value objects facilitate the interaction between BusinessDelegate and UseCase Façade. See the description of Business Delegate pattern at http://developer.java.sun.com/developer/restricted/patterns/BusinessDelegate .html. See the description of ValueObject pattern at http://developer.java.sun.com/developer/restricted/patterns/ValueObject.html . 4. Use Case Façade is Stateless Session EJB, which sits on the business tier and implements system-wise business methods that perform the logic of Use Case. See the Session Façade pattern at http://developer.java.sun.com/developer/restricted/patterns/SessionFacade.ht ml 5. JSP Page represents view in the MVC pattern. It should contain only HTML code and all the logic should be encapsulated into the Struts JSP Tags. And I think the only people using SOAP at still at SilverSteam. HTH Barry ----- Original Message ----- From: "Vic Cekvenich" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, December 18, 2001 6:37 PM Subject: Re: accessing EJB components from a Struts application? > Why are you needing to use EJB? > Presumably something distributed, and you do no want to use SOAP. > > If you use EJB for persistence, I would implement Astral Clones Design > Pattern like this: > Extend FormBean, and add a property of RowSet (a JDBC interfaces > implemented by CachedRowSet). Add geters and setters to and from RowSet, > that then go to whatever, EJB in your case. Add the rest of the Astral > Clones. You can then later replace call to EJB with JDBC/RowSet update() > method. (Why not do JDBC calls right away? EJB might make you slow if > this is a larger app.). > Then in Action, ask your FormBeans to connect, retrieve, CRUD, validate > , and disconnect. > > If you need to write something more complex in Action, then use > helper/utility classes. > > /* :-D J2EE development is a bit like Masonic brotherhood. There are > perceived secrets about how it is really developed. Ex: What are design > guidelines and exhibits best practices for building distributed > applications with the Java Enterprise Edition/ aka How should I change > my application requirements in order to use message beans. */ > > Search google.com for Astral Clones or RowSet or whatever. > > Vic > > > [EMAIL PROTECTED] wrote: > > >Hi all, > > > >after browsing the FAQ and searching the mailing list archive, > >I have not yet found a 'premium way' to go for EJB business logic > >integration into a Struts application. > > > >It's pretty clear that the EJB stuff should go into the action classes. > >I also saw hints that it might be useful to add another layer between > >the action classes and the entity/session beans in order to keep the > >action classes small and independent from the underlying business logic > >tier architecture. > > > >So the recommended architecture would be > > > >action class <-> ejb 'helper' class <-> EJB Session/Entity Bean > > > >which allows for e.g. replacing the EJB tier by direct JDBC > >database access without having to modify the action classes. > > > >Is the presented view correct/recommendable, or have I probably missed > >some important developments concerning the Struts<->EJB issue? > >Besides selected threads of this mailing list, are there any > >instructive resources/links regarding the topic? > > > >Regards, > > > >-- > >Thomas Corte > ><[EMAIL PROTECTED]> > > > > > > > > > >-- > >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
