Suggestions: Site Architecture

[b_naick]

Would like some input on site architecture. We're in a situation where
we need to host/integrate multiple applications within a single site.
For example: the URL of the main site needs to be http://www.mysite.com.
The site contains 3 key features : call them feature1, feature2 and
feature3. Each feature needs to be accessible via http://www.mysite.com/featureN.

Each feature will be developed by different development partners. The
goal is to make the entire site behave as one - single login, same
look/feel etc. Given the "shared" nature of the development, we wnat
to make sure that each feature runs in "isolation" and doenst
interfere with the other apps. This is desired to prevent a bad app
causing the entire hosting env to slow down. We'll also need the
ability to deploy/undeploy each application independently.

What site architectual options are available to support this?

Thanks in advance.

 

[Cowboy \(Gregory A. Beamer\)]

You can develop as separate applications and have them work together, as
long as you are not sharing session variables. Provided each web application
uses the same keys, you can keep the same session, especially in a situation
like this. If you are sharing application variables, you have a bigger
issue.

The two areas you generally get bit when doing what you are doing are the
config file and the database. As separate apps, you take care of the first
issue. Database schema is still a place of clashing.

One way to reduce clashes is to host the source repository and force your
vendors to get source from there. You can restrict vendors from seeing
another vendors trees. This option is the safest, as you can test, on check
in, whether or not everything is working. Cruise Control .NET, for example,
can be set up to automatically test on check in.

One way to reduce issues with the application(s) is have the applications
built around libraries, with the UI as a thin skin on top of the
functionality. This is the way applications should be written anyway (both
Silverlight and the new MVC framework force this separation of concerns).
The issue here is if two companies build the same objects, so you need some
coordination, or you will have to refactor once done.

--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA

Subscribe to my blog
http://gregorybeamer.spaces.live.com/lists/feed.rss

or just read it:
http://gregorybeamer.spaces.live.com/

*************************************************
| Think outside the box!
|
*************************************************

 

[mike]

Thanks. Can you please elaborate on the session variables comment? Are
you saying that two apps cannot share/access session variables? Or
that its dangerous to do so - one vendor overwrites the others
value(s)?

I would imagine the apps would need access to the same session
information.

 

[Cowboy \(Gregory A. Beamer\)]

Thanks. Can you please elaborate on the session variables comment? Are
you saying that two apps cannot share/access session variables?

Not natively and I have not investigated why.

The keys in the config will allow you to see the session cookie and get the
session id. But this scenario does not natively work:

'App 1
Session["keyName"] = "something";

'App 2
string something = Session["keyName"];

I am not completely sure why this is, only that it is. One way around this
is to set up your own cache, based on session id and clear it out regularly
(perhaps on Session End?). As long as the cache can be accessed by all of
the applications, you can get to it. A database table can work here, along
with local cache for each application, after they pull the values. You can
set up a method to pull the cache by session that either pulls from cache
(if present) or the database.

Or that its dangerous to do so - one vendor overwrites the
others value(s)?

This is a possibility if you do cache information. If two apps use the same
name for variables that are not really the same, it will cause issues if
someone bounces from app to app. For this reason, you should have a high
level design that each one adheres to.

I would imagine the apps would need access to the same session
information.

Ultimately, once all applications are finished, you can work on merging them
into a single web app. Until then, you need some session mechanism other
than the built in one.

--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA

Subscribe to my blog
http://gregorybeamer.spaces.live.com/lists/feed.rss

or just read it:
http://gregorybeamer.spaces.live.com/

*************************************************
| Think outside the box!
|
*************************************************