面向服务及其在互联系统策略中的角色-UML软件工程组织-火龙果软件

UML软件工程组织

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

作者： Mike Burner 出处：微软

本页内容

	面向服务的业务环境
	面向服务的技术
	创建面向服务的解决方案

面向服务的业务环境

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

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

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

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

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

对于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看到的业务将越来越少。

返回页首

面向服务的技术

Microsoft对于面向服务的投入

1999年9月，当时的Microsoft总裁(现在的首席执行官)Steve Ballmer首先公开探讨了“软件即服务”的挑战，并第一次引入了Web服务的概念。随着Internet的成熟，一种新的编程模型很快就会出现，这一点很明显；在这种模型里，软件组件将可以跨越广域网、跨越平台、跨越组织边界进行调用。到底是什么使这种编程模型成为了一种值得信任的业务应用平台？

2000年6月，这种新兴的策略获得了一个名字：“Microsoft .NET”。

紧接着是一段调整期，与Microsoft有关的组织纷纷对自身进行调整，以应对.NET提出的新挑战。出现了一系列与XML Web服务相关的面向服务策略，无论是对于你现有的Microsoft产品，还是对于你的组织技术组合中的所有其它资产，它们都充当了连接Microsoft产品的一致性策略。

Microsoft认识到，为了使技术发展到与业务流程相关的下一阶段，使技术继续促进员工生产力方面的收益，必须跨越相关的边界。其中一个边界完全来自于技术人员自身的构成：各执行平台之间的边界。Microsoft致力于与其它平台供应商进行合作，以便与他们联手将这座墙推倒。

通过与BEA Systems Inc.、IBM Corp.、TIBCO Software Inc.、VeriSign Inc.以及其它技术供应商进行合作，Microsoft创建了一种流程，它可以扩展SOAP消息的跨平台功能，并实现竞争规范的合理化。这些规范以一种免除版税的方式发布到了标准的体系中。通过不断的努力，这些竞争组织达成了合作，为它们的客户提供了互操作性，这种互操作性对于实现全局消息起到了关键作用。

由于认识到了这些规范的不足——早期的标准无法在实现过程中取得互操作性，Microsoft、IBM和其他赞助商合作创建了Web服务互操作性组织(WS-I)。WS-I为Web服务标准的通用解释提供了一个论坛，这样技术客户就可以相信WS-Security的两种实现过程其实将会实现互操作。WS-I成立于2002年2月，现在它已经拥有了接近150个成员，这些成员包括了各种不同的组织机构：从系统供应商到系统集成商到解决方案提供商到保健服务提供商到政府机构。America Online Inc.、BEA、Fujitsu、HP、NEC Corp.、Oracle Corp.、SAP AG、Siebel Systems Inc.、Sun Microsystems Inc.和TIBCO都是WS-I的成员。

在此基础之上，Microsoft又将基于标准的互操作性置入了它的企业计算产品系列中。

面向服务的目前状况

Microsoft平台支持创建符合WS-I Basic Profile 1.0的服务和解决方案，同时它也支持对高级的WS-* Web服务规范进行早期的采用。

使用ASP.NET对于Web服务的支持是Microsoft平台上创建Web服务的主要方法，ASP.NET Web服务俗称为“.asmx”或“ASMX”，这是因为Visual Studio对这些可执行文件使用了这种文件扩展名。

BizTalk Server 2004允许将编制服务公开为Web服务，对于缺乏本地Web服务支持的业务应用程序，这大大加快了Web服务网关的开发过程。

在Web Services Enhancements for Microsoft .NET (WSE)中，可以使用早期实现的高级Web服务功能，例如，使用了WS-Addressing规范的复杂消息路由，以及WS-Security规范的消息级安全性。WSE是一种技术预览程序，可用于特定的客户——这些客户希望以推荐的标准为基础对技术进行实验。

对于从我们的操作系统(Windows XP、Windows Server 2003和Windows CE)和Microsoft Office系统调用Web服务，Microsoft提供了丰富的支持。

