Q: 但当使用IIS主机实现时，可以通过向系统中添加更多的计算机来改善性能，而 .NET Remoting TCP/二进制实现则不能
——————————————————————————————————————————
A: 这个如果是在msdn中，估计是过去那个时代的那个微软的小产品人员脑袋进水了。
不论是域名解析，还是直接用IP访问，都可以在服务器端进行复杂均衡。甚至Windows2003本身就带有这个功能。不一定必须通过域名解析机制来集成负载均衡功能。
Q: Webservice分布部署时可以通过IIS的集群来完成，而.NET Remoting TCP/二进制则不行，必须得自己来写转向程序（几乎不可能）。
——————————————————————————————————————————
A: 我写了一个类，它可以到所有Assembly中去寻找Remoting对象，然后自动申请端口、注册对象。这个类总共不过20几行功能代码，只需要一条语句就能被起用。这种仅仅写一条代码的程序，并不比安装IIS并且发布和维护一套asmx机制麻烦。
Q: 那么可以说在单机应用时Remoting更具优势，而集群应用时WebService更具优势。
——————————————————————————————————————————
A: 除了采用SOAP协议完成通讯命令解析，以及使用标准的Web端口来通讯，WebService没有任何优势，而劣势非常明显。使用SOAP，因为它被大家承诺在官方类库中实现，那么你可以比较快地用异种平台上的现成类库做出程序（但是实际上我到java上确是使用其Remoting类库）。使用Web端口，是最可以保证穿越防火墙的，除非大家都不上web。
Q: 那么还有个小问题。就是IIS的集群能力到底怎么样？
——————————————————————————————————————————
A: 严格地说，没有IIS集群这种产品。这种概念过时了。现在的IIS还是一个针对单个服务器的产品，并不是一个集群服务系统。你可以看看Windows2003的负载平衡设置功能，或者一些软件。IIS没有集群功能，因此就要针对集群的底层架构对你的web系统做修改，保证会话等数据在集群中共享。
性能？这其实是个有陷阱的东西，不去却别对待其实不行。如果你的应用滥用系统资源，那么增加服务器毫无起色，对于一般人写的普通系统根本不能靠增加几台服务器来提高性能。如果本来非常精炼的程序因为用户数太多而作负载均衡，已经达到了很大系统那种层次，那么增加几台服务器提高100倍效率都是可能的。
A: 还有其他的Web服务器支持C#吗？反正我知道WebLogic好像是不支持。
——————————————————————————————————————————
Q: 没必要让WebLogic支持。不管Mono怎么想的，反正使用WebLogic的人有其特殊目的。对IIS和ASP.NET都伤害不到什么。
sp1234(eMule是我认为最像驴粪蛋的软件) ,我理解你说得．２００３的确有集群功能，对外确实是统一的端口，可是其自带的软件功能确实不怎么样（也许是我不会用，如果是那样，希望你能给一些文档．）它从本质上是一个双机热备的软件，如果是两台的集群，它只会同时跑一台（当然，磁盘阵列是可以共享的），只有当正在运行的服务器挂了的时候，才会启动另一台，而且切换很慢，且经常失败（尤其是在要同时切许多服务的时候）．
关于Ｒｅｍｏｔｉｎｇ自动转向的问题，我觉得不仅仅是这么简单．如果两台服务器提供同样的服务，那他们对外提供服务时是用一个端口还是两个端口．我给客户端提供的接口（类似于ＷＳＤＬ文件的接口定义，客户端需要具体的ＩＰ和端口）又应该怎么展现呢？还有就是负载均衡的控制可能会很复杂，如果一台机器的ＣＰＵ占用率过高，是不是新的需求就不会被转向到这台服务器上呢？
至于性能，我同意你说的．增加服务器不如改善自己的代码来得效果好．但是从设计的角度，我觉得应该考察一下，比如ＩＩＳ可以支持到多少ＣＰＵ，在同等配置的前提下和Ｗｅｂｌｏｇｉｃ，ＪＢＯＯＳ，Ｔｏｍｃａｔ之类的软件相比，效率怎么样．这些东西可能会有一些文档，但是我想听听各位用过这些系统的人的一些亲身感受，也许会有一些帮助（虽然我已经肯定要用ＤｏｎＮＥＴ的ＩＩＳ，呵呵！）．
前面还有个问题，没有人理，希望sp1234或者以后看到这个帖子的人能帮忙确认一下．Assembly之间的互访问一般是用Ｒｅｍｏｔｉｎｇ的方式吗（当然我是指中间层内部）？还是还有其他方式？
观点虽然不尽相同，但还是很感谢sp1234这么认真和热心！
关于直接把存过直接发布为 WebService,我反对．
个人感觉:推荐你使用remoting,
正对一些简单应用且要求跨网段而且网速不好的时候也可以单独用ws封装一些简单的业务逻辑.
remoting的典型应用就是其提供双向消息机制!!
有一个消息中兴:即remoting服务器端,一个客户端触发一个消息后,这个消息可以通过服务器端传递到任何订阅了该消息的所有客户端.这个功能恐怕ws实现不了吧,呵呵
其双向通讯机制很适合做大型系统使用,至于速度嘛,本人每发现有多大的影响,因为每碰到lz说的这么大的数据量.
如果是做视频的话,ws和rmt恐怕都不能满足你的要求,建议的方式:
视频流通过udp发送,控制通过ws或者rmt都行,如果你连视频流都用rmt传送的话,希望lz给偶一份副本(万分感谢)。
理由如下：
1、视频要求实时传送，对数据封包的准确性要求不高，哪怕丢几个数据包也没事，这是推荐用udp的原因，视频服务器啥也不管，你就咣咣发就行了，能不能收到无关紧要。
2、控制协议通常都要求准确传送，比如镜头、云台控制，这是需要确认，不适合用udp协议。
3、rmt有往复开销，如果一个地方卡住了，将会导致任何后续操作无法继续，remoting需要自己做错误处理，这个巨麻烦.......，这也是remoting不能用于视频的理由了。
以上只是个人浅见：）
首先数据库不是面向对象的，所以这种处理方法会导致系统朝非面向对象的方向发展，不好意思，我不知道＂CLS＂是什么意思．但我想至少现在还没有面向对象的数据库吧（下一代数据库的方向）！就会抛弃最关键的＂继承＂．
其次，数据库中加入大量的逻辑，会导致项目组中写存过的人工作量过大（我们这里一般是由专人负责的），还有难以维护，大量缺少注释和封装的代码将是一个灾难！
再次，现在人们为了解决从类到表的问题，已经有一些解决方法，比如行映射，表映射．最典型的应该是ＤａｔａＳｅｔ，所以转换应该问题不大！
关于认识每一个人的门卫，这个门卫在我的想像中应该不是一个简单的角色．
１他必须维护一个真正服务和用户所请求的服务对应的一个列表，而且是动态的．
２他必须非常智能，知道现在办公室里谁很忙，谁没事．说实话，有时候就是领导也做不到这点（哈哈！跑题了！）
３现在已经有一个很出色的门卫了（ＩＩＳ），而且免费为我服务，只不过他只能通过电话（ＳＯＡＰ）来告诉每个人．
还有就是我们的程序主要还是以监控为主，数据库只是一部分，还有很大的一部分是和设备通信（见我前面画的图）所以逻辑还是应该放在中间层的！呵呵！
至于每秒300次调用的问题，我想只要对外提供统一的接口，而内部实现分布式部署，应该不会是什么大问题吧（不知道软件方面扛得住不？）实际的服务转向到不同的业务服务器，应该可以吧．
关于＂Assemply之间没有什么互访问概念。如果对象要访问同一进程内的Assembly，就不用Remoting。如果它通过Remoting方式访问其它进程的对象（不论是本机的还是外网的，只要给出了相应的url），就是Remoting的。但是进程之间通讯有很多种，例如可以通过MSMQ、甚至用电子邮件。＂．你知道我说的是进程之间的互相访问，下次不要这么直接嘛，委婉一点嘛！还有就是电邮是万万不可以的，要不然又不知道还要安多少其他软件来辅助这个系统了．我是在做监控系统，不是ＥＲＰ，呵呵！
