See below for some comments....
Personally, I think the issues you discuss below could be eliminated by
getting direct support for EJB's into the JSP spec, to be used as
regular JavaBeans are today. I think some of the vendors are
implementing this sort of thing in their JSP 1.1 engines as custom tags,
which will give us some useful material upon which to build a
standard...
Kevin Duffey wrote:
> The one thing I didn't get an answer on from anyone yet is how to pass the
> same bean used by the forwarded JSP page, to the EJB, and get it back again.
> I am not quite clear on this. If I pass in an object, does it come back
> changed, or do I have to assign it for it to be changed? If so, do I need to
> create a new object (of the same bean instance) to reference the changed
> object, and so on.
I believe you should count on getting a different instance back from the
EJB, especially if the bean is being serialized and passed over the
network. If that doesn't happen, there is very little overhead in
assigning a particular object reference back to itself:
// plop some values in a Java bean.
Bean mybean = new Bean();
mybean.setProp1(value1);
mybean.setProp2(value2);
// Send the bean off for processing, may get a new instance back
mybean = myEJB.doSomething(mybean);
> To elaborate on what I am trying to do, I was thinking that the adaptor
> (action) class' purpose is to get the request form data from the page/form
> submitted into a javabean, pass this bean as the serialized object parameter
> to the EJB, have the EJB use this data in whatever way needed, if it is,
> doing the logic and filling this bean with various data (maybe modifying
> existing properties, adding new data to empty properties to be used on the
> JSP page for display, etc). It then returns this same bean back to the
> adaptor class which then puts it in the request or session, and forwards to
> the JSP page so it can be displayed (if need be).
This is certainly one possible design methodology (I'll call it the
bean-as-cache pattern for now). An alternative is the proxy pattern
which has been discussed here before. I'm not sure whether one of these
is better than the other, but I too would like to hear comments from
others.
The primary issues for both design methodologies are handling
concurrency and caching. You want to maximize caching to minimize
traffic between your EJB server and JSP/Servlet engine but at the same
time you do not want your web users to be viewing or updating data that
has been changed on the server.
The bean-as-cache pattern has the useful property of maximizing caching,
BUT you need to somehow handle concurrency. This could ben an event
mechanism, where the bean receives an Invalidate event when something is
updated on the server. Alternately, it could use a sequence number or
timestamp to detect that someone else has made an update on the server
when you attempt to submit your own change (an optimistic concurrency
model). A third alternative is pessimistic concurrency, which locks
things on the server while being edited (NOT recommended for web apps
where the user can just browse away from your page). Optimistic
concurrency is usually touted as having the best scalability, because
all conflict resolution is directed back at the user.
The proxy pattern has some really ugly overhead involved with hitting
the EJB server on every property get- or set-method. This could really
only work well if the EJB server is running in the same process space as
your JSP/Servlet engine where the overhead is only a few method calls.
If you have to go across the network for every get/set method, your app
will fall to its knees.
> Another question which I believe pertains to this. Craig, you already said
> to use stateless ejb. So..if I have a multi-page form, in some cases the
> next form is built based on the previous forms data, do I store the data
> from all these forms on the web-server servlet-container HttpSession? Or is
> there some other mechanism for keeping state for a particular client on a
> multi-page form?
I belive Craig's intent was that the bean (or set of beans) should be
designed to carry enough information to model the real-world entity.
So, for instance, if you are modeling a CustomerOrder, you will want it
to contain LineItem's, ShippingInfo, PaymentInfo, etc. When all items
are filled in, you would submit the whole CustomerOrder to an EJB
Session Bean for processing.
Personally, yes, I would store the CustomerOrder in the session until it
is complete.
The issue here is that the current JSP spec does not handle the
beans-contained-within-beans model very well. You will have to do some
work with scriptlet tags to do this.
> Lastly, is it good, workable or bad design to use a single bean for multiple
> page forms data storage? I am not quite in the know if I should be using a
> javabean JUST for get/set operations to "model" the particular data the EJB
> will return and the forms will send, or if I should provide any logic in the
> beans, even though we are using EJB. My thought is, let the EJB do ALL the
> work, and only use the JavaBean as a means for the JSP page to display the
> dynamic content...thus it is more of a "data" bean to store data between
> requests or during a session.
I would form the distiction like this -- you want your EJB's to
implement business rules and any Company- or System-wide logic and
behavior. You want your intermediary beans to implement presentation
logic and caching behavior (see above). You want your JSP pages to
implement the display of information, BUT, and this is a big but, you
want to minimize the amount of language-specific (i.e. Java) code in
your JSPs. Thus, some level of presentation logic belongs in the
intermediate beans.
Some of these presentation logic issues can be generalized with custom
tags if you're running in a JSP 1.1 engine, but that is not the majority
right now.
Personally, I think some level of presentation logic belongs in the
intermediary bean. Just as one would design graphical JavaBeans to know
how to present themselves in a window via AWT or Swing, I think that
web-oriented beans should know how to display themselves on an HTML
form. For instance a Province bean should know how to build a popup
list of provinces, making its current province the selected one. It
should be customizable, yes, such as passing in strings that can be used
by MessageFormat.format() for placeholder substitution. But
fundamentally, it *should* know how to present itself. By having
methods like this, one eliminates some really ugly, redundant code in
their JSPs...
Hope this helps,
-=- D. J.
===========================================================================
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
