Re: [Fwd: [LONG TERM PLAN] Proposed Architecture for Tomcat.Next Servlet Container]

[Eduardo Pelegri-Llopart <Ed...@eng.sun.com>]

I have not looked to Craig's proposal (in my printer now), but I share
the inclination of making some notion of filtering part of the platform,
with the ability of processing incoming requests and outgoing responses.

FWIW, OMG uses the term "interceptor" for something similar, in the
context of IIOP invocation, if I remember correctly (their web site -
www.omg.org - was only partially responding).  Since IIOP is also part
of J2EE, it may be worth using another term; I have not looked at
Craig's description well enough to make a suggestion yet.

	- eduard/o

Ricardo Rocha wrote:
> 
> > Ricardo Rocha wrote:
> > > Provided they're given "write-access" to the servlet
> > > response, do you see XSLT postprocessing as inside
> > > the realm of interceptors' purpose in life?
> > >
> 
> Craig McClanahn wrote:
> > If the community at large thinks that this kind of
> > post-processing should indeed be embedded in the
> > engine itself (I've personally felt that this should be
> > handled at the application level, inside a servlet
> > like Cocoon, but I haven't looked deeply at what that
> > means either), then yes, it is definitely within the purpose
> > in life of Interceptors. Because you can attach an
> > Interceptor to any container you like, you can easily
> > impose the post processing (and pay the corresponding
> > overhead price) only on the output from a particular
> > servlet, or the servlets of a particular web application.
> 
> Yes, Cocoon already provides (excellent!) application-level
> support for servlet-based XML/XSLT web publishing.
> However, there seems to be a certain degree of "friction"
> between Cocoon's DOM-based processing model and that
> of stream-oriented servlets and JSP.
> 
> Even as Cocoon embraces [stream-oriented] SAX it seems
> that the servlet architecture as such needs to be extended
> to better accommodate XML processing in general.
> 
> Under these circumstances, a "response-writing" interceptor
> looks certainly appealing!
> 
> Why so? Why embed XSLT post-processing in the engine
> itself instead of at the application-level? How does this
> relate to the fact that XSLT processing is recognized
> as relevant in the JSP spec but its support has not been
> addressed yet?
> 
> Let's consider the case where we want our servlet/JSP
> application to generate XML, instead of "raw" HTML.
> 
> We know this is desirable for the usual, well-known
> reasons: achieving "true" separation of content and
> presentation, making JSP page authoring accessible
> to non-programmers by means of tag libraries and
> application-oriented markup vocabularies, generating
> presentation markup in a browser and device-independent
> fashion, generating portable DHTML, etc, etc...
> 
> Obviously, this servlet/JSP-based XML generation
> demands XSLT post-processing. This, in turn, imposes
> a penalty in terms of additional processing load.
> 
> Let's recall here that XSLT processing may take place
> at either the server _or_ the client side. Thus, whenever
> possible, we want to offload XSLT processing to the
> client.
> 
> Not all browsers support XSLT, though (in fact, only one
> does right now!) so the server must still be capable of
> providing such processing.
> 
> How do we achieve this without requiring our servlets and
> JSP pages to be concerned about how XSLT processing
> takes place?
> 
> It looks like an interceptor could do a terrific job here:
> given the request's user-agent it would decide whether to
> transcribe response output verbatim or post-process it by
> applying an XSLT stylesheet. (Again, this is based on the
> assumption that XSLT processing is stream-based, SAX)
> 
> > The reason that write access is an issue in the proposed
> > architecture is that the Response implementation is actually
> > provided by the communications adapter through which the
> > request was received.  It is the adapter-supplied logic that
> > implements ServletOutputStream that will be oblivious to the
> > need for the extra buffering, and that's the design issue
> > that needs to be dealt with.
> 
> Yes, this is at the core of the "servlets limitations for xml
> processing" discussion. It's clear we badly need an extra
> layer between servlet-level response output manipulation
> and actual network communication.
> 
> > Of course, any such use of Interceptors for post
> > processing will be Tomcat specific, because it is
> > not part of the standard servlet API. However,
> > successful use of Interceptors for this might
> > motivate the inclusion of similar concepts in the
> > standard in some future version.
> 
> I sincerely hope this is the case! The Servlet API would
> really benefit from a revision that better accommodates
> XML processing.

