面向服务的解决方案提供一个信用余额报告应用程序，该应用程序设计为服务。 应用程序反过来又使用作为服务本身公开的三个后端应用程序来获取信用余额所需的信息。
面向服务的体系结构（SOA）是一种在构建分布式系统时部分涵盖的的方法。 面向服务的方式具有以下特征：
松散耦合。 应用程序的业务逻辑与处理服务的逻辑分开。
易于发现 应用程序应有一种查找服务的机制。
合同性的 服务的接口实现用户与服务之间的协定。
虽然文献通常将面向服务的方法视为 Web 服务的同义词，但它们不一定是同义词。 Web 服务提供了实现面向服务的解决方案的有吸引力的方法，但你可以使用其他技术（如 .NET 远程处理）来创建服务。
读者指南
此解决方案的文档假定你熟悉 BizTalk Server 和 Microsoft Visual Studio。 它还假设你了解有关企业应用程序集成和 Web 服务的基本概念。
此外，若要阅读并遵循开发人员文档，应熟悉如何使用 Visual Studio 和执行以下任务来生成应用程序：创建项目、设置引用和调试和测试 BizTalk 解决方案。
Woodgrove Bank 的信用卡报告
面向服务的体系结构解决方案是 Woodgrove Bank 的信用卡余额报告服务。 虽然银行是虚构的，但方案不是 -- 方案基于实际部署的客户应用程序。
在这种情况下，信用卡余额请求来自两个来源：
交互式语音响应（IVR）应用程序。
交互式客户端，例如网页或自定义客户端应用程序。
该解决方案通过 MQSeries 从 IVR 应用程序接收请求。 它使用 HTTP 和 SOAP 通过 Web 服务处理来自交互式客户端的请求。
新兴服务导向架构的应用程序通常需要与使用旧技术的传统应用程序进行交互，也需要与使用新兴技术的现代应用程序（如利用网络服务的网站）共同运行。 此方案为实际要求建模 - IVR 应用程序表示旧应用程序，而客户服务客户端应用程序是现代应用程序。
Woodgrove Bank 应用程序使用来自三个后端、旧系统的数据来响应请求：
提供整体信用额度限制的应用程序。 这是大型机计算机上的 SAP 系统。
一个待处理交易系统，用于报告针对帐户待处理交易的总金额。 此系统是大型机或 AS/400 系统。 该解决方案使用 Web 服务和 Microsoft Host Integration Server （HIS） 与大型机或 AS/400 系统通信。
一个支付跟踪系统，能够显示系统中最近一次的付款记录。 可以使用 MQSeries 访问付款跟踪系统。
从旧系统收集和编译信息后，解决方案会将响应发送回原始应用程序，从而发送给客户。
业务要求
由于信用报告应用程序实时响应客户请求，因此它必须具有较低的延迟才能快速处理请求。 此外，它还必须能够处理大量同时请求。 解决方案使用敏感信息和公共接口，以便安全非常重要。 最后，服务需要可靠。
有关解决方案如何满足这些要求的信息，请参阅 开发面向服务的解决方案。
性能特征
为了满足业务需求，方案具有以下性能特征：
每秒能够处理 40 个传入请求的持续吞吐量。
每秒 100 个传入请求的峰值吞吐量。
90% 的请求（包括 BizTalk Server 内部和外部）需在 1000 毫秒内完成处理。
95% 的请求需要在 2000 毫秒内处理（适用于 BizTalk Server 的传入和传出请求）。
100% 的请求，无论是传入还是传出 BizTalk Server，都需在 5000 毫秒以内被处理。
注释
这些时间不包括后端系统的延迟时间。
解决方案的三个版本
解决方案有三个版本：
存根版本将所有后端系统替换为软件存根。 存根模拟后端系统。 此版本提供了在单个计算机上部署和运行解决方案的快速方法。
适配器版本使用 BizTalk 适配器连接到后端系统。 此版本是人们首先考虑如何实现解决方案。 但是，使用适配器将消息发送到后端系统会导致回发响应时出现重大延迟。 虽然适配器本身可以提供非常低的延迟，但 BizTalk Server 的分布式体系结构要求适配器使用消息框与业务流程主机实例通信。 这会引入数据库的往返请求，并影响延迟。
内联版本将适配器替换为直接与后端系统通信的内联代码。 解决方案的内联版本具有最低的延迟和最高的吞吐量。
部署指南提供了构建和部署解决方案的所有三个版本的指导，以及在每个版本中通过 HIS 模拟与挂起事务系统连接的方法。 有关生成和部署解决方案的信息，请参阅 “部署面向服务的解决方案”。