简介

Web客户端软件工厂（ wcsf ）提供了一套指导建筑师和开发人员来构建企业级的Web应用程式。该软件工厂包括，结合Visual Studio.net可以开发出可重复使用的代码和指导方案及自动化的开发任务。

使用Web客户端软件工厂，开发人员可以创建可复用的相互独立的（独立开发和部署）Web应用程序块。这些模块是动态聚集在运行时纳入一个共同的壳。此外，工厂，包括支持asp.net AJAX技术，从而为用户提供更丰富的更负责任的用户体验。

系统环境

• Microsoft Windows XP, Windows Server 2003, or Windows Vista operating system
• Microsoft .NET Framework 3.0 (required to use page flow; otherwise, .NET Framework 2.0 is satisfactory)
• Microsoft Visual Studio 2005 Team Edition for Software Testers (required to run unit tests in the first labs)
• Guidance Automation Extensions July 2007 CTP
• Enterprise Library 3.1 – May 2007
• Web Client Software Factory - June 2007

系统功能模块

从图上我们可以很清楚看到该软件工厂已经包含的一个企业级Web应用程序所必需具备的模块功能

从上向下看：

从表现层（Presentation Layer）UI组件(ajax)，页面流程控制(page flow),到业务逻辑层(Business Layer) 包含标准的业务流程模块(可以使用wwf)，实体类（可以用ado.net entity framwork），业务功能模块或是说抽象出来的业务接口，底层就是资源访问层主要就两类，一类数据库，一类Web Service

横向看：

异常处理，认证，受权，模块管理，注册，部署功能模块，当然这里提供的这些类库并非是在功能上有多么强大，比如认证授权，但可以很方便的进行扩展和自定义开发。

如何使用wcsf

Wcsf提供了那么多的基础的功能模块，如何有效地组织在一个web解决方案（Solution）中，帮助构架师，开发人员构建出一个优秀的企业级web应用程序，这一切都要依赖于Web Client Development guidance package 通过向导的方式一步一步地构建出一个web应用程序。

上图描述了在wcsf的web解决方案中提供的模块，从这些模块中很容易可以看出这个解决方案使用的是MVC或MVP的设计模式（有module,control,view，presenter当然这些都是通过向导自动帮我们创建好），另外还有一块页面流程模块（page flow）对于做一些流程审批功能非常有帮助,page flow是在wwf(.net 3.5)上扩展出来的功能。

同时上图也告诉我们创建一个 web应用程序解决方案的顺序或是开发流程，从创建项目，加添注册业务模块，定义流程，系统配置到最后的部署一步一步的通过向导的方式指导开发人员进行开发；

使用wcsf带来的优势

不说大道理（松耦合loosely-coupled,扩展性Extensibility，健壮性robustness，可维护性maintainability，等等，这些内容可以写在项目方案里）；

只谈在使用过程中体会到方便：

专业（professional）：因为有了上面优秀的架构和功能齐全的基础类库，有帮你有机的整合到一起构建出一套专业的web应用程序。

规范（standard）：因为有自动化向导帮我们创建一系列模块和指导我们下一步该做什么，规范化的开发流程，规范化的命名，规范化的功能模块。

抽象（abstract）：因为wcsf只是帮你创建了业务逻辑（IService）,UI（IView），流程(IPageFlow)等空接口，需要架构师或开发人员通过对实际业务中提炼出有共性，变化的东西出来；迫使你往更高层面的抽象去思考设计问题，而不只是停留在实体层面的CRUD的操作。

动手实验1

让我们通过一个微软提供的动手实验来体验一下wcsf是如何一步一步帮助我们完成一个web应用程序从架构到开发到最后的部署。

创建一个web client解决方案

