I agree that the approach described by Craig is the preferred approach, but
the issue that I have with it in our application occurs with workflows. Not
unlike many others I'm sure, we are delivering a UI via the web that in the
past would have been a standalone application UI, and to do this requires
that you take a step back in technology to accommodate the limitations of
web servers and especially browsers.
Part of what we do requires complicated workflows in which the user must
traverse multiple pages to accomplish a task(s). The workflows are complex
in that they may branch, subsets of them may be re-used within other
workflows, and sometimes one workflow may bridge to another workflow (for
example, a search workflow target may be the same as the target of a
drill-down workflow).
So the issue that I have with the page->servlet->bean->page design is that
the servlet must support these workflows by directing requests to the
appropriate bean based on the client's current workflow state. The only
information that the servlet has available to direct the request is the data
in the request itself, so the servlet has to do some kind of
string-parameter to bean-class mapping to direct the request to the
appropriate bean. Given that I'm used to developing a standalone
application UI where I could fire events that would easily manage this, the
mapping seems very kludgy to me. You don't want to hard-code it, but if you
create some additional framework to make it configurable, you run the risk
of a runtime mapping error. Oh, did I mention that our framework has to
support users customizing and/or extending existing workflows and even
creating their own new workflows?
Assuming that a bean can handle workflow specific logic for a particular
workflow, all the servlet need do is map a workflow name to a workflow bean.
Then the rest of the framework is responsible for inserting the appropriate
state information (e.g, workflow name) into subsequent requests. This still
has the problem I mentioned above.
The other issue is re-using pages within different branching workflows. In
some workflows, a page would have a 'Next' link to go to the next page in
the workflow, and in others the same page would be the final page in a
workflow. You could easily create separate pages for each workflow, but I
would prefer to avoid the maintenance problems that this would cause. So
the framework has to support generating pages based on the context of the
workflow. However the JSP pages are where this logic has to be applied, and
I don't want to use scriptlets in the page to do this. I'm hoping that tag
extensions will be a clean way of separating this logic from the page.
Either there's better mechanism for supporting the workflow name mapping, or
I'm just gonna have to live with it.
David
----- Original Message -----
From: Craig R. McClanahan <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, November 24, 1999 10:16 AM
Subject: Re: Which Architecture..?
> sdheepa wrote:
>
> > Just look at the Foll. Architecture:
> >
> > JSP File ->Contacting Servlet-> This Servlet in
> > turn talks with EJB to perform bussiness logic...
> >
> > What are the advantages/diadvantages of having the
> > Servlet to contact the EJB..with repect to performance
> > and scalability...
> >
> > Instead of having the servlet contact the EJB why not
> > we have the Java Bean talk to the EJB..
> >
> > ie what problems we might face if the architecture is
> > like this:
> > JSP File ->Contacting Java Bean-> This Bean in turn
> > talks with EJB to perform bussiness logic...
> >
>
> The issue I have with this approach is not performance or scalability --
there
> will not be any significant differences here, because (as many have
pointed out)
> JSPs get turned in to servlets anyway. Rather, what I am concerned about
is
> maintainability and code re-use.
>
> Using a JSP-Bean-EJB architecture (instead of my preference, which is
actually
> JSP->Servlet-Bean/EJB->JSP) is that you have to embed your procedural
business
> logic *inside* your JSP page. This ties the two things together so that
you
> cannot change one without at least affecting the other.
>
> Instead, I prefer to segregate all my business logic (but zero HTML
generation)
> into servlets, which can use EJBs when appropriate or other techniques
(such as
> direct JDBC access) when EJBs are not necessary. I use beans to
communicate the
> processing results back to an appropriate JSP page for display, using
> RequestDispatcher.forward() to transfer control.
>
> Just as an example of the kinds of things that happens to applications
during
> their lifetime, consider that you've built a nice transactional web
application
> for browsers, using HTML for the presentation. Now, your company decides
to build
> a version of this application for a wireless device, using WDML instead of
HTML
> (this is perfectly feasible with JSP and servlets). If you've separated
the
> business logic as I suggest, you've got a pretty good chance at being able
to
> reuse most or all of it. If you've embedded your business logic in the
HTML code
> in a JSP page, you're going to have to duplicate it, and maintain two
versions
> "forever".
>
> >
> > Other than multi-threading do we have any other
> > addtional adv. if we use Servlets..?
> >
>
> On larger scale (multi-developer) projects, the separated approach also
allows you
> to devote Java programmers to the business logic side, and user interface
> developers to the JSP side. They can work reasonably independently of
each other,
> once the bean interfaces are agreed upon, without stepping on each other's
changes
> to the same source files.
>
> >
> > Can someone help me..?
> >
> > Thanks in advance..
> > Dheepa
> >
>
> Craig McClanahan
>
>
===========================================================================
> To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
JSP-INTEREST".
> FAQs on JSP can be found at:
> http://java.sun.com/products/jsp/faq.html
> http://www.esperanto.org.nz/jsp/jspfaq.html
>
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
