严格的、难于管理的应用程序

    在应用面向服务原则之前，许多老式的应用程序有同样的易管理问题。首先，LOB应用系统在前端应用程序尝试同时访问时可能会失败，还有在中间交易网络出现存储损耗时和数据格式化错误时都可能失败。当一个对应用的请求失败时，应用程序不会给出错误信息，并且系统不能够被彻底的关闭和重新重启（在适当处）。从一个运作观点来看，错误调试没有恰当的错误信息确实是一个挑战。而且，由于商业逻辑和商业流程的高度联系性，这种结构不能够利用新的技术。自从微软技术中心的商业突出为端到端的、更好的相连的模式时，这种模式在新技术和实际中是出类拔萃的。

    最后，LOB应用程序是严格的、难于管理的，运作小组在一种连续的反应模式中，试图保持这些共享资源的工作，但是对于“系统不论什么时候，都不会出问题”却没有任何真正自信。

    解决方案视角

    微软技术中心开始的时候就有一个信念，认为面向服务的构架能够使各种LOB应用系统变得更加容易集成综合，提高稳定性，在错误调试时能够提供有意义的错误信息。基于这种理念，他们建立了一种约束和需求，使它们能够满足任何建设性构架。

    最重要的目标是集成已经存在的大型主机和中介系统应用程序，应用程序有更加高效的交互性，同时也能够保持灵活性和协同工作能力，有一个基于标准的部件。形成面向服务解决方案的约束有如下一些：

    所有的公共接口都必须是Web服务，目的是：

    使所有的集成实现的时候都是同一种风格，不依赖于局部装配
    外部的开发者通过已经定义好的访问点（绑定），能够独立集成解决方案。
    外部的开发者通过已经定义好的一致模式，能够独立集成解决方案。
    对于详细的外部应用程序和结构（像网络），错误信息必须是有用的，而且是一致的、可预测的。
    为了促进交互和错误调试，必须要有一个端客户端到端的可靠的消息分发机制（在恰当处）。
    由于客户层频繁的改变，必须要支持松连结的客户端集成。

    面向服务的解决方案

    图 2 关于Redmond 设备资源共享的SOA解决方案

    所有在暗绿色区域的部件都表示新的或者已经改变了的部件。可以注意到作为一种原始的解决方案的回复服务器已经被微软的语音服务器所替代，它是一种用来配置和管理分布式语音应用程序的工具。简而言之，在一系列的Web服务和BizTalk流程组织之后，面向服务的解决方案概括了所有的资源共享。

    一个前端应用程序，比如一个订单表（上面已经描述了），发起一个交易通过发送一个XML格式的订单发到BizTalk流程组织。该流程组织检查这个订单，这个新的订单详细信息被发送到另外一些Web服务上并且执行这个商业流程，这些Web服务是和各种不同的LOB应用系统交互的。关键是面向服务的解决方案，仅此面向服务的解决方案直接和LOB应用系统交互。因此，在订单到达LOB应用系统之前Web服务能够拒绝坏损的格式化订单，解决一个共性的问题（微软技术中心以前遇到这个问题）。而且，由于BizTalk Server 2004的这个商业流程组织是异步的，多路订单能够同时到达和处理，而不需要查找LOB应用系统。

    最后，当那些很少出现的错误和异常发生时，不管是否在LOB应用系统层、在网络层、在主机集成层或者流程组织层，关于这个事件的丰富信息能够通过Web服务传播到操作小组，在这些地方利用微软的操作管理(MOM)来分析是可控的、可行的。