The cocoon-sandwich-use-case(was :Session managing problem)

[SAXESS - Hussayn Dabbous <da...@saxess.com>]

Hy, all;

I see one special use case for cocoon, which i call the
"cocoon-sandwich". The raising amount of questions
in the past few weeks triggered me to write down this text.
Lajos Moczar and myself we are in this since about two months
now. This message summarizes some of our results. I think, this
issue is of common interest. Hence i want to give you an insight
into what we found and how we solved the problems in general.


scenario:
---------

You have a webapplication, that is already up and running.
This webapp uses "conventional" interaction (jsp, servlets)
possibly it is built up with struts, expresso or whatever.
The webapp is independent of cocoon.
You need to setup an intelligent "presentation-layer" that
talks to the browser on one side and to the webapp on the
other side. This presentation layer thus acts as client to
the webapp and as server to the browser:


        client/server ...  client/server
   +---------+ +----------------+ +--------+
   | BROWSER |-|  PRESENTATION  |-| WEBAPP |
   +---------+ +----------------+ +--------+


implementation scenarios
------------------------

0.) The poor mans scenario
--------------------------

This scenario can be implemented with "standard-cocoon"
under certain circumstances:

1.) the webapp is stateless
2.) the webapp does not use sessions
3.) the webapp has an XML-interface (responds with XML-content)
     For jsp's i mean this: <%@ page contentType="text/xml"%>
3.) there is no hidden flow between webapp and browser,
     i.e. no COOKIES

You can get around by using the "http:" ptocol handler coming
with cocoon.

I name this "poor man's scenario", because you simply get it
for free and can set it up in two minutes.

But if you need to make your presentation layer transparent
to session-infos and hidden flows (cookies), you need
to make some additional work, that is currently not
available from "standard-cocoon". Even the WebappProxyGenerator
mentioned often in this context, does NOT provide transparent
session preserving!


1.) The hacker's solution
-------------------------

     We created one solution, that works almoust perfect under
     following conditions:

     * Your webapp and your presentation layer are running in the same
       ip-domain
     * You can modify your webapp in a way, that it does its own
       session handling. Basically you would setup a Hashtable containing
       the session-data. The access key is the sessionid. You put the
       sessionid into your very special cookie and tell the browser to
       send this cookie whenever it sends a request to your ip-domain.
       Now when your webapp gets such a cookie, it can refer to the
       session in the hashtable.

     We still have to provide a facility to move Cookies forth and
     back through the presentation layer. For this purpose we have
     written a special proxy-protocol handler, that can be used similar
     to the standard "http:" protocol:


     <map:match pattern="result/canvas/search_mask">
       <map:generate src="proxy://myserver/getdata.jsp"/>
         <map:serialize type = "xml"/>
     </map:match>

     When using this proxy: handler, it will take care of your
     cookies in both directions (request and response)
     The major advantage here is, that you can use the proxy: handler
     wherever you can place a src into the sitemap. i.e. you could
     enable cookies with the WebProxyGenerator (hope, that's true. of
     course it depends heavily on what the generator does ;- )

     There are two drawbacks to this:
     1.) You must login to your webapp first and create the
         session environment and the cookie. Only after you did
         this, you can use your presentation layer to go on.
     2.) You must modify your webapp after all.

     Because of these drawbacks i call this solution the
     "hacker's solution"

2.) The versatile solution
--------------------------

     Now what could you do, if you wanted to keep your webapp as is?
     There are two points here:

     1.) You need to login to your webapp through the presentation layer.
         Basically you would login to the presentation layer and the
         presentation layer would login to your webapp.
     2.) In order to get this done, you need to use the SAME credentials
         in the presentation layer as you need in your webapp.

     You would not need to move COOKIES between the browser and the
     webapp for session tracking. This would now be done internally by
     cocoon and the proxy: handler. But you may still want to pass
     cookies for other purposes. No problem, proxy: already does what
     you need.

     There is still one drawback to this solution:

     You need to use the same authentification database in
     presentation layer and webapp. This may be no problem at all
     if you can manage to run your webapp and the presentation layer on
     the same container, or at least in the same environment (using the
     same user database). But when you want to setup a scenario with
     SSO over far servers, you need just another level of processing.


3.) The SSO solution (rich mans's solution)
-------------------------------------------

      To get over the last mentioned drawback, you need to setup
      sort of a brokerage system, that may store credentials for
      your differnet webapps to be served. In principle no problem.
      I don't want to go into detail here, except i can tell, that
      i use an LDAP-server for this purpose (which says nothing after
      all).


If you are eager to get even more infos, you may contact me directly.

regards, Hussayn

-- 
Dr. Hussayn Dabbous
SAXESS Software Design GmbH
Neuenhöfer Allee 125
50935 Köln
Telefon: +49-221-56011-0
Fax:     +49-221-56011-20
E-Mail:  dabbous@saxess.com


---------------------------------------------------------------------
Please check that your question  has not already been answered in the
FAQ before posting.     <http://xml.apache.org/cocoon/faq/index.html>

To unsubscribe, e-mail:     <co...@xml.apache.org>
For additional commands, e-mail:   <co...@xml.apache.org>