Re: [Fwd: [LONG TERM PLAN] Proposed Architecture for Tomcat.Next Servlet Container]

[Eduardo Pelegri-Llopart <Ed...@eng.sun.com>]

Right, if the concepts are close enough then I agree one can reuse the
term as you do in your paragraph: tomcat interceptor, iiop interceptor. 
And, when the context is clear enough one can just talk about
"interceptor".

The situation is the same with containers, but a bit different with
components, since we have given a specific name to most (all?) of the
components we have: Servlets, JSPs, JavaBeans, EJBs.

Thaks,

	- eduard/o

Assaf Arkin wrote:
> 
> OMG indeed is using an Interceptor that can affect the outcome of a
> remote invocation. The design pattern is similar to Craig's
> interceptors, it can extend the invocation (e.g. by adding transaction
> context), block it (e.g. security) or change it (e.g. by redirecting).
> Like Tomcat interceptors, OMG interceptors are not part of the
> application but part of the environment and can be plugged into the ORB
> to enhance it's functionality, but applications are not dependent/aware
> of them.
> 
> Since both IIOP and Tomcat Interceptors fulfill the exact same design
> pattern, there is full justification for using the same name, just like
> both Servlet and EJB are termed containers and use Sessions, even though
> the APIs are totally separate,
> 
> arkin
> 
> Eduardo Pelegri-Llopart wrote:
> >
> > I have not looked to Craig's proposal (in my printer now), but I share
> > the inclination of making some notion of filtering part of the platform,
> > with the ability of processing incoming requests and outgoing responses.
> >
> > FWIW, OMG uses the term "interceptor" for something similar, in the
> > context of IIOP invocation, if I remember correctly (their web site -
> > www.omg.org - was only partially responding).  Since IIOP is also part
> > of J2EE, it may be worth using another term; I have not looked at
> > Craig's description well enough to make a suggestion yet.
> >
> >         - eduard/o
> >
> > Ricardo Rocha wrote:
> > >
> > > > Ricardo Rocha wrote:
> > > > > Provided they're given "write-access" to the servlet
> > > > > response, do you see XSLT postprocessing as inside
> > > > > the realm of interceptors' purpose in life?
> > > > >
> > >
> > > Craig McClanahn wrote:
> > > > If the community at large thinks that this kind of
> > > > post-processing should indeed be embedded in the
> > > > engine itself (I've personally felt that this should be
> > > > handled at the application level, inside a servlet
> > > > like Cocoon, but I haven't looked deeply at what that
> > > > means either), then yes, it is definitely within the purpose
> > > > in life of Interceptors. Because you can attach an
> > > > Interceptor to any container you like, you can easily
> > > > impose the post processing (and pay the corresponding
> > > > overhead price) only on the output from a particular
> > > > servlet, or the servlets of a particular web application.
> > >
> > > Yes, Cocoon already provides (excellent!) application-level
> > > support for servlet-based XML/XSLT web publishing.
> > > However, there seems to be a certain degree of "friction"
> > > between Cocoon's DOM-based processing model and that
> > > of stream-oriented servlets and JSP.
> > >
> > > Even as Cocoon embraces [stream-oriented] SAX it seems
> > > that the servlet architecture as such needs to be extended
> > > to better accommodate XML processing in general.
> > >
> > > Under these circumstances, a "response-writing" interceptor
> > > looks certainly appealing!
> > >
> > > Why so? Why embed XSLT post-processing in the engine
> > > itself instead of at the application-level? How does this
> > > relate to the fact that XSLT processing is recognized
> > > as relevant in the JSP spec but its support has not been
> > > addressed yet?
> > >
> > > Let's consider the case where we want our servlet/JSP
> > > application to generate XML, instead of "raw" HTML.
> > >
> > > We know this is desirable for the usual, well-known
> > > reasons: achieving "true" separation of content and
> > > presentation, making JSP page authoring accessible
> > > to non-programmers by means of tag libraries and
> > > application-oriented markup vocabularies, generating
> > > presentation markup in a browser and device-independent
> > > fashion, generating portable DHTML, etc, etc...
> > >
> > > Obviously, this servlet/JSP-based XML generation
> > > demands XSLT post-processing. This, in turn, imposes
> > > a penalty in terms of additional processing load.
> > >
> > > Let's recall here that XSLT processing may take place
> > > at either the server _or_ the client side. Thus, whenever
> > > possible, we want to offload XSLT processing to the
> > > client.
> > >
> > > Not all browsers support XSLT, though (in fact, only one
> > > does right now!) so the server must still be capable of
> > > providing such processing.
> > >
> > > How do we achieve this without requiring our servlets and
> > > JSP pages to be concerned about how XSLT processing
> > > takes place?
> > >
> > > It looks like an interceptor could do a terrific job here:
> > > given the request's user-agent it would decide whether to
> > > transcribe response output verbatim or post-process it by
> > > applying an XSLT stylesheet. (Again, this is based on the
> > > assumption that XSLT processing is stream-based, SAX)
> > >
> > > > The reason that write access is an issue in the proposed
> > > > architecture is that the Response implementation is actually
> > > > provided by the communications adapter through which the
> > > > request was received.  It is the adapter-supplied logic that
> > > > implements ServletOutputStream that will be oblivious to the
> > > > need for the extra buffering, and that's the design issue
> > > > that needs to be dealt with.
> > >
> > > Yes, this is at the core of the "servlets limitations for xml
> > > processing" discussion. It's clear we badly need an extra
> > > layer between servlet-level response output manipulation
> > > and actual network communication.
> > >
> > > > Of course, any such use of Interceptors for post
> > > > processing will be Tomcat specific, because it is
> > > > not part of the standard servlet API. However,
> > > > successful use of Interceptors for this might
> > > > motivate the inclusion of similar concepts in the
> > > > standard in some future version.
> > >
> > > I sincerely hope this is the case! The Servlet API would
> > > really benefit from a revision that better accommodates
> > > XML processing.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

