Hi Joshua,
We have developed a similar model and we are about to publish our first
real world application that uses the model in some days. However, as
we've been developing it for a couple of months I have some preliminary
conclusions that might be interesting.
First I'll explain the model, which just slightly different.
.- Our model also uses the "Controller Servlet" approach, that receives
all the requests for the application (or a set of applications that want
to share the same ServletContext). We also perform here the security
checking and we add application wide events control(onApplStart,
onApplStop, onApplRequest).
.- However, we decided not to redirect(from the controller) to another
servlet/JSP for the operational logic. We follow here the Action
pattern, operations are encapsulated in classes that are dynamically
loaded in Runtime and have some simple methods like setParameters,
chechParameters, executeOperation. So parameters are passed to this
classes and the operation is executed, in case anything occurs control
is forwarded to customizable error pages, otherwise the result is
redirected to a page(usually dynamic but not necessarily) that can
format the results as he wants.
We decided against using calls to "header", "data"... frames from the
controller servlet because we wanted it to be truly independent from the
UI. So if you want to keep the header/data frames structure you can do
it inside the page where your results are redirected. This way you can
also use the same class with different UI's, just adding a new operation
that uses the same class but redirects to a different JSP, for example.
To pass the results from the operation to the JSP we use the request
scope. The "contract" between the JSP designer and the operational logic
then becomes the names and types of the attributes that will be returned
through the request object. Commenting this in the javadocs of the
operational classes could be some way to specify it, not quite formal
but... Some objects are always passed by default, for example the Result
of the operation, so the JSP can also get some "environment"
information.
Good things I found about this approach:
.- We configure almost everything through XML so adding new operations,
changing error pages... is very very easy.
.- We created a set of JSP pages that can be used to see how your
application is configured(the XML file content basically) and to manage
the application (start/stop, enable/disable...) so now every application
that we create with this approach has an application manager which can
be fully customized (per site or per application). This set of JSP pages
and classes is actually one application that uses the model, so the
framework controls itself through it.
.- I'm about to add a logging facility so the framework can have a
formal log system and I'll allow the application to use the same system
for their logs, or customize them if they please. Next thing is to
create another optional application to monitor security in the
applications: write once, use it on all the applications ;). These would
be really a relieve as having to write all this security logic and
monitoring is quite repetitive and tedious for every application.
.- One way we go against the "current trend" is that we don't use XML to
specify things like security in our system, as EJB and JSKD2.2 seem they
will do. We use classes that are dynamically loaded in runtime so we
specify a "standard" interface and we allow people to implement it as
they please. For example, our first application gets the user names and
passwords from a DB, but the manager application that controls
everything gets them from an XML file. We use the same approach to
specify application wide events, and we are going to use it to allows
users to fully customize the logging system because we have founded it
to be much more flexible and powerful than specifying them through XML
files than are not easily changed/reloaded in runtime.
.- The requirements are quite low, a JSDK 2.1-compatible servlet engine
is almost everything that you need.
Not so good things I found about it:
.- We have to develop/mantain this environment ourselves. We are keeping
it simple so it's not unmanageable but of course it is much better when
you just download a product and then complain to a mailing list. Why did
we decide to go for it ourselves? Because we didn't find an application
server that was light and customizable enough for what we wanted. But we
try to keep it in a way that current standards might introduce some of
the features so servlet engines will do the job for us.(JSDK2.2 will
already save us some work, even though we find it disappointing
regarding security)
Apart of this important one, we are quite happy about it and if this
first real world application succeeds, we'll probably start using it for
all our future applications.
Last remark, we are actually using EJB in our first application and
that's where I've found the weak point to be, as RMI gets me some
strange errors under digital unix every now and then. Apart of that, the
four layer separation that we designed for the project works like a
charm(UI=JSP,OperationalLogic=classes,Business Logic=EJB,DataModel=DB).
I also apologize for this long email but you asked for it ;).
I hope this helps,
Dan
-------------------------------------------
Daniel Lopez Janariz ([EMAIL PROTECTED])
Web Services
Computer Center
Balearic Islands University
-------------------------------------------
Joshua Lannin wrote:
>
> Recently I have been helping my company develop a model for a two-tier
> architecture which will be easily migrated to an EJB multi-tier environment.
> We have created the attached document which details the architecture we are
> going to be working with. I'd like to solicit comments from this mailing
> list, as well as make it available to others. It is loosely based on some
> various MVC design pattern articles.
>
... removed for brevity's sake.
===========================================================================
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
