请问各位大侠，开发大型的WEB站点（上线人在1万人以上），是采用分布式Web Services还是NET Remoting技术最好？ 站点为何要采用 这2中技术呢？ asp.net不能满足吗？ 解决方案 » 免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货 晕，楼上的应该明白'asp.net'和'Web Services或NET Remoting'之间的关系才是！ 如果你要建的是web站点，请把Remoting这个概念从你的设计规划中除去，可以选择web service，但如果没有特殊需求，还是类库比较方便，速度也够快。当然，使用webservice的好处可以将web服务部署到远程，并且可多个站点来共享此服务，访问方式是通过soap，但速度可能不会让你满意。 这是我在微软技术资料上看到的和'Web Services或NET Remoting之间的比较：Remoting 和 ASP.NET Web 服务IT 设计中最好也是最坏的事情就是可以选择的体系结构组件太多了。Web 服务和 .NET Remoting 就属于这种情况，有时很难决定针对不同的目的应该选用哪种技术。当然，正确的答案是为要解决的问题选择最佳的技术。不要使用“始终使用 Web 服务”或“Web 服务是 Remoting 的子集，因此它就等于所有的 Remoting”等指令性的评述。本节将主要介绍这两种技术，说明在特定的情况下，为什么是选择这一种更有意义而不是另一种。ASP.NET Web 服务和 .NET Remoting让我们从 Web 服务的定义开始，定义说 Web 服务就是可以在 Web 上提供的服务。这个定义并不是很有用，我们不妨进一步把它提炼成“通过 SOAP 和 HTTP 访问的、可寻址的处理单元，这个处理单元是用 WSDL 描述的，可以通过 UDDI 发布。”这个定义就有用多了，因为它把 Web 服务和将 HTML 发送回浏览器的 Web 服务器区分开了。为了与 .NET Remoting 进行比较，我们特别强调了 Web 服务的定义，它与可在 Web 上提供的程序化的服务不同。例如，根据我们的定义，可以使用 WSDL 从客户端通过 HTTP 访问的远程主机就是 Web 服务。鉴于此（并强调 Microsoft ASP.NET Web 服务实现），对于分布式解决方案，在选择 ASP.NET Web 服务和 .NET Remoting 的“结合点”时，应该考虑哪些因素呢？互操作性一种常见的 Microsoft 理论是：如果需要在不同系统之间进行互操作，应该选择使用开放标准 (SOAP、XML、HTTP) 的 Web 服务方法，而使用 .NET Remoting 决不是一种交互的解决方案；如果各种系统中的所有组件都是 CLR 托管的，则 .NET Remoting“可能”是正确的选择。这一原则的适用范围很广，但有所区分还是非常有用的。.NET 远程对象的客户端应该是 .NET 客户端。如果您的功能必须在 Web（这里的 Web 即 Internet）上通过松散耦合的 SOAP 客户端（例如 Unix 进程）才能实现，则 Web 服务将是正确的选择。当然，Intranet 就不受这种限制：所有客户端都可以是 .NET 客户端，而且在这种配置中并不排除 .NET Remoting。同样，对于应用程序的中间层在防火墙之后并与 Web 层直接通信的环境，仍可选择 .NET Remoting。强大的类型支持.Net Remoting 支持所有托管的类型、类、接口、枚举、对象等，这通常被称为“多类型保真”。这里的关键在于，如果客户端和服务器组件都是在应用程序域中运行的 CLR 托管的对象，则数据类型的互操作是不成问题的。从根本上讲，我们拥有的是一个封闭的系统，会话的两端可以完全被理解，因此我们可以充分利用这一事实，处理好用于通信的数据类型和对象。在各种系统并存的情况下，我们需要考虑系统之间的互操作性。对于可互操作的数据类型，我们要谨慎处理。例如，Web 服务数据类型的定义要基于 XML 架构定义 (XSD) 关于数据类型的说明。任何可以使用 XSD 进行描述并可以在 SOAP 上进行互操作的类型都可以使用。但是，这也确实使得某些数据类型不能使用。例如，对于无符号的字符类型或枚举，不存在相应的 W3C XSD 表示法。对于不同的 Web 服务实现，集合的处理不同，异常和数据集的处理也不同。另一个问题是，私有字段和属性不在 Web 服务调用之间传递，这对字段和属性本身来说并不是关键问题，但如果您的系统要求在不同的技术之间进行互操作，则在设计和测试系统时，这却是一个要考虑的因素，因为可以发送内容并不意味着可以接收到它。再重复一遍，如果需要在不同的系统之间进行互操作，就不应该考虑使用 .NET Remoting 技术。如果是封闭的、CLR 托管的解决方案，则可以使用它。状态管理我们已经看到很多方法，使用基于激活方式（客户端激活或 Singleton）的 .Net Remoting 实现状态管理。对 .NET Remoting 和 Web 服务来说，通过 HTTP（带有不确定超时的无状态协议）来管理每个客户端的连接状态是件烦琐且不切实际的事情。但是，如果您需要维护状态，那么 Remoting 提供了一种基于每个对象的解决方案。Web 服务没有提供这种每个客户端的连接状态管理，但提供了对 ASP.NET 会话和应用程序对象的访问。生存期管理与状态管理有关的是生存期管理。正如我们所看到的，Remoting 为管理远程对象的生存期提供了功能强大的机制。Web 服务对象随 Web 服务的调用而存在和消失（从概念上讲，对同步和异步都是这样）。在这方面，Web 服务与 Remoting 相比，是一种单一调用类型。Remoting 对远程对象的激活和终止提供了更大程度上的控制。这对于您的设计可能有意义，也可能没意义。按值调用和按引用调用传递到 Web 服务调用的对象是经过序列化的，并按值进行传递。传递到 Remoting 的对象或被调用的对象本身可以按值或按引用进行传递。序列化的远程对象方法是在客户端进行处理的。在 Remoting 和 Web 服务之间进行选择时应该考虑这些不同。当然，这些考虑对您来说是否重要，也取决于要解决的问题的性质。支持的协议Web 服务调用仅限于 HTTP 上的 SOAP 编码的 XML。Remoting 可以使用 TCP 传输，或者扩展基础结构以支持自定义的协议。例如，在 www.gotdotnet.com 上的 jhawk 用户示例部分提供了一个使用 Named Pipe 的 Remoting 实现。这里是 NamedPipe 自述文件的一个片段，阐明了 Remoting 的可扩展性：通过实现 IChannel* 接口，可以使用可插入式通道结构将通道插入到 .NET Remoting 中。Named Pipe 通道支持以下功能：* 通过命名管道进行通信* 同步消息* 异步消息* 单程消息* 回调* 通道接收* 通道属性* 自动生成管道名称因此，如果您需要 Named Pipe，Remoting 可以提供解决方案。但是，与 SSPI NTLM 身份验证解决方案一样，Microsoft 目前也不支持这种解决方案，也许将来 Microsoft 会满足这种需要。性能如果性能对您的设计确实至关重要，那么通过 TCP 使用二进制消息格式的 Remoting 确实提供了一些显著的性能优势。对于本文所介绍的结果，如果要完整了解产生此结果的测试环境和测试，请参阅性能比较：.NET Remoting 与 ASP.NET Web 服务一文。这里是从这篇文章中总结出的一些性能统计：图例：ASMX - Web 服务，其他都是 Remoting 解决方案WS 表示集成远程组件的 Windows 服务。图 1：性能统计文章接下来对性能图表进行了解释，如下所述：“如上所示，对于 WS_TCP_Binary，其中的对象被配置为使用 TCP 通道和 Binary 格式化程序，而主机是 Windows 服务，其性能要优于其他的分布式技术。这是因为该方法通过原始 TCP 套接字传输二进制数据（比 HTTP 的效率高），且数据不需要编码/解码，因而降低了系统开销。可以看到，WS_TCP_Binary 和最慢的方法之间存在约 60% 的性能差距。虽然 IIS_HTTP_Binary 与 WS_HTTP_Binary 产生的二进制负载相同，但其速度较慢，原因是从 IIS (Inetinfo.exe) 到 Aspnet_wp.exe 之间有额外的进程跃点。IIS_HTTP_SOAP 与 WS_HTTP_SOAP 的性能差别也是由此造成的。WS_HTTP_Binary 和 WS_TCP_SOAP 的性能几乎相同。尽管前者有 HTTP 分析方面的额外系统开销，后者有 SOAP 分析方面的额外系统开销，但在本例中 HTTP 分析的系统开销与 SOAP 分析的系统开销几乎相同。ASP.NET Web 服务的性能优于 IIS_HTTP_SOAP 和 WS_HTTP_SOAP，因为 ASP.NET XML 序列化比 .NET Remoting SOAP 序列化的效率高。从上述内容可以看出，ASP.NET Web 服务与 IIS_HTTP_Binary 的性能几乎相同。”如果原始速度确实非常重要，那么这“60% 性能差距”就很有意义了。其缺点是要将服务器集成在 Windows 服务中，以便使用 TCP 协议（请参阅前面的远程集成一节）。它有效地权衡了性能的安全性，而且是一种“最好不要用于 Internet 或不安全的 Intranet”的方法。小结ASP.NET Web 服务基于 XML，用于要求使用 HTTP（假定它们集成在 IIS）的实际应用中，能够提供简单的编程模式和强大的跨平台支持，它通过使用 SoapExtensions 提供了一定程度的扩展性，例如加密数据流。Remoting 的编程模式更为复杂，但就协议和消息格式而言，它在类型保真、状态管理和扩展性方面具有明显的优势。Remoting 不能用于非 .NET 客户端，因此无法实现 Internet 客户端与远程主机的直接连接。当在 IIS 之外集成时，Remoting 不能提供安全性模型。当集成在 IIS 时，Remoting 可以提供与 ASP.NET 相同的安全性功能，包括使用 SSL 等安全协议。如果不需要考虑与其他平台的互操作性，而且客户端和服务器的配置完全在您的控制之下，则可以考虑使用 .NET Remoting。使用 Remoting 时，使用了 HTTP 通道的 IIS 集成要优于非 IIS 集成，这样，可以得益于相关的安全性和伸缩性基础结构。当然，这意味着您必须能够在解决方案中与 IIS 进行互操作。如果这无法实现，那么使用 Remoting“可能”就是件无法实现的艰巨任务了，这与要解决的问题的性质有关。由于 .NET Remoting 要求使用 .NET 客户端，因此有必要使用最快的可用格式化程序，这样一来，选择二进制而不选择 SOAP 将产生更好的性能。请记住上文的最佳方法一节的建议，在发布时使用此格式化程序，而不要在开发过程中使用。 我建议，如果你开发大型Asp.net，决定使用分布式应用，那么条件必须满足：1 分布式应用肯定是多服务器应用。2 这些服务器你肯定有控制权，而不是仅有上传文件那样的虚拟服务器权。有了这些条件，建议你使用TCT/IP方式的NET Remoting，而且必须要实现异步调用，否则如果一个操作等待时间比较长的话，非常麻烦。而且做NET Remoting的服务端的时候最好把它注册成Windows服务，这样可以获得比较好的性能。 楼上的兄弟，如果采用NET Remoting技术，那么怎样才能实现基于表单的身份验证？因为NET Remoting不支持cookies，只支持基于Windows的身份验证。 同楼上的观点一样，我也觉得NET REMOTING更适合用在局域网中并且使用WINFORM最好，现在关键是把NET REMOTING在性能上的优势用在B/S程序上 为什么要采用这两种呢，web访问方式不能满足吗？ 如果人很多，想用表单验证的话，你可以单独做一个验证服务器，采用Web Services调用完成验证。其它的业务逻辑可以使用.NET Remoting技术来实现，当然也可以使用Web Services，主要看这部分业务调用会不会涉及到跨平台。不一定就非得只用一种技术啊 支持分布式Web Services Web Services Good Thingsuse it Web Services是不错！但是效率很低！ 考虑如下：1.可扩充性：ASP.NET中的XML Web服务好。.Net Remoting 需选择驻留分布对象的平台。可以选ASP.NET为.Net Remoting的驻留平台。2.速度：.Net Remoting 用HTTP or TCP通信,TCP用二进制编码。HTTP用ASCII编码.应选二进制编码。3.互操作能力：如要分布到各种系统中，用XML Web。：.Net Remoting用要有.NET Framework的平台。4.安全：.Net Remoting用二进制编码。SOAP基于文本，不安全。 web service的速度很慢，而且不安全，你必须借助外力才能保证一定的安全。 学习，我也说说身份验证用web services业务逻辑作为后台在局域网内了用remotingxml文件的读写可以考虑线程池 很好！值得研究不过本人认为，到了上人的量，就要用到各种技术了，比如集群,即要防止数据库过载，也要防止服务过载(IIS dllhost.exe). 有异议~~不能说开发一个站点用webservice或.net remoting，采用什么技术看你实现什么功能，webservice和.net remoting 很多资料上都有介绍~~ 楼上的，我们的系统采用分布式多层结构这是一定的，而分布式组件技术在.NET下只有webservice和.net remoting两种（.NET COM+除外，因为它只是以WAPPER设计模式托管于.NET的组件），我现在的问题是.net remoting不能实现基于表单的身份验证，如何有办法解决这个问题，是否需要webservice和.net remoting结合起来使用以解决一些net remoting的问题，应该怎么做？ http://www.c-sharpcorner.com/Code/2002/Feb/NTierDevelopmentWithNetP1.asphttp://www.c-sharpcorner.com/Code/2002/Feb/NTierDevelopmentWithNetP2.asp 我建议采用基于Socket的分布式架设和进程间通信，.NetRemoting稍微笨重了点，WebService更恼火。cookies之类的可以采用自定义票据或凭证的方式来解决。 如何读取加密PDF 求助，win7下拖动最大化窗口会自动缩小的消息是什么？ textbox自定义约束 c# 界面 急急！！！ 一个简单的遍历问题,新人！ .net 2003连接sql数据库问题【不是简单问题】 《根据编码生成树》求高手帮助！！！ 跨站点获取会话问题,请大家帮忙! 请问如何使NotifyIcon类显示balloon Tooltip 在绑定的控件中对数据库中值进行修改时碰到的一个问题。 TabControl高难度问题，老帖子里查不到【Winform—如果得到鼠标坐标位置的控件？】 在DllImport之前，应该将dll文件放在哪里？
当然，使用webservice的好处可以将web服务部署到远程，并且可多个站点来共享此服务，访问方式是通过soap，但速度可能不会让你满意。
Remoting 和 ASP.NET Web 服务
IT 设计中最好也是最坏的事情就是可以选择的体系结构组件太多了。Web 服务和 .NET Remoting 就属于这种情况，有时很难决定针对不同的目的应该选用哪种技术。当然，正确的答案是为要解决的问题选择最佳的技术。不要使用“始终使用 Web 服务”或“Web 服务是 Remoting 的子集，因此它就等于所有的 Remoting”等指令性的评述。本节将主要介绍这两种技术，说明在特定的情况下，为什么是选择这一种更有意义而不是另一种。ASP.NET Web 服务和 .NET Remoting
让我们从 Web 服务的定义开始，定义说 Web 服务就是可以在 Web 上提供的服务。这个定义并不是很有用，我们不妨进一步把它提炼成“通过 SOAP 和 HTTP 访问的、可寻址的处理单元，这个处理单元是用 WSDL 描述的，可以通过 UDDI 发布。”这个定义就有用多了，因为它把 Web 服务和将 HTML 发送回浏览器的 Web 服务器区分开了。为了与 .NET Remoting 进行比较，我们特别强调了 Web 服务的定义，它与可在 Web 上提供的程序化的服务不同。例如，根据我们的定义，可以使用 WSDL 从客户端通过 HTTP 访问的远程主机就是 Web 服务。鉴于此（并强调 Microsoft ASP.NET Web 服务实现），对于分布式解决方案，在选择 ASP.NET Web 服务和 .NET Remoting 的“结合点”时，应该考虑哪些因素呢？互操作性
一种常见的 Microsoft 理论是：如果需要在不同系统之间进行互操作，应该选择使用开放标准 (SOAP、XML、HTTP) 的 Web 服务方法，而使用 .NET Remoting 决不是一种交互的解决方案；如果各种系统中的所有组件都是 CLR 托管的，则 .NET Remoting“可能”是正确的选择。这一原则的适用范围很广，但有所区分还是非常有用的。.NET 远程对象的客户端应该是 .NET 客户端。如果您的功能必须在 Web（这里的 Web 即 Internet）上通过松散耦合的 SOAP 客户端（例如 Unix 进程）才能实现，则 Web 服务将是正确的选择。当然，Intranet 就不受这种限制：所有客户端都可以是 .NET 客户端，而且在这种配置中并不排除 .NET Remoting。同样，对于应用程序的中间层在防火墙之后并与 Web 层直接通信的环境，仍可选择 .NET Remoting。强大的类型支持
.Net Remoting 支持所有托管的类型、类、接口、枚举、对象等，这通常被称为“多类型保真”。这里的关键在于，如果客户端和服务器组件都是在应用程序域中运行的 CLR 托管的对象，则数据类型的互操作是不成问题的。从根本上讲，我们拥有的是一个封闭的系统，会话的两端可以完全被理解，因此我们可以充分利用这一事实，处理好用于通信的数据类型和对象。在各种系统并存的情况下，我们需要考虑系统之间的互操作性。对于可互操作的数据类型，我们要谨慎处理。例如，Web 服务数据类型的定义要基于 XML 架构定义 (XSD) 关于数据类型的说明。任何可以使用 XSD 进行描述并可以在 SOAP 上进行互操作的类型都可以使用。但是，这也确实使得某些数据类型不能使用。例如，对于无符号的字符类型或枚举，不存在相应的 W3C XSD 表示法。对于不同的 Web 服务实现，集合的处理不同，异常和数据集的处理也不同。另一个问题是，私有字段和属性不在 Web 服务调用之间传递，这对字段和属性本身来说并不是关键问题，但如果您的系统要求在不同的技术之间进行互操作，则在设计和测试系统时，这却是一个要考虑的因素，因为可以发送内容并不意味着可以接收到它。再重复一遍，如果需要在不同的系统之间进行互操作，就不应该考虑使用 .NET Remoting 技术。如果是封闭的、CLR 托管的解决方案，则可以使用它。状态管理
我们已经看到很多方法，使用基于激活方式（客户端激活或 Singleton）的 .Net Remoting 实现状态管理。对 .NET Remoting 和 Web 服务来说，通过 HTTP（带有不确定超时的无状态协议）来管理每个客户端的连接状态是件烦琐且不切实际的事情。但是，如果您需要维护状态，那么 Remoting 提供了一种基于每个对象的解决方案。Web 服务没有提供这种每个客户端的连接状态管理，但提供了对 ASP.NET 会话和应用程序对象的访问。生存期管理
与状态管理有关的是生存期管理。正如我们所看到的，Remoting 为管理远程对象的生存期提供了功能强大的机制。Web 服务对象随 Web 服务的调用而存在和消失（从概念上讲，对同步和异步都是这样）。在这方面，Web 服务与 Remoting 相比，是一种单一调用类型。Remoting 对远程对象的激活和终止提供了更大程度上的控制。这对于您的设计可能有意义，也可能没意义。按值调用和按引用调用
传递到 Web 服务调用的对象是经过序列化的，并按值进行传递。传递到 Remoting 的对象或被调用的对象本身可以按值或按引用进行传递。序列化的远程对象方法是在客户端进行处理的。在 Remoting 和 Web 服务之间进行选择时应该考虑这些不同。当然，这些考虑对您来说是否重要，也取决于要解决的问题的性质。支持的协议
Web 服务调用仅限于 HTTP 上的 SOAP 编码的 XML。Remoting 可以使用 TCP 传输，或者扩展基础结构以支持自定义的协议。例如，在 www.gotdotnet.com 上的 jhawk 用户示例部分提供了一个使用 Named Pipe 的 Remoting 实现。这里是 NamedPipe 自述文件的一个片段，阐明了 Remoting 的可扩展性：通过实现 IChannel* 接口，可以使用可插入式通道结构将通道插入到 .NET Remoting 中。
Named Pipe 通道支持以下功能：
* 通过命名管道进行通信
* 同步消息
* 异步消息
* 单程消息
* 回调
* 通道接收
* 通道属性
* 自动生成管道名称
因此，如果您需要 Named Pipe，Remoting 可以提供解决方案。但是，与 SSPI NTLM 身份验证解决方案一样，Microsoft 目前也不支持这种解决方案，也许将来 Microsoft 会满足这种需要。性能
如果性能对您的设计确实至关重要，那么通过 TCP 使用二进制消息格式的 Remoting 确实提供了一些显著的性能优势。对于本文所介绍的结果，如果要完整了解产生此结果的测试环境和测试，请参阅性能比较：.NET Remoting 与 ASP.NET Web 服务一文。这里是从这篇文章中总结出的一些性能统计：图例：ASMX - Web 服务，其他都是 Remoting 解决方案
WS 表示集成远程组件的 Windows 服务。
图 1：性能统计文章接下来对性能图表进行了解释，如下所述：“如上所示，对于 WS_TCP_Binary，其中的对象被配置为使用 TCP 通道和 Binary 格式化程序，而主机是 Windows 服务，其性能要优于其他的分布式技术。这是因为该方法通过原始 TCP 套接字传输二进制数据（比 HTTP 的效率高），且数据不需要编码/解码，因而降低了系统开销。可以看到，WS_TCP_Binary 和最慢的方法之间存在约 60% 的性能差距。
虽然 IIS_HTTP_Binary 与 WS_HTTP_Binary 产生的二进制负载相同，但其速度较慢，原因是从 IIS (Inetinfo.exe) 到 Aspnet_wp.exe 之间有额外的进程跃点。IIS_HTTP_SOAP 与 WS_HTTP_SOAP 的性能差别也是由此造成的。
WS_HTTP_Binary 和 WS_TCP_SOAP 的性能几乎相同。尽管前者有 HTTP 分析方面的额外系统开销，后者有 SOAP 分析方面的额外系统开销，但在本例中 HTTP 分析的系统开销与 SOAP 分析的系统开销几乎相同。
ASP.NET Web 服务的性能优于 IIS_HTTP_SOAP 和 WS_HTTP_SOAP，因为 ASP.NET XML 序列化比 .NET Remoting SOAP 序列化的效率高。从上述内容可以看出，ASP.NET Web 服务与 IIS_HTTP_Binary 的性能几乎相同。”
如果原始速度确实非常重要，那么这“60% 性能差距”就很有意义了。其缺点是要将服务器集成在 Windows 服务中，以便使用 TCP 协议（请参阅前面的远程集成一节）。它有效地权衡了性能的安全性，而且是一种“最好不要用于 Internet 或不安全的 Intranet”的方法。小结
ASP.NET Web 服务基于 XML，用于要求使用 HTTP（假定它们集成在 IIS）的实际应用中，能够提供简单的编程模式和强大的跨平台支持，它通过使用 SoapExtensions 提供了一定程度的扩展性，例如加密数据流。Remoting 的编程模式更为复杂，但就协议和消息格式而言，它在类型保真、状态管理和扩展性方面具有明显的优势。Remoting 不能用于非 .NET 客户端，因此无法实现 Internet 客户端与远程主机的直接连接。当在 IIS 之外集成时，Remoting 不能提供安全性模型。当集成在 IIS 时，Remoting 可以提供与 ASP.NET 相同的安全性功能，包括使用 SSL 等安全协议。如果不需要考虑与其他平台的互操作性，而且客户端和服务器的配置完全在您的控制之下，则可以考虑使用 .NET Remoting。使用 Remoting 时，使用了 HTTP 通道的 IIS 集成要优于非 IIS 集成，这样，可以得益于相关的安全性和伸缩性基础结构。当然，这意味着您必须能够在解决方案中与 IIS 进行互操作。如果这无法实现，那么使用 Remoting“可能”就是件无法实现的艰巨任务了，这与要解决的问题的性质有关。由于 .NET Remoting 要求使用 .NET 客户端，因此有必要使用最快的可用格式化程序，这样一来，选择二进制而不选择 SOAP 将产生更好的性能。请记住上文的最佳方法一节的建议，在发布时使用此格式化程序，而不要在开发过程中使用。
1 分布式应用肯定是多服务器应用。
2 这些服务器你肯定有控制权，而不是仅有上传文件那样的虚拟服务器权。有了这些条件，建议你使用TCT/IP方式的NET Remoting，而且必须要实现异步调用，否则如果一个操作等待时间比较长的话，非常麻烦。
而且做NET Remoting的服务端的时候最好把它注册成Windows服务，这样可以获得比较好的性能。
因为NET Remoting不支持cookies，只支持基于Windows的身份验证。
use it
1.可扩充性：ASP.NET中的XML Web服务好。
.Net Remoting 需选择驻留分布对象的平台。
可以选ASP.NET为.Net Remoting的驻留平台。
2.速度：.Net Remoting 用HTTP or TCP通信,TCP用二进制编码。
HTTP用ASCII编码.应选二进制编码。
3.互操作能力：如要分布到各种系统中，用XML Web。：.Net Remoting用要有.NET Framework的平台。
4.安全：.Net Remoting用二进制编码。SOAP基于文本，不安全。
业务逻辑作为后台在局域网内了用remoting
xml文件的读写可以考虑线程池
不过本人认为，到了上人的量，就要用到各种技术了，比如集群,即要防止数据库过载，也要防止服务过载(IIS dllhost.exe).
http://www.c-sharpcorner.com/Code/2002/Feb/NTierDevelopmentWithNetP2.asp
cookies之类的可以采用自定义票据或凭证的方式来解决。