Andrew,
I thought of XML stream approach myself if I would have to introduce EJB in
my applications. If keeping JavaBean simply as a holder of JSP-related data,
there is no reason it cannot be populated easily from XML or used to
populate XML.
Using this approach and model 2, it is questionable if you need Action (or
Command) implementing classes. Your ActionServlet using general utilities
can do most of the job (populate XML, forward to session bean execute()
method that stream, get back the resulting stream , populate the bean from
it, and forward to the next JSP URL presumably read from servlet XML
configuration file).
I've never seen session bean logic constructed around the data streams which
contain data inside, but there is probably no reason this would not work.
I am interested in what others think about it.
Vadim Shun
NEW Corp
Dulles, VA
-----Original Message-----
From: Andrew S Tomlinson [mailto:[EMAIL PROTECTED]]
Sent: Monday, April 24, 2000 10:58 PM
Subject: Re: Thin beans in model 2 - revisited
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
