面向服务及其在互联系统策略中的角色

　　面向服务是一种创建分布式系统的方法。在它最抽象的层面，面向服务作为一个服务提供程序，包含了一切——从大型机应用程序到打印机到码头工作人员到隔夜交货公司。服务提供程序通过接口公开了功能。面向服务的体系结构与这些功能和接口进行了映射，这样它们就可以编制到流程里。这种服务模型是“不规则的”：新形成的流程本身就是一个服务，它公开了一种全新的聚合功能。

　　这种服务模型的基础是接口与实现之间的分离。服务的调用者只需要(只应该)了解接口;实现过程可以随着时间而发展，而不会干扰到此服务的客户。有趣的是，许多实现工具都可以提供相同的接口;面向服务的几个关键利益来源于从如何提供功能的角度对功能进行抽象化。

　　对，这就是面向服务。那么面向服务都对谁有帮助呢?

　　看到一个鸡蛋，农民可能会想到一只小鸡;厨师可能会想到一盘煎蛋卷;小孩可能会想到一个五光十色的复活节装饰品。面向服务就是一个鸡蛋。

　　对于开发人员和解决方案架构师而言，面向服务是一种创建动态的协作应用程序的方法。通过支持运行时选择的功能提供程序，面向服务允许应用程序对特定业务流程的内容和环境具有敏感性，并随着时间的推移适度地合并新的功能提供程序。

　　对于IT经理而言，面向服务是一种有效的集成现代企业数据中心的各种典型系统的方法。面向服务提供了一个模型，可将多个系统的信息和业务逻辑聚合到一个单独的接口中，这样就可以通过通用的、一致的接口集处理各种冗余的系统。

　　对于首席信息官而言，面向服务是一种在不禁止部署新功能的情况下保护现有IT投资的方法。通过在基于功能的接口之后封装业务应用程序，该服务模型允许对关键任务应用程序进行控制性访问，同时它还创造了在此接口之后持续改善实现过程的机会。面向服务使投资避免了纷繁的变化。

　　对于业务分析师而言，面向服务是一种使信息技术投资更符合业务策略的方法。通过将员工、外部功能提供程序和自动化系统映射到一个单独的模型中，分析师可以更好地理解与人、系统和来源的投资相关的成本权衡。

　　对于Microsoft Corporation而言，面向服务是创建互联系统的一个重要前提。互联系统属于应用程序，它们可利用网络来链接推动业务流程的执行者和系统。你可以在一种特殊的应用程序模型上构建互联系统，这种模型超越了任何设备，适度地跨越了边界，并抑制了同步性的限制。通过将一系列服务和设备集中到了一起，互联系统可以比过去的分离的应用程序更有效地应对业务挑战。

　　企业的IT部门需要获得更深入的业务活动洞察，在此需求的带动下，它们正在寻找有效、简便的方法来集成它们的应用程序组合。其目标是透明性和一致性：

　　•对于我们的客户和业务关系，我们是否具有一致的观点(它能够让我们以最佳的方式服务于它们的需求和呈现我们的产品)?

　　•我们所有的业务流程是否都符合组织要求和政府规定?

　　•我们的系统是否能够针对我们的业务目标有效地提供价值?

　　•我们的技术投资能够实现一般任务的自动化，并对我们的员工的工作进行配合，从而克服复杂的挑战，这能否使我们最大限度地提高生产力?

　　为了实现透明性和一致性，组织必须创建各种连接机制。它们必须连接系统，以创建一致的信息管理程序。它们必须连接人和技术功能，以创建一致的业务流程。它们必须连接工作人员，以创建协作的工作团队。它们必须连接组织，以创建有效的价值链。

　　通用的功能调用模型是面向服务的重点，而面向服务是有效的互联系统策略的核心。

　　服务和互联系统

　　在计算机组件模型的环境下，服务是一种通过交换消息进行通信的程序。换句话说，服务是一组应用逻辑，它接收和发送的消息完整地定义了它的接口。

　　通过以可扩展标记语言(XML)为基础开发消息标准，面向服务正迅速成为构建互联系统的主流方法。

　　在连接各种不同的系统的过程中，其固有的挑战是特定平台的信息和过程模型的转换。在理想的世界里，我们将拥有：

　　•标准语法，在此可以明确地表达来自所有系统的信息。

　　•标准语义模型，各组织可以通过一种一致的语言表达它们的业务实践方法。

　　•标准协议，可以跨越操作环境和组织之间的边界传递信息。

　　•标准方法，用来绑定行为和业务文档。

　　在理想的世界里，我们的所有系统都将说这种“世界语”(除了它们自身的语言之外)，这样它们就可以在它们的本地环境之外进行通信。

　　XML、XSD、WSDL、UDDI以及WS-*规范，比如WS-Security和WS-Policy，是这种不断发展的通用语言的第一批模型。

