Kevin,
I'm following the same train of thought with perhaps the following
adjustments.
Stateless session EJB = business process
i.e. the performance of a coordinated sequence of "atomic" operations
performed to accomplish a coherent goal. Typically this would involve the
instantiation/use of entity beans and their methods.
If this is the case I see stateless session EJBs as the replacement for the
"Action" classes.
The so-called adapter or JSP bean is really just a handy mode of conveyance
of the data from the presentation layer JSP to the application layer. I do
not think any validation/business rule should go here since surely this
belongs in the accessor methods of the entity EJB.
Now, regarding the task of getting the data over to the EJBs - binding EJBs
(by expecting them as parameters or return values as you have posited in
earlier emails) to the adapter/JSP beans seems to detract from the
demarcation established between layers. So, use an XML interchange instead.
Add a standard method to your adapter beans (inherit from superclass or
static) that uses introspection to render itself as XML data.
Then the EJB can similarly have standard utility using introspection to
populate itself from an XML stream.
If you write the introspection to be driven by the bean properties rather
than the XML it means that the XML stream can be very flexible file because
it can be a superset of the actual bean properties rather than tightly
bound.
I'd be very interested in anyone's input on this.
Regards
@
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
