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

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

　　在实体中扩展模式化信息的主要原则是容纳一系列可能包含任何内容的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标题可以附加到任何消息上，以传送操作信息。

　　•考虑一组可有效地重复利用的关注点和因素。例如，一条包含保健信息的消息可能需要传达多个具有相似结构的隐私声明。

　　•通过重复利用处理了真正的横向关注点(比如对于物理地址的描述)的工作成果来构成你的架构。

　　•重复构建过程;在时间和预算允许的情况下，努力构建你的消息基础结构。