　　以广泛支持的标准为基础的虚拟平台提供了互操作性，如果没有这种互操作性，面向服务就将是一门需要大量的协议设计专业知识的晦涩难懂的学科，同时它也将是一种不可靠的投资回报。如果没有Web服务跨越各种异类平台连接你的企业功能，面向服务对你和你的组织的价值就将大幅度减少。

　　客户端是互联系统的一个非常重要但是却经常受到忽略的元素。服务只有在受到调用时才会引起注意。不同的交互要求需要支持各种不同的客户端模式。Web服务的客户端包括：

　　•具有丰富用户体验的智能应用程序—它们是具有以下特性的解决方案：与一个或许多服务进行交互;对它们检索的信息进行智能缓存;既提供了良好的交互性，又对离线信息处理提供了支持。

　　•智能设备—它们是包括以下范围的解决方案：从自助式电话亭到手持式库存跟踪技术到智能电话联系人管理。

　　•Web用户界面(UI)—它们属于企业门户解决方案，这些解决方案对业务与员工和组与组之间的交互进行了统一和协调。

　　•自动化系统—它们属于客户端，这些客户端一般不呈现UI，除非需要引发异常。

　　•流程编制服务——它们是调用其它服务来提供聚合的功能的服务。

　　不断发展的Web服务标准和实现它们的平台必须支持客户端驱动的概念，例如缓存杂注、资源约束设备的页响应以及长期运行的交互过程的对话环境管理。

　　即使面向服务的热情支持者对于该模型的范围也无法达成一致。争论主要集中在以下问题上：“面向服务的基础还有什么?”(“你想用这些鸡蛋做什么?”)下面让我们探讨与此争论相关的几个服务友好的概念：

　　•企业体系结构—对组织的目标、优先级、资源和流程进行系统建模，以实现有控制的改进所需的自我意识。

　　•企业信息集成—为业务实体(复杂的“类型”，例如“客户”、“员工”和“采购订单”)创建一套组织标准，它们由你的应用程序组合进行操作。

　　•面向流程—使业务流程成为你的企业体系结构和信息技术组合的设计重点。

　　•业务流程编制—这种模型可支持灵活的业务流程，因为它们能够使流程中的步骤排序尽可能地实现轻便性和适应性。

　　•事件驱动的体系结构—在这种模型中，业务事件(例如，部件到达码头或对发票付款)可触发消息发送到订阅服务，这样它们就可以采取适当的措施。

　　•虚拟企业—将业务流程视为价值链，这种价值链能够跨越组织进行扩展，这样每个组织就可以集中精力开发其核心功能，并将非核心功能外包给外部服务提供商。

　　•面向方面—提供了一种一致地处理横切关注点(例如，业务活动监控、服务访问控制和消息传递的可靠性)的方法。

　　•基于人员的工作流管理—协调信息工作者和他们与业务流程的交互作用，以提高效率并实现对客户需求的响应。

　　•非居间化—跨越业务边界自动交换非异常信息，以消除信息工作者执行常规任务的需求，例如，通过书面(传真、邮件、电子邮件)或口头的信息交换进行数据输入。

　　•灵活性—这种系统的设计是为了响应业务请求的特殊环境和内容，以及业务要求和业务策略的更广泛的变化。

