关于.Net Remoting、Com+的一些疑惑

Question

Remoting是通讯部分的东西，COM+是后端服务支撑方面的东西，尽管COM+也可以通过DCOM支持远程访问，但代价很高，并且只能在局域网内，因此更多的用于商业逻辑支持。对应用系统来说，COM+的便利在于一是系统提供调度和负载处理，二是对商业事务（不是数据库事务）的支持。类比Java想对应的部分而言大致上可以这样看：Remoting VS. COBRA, COM+ VS EJB、JTA。Remoting因此在有其他办法的时候通常避免采用远程调用COM对象的方式。对于带宽的限制，通常使用缩减传输量来完成。最彻底的办法就是B/S结构，除了基本输入输出什么数据都放在后端转。如果做不到，则需要仔细的规划传输的数据量，也不是很麻烦，就是需要细心一点而已。

Answer 1

另，负载均衡的问题主要爆漏在并发用户超出极限的时候（这么说有点对不起客户），对于业务层面的负载超出极限通常反映在系统反应速度降低，由于不总是这样，因此对客户来说不一定能够抓住把柄。
线程堵塞的情况在你举例的连接数下出现的可能性很小，除非你的业务模块设计极其糟糕。即便出现这种情况，由于Remoting可以使用IIS作中转，因此同样可以蒙混过关（这比较混账）。
现在的问题是网络带宽不足，只能削减网络数据流量，其他的方式都是南辕北辙。

Answer 2

在區域網內用 .Net Remoting的話是比較好的選擇,如果地域跨度太大的話不能這樣的做
用webservice的方法可能會更好

Answer 3

在區域網內用 .Net Remoting的話是比較好的選擇,如果地域跨度太大的話不能這樣的做
用webservice的方法可能會更好
-----------------------------------------------
webservice的问题出在他不能提供一个由状态的对象，因此作为数据交换或简单的处理时很方便，但你需要一个有状态持久对象时webservice无能为力。Remoting还是CORBA，这是一个问题（挠头中……）。

Answer 4

首先很感谢shadowarmyChen同志。
我很认同你的说法。
实际上业务模块传输的数据除了数据模板外，别的几乎不多。因为系统设计之初就考虑了B/S模式，虽然现在没有进行，但考虑了相关细节。代码的时候很很小心。
只是由于本人太年轻，没有多少这种项目的实际经验（几乎是没有），心里没有底啊。用户也比较狠，到时会用工具进行硬性指标测试。钱多，以前上的项目也很多，有经验了，呵呵估计吃过亏了。另外，我对你的“Remoting可以使用IIS作中转，因此同样可以蒙混过关”不是很理解，能详细说明一下么？期待中……

Answer 5

to lxy0423((zjl)) 
的确如shadowarmyChen同志所言，在数据层有某些对象需要做常连接。且某些功能模块更是需要如此。

Answer 6

To shadowarmyChen
补充一下，有些模块的确很占带宽，也占CPU，比如一个通用的数据备份、合并、恢复模块，不过这些模块应该在服务器局域网内完成，不会提供给普通客户端。

Answer 7

Remoting可以通过http链路进行通讯，而任何web服务器均可以提供负载均衡，当然别是太滥的东西。但这种负载均衡实际上是接入的负载均衡，而不是对业务对象提供负载均衡，所以只是混事的方法，为了保证数据安全，你的业务对象必须考虑冲突的问题。但反过来说，由于这种问题是随机出现，因此客户无法肯定的说是什么地方做错了，因此你有机会把问题推到任何人头上，包括微软在内。使用工具进行硬指标测试不一定能够真的发现问题，涉及到硬件、链路、数据库版本、测试数据等等所有方面，到最后也只不过就是看一下响应速度而已，而这个东西又是仁者见仁智者见智。所以做的时候凭良心作，使得时候按样子使，仅此而已。如果下定决心要蒙客户，没有什么客户能全身而脱，只不过自己的荣誉会损失殆尽而已。

Answer 8

我以前做过一个项目，用的就是Remoting,虽然最后的结果速度上不是很理想。
但客户还是在总部的局域网内使用。但远程的客户端由于速度没有采用。
由于这也是我们当时做的第一个.net项目，所以我们也有很多地方做的不好。

Answer 9

分发大饼！
shadowarmyChen能否留下联系方式？想某个时候再接收您的“教诲”，呵呵