Re: [Fwd: [LONG TERM PLAN] Proposed Architecture for Tomcat.Next Servlet Container]

[Assaf Arkin <ar...@exoffice.com>]

OMG indeed is using an Interceptor that can affect the outcome of a
remote invocation. The design pattern is similar to Craig's
interceptors, it can extend the invocation (e.g. by adding transaction
context), block it (e.g. security) or change it (e.g. by redirecting).
Like Tomcat interceptors, OMG interceptors are not part of the
application but part of the environment and can be plugged into the ORB
to enhance it's functionality, but applications are not dependent/aware
of them.

Since both IIOP and Tomcat Interceptors fulfill the exact same design
pattern, there is full justification for using the same name, just like
both Servlet and EJB are termed containers and use Sessions, even though
the APIs are totally separate,

arkin


Eduardo Pelegri-Llopart wrote:
> 
> I have not looked to Craig's proposal (in my printer now), but I share
> the inclination of making some notion of filtering part of the platform,
> with the ability of processing incoming requests and outgoing responses.
> 
> FWIW, OMG uses the term "interceptor" for something similar, in the
> context of IIOP invocation, if I remember correctly (their web site -
> www.omg.org - was only partially responding).  Since IIOP is also part
> of J2EE, it may be worth using another term; I have not looked at
> Craig's description well enough to make a suggestion yet.
> 
>         - eduard/o
> 
> Ricardo Rocha wrote:
> >
> > > Ricardo Rocha wrote:
> > > > Provided they're given "write-access" to the servlet
> > > > response, do you see XSLT postprocessing as inside
> > > > the realm of interceptors' purpose in life?
> > > >
> >
> > Craig McClanahn wrote:
> > > If the community at large thinks that this kind of
> > > post-processing should indeed be embedded in the
> > > engine itself (I've personally felt that this should be
> > > handled at the application level, inside a servlet
> > > like Cocoon, but I haven't looked deeply at what that
> > > means either), then yes, it is definitely within the purpose
> > > in life of Interceptors. Because you can attach an
> > > Interceptor to any container you like, you can easily
> > > impose the post processing (and pay the corresponding
> > > overhead price) only on the output from a particular
> > > servlet, or the servlets of a particular web application.
> >
> > Yes, Cocoon already provides (excellent!) application-level
> > support for servlet-based XML/XSLT web publishing.
> > However, there seems to be a certain degree of "friction"
> > between Cocoon's DOM-based processing model and that
> > of stream-oriented servlets and JSP.
> >
> > Even as Cocoon embraces [stream-oriented] SAX it seems
> > that the servlet architecture as such needs to be extended
> > to better accommodate XML processing in general.
> >
> > Under these circumstances, a "response-writing" interceptor
> > looks certainly appealing!
> >
> > Why so? Why embed XSLT post-processing in the engine
> > itself instead of at the application-level? How does this
> > relate to the fact that XSLT processing is recognized
> > as relevant in the JSP spec but its support has not been
> > addressed yet?
> >
> > Let's consider the case where we want our servlet/JSP
> > application to generate XML, instead of "raw" HTML.
> >
> > We know this is desirable for the usual, well-known
> > reasons: achieving "true" separation of content and
> > presentation, making JSP page authoring accessible
> > to non-programmers by means of tag libraries and
> > application-oriented markup vocabularies, generating
> > presentation markup in a browser and device-independent
> > fashion, generating portable DHTML, etc, etc...
> >
> > Obviously, this servlet/JSP-based XML generation
> > demands XSLT post-processing. This, in turn, imposes
> > a penalty in terms of additional processing load.
> >
> > Let's recall here that XSLT processing may take place
> > at either the server _or_ the client side. Thus, whenever
> > possible, we want to offload XSLT processing to the
> > client.
> >
> > Not all browsers support XSLT, though (in fact, only one
> > does right now!) so the server must still be capable of
> > providing such processing.
> >
> > How do we achieve this without requiring our servlets and
> > JSP pages to be concerned about how XSLT processing
> > takes place?
> >
> > It looks like an interceptor could do a terrific job here:
> > given the request's user-agent it would decide whether to
> > transcribe response output verbatim or post-process it by
> > applying an XSLT stylesheet. (Again, this is based on the
> > assumption that XSLT processing is stream-based, SAX)
> >
> > > The reason that write access is an issue in the proposed
> > > architecture is that the Response implementation is actually
> > > provided by the communications adapter through which the
> > > request was received.  It is the adapter-supplied logic that
> > > implements ServletOutputStream that will be oblivious to the
> > > need for the extra buffering, and that's the design issue
> > > that needs to be dealt with.
> >
> > Yes, this is at the core of the "servlets limitations for xml
> > processing" discussion. It's clear we badly need an extra
> > layer between servlet-level response output manipulation
> > and actual network communication.
> >
> > > Of course, any such use of Interceptors for post
> > > processing will be Tomcat specific, because it is
> > > not part of the standard servlet API. However,
> > > successful use of Interceptors for this might
> > > motivate the inclusion of similar concepts in the
> > > standard in some future version.
> >
> > I sincerely hope this is the case! The Servlet API would
> > really benefit from a revision that better accommodates
> > XML processing.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org