　　•模型驱动的开发—通过高级(通常是图形化的)语言驱动解决方案的开发流程，这种语言与正在实现自动化的业务流程进行了更紧密的绑定(例如，与Visual C#相比)。

　　Microsoft将灵活性和面向方面视为面向服务在业务和技术方面取得成功的关键因素;在本论文中，将不断地围绕这些主题进行讨论。不干预性是面向服务解决方案的一个非常普通的目标，因此它可能被视作该体系结构的一个隐含收益。其它任何概念都是对面向服务的补充，它们可能(或不会)对你的互联系统策略起到关键作用。

　　你的互联系统策略需要成为一种应对机会和难题的标准方法，它们保证了你的IT投资的最佳回报。服务和支持模型的交换使用是无限制的，但是发展的实例应该证明它具有启发意义。

　　第一步：爬

　　Typhoon Taylor是Rum Island Industries(RII)的信息枢纽。每份订单和发货报告都要经过他的办公桌，他必须确保数据输入到了主机里。但是，在RII被Worldwide Spirits(WWS)收购之后，Typhoon发现他必须将相同的信息输入到RII操作系统和WWS企业资源计划(ERP)系统中;不同的信息模型不断地造成数据输入错误，它们导致了两个系统之间的数据不一致。

　　Typhoon与他的IT搭档Daiquiri Jones讨论了这种情况。Daiquiri不想破坏主机应用程序，但是她又无法获得WWS ERP系统的修改权限，因此她建议在两个系统之前添加一个服务层。

　　通过与Typhoon合作，Daiquiri定义了一个PurchaseOrder(采购订单)文档，它包含了该操作系统或ERP系统需要的全部信息，同时它又对二者都需要的公共元素进行了映射。然后，Daiquiri将这份草案交给会计部门的Hurricane Harris和客服部门的Salty Robinson过目。根据他们的反馈意见，她又在PurchaseOrder架构上添加了若干元素，以便支持Hurricane和Salty的需求。

　　通过再次与Typhoon合作，Daiquiri确定了两项服务：

　　•NewOrder(新订单)：接收采购订单文档，并更新两个后端系统。

　　•ProcessShipment(进行发货)：接收Shipment(发货)文档，将它与订单相关联，然后更新后端系统。

　　通过利用DB2数据库和WWS ERP系统现有的适配器，并使用ASP.NET为Typhoon迅速编制一个用户接口，Daiquiri在BizTalk Server 2004中实现了这些服务。

　　Typhoon非常高兴。此后，他只需要输入一次数据，而且信息不一致的问题也解决了。

　　第二步：走

　　然而，Salty和Hurricane却刚刚开始感觉到麻烦。

　　由于运输途中海浪很大，经常会打碎几个瓶子，每当出现这种情况时，Salty就不得不处理客户的投诉。面对各种不同的系统，Salty甚至不知道该从哪里提取客户数据;另外，在客户需要紧急更换货物时，他必须与Typhoon协商酒产品脱离包装线的改向问题。

　　对于Daiquiri来说，为Salty提供Typhoon用来检查订单完成情况的GetPurchaseOrder (获得采购订单)接口非常容易，但是Typhoon坚持认为，在没有他的批准的情况下，Salty无权擅自更新订单。因此，Daiquiri为PurchaseOrder业务服务定义了一套角色，并将Salty映射为“读取者”的角色。

　　Daiquiri还拟订了一份新的CustomerCredit(客户信用)提案，Salty可以用它来处理关于产品破损的投诉，但是当Hurricane看到这份文档时，她变得非常愤怒。这份提案根本没有考虑到Sarbanes-Oxley的合规性问题。“我们作为一家固定而松散的私人公司的日子已经结束了!”她咆哮说。因此，通过使用WWS会计部门已经采用的架构，Daiquiri又重新确定了CustomerCredit文档包含的各项元素，并收入了RegulatoryCompliance(合规性)元素。

　　在发货过程中重新排列客户的优先次序变得更加复杂，但它也是一次解决问题的机会，在Rum Island(拉姆岛)，长期以来这个问题一直限制着生产力的发展，客户对这个问题也非常关心。

　　通过与Typhoon、Salty以及发货部门的Mojito Moore进行合作，Daiquiri重新设计了Shipment的架构，以包含对于Customers(客户)和PurchaseOrders的绑定。然后，她为Shipment文档实现了一个优先级队列，这样Mojito就会知道下一个离线的集装箱应该发往哪里。(Mojito被映射为队列接口的“写入者”角色，因此他可以根据离港的货船来优化队列。)

　　Daiquiri定义了一个工作流，当Salty调用ReprioritizeShipmentQueue(重新排列发货队列的优先次序)接口时，此接口会把相关请求发送给Typhoon审核，这样工作流就会得到实例化。

　　以前的某些工作流程需要手动完成，这会牵涉到Typhoon、Mojito和Salty之间的不准确通信，而现在，这种工作流程可以非常顺利地进行。当然，每当Typhoon否决了Salty的一个请求时，Salty还是会发脾气。

　　第三步：跑

　　当Daiquiri的预算再一次被削减时，她意识到她必须拥有找到资金的创造力。她投入大量资金购买了一条通向WWS的长途电缆，但是这条电缆每天只有几百KB的电子数据交换(EDI)流量。如果……

　　在WWS总部，Martini Wilson已经创建了可提高EDI流量的XML架构;他需要它们将传入的EDI消息转换为符合《美国爱国者法案》(USA PATRIOT Act)的数据包。通过使用加密的Web服务调用功能，而不是使用专用的EDI电缆，WSS的大部分子公司都可以降低成本，他同意这一点，因此他实现了一项可将请求映射到EDI处理管道的网关服务。

　　通过利用她的新基础结构和专业知识，Daiquiri还向Rum Island的甘蔗供应商推荐了一组服务接口。Beachcomber Perry是这项服务的受益者之一，他感到非常兴奋;他已经厌倦了整天与种植园主和船长在电话里打交道。当然，Mojito也参加了这项活动。通过使用这种改善的信息，他可以安排相同的货船来运糖，以便酿酒。Rum Island的库存管理从没像现在这样好过。

　　某些种植者和船员对这种变化进行了抵制，但是这仅仅意味着他们以后在Rum Island看到的业务将越来越少。