ASP.NET 怎么跟后端main process通信？ - 未名空间MITBBS历史存档

国际科技财经博客移民网络热点娱乐民生时事公众号

Redian新闻

>未名空间

>DotNet - 窗口里的风景

ASP.NET 怎么跟后端main process通信？

ASP.NET 怎么跟后端main process通信？# DotNet - 窗口里的风景

c*t2012-08-08 07:08

1 楼

现在的project, 我用ASP.net host了一个XML-RPC的web service. 但是真正的
processing logic是在另一个main program里面，这个program和IIS在同一台机器上
。现在的问题是，怎么让ASP.net和这个main program 通信比较好呢，我现在用的是
named pipe, 但是我觉得好像不够稳定，可能scalability有问题。

C*n2012-08-08 07:08

2 楼

Named Pipe is the best.
不过我一般用WCF, Running above NamedPipe protocol.
其实WCF Above TCP/IP 也行. 这两个我都试过. 吞吐量没有问题, 我的是大型真实工
业应用.
最好是ONE WAY的WCF, 如果你需要等待处理结果, 最好用Asynchronous.

【在 c*****t 的大作中提到】

: 现在的project, 我用ASP.net host了一个XML-RPC的web service. 但是真正的
: processing logic是在另一个main program里面，这个program和IIS在同一台机器上
: 。现在的问题是，怎么让ASP.net和这个main program 通信比较好呢，我现在用的是
: named pipe, 但是我觉得好像不够稳定，可能scalability有问题。

c*t2012-08-08 07:08

3 楼

太感谢了。不知道web service背后的logic，是不是必须象我这样另外做一个main
process呢？还是可以直接在asp .net里面做，那样好像影响响应时间。但是我这样做
，就需要两层communication, WS client到WS host, WS host再到main process via
IPC。

【在 C****n 的大作中提到】

: Named Pipe is the best.
: 不过我一般用WCF, Running above NamedPipe protocol.
: 其实WCF Above TCP/IP 也行. 这两个我都试过. 吞吐量没有问题, 我的是大型真实工
: 业应用.
: 最好是ONE WAY的WCF, 如果你需要等待处理结果, 最好用Asynchronous.

C*n2012-08-08 07:08

4 楼

要看你的具体应用, 这个没有定论, 我也不知道你的MAINPROCESS是个什么东西.
我的布局是:
ASP.NET website/IIS
WINDOWS SERVICE/HOST WCF SERVICE
这样ASP.NET就是一个WCF CLIENT, call WCF HOST. 我的是ONE WAY的. 也就是撂给
WCFSERVICE就不管了, 不等结果的.
如果你一定要等结果, 而且处理时间不长的话, 最好把哪个WCF合并到ASP.NET里面吧 (
如果可能的话). 这样没那么多罗嗦事. 如果由于某种原因必须分开, 就两个PROCESS
挺好. ASP.NET/IIS CALL WINDOWS SERVICE/WCF
看来你其实是可以合在一起的, 而且网页用户是不用等结果的. 那就合在一起做吧.
你怕影响响应时间, 直接用threadPool 就行了.
ThreadPool.QueueUserItem(xxxx), 这样你的ASP.NET逻辑马上返回. 让你的任务处理
在IIS后台慢慢来吧.几个小时也没问题.
不过你真这样做就要注意不要随便重启IIS, 因为怕你处理一半你把IIS重启了就麻烦了
. 除非你有其它机制恢复. 因为你已经通知网页任务提交了. 你可能等一下才要告诉他
结果吧.
总之具体问题具体分析.

【在 c*****t 的大作中提到】

: 太感谢了。不知道web service背后的logic，是不是必须象我这样另外做一个main
: process呢？还是可以直接在asp .net里面做，那样好像影响响应时间。但是我这样做
: ，就需要两层communication, WS client到WS host, WS host再到main process via
: IPC。

c*t2012-08-08 07:08

5 楼

我的main process就是实现WS后面的logic，包括数据库操作和一些算法实现，等等。
其中有些是马上返回结果的，有些只是提交数据（这些也要返回状态）。不过我的WS
client除了网页，还有Android app等等。除了响应时间，还有个因素就是有些算法是
single thread only, 如果自己做在asp. net里不就成了多线程了？我的main process
里可以queue这些request给算法模块。
你的WCF over namedpipe看上去很不错。因为我用named pipe实现client-sever的code
有点土，我觉得有时候不稳定就是那里的问题。看来我要学WCF了，呵呵。

(

【在 C****n 的大作中提到】

: 要看你的具体应用, 这个没有定论, 我也不知道你的MAINPROCESS是个什么东西.
: 我的布局是:
: ASP.NET website/IIS
: WINDOWS SERVICE/HOST WCF SERVICE
: 这样ASP.NET就是一个WCF CLIENT, call WCF HOST. 我的是ONE WAY的. 也就是撂给
: WCFSERVICE就不管了, 不等结果的.
: 如果你一定要等结果, 而且处理时间不长的话, 最好把哪个WCF合并到ASP.NET里面吧 (
: 如果可能的话). 这样没那么多罗嗦事. 如果由于某种原因必须分开, 就两个PROCESS
: 挺好. ASP.NET/IIS CALL WINDOWS SERVICE/WCF
: 看来你其实是可以合在一起的, 而且网页用户是不用等结果的. 那就合在一起做吧.

C*n2012-08-08 07:08

6 楼

那就还是分成两个PROCESS吧.
不过你的ASP.NET调用WCF之后等时间太长不好. 尤其是你的MAINPROCESS要QUEUE
REQUEST的话.感觉等待时间是Unpredictable, 这里可能要处理一下.

process
code

【在 c*****t 的大作中提到】

: 我的main process就是实现WS后面的logic，包括数据库操作和一些算法实现，等等。
: 其中有些是马上返回结果的，有些只是提交数据（这些也要返回状态）。不过我的WS
: client除了网页，还有Android app等等。除了响应时间，还有个因素就是有些算法是
: single thread only, 如果自己做在asp. net里不就成了多线程了？我的main process
: 里可以queue这些request给算法模块。
: 你的WCF over namedpipe看上去很不错。因为我用named pipe实现client-sever的code
: 有点土，我觉得有时候不稳定就是那里的问题。看来我要学WCF了，呵呵。
:
: (