application architecture

["Sayles, Scott SAXONHQ" <Sa...@Saxonmtg.com>]

Hello,

This is probably close to being off topic but...

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.  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.

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
2. separated contexts => easier application maintenance but more complex
mechanisms are required to make the system seamless.

Anybody have any thoughts about this?  I would appreciate any feedback. :)

Thanks 

Scott

Re: application architecture

["Craig R. McClanahan" <Cr...@eng.sun.com>]

"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.
>