"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
