有关配置网站和配置服务在StockTrader 3.0中使用，微软在其提供的配置说明文档中已经做了很详细的说明。基本上是一步一步傻瓜式的阐述的，在这里也就简单的在文档中摘选一下重点简单的做一下记录，理一下整个配置使用过程。
首先先简单介绍一下StockTrader 3.0中的核心组件构成：
.NET StockTrader Web application--网站UI主程序
.NET StockTrader Business Services (hosted in IIS or in the .NET self-host program)--主业务逻辑服务(示例提供了二种实现方式IIS宿主和自宿主)
.NET StockTrader Order Processor Service--订单处理服务(从属于主业务逻辑服务)
示例安装以后，默认情况下所有的组件都运行在同一个Asp.net进程中，没有使用任何远程服务调用技术。 但是通过配置网站和配置服务，你可以把它们部署在不同的进程，甚至不同的机器中，从而轻松地实现应用程序的分布式架构。当然处于学习研究的目的，你也可以在同一台机器上，通过利用不同的宿主端口配置也可以模拟整个测试过程。
以下是微软提供的系统架构图：
接下来让我们跟着微软的StockTrader配置使用说明，进一步了解配置网站和配置服务：
第一步我们首先要登录配置网站，打开安装的ConfigWeb页面，可以看到Login/Logout链接，点击以后我们就可以进入登录界面了。这里需要强调的是一般来说整个系统架构都是通过自上而下进行配置的，通俗点说就是先进入WebAppUI,WebAppUI连接主BSL,主BSL连接其他BSL,可以进一步实现任意的n层体系架构。在登录界面我们需要输入用户名和密码，以及期望的宿主服务终结点，在这里我们选用默认的网站应用程序服务终结点。用户名和密码为安装时的默认的初始用户名Admin和密码yyy，当然你也可以在生产环境配置中修改此用户名和密码，方法是在配置网站上登录需要修改的配置服务，在配置管理主设置界面，点击用户管理(ManageUsers)链接，修改此用户名和密码。
登录以后我们可以看到StockTrader的网站应用程序设置主界面，在这里我们可以看到当前宿主服务的运行状态，如果当前系统已经配置为使用负载均衡，我们还可以看到已经定义的集群节点。当然在这里我们也可以调整各项配置，以满足其他系统需求。默认配置情况下其他业务逻辑服务组件都运行在同一个.net进程中，没有使用任何远程服务调用技术，在页面上使用了*标记出。
当然你也可以重新配置StockTrader Web应用程序所使用的主业务逻辑服务，首先让我们来实现使用一个宿主在IIS中的远程主业务逻辑服务组件，通过点击上图用红圈标出的链接，我们可以到达StockTrader Web应用程序配置管理页面。
在整个配置管理页面我们可以看到三个设置组，基本设置、具体设置和高级设置，默认选择在基本设置上。在下面的设置表格中我们可以看到目前系统的当前设置值， 在这里我们需要做的是把StockTraderWebApplication的AccessMode从默认的进程内(InProcess)改为一种远程的业务逻辑服务模式，具体业务逻辑服务模式详细可以参见配置参考文档。我们点击上图红圈标记的链接进入具体设置界面，选择IIS宿主Web服务模式(IISHost_WebService)，注意区分大小写。点击更新按钮便激活当前的设置，最后点击Configuration链接返回ConfigWeb主设置页面。
再次进入配置管理主设置页面，我们发现在StockTrader网站应用程序下先前的主业务逻辑服务和订单处理服务没有了，这是因为之前我们已经把所有的业务逻辑服务都改成了远程激活调用导致的，然而现在并没有任何远程服务连接，StockTrader网站应用程序需要连接使用远程服务实例，为了达到此目的我们需要进入连接(Connections)管理界面添加远程连接点。
点击添加连接按钮，你可以看到一个远程服务实例连接列表，服务列表定义在配置管理主设置页面点击编辑定义服务(Edit Defined Services)链接进行设置管理。在这里我们选择最后一个选项，IIS宿主WCF服务类型实例。并把远程宿主连接地址改成你机器安装的地址，保持端口80设置。确认点击添加连接后，点返回按钮返回连接管理界面。
注意，在连接管理界面我们可以看到有2个连接被添加进去了，这是因为基于2.0的ASMX和3.0的WCF被实现在同一个IIS宿主应用程序中，通过配置服务返回所有的连接类型。然而只有一个是当前被激活并使用的访问模式类型(在页面上用绿色高亮显示)，接下来我们通过Configuration链接返回到设置主页面。
在这里我们可以看到出现了一个在线的已连接远程服务配置区，现在你可以使用一个StockTrader网站用户登录到实际的StockTrader网站(不是配置网站)，你在此之间的所有操作活动都将发生在远程业务逻辑服务实例中，而不是默认的进程内服务实例。当然你是觉察不到此变化的。
接下来我们将实现配置业务逻辑服务内部远程调用，通过一个中间第三层订单处理将通过独立的服务实例实现。如何配置订单处理我们将通过配置主业务逻辑服务来实现。这里我们将不再直接使用Web应用程序配置，因为订单处理服务属于业务逻辑服务层的扩展，Web应用程序不能跨层操作，订单处理服务逻辑相对于Web应用程序逻辑是看不到的。
选择IIS宿主业务逻辑服务实例为首节点，接下来你会看到主设置界面变成了IIS宿主业务逻辑服务实例配置主界面，首节点总是在页面的左侧，而远程连接服务总是在页面的右侧。接下来的配置过程基本上和Web应用程序从新配置并激活远程主业务逻辑相同，不同的是现在将配置IIS宿主业务逻辑实例通过远程调用订单处理服务。
我们可以通过配置主业务逻辑服务的订单模式来实现这一目的，点击上图红圈的链接进入具体设置界面。主业务逻辑可以有多个不同的订单处理服务模式实例供选择，在订单模式选择栏中选择修改值进入具体修改页面，我们选择Async_Msmq，也就是连接事务性的MSMQ队列服务实例处理模式。点击更新按钮并提示更新成功。注意订单处理服务实例并不宿主在IIS中，是一个独立宿主应用程序，当然我们也可以让它宿主在IIS7以上版本IIS中。在使用StockTrader网站应用程序前，我们首先要确保主业务逻辑服务实例已经连接上了订单处理服务实例，因此首先我们需要先启动订单处理服务宿主应用程序，你可以在示例程序的安装目录下找到Trade.OrderProcessorServiceHost.exe并启动它。
在一台未使用过示例的机器上，第一次启动订单处理服务实例会自动创建StockTrader所需的MSMQ消息队列，如果启动的宿主实例的机器没有安装MSMQ Windows组件实例，订单处理服务宿主实例将无法启动(当然如果你真的需要改变订单处理服务宿主的配置设置来忽略此限制，你可以通过service/ConfigWeb来实现)。
这样以后，要来实现主业务逻辑服务实例调用远程订单处理服务实例 ，是通过在主业务逻辑服务配置中添加远程订单处理服务连接来实现的。要达到此目的，在配置网站(ConfigWeb)重新回到连接管理界面。在网站应用程序连接管理界面，通过配置系统的中间连接特性我们可以直接进入主业务逻辑服务连接管理界面，通过上图红圈标记的链接进入。
同样点击上图红圈标记的添加新连接按钮，接着你可以看到默认的订单处理业务逻辑连接选项。输入你计算机的名称或地址，订单处理配置服务将通过http在端口9002上监听。点击添加按钮提示操作成功，点返回按钮回到连接管理界面查看活动连接。注意如果你直接点击Connections链接，你将会直接返回到StockTrader网站应用程序连接管理界面，然后你需要重复上述进入过程来查看主业务逻辑服务的活动连接。
在主业务逻辑服务连接管理界面你将可以看到有多个活动连接实例，这是由于订单处理服务宿主同时运行着4个不同协议的服务实例的的缘故。进一步我们可以任意改变OrderMode的设置从而实现主业务逻辑服务实例可以使用(http，tcp，Msmq-transacted queue, Msmq-in-memory-queue) 它们中的任意一种设置。在所有的情形下，订单处理服务不仅仅是远程的，它们还将在主业务逻辑服务中被异步的处理(因为所有的订单处理服务契约都被定义成单向的)。
最后点击配置(Configuration)链接返回到配置网站(ConfigWeb)首页，初始你将重新回到网站应用程序做为首节点的情况下。
通过点击上图红圈标记的链接，你可以选择主业务逻辑服务作为首节点。 主业务逻辑服务在左侧，新添加到远程订单处理服务连接在右侧。
同样的你也可以更进一步扩展服务层，把订单处理服务实例作为首节点，从而配置它的设置。通过完成以上的配置后，你现在可以使用一个StockTrader网站用户，尝试着去下订单，当然整个订单处理流程将按照你配置的架构来执行。
1.网站应用程序通过http Web服务同步的提交一个请求到远程IIS宿主主业务逻辑服务实例。
2.IIS宿主主业务逻辑服务实例在数据库中创建一个订单头信息，并把订单详细信息通过消息机制异步的提交到远程订单处理服务实例，用于处理订单。
3.订单详细信息消息并没有直接发送给订单处理服务宿主实例，而是通过WCF MSMQ绑定机制实现松散绑定。通过MSMQ自身的特点我们可以MSMQ消息队列部署到其他远程服务器上或者在同一台机器上的其他独立服务宿主实例。
４.WCF底层基础架构将会自动通知宿主应用程序(Trade.OrderServiceHost.exe)，从而触发服务契约方法处理订单。
5.订单处理服务通过把订单事务性的回放处理，并把处理后结果保存到数据库中。当订单处理完成后在网站应用程序中的用户将会得到通知。
6.如果数据库部分的处理逻辑失败，分布是事务将会自动回滚，事务性队列中的订单信息也不会丢失。如果事务性队列被强制设置成按序执行，它将在一个延时的机制下被自动重试N次(主要基于WCF服务的绑定设置)。如果还不能被成功处理，它将会自动发送到有害队列中，不会干扰到正常处理，同时也保证消息的不丢失(注意有害队列只在MSMQ4.0版本中才存在)。