tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Assaf Arkin <ar...@exoffice.com>
Subject Re: [LONG TERM PLAN] Proposed Architecture for Tomcat.Next Servlet Container
Date Wed, 29 Dec 1999 00:31:47 GMT
> IMO, interceptors and pipes do not (and should not) overlap.
> Interceptors are used to "intercept" events and trigger actions, pipes
> are used to "decouple" the processing into several stages to allow
> better context separation, easier component reuse and more flexible
> functionality.

I agree, but that should not prevent interceptors from messing with the
response stream.

IMHO Interceptors have nothing in common with what Servlets in general
(including Cocoon) deal with. If you look at the APIs you might find
functional similarities, stuff you can do with either one, but Servlets
and Interceptors exist in two separate problem/solution domains, so
there's no real overlap between the two.

Your application is made up of Servlets and should be made up of just
that, Servlets. It's contents is defined by web.xml, and has no
authority over interceptors. In contrast services hooked up into Tomcat
are extensions to the Tomcat engine. Servlets do not explicitly depend
on them, nor are they aware of their existence.

Consider a security service implemented as a response-changing
interceptor. Whenever a request is made the service checks whether the
connection is secure and the user is authenticated, and if not, displays
an "access denied" page. If you hook up this service into Tomcat through
the Interceptor API you gain an extra level of security for your
Servlets. But your Servlets will run the same whether or not you have
this service.

As long as your servlets remain true to the Servlet API and make no
assumptions about the environment, and Interceptors remain true to the
connector API and make no assumption about particular servlets being
run, you can plug and play applications and services to the same server.

As proof of how robust this model is, I got Tyrex integrated into Tomcat
in a matter of hours offering JTA and JDBC services to Servlets running
inside Tomcat without requiring any changes to your Servlets. I can plug
an LDAP security provider into Tomcat, once again without changing a
single thing about the Servlets running in it. I can plug the Tyrex
visual meter (nice eye candy) to see how many Servlets are running in
real time without changing any of the Servlets I'm using. I can plug a
persistence engine to automatically persist sessions.

And all the while, I'm happily using Cocoon which is my Servlet
application.

arkin



> 
> The RequestDispatch idea was proposed to fill holes in the Servlet API
> for JSP support, but do not provide any piping feature since you can't
> touch the generated response. Interceptors should do the same, leave it
> untouched.
> 
> It will be responsibility of another proposal to come up with something
> to allow a servlet to be decoupled into piped components.
> 
> IMHO, I don't think there is the need for servlet piping (you can't pipe
> a response into a request!). And servlet filtering is something that
> will be proposed in Servlet 3.0 but that I consider totally useless, if
> stream based.
> 
> My idea is what I designed almost exactly last year in Cocoon: create a
> framework for servlet internal components and provide standard abstract
> transport ways to connect them.
> 
> Our latest model is the following: a servlet operation can be decoupled
> into
> 
>  - a producer
>  - zero or more filters
>  - a serializer
> 
> The producer is responsible to produce some output and start the
> processing either from request parameters or from internal logic.
> 
> Every filter, if present, is responsible to work on the receiving input
> and generate output. A filter implements both "producer" and "consumer"
> patterns.
> 
> A serializer is responsible to go from the internal transport used
> between components to the byte stream used to drive the response.
> 
> This model allows servlet engines to be back compatible since servlets
> do not change their functionalities. On the other hand, it allow better
> code reuse and better flexibility for XML needs. (for example, JSP are
> compiled into producers, not servlets).
> 
> This is, IMO, the way to go: instead of following the appealing yet
> nonsense path of servlet chaining, use better OO patterns and create a
> framework for internal component structure.
> 
> Hope this helps.
> 
> --
> Stefano Mazzocchi      One must still have chaos in oneself to be
>                           able to give birth to a dancing star.
> <stefano@apache.org>                             Friedrich Nietzsche
> --------------------------------------------------------------------
>  Come to the first official Apache Software Foundation Conference!
> ------------------------- http://ApacheCon.Com ---------------------
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

Mime
View raw message