在Web应用程序之间进行通信 [英] Communicating Between Web Applications

查看:92
本文介绍了在Web应用程序之间进行通信的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

你好,

目前我有一个非常大的Web应用程序(1个解决方案,带有~20

个项目),它正在内部网上部署。做出决定

以分手应用程序(大约20个解决方案 - 每个

项目1个)。

大多数情况下,这是成功的,但确实会导致问题,
其中一个项目将使用会话状态信息,即另一个项目填充的b / b
现在这些单独的项目将成为单独的应用程序。我发现会话

信息不是跨应用程序维护的,这反过来又会打破这种关系。

我已经研究过这个问题问题,目前我们将

将两个应用程序保持在一起(作为临时解决方案)。我有

找到3种常用的解决方案。 1:使用

会话服务器(这对我来说似乎最简单),2:.Net Remoting

(这似乎是最好的,但我不是'什么都不知道.Net

Remoting因此我真的不能对它做出很好的决定)和3:

MSMQ(Message Queing)(似乎是一个很好的解决方案,但不是更好的.Net Remoting再次,我对MSMQ不太了解。

除了这三个之外还有其他方法吗?会解决这个问题。


此外,我原本反对分手

解决方案。这实际上是更好的方法(许多解决方案中每个都有一个

项目)或者它最初是否更好(一个包含所有

项目的解决方案)?


很抱歉扩展了这篇文章的主题。

感谢您提出任何建议和意见。

~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

推荐答案

" Sinisa" < SI ********** @ hotmail.com>在留言中写道

新闻:11 ********************** @ c13g2000cwb.googlegr oups.com ......


....
"Sinisa" <si**********@hotmail.com> wrote in message
news:11**********************@c13g2000cwb.googlegr oups.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)?



最初导致决定将

解决方案分成20个独立解决方案的问题是什么?


John Saunders



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

John Saunders


另一种常见的方法是将公共信息存储在一个公共的
数据库中。

您可以创建一个包含所需的公共组件功能。


-

我希望这会有所帮助,

Steve C. Orr,MCSD,MVP
< a rel =nofollowhref =http://Steve.Orr.nettarget =_ blank> http://Steve.Orr.net


"西尼沙" < SI ********** @ hotmail.com>在消息中写道

news:11 ********************** @ c13g2000cwb.googlegr oups.com ...
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**********@hotmail.com> wrote in message
news:11**********************@c13g2000cwb.googlegr oups.com...
您好,
目前我有一个非常大的Web应用程序(一个包含约20个项目的解决方案),它正在内部网上部署。做出决定以分开。应用程序(大约20个解决方案 - 每个项目1个)。
在大多数情况下,这是成功的,但确实会导致问题,
一个项目将使用会话状态信息,由另一个项目填充,现在这些单独的项目将成为单独的应用程序。我发现会话
信息不是跨应用程序维护的,这反过来会破坏这种关系。
我已经研究过解决这个问题,目前我们要继续两个应用程序在一起(作为临时解决方案)。我已经找到了3种解决这种情况的常用做法。 1:使用
会话服务器(这对我来说似乎最简单),2:.Net Remoting
(这似乎是最好的,但我对.Net一无所知) Remoting因此我不能对它做出很好的决定)和3:
MSMQ(消息队列)(这似乎是一个很好的解决方案,但不是更好的.Net) Remoting再次,我对MSMQ知之甚少。
除了这三种方法之外还有其他方法可以解决这种情况。

此外,我原本反对分开
解决方案。这实际上是更好的方法(许多解决方案中每个都有一个
项目)或者它最初是否更好(一个包含所有
项目的解决方案)?

抱歉有扩展了这篇文章的主题。
感谢您提出的任何建议和意见。
~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



inproc会话是在appdomain(vdir)中维护。会话cookie

也保留在vdir。简单的解决方案是将

项目部署到同一个vdir,这样他们就可以共享会话。你可以使用

无cookie会话,以及proc会话管理器之外的共享会话

(当你链接到其他网站时,你会想到一些代码来管理网址)。 br />
对于一个大型网站我还是会使用sql会话管理器。


你可以写自己的会话cookie和存储绑定到主机而不是

vdir并使用一个不合格的会话。


- 布鲁斯(sqlwork.com)


" ;西尼沙" < SI ********** @ hotmail.com>在留言中写道

新闻:11 ********************** @ c13g2000cwb.googlegr oups.com ......

|你好,

|目前我有一个非常大的Web应用程序(1个解决方案,带有~20

|项目),它正在内部网上部署。做出决定

| 分手应用程序(~20个解决方案 - 每个1个

|项目)。

|在大多数情况下,这是成功的,但它确实引起了问题,

|其中一个项目将使用会话状态信息,即

|由另一个项目填充,现在这些单独的项目将

|成为单独的应用程序。我发现那个会话

|信息不是跨应用程序维护的,而这反过来又会是b $ b |打破这种关系。

|我已经考虑过解决这个问题,目前我们要去讨论
|将两个应用程序保持在一起(作为临时解决方案)。我有

|找到了解决这种情况的3种常用做法。 1:使用

|会话服务器(这对我来说似乎最简单),2:.Net Remoting

| (这似乎是最好的,但我什么都不知道.Net

| Remoting因此我真的不能做出很好的决定)和3:
| MSMQ(消息队列)(这似乎是一个很好的解决方案,但不是

|更好.Net Remoting再次,我对MSMQ了解不多)。

|除了这三个之外还有其他方法可以解决这个问题吗?
|情况。

|

|此外,我原本反对分手。

|解。这实际上是更好的方法(许多解决方案中每个都有一个

|项目)或者它原来是否更好(一个解决方案包含所有

|项目)?< br $> b $ b |

|很抱歉扩展了这篇文章的主题。

|感谢您提出的任何建议和意见。

| ~Sinisa

|
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**********@hotmail.com> wrote in message
news:11**********************@c13g2000cwb.googlegr oups.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
|


这篇关于在Web应用程序之间进行通信的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