| 适用于以下开发环境：
Web Services Interoperability Organization (WS-I) WS-I Basic Profile 1.0 Web Services Enhancements for Microsoft .NET (WSE) 摘要：这份白皮书展示了微软公司关于面向服务及其结构在企业计算中的应用的观点。 本页内容
面向服务的事务上下文环境面向服务是一种建构分布式系统的方法。在它的最高抽象观点中，一切事物—从大型服务器应用到打印机到装卸工再到24小时快递公司，都被视为是一个服务提供者，他们通过接口向外界展现可提供服务的能力。面向服务结构将这些能力和接口通过映射协调的组织进过程中。服务模型是一个个不规则的碎片，由它们形成的过程就是一个服务，它可以对外展示出一个全新的，整合的能力。 服务模型的基本要求就是接口和底层实现的分离。服务调用者只需要（也只应该）懂得接口的含义和使用方法；而服务的底层实现可以时时根据需要而变，并不会影响到用户的使用。有趣的是，不同的底层实现可以共用一个接口；面向服务的几个关键性优势都是来源于此。 好了，我们已经弄清楚什么是面向服务了，那么面向服务会带来哪些好处呢？ 当看到一个鸡蛋的时候，一个农民可能会联想到一只鸡；一个厨师会联想到一个煎鸡蛋；一个孩子可能会联想到一个色彩鲜艳的复活节彩蛋。面向服务就像是这个鸡蛋。 对于开发者和设计者来说，面向服务是一种搭建动态协同式应用程序的方法。通过支持实时选择能力提供者，它使应用迅速的对某一业务过程的内容和环境的变化做出响应，并且可以随时加入新的能力提供者。 对于IT管理者来说，面向服务是一种有效整合各种不同系统的方法。通过使用一个模型将多个系统的信息和业务逻辑整合成一个单一的接口，它可以使多个业务上有重叠内容的系统对外展示出统一的接口。 对于CIO（首席信息官）来说，面向服务是一种既保护现有IT投资又可以应用新能力的方法。通过将一项业务应用封装到一组基于能力的接口中，服务模型可以对关键应用的访问进行控制，并且，在保证对外接口不变的基础上，对底层应用进行不断改进，使得投资免受不断变动带来的风险。 对于业务分析者来说，面向服务使IT投资更符合业务策略。通过将工作人员、外部能力提供者以及自动化系统映射到同一个模型中，分析者们可以更好的在人力、系统和原始资料的投资比例上进行权衡，寻找出最佳的解决方案。 对于微软公司来说，面向服务是一个搭建互联系统的必不可少的先决条件。互联系统使使用者和系统连接起来，从而带动整个业务的应用。在一个跨越界限并且不受同步限制的应用模型上，你可以搭建出一个互联系统。互联系统将各个服务和设备有机的组合到一起，较之从前分散的状态，能更有效地应对业务上的挑战。 IT界正努力寻求一个高效的应用整合办法。其目标是明确一致的：
为了获得透明性和一致性，组织必须搭建各种连接：将各个系统连接起来进行一致的信息管理；将工作人员和技术能力连接起来以便搭建业务过程；将单个工人连接起来形成一个协同工作的团队；将各个组织连接起来形成有效的价值传递链。 由于它对使用统一模型调用能力的强调，面向服务在高效的互联系统策略中处于核心地位。 服务和互联系统在组件模型中，一项服务就是一个通过交换消息与外界进行交流的程序。换句话说，就是一个应用逻辑单元，它的接口只是通过其接收和发送的信息来定义的。 随着基于可扩展标记语言（XML）的信息标准的发展，面向服务迅速成为构建互联系统的主流方法。 将各种不同系统连接起来有其固有的挑战，就是对于特定平台的信息及过程转换。在理想的状况下，应该可以做到以下几点：
在这个理想的状态中，所有系统（除了使用自己本地的语言外）都需要使用通用语言，以便与非本地语言的外界环境进行交流。 XML、XSD、WSDL、UDDI以及WS系列，如WS-Security和WS-Policy，都是这种逐渐成熟的通用语言的第一批组成部分。 如果没有一个基于广泛认同的标准的虚拟平台提供的协调性支持，面向服务就是一项不可预知的科学，它需要相当高超的协议设计方技能，而且风险也相当大。如果没有Web Service将企业的各种分布在多个异质平台上的能力连接起来，面向服务对于你和你的组织将没有多大价值可言。 在互联系统中，一个至关重要但却常常被忽略的因素就是用户。服务只有被调用时才有意义。不同的交互必须得到多种模式的支持。Web Service的用户包括：
不断演变的Web Service标准及其实现平台必须支持各种用户驱动，比如对于资源有限设备的分页管理以及对于长时间交互的对话上下文环境管理等。 即使是面向服务最狂热的拥护者，当谈到模型问题时，都会持不同的观点。争论的焦点就是，“面向服务来还有什么别的关键性要素吗？”（“你想用这些鸡蛋做什么？”）让我们来了解一些与这个争论有关的一些概念：
微软将灵活性和面向特定方面视为面向服务取得成功的关键因素；这些思想在今后的讨论中还将反复被提到。无人为干预是面向服务解决方案的一个共同目标，可以将它视为这种结构的一个隐含优势。其他的每一个概念，都是对面向服务的一个补充，对于你的互联系统策略来说，它们可有可无。 你需要一个标准的方法来建构和改进互联系统，下面这个逐渐演变的例子具有很好的启示性。 第一步：爬 Typhoon Taylor以前是Rum岛工厂(RII)的一名信息转发员，所有的订单和货物报告数据都经他录入到了主机里。但是，在RII被Worldwide Spirits(WWS)收购了之后，Typhoon发现他必须录入两次相同的数据，一次是到RII的操作系统里，一次是到WWS的系统(ERP)里。两个系统使用的是不同的信息模型，这个区别不断的带来数据录入错误，导致两个系统中的数据不一致。 Typhoon将此事告诉了从事信息技术的Daiquiri Jones, Daiquiri并不想破坏原有的应用，但她又无法获得对WWS的ERP系统进行修改的权限，所以她建议在两个系统前面再加入一个服务层。 Daiquiri与Typhoon一起定义了一份名为PurchaseOrder订单的文件，它包括了RII系统以及ERP系统所需要的全部信息，并对二者都用到的共同元素作了映射。然后Daiquiri将此草案拿给会计部门的Hurricane Harris 和客服部门的Salty Robinson过目。根据他们两个的反馈意见，她又在PurchaseOrder订单的结构上添加了一些元素，使得它对Hurricane 和Salty的需要进行支持。 Daiquiri与Typhoon一起又定义了两项服务：
利用DB2数据库和WWS ERP系统转换器，Daiquiri在BizTalk Server 2004上实现了她的服务，并用ASP.NET为Typhoon提供了一个使用接口。 这下Typhoon不再苦恼了，他又可以只录入一次数据了，而且数据不一致的问题也没有了！ 第二步：走 但是，Salty 和Hurricane却开始感觉到不舒服了。 每当运输途中发生货物意外损坏时，Salty都会收到客户的抱怨。面对两个系统，Salty甚至不确定应该从哪一个里获得客户的数据，还有，当客户需要进行临时货物替换的时候，Salty不得不就重新调度发货次序的问题与Typhoon进行协商。 只要让Salty获得GetPurchaseOrder这个接口的使用权限，他目前的问题就可以很容易的解决。但是Typhoon坚持认为Salty无权擅自对订单进行更改。结果，Daiquiri只好为PurchaseOrder这个业务服务定义了一组使用角色，然后把Salty映射成为“读者”角色。 Daiquiri还提议新增一个CustomerCredit文件，让Salty可以用它来解决客户对损坏问题的抱怨，但是，当Hurricane看到这个提议后立刻变得非常愤怒，认为它没有考虑到Sarbanes-Oxley规范的问题。Daiquiri不得不重新组织CustomerCredit文件，使用WWS会计部门认可的结构将RegulatoryCompliance元素包含了进来。 挑出需要重排运货次序的顾客是一个更加棘手的问题。 Daiquiri与Typhoon、Salty以及货运部门的Mojito Moore一起重新修订了Shipment文件的结构，使它可以与Customers以及PurchaseOrders进行绑定。然后，她又为Shipment文件实现了一个优先级队列，以便Mojito可以清楚地知道下一批货物应该发到哪里。（Mojito被映射成为队列接口的“写者”角色，所以他可以根据船的启航来优化队列。） Daiquiri定义了一个工作流，每当Salty调用ReprioritizeShipmentQueue接口的时候，都会实例化一个工作流，它可以将这个请求发送给Typhoon以取得他的批准。 Typhoon、Mojito和Salty之间曾经一度需要人工完成，因此常常引发混淆问题的沟通过程现在已经变得非常流畅了。当然，如果Typhoon否决了Salty关于调度次序上的请求，那他也只有发脾气的份了。 第三步：跑 当批给Daiquiri的预算被再一次的削减时，她意识到需要寻求别的途径了。她曾经买过一条通向WWS的长途线缆，但它现在每天只有几百kb的电子信息交换(EDI)传输量，如果…… WWS总部的Martini Wilson已经为EDI传输设计了XML结构；他需要将传来的EDI信息打包成符合USA PATRIOT ACT的内容。他主张为了削减WSS各个分公司的支出，应该放弃使用昂贵的EDI线缆而改用经过转译的Web Service呼叫，为此，他实现了一个通路服务将所有EDI请求映射进EDI处理流水线。 Daiquiri还为Rum岛的甘蔗供应商们设计了一组服务接口。这项新服务的使用者之一Beachcomber Perry为此兴奋不已，他早已厌倦了花大量时间和种植园主及船长们进行电话协商。当然，Mojito也从中获了益。利用改善后的信息，他可以更好的调度运货船只。Rum岛的货物清单管理从来没有像现在这样好过。 有一些种植者和船员们抵制这项改变，但这带给他们的只是在越来越少的来自Rum岛的业务。 面向服务的技术微软始终坚持面向服务 在1999年9月，那时的微软主席（现在的首席执行官），Steve Ballmer先生首先公开探讨了“将软件视为服务”所面临的挑战，并且第一次引入了Web Service的概念。随着互联网技术的成熟，一种新的编程模式已经呼之欲出，它允许软件组件可以在广阔的网络世界，跨越各种平台及组织界限被自由地调用。将这个模型真正应用到实际中，到底还需要做些什么呢？ 在2000年6月，这个刚刚出台的策略有了一个名字：“Microsoft. NET”。 紧接着，与微软有关的组织纷纷进行了一系列的自身调整，以应对. NET框架带来的新挑战。面向XML的Web Service 的出现为各种组件互联提供了统一的策略。 微软意识到，为了使这项技术更上一层楼，必须跨越一些界限。其中一个界限来源于技术员们自身的组织结构：各个操作平台之间的界限。微软决心与其他的平台供应商们联手将这座墙推倒。 为了拓展跨平台的能力，微软与BEA Systems 公司., IBM 公司, TIBCO Software公司., VeriSign公司以及其他技术供应商们一起，开发了一个SOAP的消息传递过程。各种规范，以完全免除各种使用税的方式，被应用到了标准中。这股对于实现信息传递规范化的热情，让这些彼此之间竞争激烈的组织开始进行合作，向他们的用户推广协同工作的概念。 由于早前的标准没能在实际中中获得协调工作的能力，微软，IBM以及其他的赞助商们意识到仅仅依靠这些规范是不够的，于是他们成立了一个网络服务协调工作组织(Web Service Interoperability Organization,简称WS-I)。WS-I为了对网络服务标准做出统一的解释，建立了一个论坛，这样，技术使用者们就可以放心的对WS-Security进行各种不同的实现了，因为它们之间确实是可以相互协调操作的。自2002年2月创立至今，WS-I已经拥有大约150个成员，从系统供应商到系统整合者，从解决方案提供者到政府改良者，以及America Online 公司, BEA, Fujitsu, HP, NEC 公司, Oracle 公司, SAP AG, Siebel Systems 公司., Sun Microsystems 公司，TIBCO 都是 WS-I 的成员。 在此基础之上，微软又将基于标准的协调工作能力应用进了它的企业计算产品中。 面向服务的今天 微软的平台支持建构符合WS-I Basic Profile 1.0的服务和解决方案，同时为使用高级WS-* 规范的网络服务提供早期的接收器。 在微软平台上建构Web Service的主要方法是使用ASP. NET提供的网络服务支持，通俗地讲也就是使用”.asmx”或者”.ASMX”作为后缀名，这是Visual Studio对这些可执行文件的文件扩展名。 BizTalk Server 2004允许将安排控制作为一种Web Service提供出来，对于那些缺乏本地网络服务支持的业务应用来提供了方便的接入点，大大加速了网络服务的开发过程。 在Web Services Enhancements for Microsoft. NET(WSE)中已经可以实现基本的高级网络服务特点，比如说基于WS-Addressing规范的复杂信息转发以及基于WS-Security规范的信息层安全。WSE是一个技术预览程序。 微软为用户提供了丰富的支持，让他们可以方便的从自己的操作系统（如Windows XP，Windows Server 2003以及Windows CE）以及Microsoft Office系统中调用网络服务。 Microsoft Office InfoPath 2003是Microsoft Office中的一个新成员，它支持将结构化的表格作为一个与后端服务交互的模型来使用。事实证明InfoPath在结构化联合应用中，从人力资源招募到合同协商，是非常有用的。 另一个Office系统的新成员是Microsoft Office Information Bridge Framework(IBF)，它可以提供对网络服务的信息访问。它是对Visual Studio .NET的一个补充，它允许开发者搭建可以对企业业务数据，比如说销售数字、货物数据、客户信息等，进行访问的基于Web Service的解决方案。这些数据可以用2003版的Word、Excel和Outlook直接进行浏览。IBF解决方案通过让信息处理员在熟悉的Office系统中方便地遍历信息并据此采取行动，大大提高了他们的生产率。 Visual Studio延续了它一贯的优良传统，为企业的业务流程应用提供最好的开发环境。下面列出来的是Visual Studio提供的对Web Service的一些支持：
微软也关注如何为使用者提供更好的指导。除了MSDN，微软还为开发者提供了其他形式的指导，比如说书籍、白皮书、参考应用样例以及模式库等。 SQL Server 2005和Visual Studio .NET 2005中的面向服务 2005年的两个重要的技术版本将是微软的Microsoft SQL Server 2005（编码名字为”Yukon”）和Visual Studio .NET 2005（编码名字为”Whidbey”）。 针对使用Web Service来设计分布式系统，Visual Studio将会引进一个新的建模方法，并随Visual Studio附带两个使用这种新方法的设计工具：
这些建模工具主要是为了支持解决方案工程师与系统工程师之间的初期交流，以确保在设计过程中，操作需要可以被充分的考虑到。微软不只一次的接到这样的用户反馈：由于开发问题，很多工程不得不被延期和增加预算。如果在开发之前进行较好的建模，这些问题本来都是可以避免的。 解决方案工程师和系统工程师都将目标锁定在了系统定义模型(System Definition Model-SDM)上，它是一个用来描述软件组件、电脑硬件、网络以及交互模型的XML结构。作为一种对互联系统进行描述和分析的建模语言，SDM是动态系统建立(Dynamic Systems Initiative，见下文)的技术基石。 SQL Server 2005的改进地方之一就是对于XML和Web Service提供更好的支持：
SQL Server中的一些结构元素可以为面向服务式的数据中心提供解决方案：
“Indigo”和Window “Longhorn”与实现面向服务 “Indigo”将会达到微软在相互可操作通信方面的投资的顶点：
基于面向服务的概念，如合同、消息、通道以及服务等，”Indigo”将会提供一个编程模型和一个信息传递的实现。”Indigo”将会使那些符合各参与方共同声明的交换策略的信息传递和功能调用变得更加安全、可靠、更加具有可互操作性。 “Indigo”技术将会被加入到”Longhorn”客户端运行程序的版本中，以及Window XP和Windows Server 2003中。 下一代的Windows客户端程序—编码名称为”Longhorn”，将会引入很多革新来扩展单机用户的能力，使它们加入到面向服务业务的阵营中来。 为了更加高效的Windows系统应用，“Longhorn”将会引入一种XAML语言，它是一种基于XML的标记性语言。 向HTML一样，XAML使用一个事先声明的符号集来描述用户接口元素，这使得它在编程时可以更容易地被生成和解析。这些革新将使得用户接口更加能够反映它们所代表的信息，因为此时用户接口可以根据交互状态由程序来生成。 WinFx是微软的下一代系统编程接口。为了实现面向服务，WinFX对微软的多个消息传递模型进行了统一，根据来自网络的信息提供代码访问的安全性保证，并全面向开发者们开放了”Indigo”的消息栈功能。 通过动态系统开发(DSI)，微软正在努力提高信息技术的生产效率并且降低在对分布式面向服务的系统进行设计、应用以及操作时的成本。作为开发的一项核心技术，系统定义模型(SDM)通过为应用、系统以及交互定义通用语意，将面向服务的核心原则应用到了系统管理当中。使用这种通用的特定域语言，应用程序可以表达自己的技术要求，比如说CPU周期和存储容量等，系统也可以描述所拥有的资源。这个新的建模技术将使企业更迅速的生产出便于使用和管理的应用程序。DSI是微软公司和整个业界共同努力的结果，它必将对软件工具的发展和应用、操作系统、管理策略以及硬件平台产生深远影响。 建构面向服务的解决方案每个网络服务做出来可不都是一样的。就像一个鸡蛋可以变成美味的蛋塔，如果搭配荷兰辣椒油，将会变成一次让人倒胃口的品尝，如果不幸掉在了地上，那它只能变成一滩粘糊糊的东西了。你可以搭出任何的服务：好的、坏的或者丑的。 当你正在筹划一个企业服务组的时候，有三个基本的挑战需要应对：
下面将分别探讨这三个挑战并给出一般性的指导，使你知道怎样可以立刻体会到面向服务带来的好处，同时还会给出一些小提示，帮你预估一下未来投资。 面向服务分析 面向服务的结构是一门建模艺术，它将一个组织的业务过程结构合理地拆分成为一个个在网络上可以访问的业务组件。 建模时真正的挑战来自于那个看似平常的修饰词，结构合理地，当真的开始着手去定义一个至关重要的信息集（把它看成是“结构化的业务文档”的近义词）和行为时，你很有可能会掉入“模型泛滥”的陷阱，试图为组织里的每一项功能都建立一个模型，然后将它们整合进一个统一的结构里。同时，今天需要解决方案的业务单元随投资的变化，不断地向前发展。 解决眼前的问题是一个强有力的动力。利用它，但是需要对它进行适度的控制。这就像这样一个过程：在不断的尝试中开始学会爬，在不断的交流中学会走，在不断的合作中开始起跑。 你如何根据当前情况定义一个服务组呢？以下是一些提示： 设计长期有效的服务，设计灵活应变的系统 在一个企业服务结构中，功能服务是构成业务流程和业务系统的组件。实践证明最好的接口设计方法是让它们与业务功能模型紧密一致。比如说，大多数的制造商都有接收订单的业务需求，那么就定义一个信息集用来描述一个订单以及一个终端用来接收一个这样的信息集的实例。 业务流程比起它们处理的信息来可能更加多变，因为这些操作依赖于操作者的判断甚至是一闪念的想法，而且无数的业务异常也极有可能扰乱操作实例。每一个业务流程实例都可能经历一条独特的执行路线。 因此系统必须是灵活应变的。业务流程的组织应该是很容易改变的，或者甚至就是动态的。死板的将业务流程的先后次序写成代码并编译成可执行文件，是不符合成功的业务系统模式的。 事件驱动结构的概念对于设计高效的流程是很有启发性的。流程应该可以察觉到业务事件的发生，并判断出这个事件会带动流程的前进还是导致流程偏离正轨。当发现一个导致流程离轨的异常事件时，应该努力使流程恢复正常，将它带回到正确轨道上。如果人工的监视整个业务流程，将导致操作费用的急剧膨胀以至于远远超出业务本身带给组织的价值。 从全局着眼，从局部着手 大多数的组织在其操控的核心业务流程里都有一些，可能10个左右，关键的实体。比较常见的包括：Customer顾客、Employee雇员以及BusinessTransaction交易业务（通常也称为PurchaseOrder订单）。应该定义一些关键的实体，以此建立实体的风格。寻找一些正式投入使用的标准作为指导并适当重用（如果在你所处的整个业界有这样的标准，而且它们也符合你的需要，那么只管拿来用就好了）。 当建立了一个拥有专业知识的相互了解团队以后，就可以列出业务上存在的机遇与挑战了：
这样设计出来的结果可能并非尽善尽美。很快就会发现一些业务需要额外的信息，一些步骤需要添加到现在的业务处理模型中去。但是，有了下一个窍门，你很快就会学会如何为可能发生的改变进行准备。 可扩展的设计 在时间面前，任何对于业务需求的理解都是不充分的。为了使你的服务和解决方案可以经得起时间的考验，它必须具有可扩展性。这里有两个关键的可扩展性：实体可扩展性和行为可扩展性。 扩展一个实体对象内部信息的主要方法就是留出一系列可以装入任何内容的扩展元素。这些元素通常都有一个可被唯一识别的名字以及对它们自身结构的引用。通过将这种支持加入到实体定义中，你就创建了多态的实体。一个扩展以后的Employee实体依然可以被那些了解基本实体结构的所有服务所操控，同时它还可以被那些了解，比如说TravelProfile扩展结构的服务进行操作。 不同的地域需要不同的信息，比如说在不同的国家，纳税号的组织形式可能就是不一样的。不要在Employee实体里把美国的社会安全号码设计成一个顶级的元素，应该设计一个名为TaxID的元素，将社会安全号作为它的一个子类型，用”US-SSN”来唯一标识。 与面向对象不同，面向服务推迟了行为绑定的时机—一个实体的“行为”只有在这个实体被转发到一个可以对其内部信息进行操作的服务后，才与实体进行绑定的。 因此，行为扩展主要是通过这些服务展示出来的。有很多有效的模式可以将新的行为绑定到实体上，这里就不对它们一一评述了。一个指导性的例子就是如果一个服务总是会在另一个服务的前面运行，那这个服务可以对一个更大的实体进行操作。比如说VerifyEmployeeAddress接受一个Employee实体,提取出实体中的Address 元素，将它传递给由相应国家提供的，更具有针对性的VerifyAddress服务。 还有一个关键提示，就是尽量使用标准元素构成实体，这样可以最大限度的重新使用常用处理服务并获得信息元素处理过程的一致性。 将功能和操作分开考虑 将你的业务服务和底层服务都看成是传递功能。底层服务传递的是水平的能力。 当做一个面向服务的分析时，你所面临的挑战就是找出这些跨界限的问题并将它们从业务实体中分离出来。你可能想单独实现每一个底层服务，然后把它们组成一条流水线，以解决某一处信息传递的总体操作需要。 建构底层服务组将像是一个由买和建组成的过程，如果在市场上可以找到合适的操作，则更倾向于买。这个思想将在下面的服务管理部分中进行更为详细的讨论。 时刻想到顾客 面向服务分析的很重要的一点就是以顾客为中心进行一次试运行。这些服务将会发生那些使用情况？谁会调用这些服务？为什么会调用？顾客将以一种怎样的角色来访问这些服务？谁有权调用某项服务而谁无权这样做？需要支持哪些设备和状况的发生？是否需要开发服务代理来简化可能的设备对服务的访问？ 当为顾客操作的信息进行建模时，需要考虑到以下几方面：
一旦一个服务开始对外开放，所有人都有可能使用它。因此，不要想当然的认为只有那些在设计时被你识别为用户的人才会调用服务。不要指望用户都对服务的需求合同了如指掌，也不要相信用户向服务发来的请求都是合法的。 服务设计 面向服务的思想来源于分布式对象技术以及面向消息的中间件解决方案的成功之处，并且摒弃了这两种结构的缺陷。”Indigo”小组的Don Box总结出了考虑面向服务时应该时刻牢记的四个宗旨：
在你的服务边界上进行的交互因该符合上述的四个宗旨。这些宗旨要求在一个面向服务的环境中进行相互操作的服务使用一种正规的表达方式来定义自己的框架、需求合同以及策略。你为手头的问题专门建立的机制很容易被限制在某一影响范围内。比如说，如果你在开发一个系统的时候，使用一种只在你的部门可识别的表达方式来定义框架和需求合同，那么你无形中禁止了你部门之外的人来使用你的服务。 为了充分的体验面向服务带来的好处，你对于服务界限的表达必须尽可能的被广泛接收并且具有互操作性。业界一致选择在SOAP消息中进行传播的WS-*协议作为服务的互操作标准。具体的实现面向服务，需要Web Service，SOAP消息以及使用WS-*协议。 选择支持面向服务的通信技术相当于选择支持SOAP以及WS-*协议的通信技术。在微软现在发行的技术中，指的就是ASP .NET中的.asmx。如果你需要得到对于演变后的WS协议的支持，可以把.asmx与WSE一起使用。 服务边界的关键性在于，在边界内部，任何实现方式都可以使用。为了简单性和一致性，我们建议在服务边界上也与服务模型保持一致并且使用ASMX。不管是为了得到对某一特定服务的支持还是对现行应用的使用的支持，MSMQ，Remoting，或者Enterprise Service都是在服务边界内部的合理选择。但是它们并非用来实现服务边界接口的合适技术。 服务管理 SOAP规范的可贵之处就在于它将服务的功能需求与服务的操作需求。功能需求在SOAP消息的消息体中得到表达，而操作需求则在SOAP消息的消息头中进行表达。 这样的话，如果你希望在Employee实体中加入对来访信息进行处理的支持，你需要建构一个信息来访的实现，它可以解构Employee实体。如果你专门针对来访的SOAP消息头，而不管SOAP消息体的内容进行实现，效果会更好。 发展和维护底层服务是一项耗资巨大的工程。建构基于WS-*规范的实现并且在你所处的环境中对它进行测试需要的经费超出了大多数信息技术预算的范围。但是对于系统经销商来说，费用是可以承受的，因为他们拥有广泛的用户群，而且可以利用其他经销商的互补技术来测试系统的互操作性。 如果对于WS-*规范的实现还是掌握在系统经销商手中的话，那么，信息技术部门应该做些什么呢？ 折衷。首先使用那些最满足你要求的现有技术，当本地服务技术可用而且得到你的系统经销商的全面支持时，考虑过渡到这些技术。如果你需要传输安全性，使用HTTPS；如果你需要可靠的信息传递，使用MSMQ。 一些操作需求可能在你的整个操作服务组很重要，但是却不能得到系统经销商的支持。这些需求往往是对于整个业界的纵向需求，比如说需要跟踪探求汽车制造业内的零部件的来源。 当你需要设计建构这样的服务时，请仿照系统经销商对于WS-*协议的实现模式：
面向服务的解决方案模式 那么为了搭建一个互联系统，你现在应该做些什么呢？是否应该立即着手围绕面向服务模型来改造你的整个应用组？还是应该观望一下？ 微软本身的经验—以及我们的顾客和合作者的经验—都表明应该采用一中比较和缓的方式。 最流行的一个模式就是信息整合，已经在Rum岛工厂那部分介绍过了。在过去的30年里，随着技术的发展，需要对大量的分散冗余数据进行管理和使用。比如说，对于一个顾客的完整描述，可能会涉及到十多个业务。为了与客户（或者合作人和雇员）进行良好的交互，需要将这些信息整合。信息整合可以将应用组统一地展现给所有关键实体，并且保证在所有后端系统中信息的一致性。在微软内部搞的一项名为Alchemy的工程成功地解决了公司在这个问题上面临的挑战。信息整合工程可以进行小规模的实现—比如Rum岛工厂的例子，也可以使用庞大的策略—在整个企业中对信息访问和管理进行改造。 现有资源整合描绘了一种是用服务的巧妙方法，使你可以保留对业务的现有投资，并在此基础上扩展其所传递的功能。比如说，一项服务为了符合新的规范可能需要在现有的企业资源规划(ERP)系统中添加新的支持。这需要设计与服务进行消息交换的应用，它将与规范有关的数据提取出来并将请求部分发送给ERP系统。 前面这个例子为面向服务提出了一个更广泛的模式：操作管理。在这种模式里，消息“头部”元素用来表示关键的业务元数据。这些元数据被一个底层服务捕捉到并对其进行实时的和/或者综合的分析。“本地服务”过程将把这些信息添加到SOAP的头部，而非本地应用需将这些元数据封装成一个消息传递给管理服务器。 另一个稍有不同的模式叫做一致访问—使用一个服务层，当很多应用需要与同一个后台资源连接时，它可以统一的执行某些操作需求，强制推行一致的访问权限、费用分配以及流量管理方案。 很多服务都带有一些虚拟资源的形式：
最后，将形成一个非常成功的过程外部化服务。可以通过Web Service安全地协商例如工资单的处理问题、雇员报销问题以及后勤保障等问题。手机服务提供商和Internet入口提供商使用Web Service将内容进行整合。直接面对顾客的组织使用Web Service提供复杂的功能。在今天的技术栈中，对于一个成功的过程外部化服务来说，最重要的就是处理好你自己可能遇到的问题—综合考虑你的需要以及现有技术对你的限制，采取折衷方案，确保自己不会花费大量的资金在那些你可能不久之后就要替换掉的底层设备上。 这里介绍了一些你可能会用到的一些高级模式的例子。你了解自己的业务；互联系统应该怎样帮助你呢？
|
