Hi Chris,
Here is the approach used in my just-finished application. You seem to
be familiar with the J2EE patterns catalog so I'll use those terms.
Regarding Tags vs Custom Actions -- I have come to the pattern you
paraphrased below (Model-altering=Actions, vs Model-reading=Tags) based
upon the work and comments of luminaries in the JSP community such as
Hans Bergsten (author of the OReilly book on JSP). I can't quote any
specific pages or sites, but the pattern has a very nice feel to it, it
just seems right. Basically, as the "business logic provider", you need
to maintain tight control over changes to the model, including
parameters used etc. In that case, it makes sense to centralize model
changes into a "Front Controller servlet" (of which Struts is an
example). On the other hand, your HTML/JSP developers might need to pull
data together to render, in combinations you didn't forsee (or even
really care about) at project outset -- to support that scenario, you
simply provide a library of "Model-reading JSP tags" and throw it out
there, for your HTML/JSP developers to go to town with.
In both cases (either custom tags or Struts actions), every method is
really just a shallow pass-through to methods in a Business Delegate,
which in turn is passing through to a [Stateful] Session Facade.
I also never pass anything Struts OR EJB specific across the Struts-EJB
boundary -- that is, I only pass Java primitives, or simple beans ala
the Value Object pattern. This means that when a Struts action is
processing an ActionForm, I copy it into a simple Value Object (which
has roughly the same methods and properties), and then pass the VO to
the EJB layer. The EJB layer is also returning complex data in this same
format (Value Objects), and since VO's are just java beans, then these
VO's are ready to be inserted into the request, session, or page
context, to be utilized by the JSP pages.
This style results in a lot of classes which have roughly the same
method signatures. This includes:
- entity beans, bean class
- entity beans, remote interface
- Value Objects
- Struts ActionForms
Here's a key shortcut: The tedium and error-proneness associated with
all that duplication can be reduced by abstracting the get/set methods
into an Interface which all those classes implement, and the properties
themselves (the Java primitives) into a base class from which
everythings extends (except the entity bean remote interface, which
can't because it's an Interface, not a class).This only works perfectly
when there is a 1:1 correspondence of properties across all layers in
the system. When this isn't the case (e.g. when the EJB utilizes a
primary-key-sequence-integer, but the JSP layer isn't concerned with
it), then you have some dead code floating around which I suppose you
just have to remember to ignore.
Using the above shortcut, I also simplified development of the Session
Facade and Business Delegate by both implementing a common interface.
The Business Delegate was very useful because I added a simple
object-level sycronization statement around each method call into the
actual EJB session bean. This is very important, because, Stateful
Session Beans in EJB are required to be single-access only (no
concurrent method calls); if you try to issue concurrent method calls,
the EJB container will throw an exception when it receives the second
call. This is surely to be a BIG PROBLEM if your "client" is a web
application which uses FRAMES -- Multiple frames in a frameset all
hitting EJB at the same time (for the same user) will error out.
The synronization code in the Business Delegate was ridiculously easy to
implement -- all it's methods look like this:
// theBean is the "actual" EJB stateful session bean, managed by this
Business Delegate "handler".
public boolean logon(String username, String password) throws
RemoteException {
synchronized (theBean) { return theBean.logon(username, password); }
}
In the whole arena of "copying similar ValueObjects", there is room to
grow in my work -- for example, an intelligent property-copier could
note, for example, that I am copying FROM the web tier, TO the EJB tier,
thus don't bother copying a primary-key-integer for example (since it's
immutable and EJB-assignable). Or I could be copying FROM the EJB tier
TO the web tier, in which case, don't copy any password fields (since
they are "writable" when a user changes password, but never "readable",
as is the common style in web applications). This is probably a fuzzy
concept right now but after your project I'm sure you'll understand.
In the end (as you probably gleaned from my Post-Mortem), I was a little
disappointed in Struts -- not because it doesn't do well what it
purports to do (it does, in fact, do it well), but instead, because I
entered into the project thinking Struts would be a central organizing
principle for my entire application, keeping complexity in check and
making the whole thing manageable. Perhaps it was my error to start off
with that perception. But in the end, the whole Struts framework ended
up "handling" only a relatively small piece of my entire application.
The "front controller servlet" aspect of it is useful but there are
certainly other front controller patterns to use (such as the one in the
J2EE pattern catalog or their Pet Store app, or the one in the OReilly
JSP book).And the "form validation framework" I am certainly grateful
for and probably is the biggest piece I am happy to be using, but again,
Struts isn't the only game in town there (see Barracuda for what at
first glance appears to be a much more robust form validation framework).
Hope this helps, it's good for me to write about the experience as a way
of processing and debriefing myself, in addition to helping others.
Bryan
[EMAIL PROTECTED] wrote:
>Hi Bryan,
>
>Thanks for your reply and pointer!
>
>I got several questions for u and all experts of this list,
>
>Any reasons behind regarding the recommendation about "the tags vs. actions
>dilemma"?
> ==========================================================================
> =1. if the Java code will alter your Model, then put it in an Action (or =
> =equivalent). =
> =2. if the Java code is only reading your Model to aid in rendering some =
> =portions of it, the put it in a custom JSP tag. =
> ==========================================================================
>
>Do u mind to give me more information about your application architecture?
>
>For the sake of discussion, let's assume I only have two tables (parent and
>child), what will be the steps for doing fundamental stuff like query,
>update and create?
>
>For example, use case for query of record:
>1. jsp captures all required parameters for the query
>2. action form creates corresponding query form bean and validation
>3. action invokes business delegate and then service locator for getting a
>jndi reference to corresponding EJB (session or entity)
>4. action form (another one) creates corresponding display form bean with
>attribute of list of records (e.g. array)
>5. action (another one) copies EJB to list
>6. jsp displays results using iterate tag for the list
>
>Thanks again, I appreciate!
>
>P.S.
>I'm very very new for such development environment (struts + EJB), please be
>patience 8)
>
>Chris
>
>-----Original Message-----
>From: Bryan Field-Elliot [mailto:[EMAIL PROTECTED]]
>Sent: April 26, 2001 4:39 PM
>To: [EMAIL PROTECTED]
>Subject: Re: (struts + EJB) example
>
>
>Chris,
>
>I don't have an example for you, but I have written a brief post-mortem
>analysis of a major project just finished which used EJB and Struts. It
>can be found here:
>
>http://www.mail-archive.com/struts-user%40jakarta.apache.org/msg06088.html
>
>It was posted to this group, but no one had anything to say in response,
>other than someone who referred me to a different framework (Barracuda),
>which I will be investigating next.
>
>Regards,
>
>Bryan
>
>
>[EMAIL PROTECTED] wrote:
>
>>Folks,
>>
>>Anyone know where I can get an example which use struts and ejb?
>>
>>Thanks in advance!
>>
>>P.S.
>>Struts can work out of box with latest version of orion (i.e. 1.4.8) now 8)
>>
>>Chris
>>
>>
