为了举例说明SOA的价值，本文描述了微软公司的一些步骤，这些步骤讲述了微软技术中心在应用程序集成方面所遇到的一些重要挑战，这些挑战和大多数公司所遇到的是类似的。伴随着我们探究这些挑战，揭示其深层次的原因，找到一种方法，这种方法能够使面向服务的解决方案技术迅速改进操作效率和提高同各种LOB应用系统相互交互的能力，那么SOA的前景将变得清晰。 本文同时讲述了微软技术是如何为面向服务解决方案技术中的一些重要的功能提供服务的。例如，Microsoft Host Integration Server 2004将基于IBM大型主机与中阶系统的应用系统当成基于Microsoft .NET的Web服务来处理，这种Web服务带有能够满足Windows应用的全部功能。这些功能使系统变得更加具有协同能力，同时为错误报告和错误处理提供了一种更好的解决方案。利用Microsoft BizTalk Server 2004去管理商业流程组织，微软技术中心能够控制商业流程，比如，在提交给应用程序之前进行错误数据检测。在下面详细的描写中，你将看到其他一些解决方案的原理，包括一般的和基于微软的。
当微软公司坚定地相信选择去实施面向服的构架是一种商业决定而非一种技术决定时，你所采用的技术仍然很重要。本文将讲述在这个快速开发、快速集成和管理的时期，微软的技术能够更好的帮助你解决目前所面临的挑战。比如，通过采用微软的开发技术和中间层技术，整个面向服务的解决方案(如下所述)能够在2个人月里完成。
绪论
微软技术中心 (MTCs) 给用户提供了一个环境，供其去想象、构思，同时通过微软及其合作伙伴的技术得到一种解决方案，这种技术优先配置在用户自己的IT环境中。当微软公司技术中心这一商业组织去推广其服务时，它和它的13个遍及世界的技术中心像其他企业一样运行，关心所有的方面诸如可用性、安全性、稳定性和可管理性等等。
全球的微软技术中心组织机构设计成为了一个真实的企业环境。像其他公司一样，围绕着微软技术中心最主要的挑战是很多老式应用程序已经不再使用微软的技术来开发，并且前端的应用程序已经不在Windows平台环境下运行。确切地说，每个地域都有它们自己的构架，在总局主要访问一组LOB应用系统(比如在Redmond中)。在总局和分局里，它们通过前端应用程序来为主要的商业流程实现资源共享。
伴随着各个地方交易数量的增长，如何给那些总局提供可靠的资源共享变得日益困难。比如，一些运行在中阶系统(Report Program Generator)和大型主机系统(COBOL)的应用程序在过去设计时并不能提供多路访问。结果，很多分局运行应用程序时会遭遇死锁和间歇性失败，并且没有任何出错原因提示和问题来源提示。当这些问题产生时，总局将要经历一个艰难的过程去管理这些应用程序和修复问题，尤其那些原始的开发者不在的时候。
为了不重新构建所有的微软技术中心的演示环境的LOB系统，管理小组决定检查已经存在的综合集成需求，同时优化介于LOB应用系统和前端应用程序的集成层，这样做有如下好处：
通过允许多前端应用程序同时访问LOB资源，并且有商业流程来彻底处理失败的业务来改进系统的稳定性。
◆通过提供可控的错误信息，减少了错误调试时间。
◆通过良好的监控器能够避免问题的发生
◆定义了一致的契约信息
◆定义了一致的绑定信息
挑战
总的来说，微软技术中心使用相同的系统来进行运作，作为一个典型的公司也拥有挑战。为了更好的了解微软技术中心所面临的一些特定问题，我们将利用其拓扑结构来讨论。
一个全球性的组织结构
微软技术中心的组织结构体现了一个虚拟中型的零售产品制造商的组织结构，在这个系统里完成接收订单和分发订单。每个分局都有一个需求组织结构(区域控制器，消息服务器，Web服务器，SharePoint 组织结构等等)，这个需求组织结构用来初始化一个订单和与订单进行交互。如图1 所示，总局有中阶系统(iSeries) AS/400 server(基于仓库应用程序为RPG服务)，大型主机zSeries 890 server(基于托运应用程序为客户信息控制系统服务[CICS])，RS/6000 UNIX server(基于执行应用程序为WebSphere服务)，还有一个土生土长的运行在Windows上的回复应用程序。
图 1. 全球组织结构
基于这个组织结构，每一个分局通过访问共享资源来演示多种逼真的商业流程。一个重要的商业流程包括分局利用Web应用程序或者InfoPath 2003 form(InfoPath实际上是一个超强的Form表单设计和信息处理软件)来初始化一个订单。通过LOB应用系统，这种活动初始化了一个复杂的商业流程。比较基本的商业流程如下所示：
1.一个分局将订单发送到运行在中阶系统上的仓库应用程序。
2.仓库用户利用IBM 5250 Emulator 去查看订单，并且把订单的状态从新建改为已分配。
3.一个灵敏的挑选应用程序接收到了一个挑选请求。
4.仓库工作人员执行挑选活动，并且承认该项已经被挑选了。
5.订单状态信息在仓库应用程序上改为已经挑选了。
6.仓库工作人员更新订单的状态信息，从已经挑选了改为已经托运了。
7.大型主机托运应用程序收到了托运请求，该托运请求可以用IBM 5250 Emulator 来进行校验。
8.WebSphere执行应用程序 收到了执行请求。
9.回复服务器通报买方该项目将会在规定的时间内托运到。
严格的、难于管理的应用程序
在应用面向服务原则之前，许多老式的应用程序有同样的易管理问题。首先，LOB应用系统在前端应用程序尝试同时访问时可能会失败，还有在中间交易网络出现存储损耗时和数据格式化错误时都可能失败。当一个对应用的请求失败时，应用程序不会给出错误信息，并且系统不能够被彻底的关闭和重新重启(在适当处)。从一个运作观点来看，错误调试没有恰当的错误信息确实是一个挑战。而且，由于商业逻辑和商业流程的高度联系性，这种结构不能够利用新的技术。自从微软技术中心的商业突出为端到端的、更好的相连的模式时，这种模式在新技术和实际中是出类拔萃的。
最后，LOB应用程序是严格的、难于管理的，运作小组在一种连续的反应模式中，试图保持这些共享资源的工作，但是对于“系统不论什么时候，都不会出问题”却没有任何真正自信。