Microsoft Office InfoPath 2003是Microsoft Office系统中提供的一个新组件，它支持将图式化的表单用作包含后端服务的交互模型。InfoPath已经证明它在结构化的协作方案(从人力资源注册到合同协商)中是非常有用的。

Office的另一个新组件是Microsoft Office Information Bridge Framework (IBF)，有了它，就可以通过Web服务访问信息。IBF是Visual Studio .NET的一个外接程序，它使开发人员可以创建基于Web服务的解决方案，这种解决方案能够访问企业业务数据，例如销售额、库存数字、客户信息等等。在Word、Excel和Outlook的2003版中，可以直接查看这些信息。IBF能够让信息工作者在不离开他们熟悉的Office应用程序的情况下检索和操作信息，从而增强了他们的生产力。

Visual Studio为企业的行业应用程序提供了最佳的开发环境，它一直保留了这种传统。Visual Studio .NET支持Web服务的实例包括：

•	服务部署
•	XSD创作
•	WSDL的自动生成
•	UDDI注册
•	数据中心部署包
•	通过UDDI发现客户端服务
•	客户端服务绑定
•	服务代理的自动生成

同时，Microsoft正努力提供必要的指导，以便开发人员完善创建过程。传统上，MSDN为开发人员提供了较为完善的指导材料，Microsoft对这些指导材料进行了扩展，它以书籍、白皮书、参考应用程序和模式库的形式提供了体系结构指导。Microsoft的模式与实践门户(http://www.microsoft.com/practices/)是体系结构指导的入口，从信息设计到解决方案体系结构到解决方案建模(目的是将这些解决方案部署到企业的数据中心中)，这些指导材料包含了非常丰富的内容。

使用SQL Server 2005和Visual Studio .NET 2005实现面向服务Microsoft SQL Server 2005 (代号为“Yukon”)和Visual Studio .NET 2005 (代号为“Whidbey”)将是2005年发布的两项关键技术。

对于需要应对特殊挑战(使用Web服务设计分布式系统)的架构师，Visual Studio将引入一种新的建模画布。另外，Visual Studio还将附带两个使用了此画布的设计工具：

•	逻辑应用程序设计器，可用来对面向服务的解决方案的各个组件以及它们之间的交互作用进行建模。
•	逻辑数据中心设计器，可用来对部署服务的处理器以及这些处理器的防火墙所在的安全区域进行建模。

这些建模工具主要是为了支持解决方案架构师和系统架构师之间的初期通信，从而保证设计阶段能够完整地考虑到解决方案的操作要求。Microsoft不断地接到以下的客户反馈：由于部署问题，许多项目都延期进行，并且超过了预算；如果事先进行更好的建模，这些问题本来都是可以避免的。

双方的设计师都以系统定义模型(SDM)为目标，SDM是一种XML架构，可描述软件组件、计算机硬件、网络和交互模型。作为一种用来描述和分析互联系统的建模语言，SDM是动态系统计划的技术基础(参见下文)。

SQL Server 2005具有很多改进之处，其中之一是加强了对于XML和Web服务的支持。SQL将提供：

•	XML文档的本地存储。
•	支持XQuery搜索这些文档。
•	在XML中返回结果集。
•	将存储过程公开为Web服务。

SQL Server中的若干体系结构元素将支持面向服务的数据中心内的解决方案：

•	通知服务可用于发布和订阅信息源。
•	报表服务可执行计划的查询，并针对分析结果产生XML格式的通知。
•	SQL Service Broker可用来支持在分布式数据模型上设计的服务，包括超标量的信息存储库。

使用“Indigo”和Windows “Longhorn”实现面向服务

“Indigo”将成为Microsoft对于互操作性消息的投资的高峰：

•	它将成为Microsoft对于高级Web服务(WS-*规范)的实现。
•	它将成为Microsoft用于分布式计算(从进程间通信到跨组织的Web服务调用)的统一消息堆栈。
•	它将成为Microsoft用来开发面向服务的业务应用程序的模型和框架。

根据协定、消息、通道和服务的面向服务概念，“Indigo”将提供一个编程模型和一个消息实现程序。“Indigo”将支持更安全、可靠的交易信息交换和功能调用，同时它们应该符合各参与组织声明的交换政策。

“Indigo”技术将包含到“Longhorn”客户端发行版中，同时可供Windows XP和Windows Server 2003使用。

下一代Windows客户端(代号为“Longhorn”)将引入创新技术，它们将扩展桌面参与面向服务的业务协作的能力。

“Longhorn”将引入XAML，这是一种基于XML的标记语言，可用于智能的Windows应用程序。与HTML一样，XAML使用了一种描述UI元素的声明语法，相对于过程声明，它可以非常容易地通过编程方式进行生成和分析。这种创新将允许用户接口更好地反映它们表示的信息，这是因为UI能够基于交互状态以编程方式生成。

WinFX完成了到Windows中的托管代码的过渡，这种过渡是从2002年Visual Studio .NET的引入开始的。WinFX是下一代的系统编程接口。在面向服务方面，WinFX统一了Microsoft的多个消息模型，以检索自Web服务的信息为基础对代码访问的安全性提供了支持，并向应用程序开发人员公开了“Indigo”消息堆栈的功能。

通过动态系统计划(DSI)，Microsoft正在努力提高IT的生产力，并降低与面向服务的系统的设计、部署和分布式操作相关的成本。作为此计划的一部分，系统定义模型(SDM)是一项核心技术，通过为应用程序、系统和交互操作定义通用的语义，它使面向服务的规则可以应用到系统管理中。通过使用这种通用的领域特定语言，应用程序可以表达它们的技术要求，比如CPU周期、内存容量和存储容量，同时系统还可以对其资源进行描述。这种新的建模技术将能够使业务更迅速地推出面向服务的应用程序，这种应用程序更容易部署，管理费用也更低。DSI是Microsoft和业界共同努力的结果，它将对软件开发工具和应用程序、操作系统、管理解决方案及硬件平台产生深远的影响。欲了解DSI的详细信息，请参见http://www.microsoft.com/dsi/。

返回页首

创建面向服务的解决方案

并不是所有的Web服务都是平等创建的。一个鸡蛋可能变成美味可口的蛋奶酥；但是如果将它放在荷兰辣酱油上，就将变成一次让人反胃的品尝；或者，如果掉在了地上，它就会变成一团粘糊糊的东西。每个人都可以通过服务构建任何事物：好的，坏的，或丑陋的。

在策划企业服务组合时，需要面对三个基本的挑战：

•	面向服务的分析—为了支持组织的业务优先级，应该创建哪些服务？
•	服务设计—应该怎样创建每项服务？
•	服务管理—为了支持业务服务，应该部署哪些基础结构服务？了解和处理异常需要哪些支持？

本章节将探讨所有这些挑战，并进行总体的指导，告诉你现在应该怎样做才能获得面向服务带来的直接收益；同时，它还为你提供了一些提示，这样你就可以预测完成互联系统策略所需的未来投资。

面向服务的分析

面向服务的体系结构是组织机构业务流程的建模艺术，同时它也是网络可寻址的业务组件的结构完善的组合。

真正的挑战来自于那个看似平常的修饰语：结构完善的。在确定对组织功能的建模起关键作用的信息集(请将它作为“结构化业务文档”的一个令人讨厌的同义词来阅读)和行为时，总有一种“翻江倒海”的诱惑——设法为组织的所有行为创建一个完整的自上而下的视图，并在一个一致的企业体系结构中对其进行建模。同时，那些需要解决方案的业务单位目前正通过技术和业务流程重组投资而迅速发展。

“权宜之计”是一个强大的动力。利用它，但是也要对它进行适度的控制。在不断的尝试中学会爬；在不断的交流中学会走；在不断的协作中学会跑。

应该怎样权宜性地定义一个服务组合呢？这里有几个原则。

设计长期稳定的服务，设计灵活应变的系统

在一个企业服务体系结构中，功能服务是构成业务流程和业务系统的组件。对服务接口进行建模，从而紧密地结合业务功能模型，这是一个重要的最佳实践方法。例如，大多数制造商都有接收订购请求的业务需求；定义一个描述订购请求的信息集和一个接收此信息集实例的终点，即可构成一个井然有序的服务范例。

业务流程远比它们处理的信息不稳定。在流程中，操作者(人)的判断甚至是一时冲动都会对处理操作造成很大的影响，同时各种服务异常情况也会对业务实例造成干扰。每个业务流程实例都可以构成一条穿过你的服务组合的唯一路线。

因此，系统必须具有灵活性。流程的编制应该易于修改，甚至是完全动态的。对于成功的业务系统而言，将硬编码的业务流程排入已编译的可执行文件是一种反模式。

事件驱动的体系结构的概念对于有效的流程设计具有指导意义。流程应该能够洞察推动其发展或使其脱离正常路线的业务事件。当异常事件使某个流程脱离正常的轨道时，应该努力使流程恢复正常，并使其返回主要的轨道；如果对整个流程进行人工监控，将导致流程成本的激增，甚至远远超过流程本身带给组织的价值。

从全局着眼，从局部着手

大多数组织都拥有几个(也许多达10个)关键实体，这些实体在它们的核心业务流程里运行。一般的例子包括Customer(客户)、Employee(员工)和BusinessTransaction(业务交易，或通称为PurchaseOrder(采购订单))。应努力对这几个关键实体进行定义，以创建实体类型的组织模式，并开发实体建模的专业知识。同时，还应参阅关于指导和重复使用的正式标准和实际标准(如果你所在的垂直行业中存在着任何满足要求的标准，那么就可以使用此标准)。

我们已经建立了专业知识和一组观点，下面我们要更加深入地探讨如何应对业务机会和难题：

•	确定进行改进的关键机会。
•	对目前的业务方案进行建模，并适当参考现有的标准。
•	与三到四个相关业务科目的专家一起检查此模型。
•	根据他们的反馈扩展和修改此模型。
•	开发业务服务。
•	重复以上步骤。

结果将不会很完美。稍后就会发现某些业务案例需要附加的信息。必须向业务流程模型中添加步骤。不过，有了下一条原则，你就可以对变化做好充分的准备。

对于可扩展性的设计

在时间的考验下，任何对于要求的理解都是不充分的。为了进一步证明你的服务和解决方案，你必须将可扩展性设计进来。可扩展性有两个关键领域：实体可扩展性和行为可扩展性。

在实体中扩展模式化信息的主要原则是容纳一系列可能包含任何内容的Extension(扩展名)元素。这些元素通常都会使用一个名称来鉴别自己，并引用它们自己的架构。通过在实体定义中包含这种支持功能，你就可以创建多态实体。一个已扩展的Employee实体仍然可以由任何了解基础实体的服务进行操作，不过它也可以支持那些了解实体的服务(也就是称为TravelProfile(旅游资料)的扩展名)进行扩展处理。

不同的地区需要不同的信息。例如，一个税号在不同的国家可能会有不同的构成方式。请勿将社会保险号作为你的Employee实体中的顶级元素；正确的做法是，包含一个可能将其子类型标记为“US-SSN”的TaxID(税号)元素。

与面向对象不同，面向服务对行为进行了延迟的绑定——只有在实体被传送到一个知道如何处理其内部包含的信息的服务时，实体的“行为”才会得到绑定。

因此，可通过操作实体增加价值的公开服务基本上实现了行为可扩展性。如果要将新的行为绑定到实体上，可以使用很多有效的模式，但是本文不会介绍这些模式，因为它们超出了本文讨论的范围。不过，一个具有指导意义的实例是，一个服务充当了另一个服务(该服务能够操作较大实体的元素)的门面。VerifyEmployeeAddress(验证员工地址)也许可以接收Employee实体，并提取它的Address(地址)元素，然后将它传送到更通用的VerifyAddress(验证地址)服务中，VerifyAddress服务是由合适的国家邮政服务提供的。

另外，一个关键的指导原则是从标准化的元素组成实体，从而最大限度地提高实用服务的可重用性和通用信息元素处理的一致性。

分开的功能和操作关注点

请将你的业务服务和基础结构服务都视作提供的功能。基础结构服务提供了横向的功能，它也被称作横切关注点或方面(比较深奥)。

在进行面向服务的分析时，你的挑战是如何确定这些横切关注点并把它们从你的业务实体中分解出来。你最需要的是单独实现每个基础结构服务，它们可以通过管道传送，以满足特殊消息交换的总体操作要求。

你的基础结构服务组合可能会成为购买和创建行为的综合体，如果在市场上可以获得合适的实现工具，它就将以购买为主。下面的“服务管理”一节将更详细地讨论这个主题。

牢记客户

进行以用户为中心的设计练习是面向服务的分析的一个重要部分。这些服务有哪些用例？它们将由谁调用，为什么？用户将会在哪些角色里访问这些服务？谁可以调用服务，谁又不可以？需要支持哪些类型的设备和体验？为了简化从所有这些设备到服务的访问，我们是否需要开发服务代理？

为客户操作进行信息建模时，需要考虑以下几个方面：

•	只能使用XSD类型(以及由XSD类型组成的复杂类型)；不要通过特定平台的数据编码将你自己绑定到操作平台上。
•	架构应该表现出对于数据值的约束，以允许客户端在提交更新请求之前对其进行验证；客户端的验证可大大减少服务拒绝请求由于数据值超出限制所带来的成本和阻碍。(当然，即使在发布约束时，服务仍然需要验证数据值。)
•	参考信息应该具有时间戳或版本标记，以支持缓存、增量更新和连续的更新请求。

在服务可用时，你的组织里的聪明人会找到办法来使用它。请不要假设你在设计阶段所能够确定的客户是所有将会调用此服务的客户。请不要寄希望于客户对服务协定会有更深入的理解，也不要相信客户只会向服务发送有效的请求。

服务设计

面向服务是创建分布式系统的最佳实践方法的发展和完善。与此相同，它的模式来自于分布式对象技术和面向消息的中间件解决方案的成功之处，同时它也确定了这些体系结构的不完善之处导致的反模式。“Indigo”小组的Don Box确定了在考虑面向服务时要牢记的四个原则：

•	原则1：边界是显式的。通过边界后面的显式消息传递方式，服务可以进行交互。对于服务边界之后的空间，我们不做任何假设。跨越服务边界可能需要很高的成本(例如，你可能需要扩展地域、可靠的边界或执行环境)。通过在服务之间正式地传递已定义的消息，我们明确地决定调用服务。显式的边界使我们可以正式地展示独立于实现过程的交互操作——我们不必明确地选择实现其它服务所使用的平台、中间件或编码语言。
•	原则2：服务是自治的。作为独立的实体，服务采取了合理的行为。对于服务边界之间的空间，我们不做任何假设。在面向服务的环境中，并没有主导的权威。服务的部署、版本控制和管理都是独立的。执行服务的拓扑可能会(也必将会)不断地发展。服务应该预料到对等的服务可能会(也必将会)失效，而且它可能会(也必将会)收到残缺的或恶意的消息。应该使用冗余和故障转移等技术来创建服务，以避免服务失效。
•	原则3：服务对架构和协定(而不是类)进行共享。服务只在其使用架构的结构表达式和使用协定的行为表达式上进行交互。服务的协定描述了消息的结构和消息的排序约束。表达式的形式使机器可以验证传入的消息，这样我们就可以保护服务的完整性。在时间变化时，协定和架构必须保持稳定，因此灵活地创建它们(例如，通过在架构中使用xsd:any)很重要。
•	原则4：服务的兼容性是以策略为基础的。服务提供者和服务消费者都具有与跨边界交互相关的策略——操作要求。提供端策略的一个简单示例是，服务可能需要调用者在服务提供者那里拥有有效的帐户。从消费端的角度来说，组织可能需要对跨越Internet的服务调用进行加密，这样它就只能使用可提供安全性增强的双向数据交换功能的服务。服务使用了机器可读的策略表达式来表现其功能和要求。策略断言是由一个稳定的全局唯一名称来标识的。单独的策略断言对于整个系统而言是难以理解的；服务必须能够满足彼此的策略要求。

在你的服务边界上进行的通信应该支持以上的原则。对于面向服务的环境中存在的服务，这些原则需要它们之间的架构、协定和策略的正规表达式。可以开发专门为眼前的问题创建的机制，以表示服务的边界，但是这些机制仅限于创造者的影响范围之内。例如，如果你开发了一种系统，这种系统能够以一种特殊的方式表示架构和协定，而只有你的部门才能识别这种表示方式，那么你就避免了你的服务在你的部门之外被使用。

为了充分实现面向服务带来的利益，你的服务边界表达式必须得到最广泛的采用，并具有最高的互操作性。本行业已将SOAP消息中传播的WS-*协议明确选定为服务的互操作性标准。在实际应用时，面向服务需要获得Web服务和SOAP消息，并使用WS-*协议。

选择一项支持面向服务的消息技术就相当于选择了一项能够支持SOAP和WS-*协议的消息技术。在目前发布的Microsoft技术中，这项技术指的是ASP.NET中的.asmx。如果你需要支持不断发展的WS协议，请结合WSE使用.asmx。如果要以一种互操作的方式公开架构、协定和策略，并且此过程要独立于实现过程，那么请选择.asmx，因为它在目前的Microsoft消息技术中提供的支持是最好的。

服务边界的重点在于，在边界内可以使用任何实现工具。如果你通过ASMX和/或WSE正式指定了你的服务边界，那么你就可以在这些边界内选用任何技术或消息堆栈执行处理和数据交换。为了实现简单性和一致性，我们推荐保留此服务模型，并结合服务边界使用ASMX。不过，无论是为了支持特定的功能，还是为了支持现有部署工具的使用，MSMQ、Remoting或Enterprise Services都是服务边界内的合理选择。如果要实现服务的边界接口，这些技术就不适用了。

服务管理

SOAP规范的精妙之处在于，它允许从服务的操作要求(例如，与传送消息相关的指令和对服务的授权访问)中明确地分离服务的功能要求(服务将要处理的业务信息)。SOAP消息的正文满足了功能要求；SOAP消息标题中的元素满足了操作要求。

就保持这种方式。如果你支持消息登录到你的Employee实体中，你就需要创建一个可以分析Employee实体的消息登录实现工具。如果你拥有这样一个通用的消息登录实现工具——它可以在SOAP标题里定位合适的元素，而不用去管SOAP正文里包含了什么，你的工作就会方便很多。

可互操作的基础结构服务的开发和维护是一个成本很高的项目。基于WS-*规范创建值得信任的服务实现工具，对它们进行测试并将测试结果与所有合作伙伴组织使用的实现工具相比较，将会超出大多数IT预算的范围。系统供应商可以跨越更广阔的用户群利用这些开发成本，并针对其他供应商的补充技术测试互操作性。在创建这些服务(而不是从系统供应商处获得这些服务)之前，各个组织应该进行认真的思考。

那么，在系统供应商仍然把持着WS-*规范的实现工具的情况下，为了满足目前的操作要求，IT部门应该怎样做呢？

折衷。使用能够最有效地满足你的需求的现有技术，如果本地服务技术具有可用性并得到了你的系统供应商的充分支持，那么就计划向本地服务技术进行移植。如果你需要保证传输的安全性，请使用HTTPS；如果你需要可靠的消息功能，请使用MSMQ。

某些操作要求将会简化组织的服务组合，但是并不会得到系统供应商的良好支持。一部分示例可能来自于垂直行业的需求，例如，在汽车行业中需要跟踪零部件的来源；同时，其它示例可能是完全组织化的，比如主动的跟踪调查计划，其目的是在雇佣和提拔员工的过程中保证平等的机会。

当你需要设计和创建这些服务时，请参照供应商的WS-*协议实现工具中出现的模式：

•	与相关的集团进行合作，以有效地收集需求；对于垂直行业的需求，可与贸易伙伴甚至是竞争对手合作。
•	为SOAP标题定义架构，这种SOAP标题可以附加到任何消息上，以传送操作信息。
•	考虑一组可有效地重复利用的关注点和因素。例如，一条包含保健信息的消息可能需要传达多个具有相似结构的隐私声明。
•	通过重复利用处理了真正的横向关注点(比如对于物理地址的描述)的工作成果来构成你的架构。
•	重复构建过程；在时间和预算允许的情况下，努力构建你的消息基础结构。

面向服务的解决方案的模式

那么，为了创建互联系统，你现在应该怎样做呢？是否应该立即着手围绕面向服务的模型重新设计你的整个应用程序组合？还是应该先观望一下？

Microsoft自身的经验通过我们的客户和合作伙伴的经验得到了加强，它提出了一个更适当的方法。现在，对于许多的业务和技术模式，面向服务都提供了明确的利益。

最普遍的模式是信息集成，它在Rum Island crawl(爬)方案中得到了描述。由于技术体系结构在过去的30年里不断地发展，组织开始管理或获得大量的分布式冗余数据。例如，一个客户的完整描述信息可能会传播到一打业务应用程序和数据库。这种信息很难完全同步，为了实现最佳的客户(或合作伙伴或员工)交互而进行的信息聚合也无法得到足够的支持。信息集成服务是一种有效的方法，它可以使用这些关键实体的统一视图来表示你的应用程序组合，并保证你的所有后端系统之间的信息的一致性。Microsoft的内部项目Alchemy就成功地克服了我们在公司信息存储区问题上的挑战。信息集成项目可以从战术角度(比如Rum Island的例子)到广泛的战略角度(逐渐深入的信息访问再设计和跨企业管理)运行。

传统集成模式描述了对于服务的战术性使用，其目的是保留对业务应用程序的现有投资，同时扩展它们实现的功能。例如，为了符合新的规定，服务可能会在现有的ERP包前增加支持功能。应用程序也将得到重新设计，以便与服务交换消息，服务将会提取与合规性有关的数据，然后向ERP包发送请求。

上一个例子提出了一个更广泛的面向服务模式：流程管理。在此模式中，“标题”元素用来传送关键的业务元数据——从客户请求的周转时间到特殊业务决策批准者的身份。基础结构服务将会捕捉到此元数据，以用于实时分析和/或聚合分析。“本地服务”流程将会把此信息包含在SOAP标题中，非本地应用程序则需要进行重新设计，以便将元数据作为消息传送到管理服务器。

另一个略有不同的模式(或者可以直接称为派生的模式)是一致的访问——在一组不同的应用程序需要连接关键的后端资源时，使用服务层来保证各种操作要求得到一致的执行。通过命令所有访问通过一个服务接口进行路由，组织可以执行一致的访问授权、成本分配和负载管理。

许多服务都提供了某种形式的资源虚拟化。这里有一些例子：

•	区分上下文和区分内容的请求路由，比如向指定地区的农场房地产专业代理商发送房地产咨询问题。
•	到分区信息存储区的请求路由(请求者无须了解分区方案)。
•	跨越可用资源的负载平衡请求——从客户服务代表到流视频源。

最后，各组织都非常成功地使用这些服务实现了流程具体化。目前，通过使用Web服务，使用者可以安全地协商工资单处理情况、员工费用报销和后勤支持等事宜。移动电话服务提供商和Internet门户使用Web服务来聚合各种内容。需要面对客户的组织使用Web服务来创建合成的报价材料，比如包含了飞机票价和租车价格的信息包。基于目前的技术堆栈，流程具体化取得成功的关键是对你自己的要求进行管理——根据现有技术的限制，折衷处理你的要求，这样你就无须使用你的利润或储备资金来创建将会在几年之内更换的基础结构服务。

这些只是高级模式的几个例子，你的组织目前可能会用到这些高级模式。你了解你自己的业务；互联系统怎样才能帮助你呢？