Communicating Between Web Applications

[Sinisa]

Hello,
Currently I have a very large Web application (1 solution with ~20
projects) that is being deployed on an intranet. A descision was made
to "break apart" the application (into ~20 solutions -- 1 for each
project).
For the most part, this was successful, but it did cause a problem,
where one project would use session state information, that was
populated by another project, and now these seperate projects would
become seperate applications. I have discovered that session
information is not maintained across applications, which in turn would
break this relationship.
I have looked into soloving this problem and currently we are going to
keep the two applications together (as a temporary solution). I have
found 3 commonly used practices for solving this scenario. 1: using a
session server (which seemed to be the easiest to me), 2: .Net Remoting
(which seems to be the best, but I don't know anything about .Net
Remoting and thus I can't really make a good descision about it) and 3:
MSMQ (Message Queing) (which seems to be a good solution, but not
better that .Net Remoting and again, I do not know much about MSMQ).
Are there any other methods besides these three that would solve this
situation.

Further more, I was origianlly opposed to "breaking apart" the
solution. Is it infact the better approach (many solutions with one
project in each) or was it better originally (one solution with all the
projects in it)?

Sorry to have extened the subject of this post.
Thank you for any suggestions and comments you might have.
~Sinisa

[John Saunders]

"Sinisa" <si**********@h otmail.com> wrote in message
news:11******** **************@ c13g2000cwb.goo glegroups.com.. .

....

Further more, I was origianlly opposed to "breaking apart" the
solution. Is it infact the better approach (many solutions with one
project in each) or was it better originally (one solution with all the
projects in it)?

What was the problem which initially caused the decision to split the
solution into 20 separate solutions?

John Saunders

[Steve C. Orr [MVP, MCSD]]

Another common approach is to store the common information in a common
database.
You might create a common component that wraps the required functionality.

--
I hope this helps,
Steve C. Orr, MCSD, MVP
http://Steve.Orr.net

"Sinisa" <si**********@h otmail.com> wrote in message
news:11******** **************@ c13g2000cwb.goo glegroups.com.. .

Hello,
Currently I have a very large Web application (1 solution with ~20
projects) that is being deployed on an intranet. A descision was made
to "break apart" the application (into ~20 solutions -- 1 for each
project).
For the most part, this was successful, but it did cause a problem,
where one project would use session state information, that was
populated by another project, and now these seperate projects would
become seperate applications. I have discovered that session
information is not maintained across applications, which in turn would
break this relationship.
I have looked into soloving this problem and currently we are going to
keep the two applications together (as a temporary solution). I have
found 3 commonly used practices for solving this scenario. 1: using a
session server (which seemed to be the easiest to me), 2: .Net Remoting
(which seems to be the best, but I don't know anything about .Net
Remoting and thus I can't really make a good descision about it) and 3:
MSMQ (Message Queing) (which seems to be a good solution, but not
better that .Net Remoting and again, I do not know much about MSMQ).
Are there any other methods besides these three that would solve this
situation.

Further more, I was origianlly opposed to "breaking apart" the
solution. Is it infact the better approach (many solutions with one
project in each) or was it better originally (one solution with all the
projects in it)?

Sorry to have extened the subject of this post.
Thank you for any suggestions and comments you might have.
~Sinisa

[bruce barker]

inproc sessions are maintained in the appdomain (vdir). the session cookie
is also maintained at the vdir. the simple solution, is to just deploy the
projects to the same vdir, so they will share session. you could use
cookieless sessions, and out of proc session manager for shared sessions
(you would a little code to munge the urls when linking to the other sites).
for a large site I'd use the sql session manager anyway.

you can write you own session cookie and store tied to the host rather than
the vdir and use an out of proc session.

-- bruce (sqlwork.com)

"Sinisa" <si**********@h otmail.com> wrote in message
news:11******** **************@ c13g2000cwb.goo glegroups.com.. .
| Hello,
| Currently I have a very large Web application (1 solution with ~20
| projects) that is being deployed on an intranet. A descision was made
| to "break apart" the application (into ~20 solutions -- 1 for each
| project).
| For the most part, this was successful, but it did cause a problem,
| where one project would use session state information, that was
| populated by another project, and now these seperate projects would
| become seperate applications. I have discovered that session
| information is not maintained across applications, which in turn would
| break this relationship.
| I have looked into soloving this problem and currently we are going to
| keep the two applications together (as a temporary solution). I have
| found 3 commonly used practices for solving this scenario. 1: using a
| session server (which seemed to be the easiest to me), 2: .Net Remoting
| (which seems to be the best, but I don't know anything about .Net
| Remoting and thus I can't really make a good descision about it) and 3:
| MSMQ (Message Queing) (which seems to be a good solution, but not
| better that .Net Remoting and again, I do not know much about MSMQ).
| Are there any other methods besides these three that would solve this
| situation.
|
| Further more, I was origianlly opposed to "breaking apart" the
| solution. Is it infact the better approach (many solutions with one
| project in each) or was it better originally (one solution with all the
| projects in it)?
|
| Sorry to have extened the subject of this post.
| Thank you for any suggestions and comments you might have.
| ~Sinisa
|

[Sinisa]

John,
The decision to split appart the solution into 20 seperate solutions
was because much of the team felt that it would improve development
preformance (quicker to load the application into VS, quick to build
the application). Sometimes Visual Studio would halt when moving from
debug to release. Much of the decision was made to make things more
comfortable for "us". I never really agreed with it, but I don't
really have a reason to think that it was the wrong way to go, just as
I don't have a reason to feel that it was the right way to go.

I hope this clarifies things a little.

~sinisa
John Saunders wrote:

"Sinisa" <si**********@h otmail.com> wrote in message
news:11******** **************@ c13g2000cwb.goo glegroups.com.. .

...

Further more, I was origianlly opposed to "breaking apart" the
solution. Is it infact the better approach (many solutions with one project in each) or was it better originally (one solution with all the projects in it)?

What was the problem which initially caused the decision to split the
solution into 20 separate solutions?

John Saunders

[Sinisa]

Bruce,

to just deploy the projects to the same vdir, so they will share session
If I had two web applications in the same vdir (a physical folder?)
then wouldn't the two application be considered one application by the
IIS? Following that, could I then put all applications in one vdir,
and then all the applications would be considered to be one? Or would
it be sufficient to have the seperate applications be sub-directories
of the main vdir so that some management of the applications would be
easier.
for a large site I'd use the sql session manager anyway. Regarding the sql session manager, I was under the impression that it
too was constrained with the same rules, not allow another web
application access to the session data.
you can write you own session cookie and store tied to the host rather thanthe vdir and use an out of proc session.

I would like to try an avoid using cookies (but am not fully opposed to
the idea).

~sinisa

[Sinisa]

Steve,
I have proposed something along those lines, but it encapsulated a
general framework for accomplishing a solution to this problem, but it
was felt that the component would be difficult to write, maintain and
use.
I personally feel that it might be hard to write, but not maintain or
implement.
Would you have any experiences that would be able to support or
discredit my claim. I just want to reach a good solution, and I'm not
sure what the best approach would be at this point.

~sinisa

[Steve C. Orr [MVP, MCSD]]

You'd basically just be writing a replacement for the Session object that
does a little database work in the background. It doesn't have to be fancy
or complicated or bug-prone.

--
I hope this helps,
Steve C. Orr, MCSD, MVP
http://Steve.Orr.net
"Sinisa" <si**********@h otmail.com> wrote in message
news:11******** **************@ f14g2000cwb.goo glegroups.com.. .

Steve,
I have proposed something along those lines, but it encapsulated a
general framework for accomplishing a solution to this problem, but it
was felt that the component would be difficult to write, maintain and
use.
I personally feel that it might be hard to write, but not maintain or
implement.
Would you have any experiences that would be able to support or
discredit my claim. I just want to reach a good solution, and I'm not
sure what the best approach would be at this point.

~sinisa

[John Saunders]

"Sinisa" <si**********@h otmail.com> wrote in message
news:11******** **************@ z14g2000cwz.goo glegroups.com.. .

John,
The decision to split appart the solution into 20 seperate solutions
was because much of the team felt that it would improve development
preformance (quicker to load the application into VS, quick to build
the application). Sometimes Visual Studio would halt when moving from
debug to release. Much of the decision was made to make things more
comfortable for "us". I never really agreed with it, but I don't
really have a reason to think that it was the wrong way to go, just as
I don't have a reason to feel that it was the right way to go.

I hope this clarifies things a little.

Thanks, that does clarify things.

I'd suggest that you look at a different partitioning. If you take a look at
Team Development with Visual Studio .NET and Visual SourceSafe
(http://msdn.microsoft.com/library/de...sp?frame=true),
you'll see that it talks about several ways to partition solutions to
address this issue.

One other hint, though: if you've got two projects which need to communicate
this closely, then perhaps they belong in the same solution.

John Saunders

[Sinisa]

Thanks Steve. Thats pretty much what I thought.

~sinisa
"Steve C. Orr [MVP, MCSD]" <St***@Orr.ne t> wrote in message
news:ep******** ********@TK2MSF TNGP10.phx.gbl. ..

You'd basically just be writing a replacement for the Session object that
does a little database work in the background. It doesn't have to be fancy or complicated or bug-prone.

--
I hope this helps,
Steve C. Orr, MCSD, MVP
http://Steve.Orr.net
"Sinisa" <si**********@h otmail.com> wrote in message
news:11******** **************@ f14g2000cwb.goo glegroups.com.. .

Steve,
I have proposed something along those lines, but it encapsulated a
general framework for accomplishing a solution to this problem, but it
was felt that the component would be difficult to write, maintain and
use.
I personally feel that it might be hard to write, but not maintain or
implement.
Would you have any experiences that would be able to support or
discredit my claim. I just want to reach a good solution, and I'm not
sure what the best approach would be at this point.

~sinisa