Craig,
I really appreciate the response. :)
> On the other hand, having everything in one context has an
> impact on installing
> new versions of any "sub-application". You basically have to
> take down and
> restart the entire web app, instead of just one portion of
> it. This might or
> might not be acceptable, depending on your operational environment.
When you say "restart the entire web app" I guess you're talking about
restarting the servlet container(e.g. Tomcat), correct?
If I were to install a new version of an existing application(i.e. context),
wouldn't I have to restart Tomcat anyway? We're using Tomcat 3.1 if it
makes any difference.
> The security issue can be dealt with fairly easily. It is
> the shared state
> issue that makes this one interesting -- especially when some
> of that shared
> state might be required just to maintain the look and feel of
> the "seamless"
> user interface.
Well, for the look and feel issue we plan to use a single template for all
pages implemented with Struts template tags. This main template would also
have stuff like a menu toolbar and links for style sheets. Under the
multiple contexts scenario I've thought about sharing a single template by
creating symbolic links (on our UNIX system) from the template file into
each context. That way, our designer can simply modify the one file and
change the template for all applications. However, I suppose this wouldn't
work on Windows?
There really isn't much that will be shared between our "applications" under
a multiple context scenario. At this point, the only thing that needs to be
common is the user's login and associated information. All the applications
will be able authenticate users on a middle tier system. Based on the user
information, the menu presented on the main template will be dynamically
generated. I'm contemplating setting a cookie to be used by each context in
verifying the user's login (i.e. to help maintain login information between
the contexts).
Another issue I can see is how to implement a loggoff mechanism under
multiple contexts. I would like to make the initial point of login
verification to be a check against a session scope attribute. The logoff
would have to invalidate or remove the session attributes from all
application contexts. We would also have to know the session id for the
other contexts in that case. I guess we could maintain some kind of user
context registry for the overall system in the middle tier? a cookie? Then
when the user logsoff we could obtain the user context session ids and
request logoffs to each corresponding context. hmmmm.... far fetched?
Perhaps the single context will be easier to implement. My main concern is
that there are other individuals working on specific "applications" and we
are not following a standard architecture for web application development.
I can see it ending up a big cluge. I'm pushing for the use of Struts to
help rectify this.
Thanks
Scott
> -----Original Message-----
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, November 28, 2000 7:54 PM
> To: [EMAIL PROTECTED]
> Subject: Re: application architecture
>
>
> "Sayles, Scott SAXONHQ" wrote:
>
> > Hello,
> >
> > This is probably close to being off topic but...
> >
>
> I'm personally comfortable with talking about architecture
> topics here, even if
> they extend beyond the specifics of using Struts. This topic
> is going to be
> important to people that use Struts (as well as those that
> are not), so it seems
> germane if everyone is willing to put up with a few extra
> mail messages.
>
> And it is sure a lot more fun for me than telling newbies on
> TOMCAT-USER how to
> set the default session timeout in web.xml :-).
>
> >
> > We're currently looking at building an internal application
> system that will
> > be composed of functionally different components. By this
> I mean, for
> > example, we'll basically have different "applications" that will be
> > presented seamlessly to the user.
>
> I'm assuming when you use the term "application" here you are
> thinking about
> whether or not the entire suite should be packaged as one
> "web application"
> (i.e. running inside one ServletContext) or not, right?
>
> > What I'm trying to figure out is what the
> > pros and cons are of lumping these applications into one
> context, or having
> > individual contexts for each. Normally, I would choose the
> latter, but
> > there is a lot of common stuff that's going to be used between the
> > applications. For instance, all user's will login through a common
> > interface to establish a single session, which is
> maintained on a middle
> > tier, and all movement between applications will have to be
> seamless. Also,
> > the applications will utilize Struts for basic application
> framework and
> > templating for common look and feel.
> >
>
> From the general servlet API point of view, I would imagine
> the following issues
> are the most important:
>
> (1) Authentication Scope
>
> In a sense, the division of "one app" or "many apps" you are
> talking about is
> invisible to the end user. They want to go access "the
> system", and navigate
> their way around, irrespective of how it is organized internally.
>
> One place where a wrong choice can make this internal
> organization *very*
> visible is if you make the user sign on to each of your
> separate "application"
> contexts, rather than once when they start. In many servlet
> containers, such as
> Tomcat 3.x, you don't have any choice in the matter -- user
> authentication is a
> per-application function, so the user would have to do this.
>
> The servlet spec actually encourages (well, requires -- see
> Section 11.6 of the
> 2.2 spec) support for a "single sign on" capability, so that a user is
> authenticated the first time they access a resource protected
> by a security
> constraint in any application, and the authenticated identity
> is then propogated
> to all of the other applications in the same environment.
> Tomcat 4.0 supports
> this on a per-virtual-host basis if you choose to configure
> it. You will want
> to make sure that your deployment platform supports it if you
> choose the
> multiple-application approach.
>
> (2) Session Scope
>
> As the servlet spec requires, sessions are scoped at the
> context (i.e. web
> application) level. Therefore, if your environment has five
> web apps, and the
> user has touched all five of them, that user will have five
> concurrently active
> HttpSessions -- each with completely separate session attributes.
>
> There is no mechanism through the servlet API to share
> session attributes across
> contexts -- indeed, this would be very difficult because the
> classes that make
> up those attributes are normally loaded from a web-app specific place
> (WEB-INF/classes or WEB-INF/lib) that is not visible to any
> other web app.
>
> The net effect of this is that, if you go the
> multiple-application route, and
> you find a need to share per-user state information globally
> across all of the
> apps, you will need to use external mechanisms (such as EJBs,
> databases, ...) to
> store and retrieve the shared state information.
>
> >
> > I've gone over various scenarios in my head. There are
> certainly other
> > factors to consider but I think the crux of what I'm trying
> to weigh is:
> > 1. common context => easier to implement seamless
> application, but could
> > potentially grow into a beast of actions and etc. and have harder
> > maintainability
>
> Naming conventions would deal with most of this issue. For
> example, if you had
> sub-applications named "admin" and "catalog", you could even
> have two different
> actions:
>
> /admin/lookupUser.do
>
> /catalog/lookupUser.do
>
> that are completely separate. Using corresponding
> conventions for the Java
> packages, and the JSP pages, would ease most of the burden.
>
> Internally, Hashtables or HashMaps are used to represent the
> collections of
> available form beans, mappings, and forwards -- so you can
> scale to many
> thousands of entries with no big impact on response time due
> to the lookups.
>
> On the other hand, having everything in one context has an
> impact on installing
> new versions of any "sub-application". You basically have to
> take down and
> restart the entire web app, instead of just one portion of
> it. This might or
> might not be acceptable, depending on your operational environment.
>
> >
> > 2. separated contexts => easier application maintenance but
> more complex
> > mechanisms are required to make the system seamless.
> >
>
> The security issue can be dealt with fairly easily. It is
> the shared state
> issue that makes this one interesting -- especially when some
> of that shared
> state might be required just to maintain the look and feel of
> the "seamless"
> user interface.
>
> >
> > Anybody have any thoughts about this? I would appreciate
> any feedback. :)
> >
> > Thanks
> >
> > Scott
>
> Craig McClanahan
>
>