• 新建一个项目 illustrated in Figure 1, opens
• 选择 Guidance Packages,单击 Web Client Development June 2007或February2008.
• 选择Templates, 单击 Web Client Solution (C#, Web Site).
• 取名 GlobalBank.

  

  Figure 1
  New Project dialog box

• 单击OK.
• 开始创建Web Client解决方案的向导 Figure 2,
• 在 Root namespace box输入 GlobalBank.
• 单击 Show documentation后点Finish完成任务 .

Figure 2
Create Web Client Solution recipe wizard

添加一个EFT业务模块

业务模块(Business Module)从项目的角度可以看是一个大的业务功能模块，比如管理模块，报表模块。也可以当作只有一个页面的小模块。但是该业务模块是必需的。

1. 选择解决方案下面 Modules目录,鼠标右键新建一个目录 命名 EFT.
2. 通过向导创建一个新的业务模块（business module）在 EFT目录下.右击EFT 目录,点 Web Client Factory, 在选择 Add Business Module (C#).
3. 新建项目的对话框如图Figure 4,命名 EFT
4. 选择一下路径 C:\GlobalBank\Modules\EFT

Figure 4
Add New Project dialog box

1. 单击OK开始一个创建业务模块向导.
2. Figure 5一个创建业务模块的向导, 如果需要加添单元测试的选择 Create project for unit tests然后单击 Finish.

Figure 5
Add Business Module recipe wizard

验证一下创建的Web应用程序

1. 设定这个Website 作为启动项目as StartUp Project.
2. 设定Default.aspx page 为起始页as Start Page.
3. 编译并运行这个Web如图 Figure 8.我们添加的业务模块就会自动在菜单栏中显示

Figure 8
GlobalBank Web client application default page

1. 单击每个菜单项会自动连接到每个模块的默认页面中.

    

代码分析

整个解决方案(Solution)的结构

主要有两大块组成Module和WebSites;

Module目录下面就是每个业务模块对应如下图的Module内的内容有Presentation,Busincess,Resource access.

展开一个EFT的Module看一下里面的内容如下图每一个类(Class)都能找到在上图中的位置

下面定义了很多Interface和这些Interface的实现(implement)

IEFTController：MVC中的控制器用于连接UI和Business logic从下面的代码我们可以很清楚的看出来；下面定义了ITransferService（定义的业务逻辑）,INavigationService（控制页面跳转）。IPageFlow（页面流程控制类）

INewTransferViewView：处理页面(aspx)发送过来的请求并且响应的结果返回给页面，代码如下，这里有Controller，有响应页面的CRUD的操作；

通过aspx实现了INewTransferViewView进行关联

ITransferService：我们抽象出来的Business Logic或是说User Case

EFTModuleInitializer：实现初始化注册模块，加载菜单项；

Shell:公共的模块下面定义MasterPage上的公共属性，初始化首页面的信息，和加载公共的业务模块如，EnterpriseLibraryAuthorizationService, SiteMapBuilderService 认证/授权，菜单

WebSites就是一个web应用程序站点其中只包含web页面（aspx）和UI Control;不同的模块由不同的目录分开。主要处理UI的操作，验证，显示。

整个解决方案（Solution）结构非常清晰，各模块间的功能非常明确，所有模块之间引用或是说依赖(Dependency)都是通过接口(Interface)实现，面向接口编程。这样可以很好做到松耦合。

评价

平时我们在程序设计开发都很喜欢讲要面向对象，要SOA，要MVC，要分N层等等高级思想，可一到实际的项目过程中往往这些思想便成了理论或是写方案充页数的东西；而微软patterns & practices Team把这些优秀的框架，先进的思想通过工具，让它变得更加实际，更加方便，更容易接受，我想这就是微软patterns & practices Team价值所在。

居于.net和x509证书实现安全

概述

    主要针对目前xxx数据交换平台实现安全数据交换的设计方案;本方案通过PKI技术实现对报文加密,加签和证书的管理实现对数据交换安全的功能性需求.

PKI技术介绍

PKI是"Public Key Infrastructure"的缩写，意为"公钥基础设施"，是一个用非对称密码算法原理和技术实现的、具有通用性的安全基础设施。PKI利用数字证书标识密钥持有人的身份，通过对密钥的规范化管理，为组织机构建立和维护一个可信赖的系统环境，透明地为应用系统提供身份认证、数据保密性和完整性、抗抵赖等各种必要的安全保障，满足各种应用系统的安全需求。简单的说,PKI是提供公钥加密和数字签名服务的系统，目的是为了自动管理密钥和证书，保证网上数字信息传输的机密性、真实性、完整性和不可否认性。

为什么需要PKI

随着网络技术的发展，特别是Internet的全球化，各种基于互联网技术的网上应用，如电子政务、电子商务等得到了迅猛发展。网络正逐步成为人们工作、生活中不可分割的一部分。由于互联网的开放性和通用性，网上的所有信息对所有人都是公开的，因此应用系统对信息的安全性提出了更高的要求。

（1）对身份合法性验证的要求
以明文方式存储、传送的用户名和口令存在着被截获、破译等诸多安全隐患。同时，还有维护不便的缺点。因此，需要一套安全、可靠并易于维护的用户身份管理和合法性验证机制来确保应用系统的安全性。
（2）对数据保密性和完整性的要求
企业应用系统中的数据一般都是明文，在基于网络技术的系统中，这种明文数据很容易泄密或被篡改，必须采取有效的措施保证数据的保密性和完整性。
（3）传输安全性要求
以明文方式在网上传输的数据，很容易被截获以至泄密，必须对通信通道进行加密保护。利用通信专线的传统方式已经远远不能满足现代网络应用发展的需求，必须寻求一种新的方法来保证基于互联网技术的传输安全需求。
（4）对数字签名和不可否认的要求
不可抵赖性为了防止事件发起者事后抵赖，对于规范业务，避免法律纠纷起着很大的作用。传统不可抵赖性是通过手工签名完成的，在网络应用中，需要一种具有同样功能的机制来保证不可抵赖性，那就是数字签名技术。
PKI基于非对称公钥体制，采用数字证书管理机制，可以为透明地为网上应用提供上述各种安全服务，极大地保证了网上应用的安全性。

功能模块

证书管理控制台：

证书颁发机构(CA) 用于申请和颁发证书的应用服务。

证书生成工具(Makecert.exe)生成仅用于测试目的的 X.509 证书。它创建用于数字签名的公钥和私钥对，并将其存储在证书文件中。此工具还将密钥对与指定发行者的名称相关联，并创建一个 X.509 证书，该证书将用户指定的名称绑定到密钥对的公共部分。

证书控制台，用于管理本地计算机上安装的证书。

安全管道：

证书读取器，读取安装在本地计算机中的证书信息。

加密/解密组件，通过证书提供的信息对报文进行加密/解密操作。

加签/验签组件，通过证书提供的信息对报文进行加签/验签操作。

证书管理过程

通过X.509证书实现密钥的交换和签名；用自己的证书（包含私钥）签名，用其他人证书（公钥）进行加密，验签的过程；

1. 生成证书，该证书的用途可用于签名，也可用于解密（将证书的公钥导出到其他电脑后通过公钥加密）生成证书的方式有两种
   1. 通过外部CA证书颁发机构申请证书
   2. 通过.net Makecert.exe工具通过命令行创建证书(这种方式才生的证书无法实现验证证书的合法性和可用性)
2. 将获取到的证书导入到本地计算机的证书管理容器中如图1所示

   

3. 对于需要解密的证书需要把公钥导出给其他电脑，让对方用这个公钥加密，用于签名的证书，则需要把公钥导出给其他电脑，用公钥来验证自己的身份和报文是否被篡改。
4. 将导出的公钥文件通过文件拷贝的方式复制到远程计算如图2。

   

5. 远程计算获取到公钥文件后直接导入到计算机的证书管理器的其他人目录下如图3,加密的时候需要读取本地计算其他人（Local Computer\Other People）下的证书加密和验证签名

   

加密/加签过程

客户端需要发送加密/加签报文到服务器的过程。

满足的前提条件

    在证书管理器中存在加密用的服务器证书和加签用的客户端证书

1. 获取需要加密/加签的明文，对于加密操作则读取本地计算机其他人目录下的证书信息，对于签名操作则需要读取本地计算机\个人下面的证书。加密/加签需要的证书名称通过配置文件获取。如图4证书内容

   

2. 调用加密/加签算法进行对报文的加密/加签操作；使用.net标准的类库实现；加密后的文档结构如图5

   

   

   加密算法说明

   EncryptedXml 类是 .NET Framework 中用于 XML 加密的主类。XML 加密是对所有或部分 XML 文档或任意数据进行加密的一种基于标准的、可互操作的方法。.NET Framework XML 加密类实现了位于 http://www.w3.org/TR/xmldsig-core/ 的万维网联合会 (W3C) XML 加密规范。无论何时需要在应用程序或组织之间以标准方式共享加密的 XML 数据，都可使用 EncryptedXml 类。任何使用此类进行加密的数据均可通过符合 W3C XML 加密规范的任何实现进行解密。 XML 加密用 <EncryptedData> 元素替换任何明文 XML 元素或文档，此元素包含明文 XML 或任意数据的加密（或密文）表示形式。<EncryptedData> 元素可以选择包含有关在何处查找用于对密文进行解密的密钥的信息，以及关于使用哪种加密算法对明文进行加密的信息。除了允许对用于解密 <EncryptedData> 元素值的密钥进行加密外，<EncryptedKey> 元素在样式和用法方面与 <EncryptedData> 元素类似。注意，<EncryptedKey> 元素和 <EncryptedData> 元素从不包含未加密的密钥。使用下列方法之一交换密钥信息：

• 不包含任何密钥信息。如果选择此选项，则双方必须在交换加密数据之前在算法和密钥上取得一致。
• 在 <RetrievalMethod> 元素的统一资源标识符 (URI) 属性中包含密钥位置。双方必须事先就密钥位置取得一致，并且必须将此位置保密。
• 包含一个字符串名称，此名称映射到 <KeyName> 元素中的密钥。双方必须在交换加密数据之前在密钥名称映射上取得一致，并且必须将此映射保密。
• 在 <EncryptedKey> 元素中包含加密密钥。双方必须在交换加密数据之前在对加密密钥进行解密的密钥上取得一致。可以有选择地包含将对 <EncryptedKey> 元素中的密钥进行解密的密钥的名称或位置。

加签算法说明

SignedXml 类是 .NET Framework 中用于 XML 签名和验证 (XMLDSIG) 的主类。 XMLDSIG 是一种基于标准且可互操作的方法，用于对 XML 文档的全部或部分或者可通过统一资源标识符 (URI) 查找的其他数据进行签名和验证。.NET Framework XMLDSIG 类实现了 WWW 联合会 (W3C) 有关 XML 签名和验证的规范，可从 http://www.w3.org/TR/xmldsig-core/ 获得该规范。

无论何时需要在应用程序或组织之间采用标准方式共享已签名的 XML 数据，都可使用 SignedXml 类。 使用此类签名的任何数据都可以通过符合 XMLDSIG 的 W3C 规范的任何实现进行验证。

XMLDSIG 将创建一个 <Signature> 元素，该元素包含用于 XML 文档或可通过 URI 查找的其他数据的数字签名。 <Signature> 元素可以有选择地包含有关在何处查找用于验证签名的密钥以及使用哪种加密算法进行签名等信息。

通过 SignedXml 类，可以创建以下三种 XML 数字签名：

使用下列方法之一交换密钥信息：

• 不包含任何密钥信息。 如果您选择此选项，则双方必须在交换数字签名之前在算法和密钥上取得一致。
• 在 <EncryptedKey> 元素中包括公钥。
• 在 <RetrievalMethod> 元素的 URI 属性中包括密钥的位置。双方必须事先就密钥位置取得一致，并且必须将此位置保密。
• 在 <KeyName> 元素中包括映射到密钥的字符串名称。 双方必须在交换加密数据之前在密钥名称映射上取得一致，并且必须将此映射保密。

1. 将生成的密文；密文中包含加密证书信息和加签证书的信息提供给服务端解密和验签使用
2. 发送到目的地

解密/验签过程

服务端接收解密/验签报文的过程，通过对报文的加密/加签和证书的管理实现对客户端传输的控制和安全上管理。可以很好保证报文的安全不会在传输过程中被篡改和截获。

满足的前提条件

    在证书管理器中存在解密用的服务器证书和验签用的客户端证书

1. 接收到加密/加签的报文后首先抽取中间的证书信息（包含证书名称）
2. 获取到证书名称后匹配本地计算中是会存在这本证书对于验证签名的证书统一存放在本地计算机\其他人目录下，对于解密的证书统一存放在本地计算机\个人目录下 ，如果没有找到相应的证书则抛出异常终止这个过程
3. 调用.net SignedXml类库验证报文的合法性-是否在传输过程中被篡改和证实客户端的身份，如果发现验证不通过比如被篡改过饿抛出异常终止这个过程。
4. 验证通过后对于需要解密的报文调用.net EncryptedXml类库进行解密，最终变成明文进行后续的处理。

I'm sure I've written about this; at the least, it's in my install documentation and also the Official Microsoft BizTalk Installation documentation.

When firing BizTalk up pointing to a remote SQL Server, you might see the following error: "The transaction manager is not available".

I'm careful to point out you must set client network access for DTC in my installation documentation.  I also found reference to a MS article titled “How to enable network DTC access in Windows Server 2003“. Be sure to restart DTC when you've finished the configuration steps.

I located a link to “How To Use DTCTester Tool“, which contains a DTC Test application and instructions on how to set it up to test your DTC installation is configured correctly.

Windows Server 2003 SP1 invited the Windows Firewall into the mix, so configuring network DTC is all the more important on both the BizTalk and MSSQL servers.  I have a few details which I'll provide later, but here are two MSDN articles that helped me:

How to adjust the MSDTC settings:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/deploying/htm/ebiz_depl_assemblies_tfrh.asp?frame=true

MSDTC Changes in Windows 2003 SP1:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cossdk/html/2627a956-60b3-4d26-bc04-e0676ec97786.asp

    可以跨进程、跨机器甚至于跨平台的通信，只要支持标准的Web Service，例如J2EE应用服务器（如WebSphere，WebLogic）。应用程序可以运行在Windows操作系统下，也可以运行在其他的操作系统，如Sun Solaris，HP Unix，Linux等等。

    3、安全与可信赖
WS-Security，WS-Trust和WS-SecureConversation均被添加到SOAP消息中，以用于用户认证，数据完整性验证，数据隐私等多种安全因素。
在SOAP的header中增加了WS-ReliableMessaging允许可信赖的端对端通信。而建立在WS-Coordination和WS-AtomicTransaction之上的基于SOAP格式交换的信息，则支持两阶段的事务提交（two-phase commit transactions）。
    上述的多种WS-Policy在WCF中都给与了支持。对于Messaging而言，SOAP是Web Service的基本协议，它包含了消息头（header）和消息体(body)。在消息头中，定义了WS-Addressing用于定位SOAP消息的地址信息，同时还包含了MTOM（消息传输优化机制，Message Transmission Optimization Mechanism）。

    4、兼容性
    WCF充分的考虑到了与旧有系统的兼容性。安装WCF并不会影响原有的技术如ASMX和.Net Remoting。即使对于WCF和ASMX而言，虽然两者都使用了SOAP，但基于WCF开发的应用程序，仍然可以直接与ASMX进行交互。

二 WebService的运行机理

首先客户端从服务器的到WebService的WSDL，同时在客户端声称一个代理类(Proxy Class)， 这个代理类负责与WebService服务器进行Request 和Response， 当一个数据（XML格式的）被封装成SOAP格式的数据流发送到服务器端的时候，就会生成一个进程对象并且把接收到这个Request的SOAP包进行解析，然后对事物进行处理，处理结束以后再对这个计算结果进行SOAP包装，然后把这个包作为一个Response发送给客户端的代理类(Proxy Class)，同样地，这个代理类也对这个SOAP包进行解析处理，继而进行后续操作。

三 .net Remoting

是在DCOM等基础上发展起来的一种技术，它的主要目的是实现跨平台、跨语言、穿透企业防火墙，这也是他的基本特点，与WebService有所不同的是，它支持HTTP以及TCP信道，而且它不仅能传输XML格式的SOAP包，也可以传输传统意义上的二进制流，这使得它变得效率更高也更加灵活。而且它不依赖于IIS，用户可以自己开发(Development)并部署(Dispose)自己喜欢的宿主服务器，所以从这些方面上来讲WebService其实上是.netemoting的一种特例。

区别：

1、Remoting可以灵活的定义其所基于的协议，比如http，tcp等，如果定义为HTTP，则与Web Service相同，但是webservice是无状态的，使用remoting一般都喜欢定义为TCP，这样比Web Service稍为高效一些，而且是有状态的。

2、Remoting不是标准，而Web Service是标准。

3、Remoting一般需要通过一个WinForm或是Windows服务进行启动，也可以使用iis部署，而Web Service则必须在IIS进行启动。

4、在VS.net开发环境中，专门对Web Service的调用进行了封装，用起来比Remoting方便。

5 net remoting只能应用于MS 的.net framework之下，需要客户端必须安装framework，但是WebService是平台独立的，跨语言（只要能支持XML的语言都可以） 以及穿透企业防火墙。

来自MSDN：http://www.microsoft.com/china/MSDN/library/enterprisedevelopment/builddistapp/ASP.NETWebServicesor.NETRemoting-HowtoChoose.mspx?mfr=true

分布式应用程序设计：ASP.NET Web 服务和 .NET Remoting

ASP.NET Web 服务偏向于 XML Schema 类型系统，提供具有广泛使用范围的跨平台支持的简单编程模型。.NET Remoting 偏向于运行时类型系统，提供较为复杂而且使用范围小得多的编程模型。这种本质上的差别是决定使用哪种技术的主要因素。但是，还要考虑很多其他设计因素，包括传输协议、主机进程、安全性、性能、状态管理以及对事务的支持等。

传输协议和主机进程

尽管 SOAP 规范并不要求用 HTTP 作为传输协议，但是客户端只能通过 HTTP 访问使用 ASP.NET Web 服务实现的 Web 服务，因为它是 ASP.NET 支持的唯一一种传输协议。服务是通过 IIS 调用的，并在 ASP.NET 的辅助进程 aspnet_wp.exe 中执行。

.NET Remoting 使您能够在任何类型的应用程序（包括 Windows 窗体、托管的 Windows 服务、控制台应用程序或 ASP.NET 辅助进程）中灵活地托管远程对象。正如前面所述，.NET Remoting 提供两个传输信道——TCP 和 HTTP。这两个信道都能使用套接字提供任意发送和接收进程之间的通信。

它还能将 HTTP 信道与 IIS 和 ASP.NET 辅助进程集成。这一点很重要，原因有以下几点。首先，它是当客户端请求到达时自动启动 .NET Remoting 端点的唯一方法。.NET Remoting 管线不包括启动远程服务器所需的 DCOM 类型的服务控制管理器 (SCM)。如果从任意进程中提供远程对象，则需要确保那些进程正在运行。还必须确保它们是线程安全的，例如，线程 A 不能在线程 B 开始关闭进程之后激活对象。如果从 ASP.NET 提供远程对象，则可以利用 Aspnet_wp.exe 辅助进程，这样既可自动启动又具有线程安全的优势。第二，与 IIS 集成是确保跨进程 .NET Remoting 调用的唯一途径，如下一节所述。

ASP.NET Web 服务和 .NET Remoting 基础结构都是可扩展的。您可以过滤入站和出站消息，从多方面控制类型封送和元数据的生成。使用 .NET Remoting，还能实现您自己的格式化程序和信道。

安全性

由于 ASP.NET Web 服务依赖于 HTTP，因此它们与标准的 Internet 安全性基础结构相集成。ASP.NET 利用 IIS 的安全性功能，为标准 HTTP 验证方案（包括基本、简要、数字证书，甚至 Microsoft? .NET Passport）提供了强有力的支持。（还可以使用 Windows 集成验证，但只能用于信任域中的客户端。）使用可用的 HTTP 验证方案的一个优势在于，无需在 Web 服务中更改代码，IIS 是在 ASP.NET Web 服务被调用之前执行验证的。ASP.NET 还支持基于 .NET Passport 的验证和其他自定义的验证方案。ASP.NET 支持基于目标 URL 的访问控制，并通过与 .NET 代码访问安全性 (CAS) 基础结构的集成支持访问控制。SSL 可用于确保通信的安全。

尽管这些标准传输技术对于确保 Web 服务相当有效，但它们只能做到这种程度。在涉及到不同信任域中多个 Web 服务的复杂情况下，还得建立自定义的特殊解决方案。Microsoft 和其他公司正致力于创建一套安全性规范，该规范将基于 SOAP 消息的可扩展性提供消息级别的安全性功能。这些规范之一是 XML Web 服务安全性语言（WS-Security），它为消息级别的凭据传输、消息完整性和消息保密定义了框架。

正如上一节所述，一般情况下，.NET Remoting 管线不能确保跨进程调用的安全。使用 ASP.NET 托管于 IIS 中的 .NET Remoting 端点可以利用 ASP.NET Web 服务可用的所有安全性功能，包括对使用 SSL 确保有线通信的安全性的支持。如果您正在使用托管在进程中的 TCP 信道或 HTTP 信道（而不是 aspnet_wp.exe），则必须自己执行身份验证、授权和保密机制。

另一个要关注的安全性问题是，在不必更改默认安全性策略的情况下，从不完全信任的环境中执行代码的能力。ASP.NET Web 服务客户端代理可以在这些环境中工作，但 .NET Remoting 代理则不能。要从不完全信任的环境中使用 .NET Remoting 代理，需要特殊的序列化权限。默认情况下，该权限不会授予从 Intranet 或 Internet 上下载的代码。如果要在不完全信任的环境中使用 .NET Remoting 客户端，则需要更改从那些区域中加载的代码的默认安全性策略。当您从运行于沙箱（如下载的 Windows 窗体应用程序）中的客户端连接到系统时，ASP.NET Web 服务是较简单的选择，因为不需要更改安全性策略。

状态管理

默认情况下，ASP.NET Web 服务模型采用无状态的服务结构；它并不是本能地与来自同一个用户的多个调用相关。另外，客户端每次调用 ASP.NET Web 服务时，都创建一个新的对象以服务于该请求。方法调用完成后，该对象即被破坏。要维护请求之间的状态，可以使用 ASP.NET 页面使用的相同技术（例如，Session 和 Application 属性包），也可以自己实现自定义的解决方案。

.NET Remoting 支持许多状态管理选项，并且可能与来自同一个用户的多个调用相关或不相关，这取决于您选择的对象生命周期架构。SingleCall 对象是无状态的（如用于调用 ASP.NET Web 服务的对象），Singleton 对象共享所有客户端的状态，客户端激活的对象在每个客户端的基础上保持状态（带有其产生的所有相关的可升级性和可靠性问题）。

性能

从原始性能方面来讲，使用 TCP 信道和二进制格式化程序时，.NET Remoting 管线能够提供最快的通信。在我们进行的比较 ASP.NET Web 服务和 .NET Remoting 的相对性能的几乎所有的测试中，ASP.NET Web 服务在性能上都超出了使用 HTTP 或 TCP 信道的 SOAP 格式化程序的 .NET Remoting 端点。更有意思的是，使用二进制格式化程序和 HTTP 信道的 ASP.NET 和 .NET Remoting 端点在性能上非常相近。（更多信息，请参见 Performance Comparison:NET Remoting vs. ASP.NET Web Services。）

企业服务

ASP.NET Web 服务或通过 .NET Remoting 提供的对象可以使用本地事务根据单个数据库协调工作。如果需要根据多个资源协调工作，可以使用 .NET 企业服务（又称 COM+）公布的事务（由 COM+ 管线管理的 DTC 分布式事务）。但要注意的是，ASP.NET Web 服务和 .NET Remoting 管线都不能传播公布的事务，因此两种端点都不可能通过跨进程的调用继承公布的事务。

这不一定是件坏事。一般来讲，公布的事务比本地事务代价要高，而要跨进程传播公布的事务，则代价会更高。如果确实需要这一功能，简单的解决方案是在 .NET 企业服务的服务器应用程序中部署一个从 System.EnterpriseServices.ServicedComponent 派生的类（更多信息，请参见 COM+ Integration:How .NET Enterprise Services Can Help You Build Distributed Applications）。对该类对象的跨进程调用将使用 DCOM 进行处理，以确保正确传播事务环境。较难的解决方案是使用底层的 API，手动传播分布的事务。

值得注意的是，传统的分布式事务模型一般不适用于松散耦合的 Web 服务。基于补偿事务的模型（即，撤消其他事务所提交工作的事务）更有意义，因为其隔离约束条件并不是很严格。在包括 Microsoft 的 Web 服务供应商中有一种普遍的说法，即 Web 服务空间需要的事务模型越灵活，该空间中进行的工作越多。等到定义出 Web 服务事务的标准方法时，您就可以根据情况使用本地或公布的事务实现自己的补偿架构了。

小结
虽然 .NET Remoting 基础结构和 ASP.NET Web 服务都可以进行跨进程通信，但每种设计适用于不同的用户。ASP.NET Web 服务提供了简单的编程模型，并具有广泛的使用范围。.NET Remoting 提供了较为复杂的编程模型，而且使用范围窄得多。请务必了解这两种技术的工作原理，并选择适合您应用程序的技术。在任意一种情况下，都要使用 IIS 和 ASP.NET 管理进程生命周期，并提供一般的安全性。