服务独立性与无状态性.docx

文档来源为 : 文档来源为 :从网络收集整理 .word 版本可编辑 .欢迎下载支持 . PAGE PAGE 10 服务定向原则第二部分：服务合同和松耦合 在前面的文章里， 我们建立了一个服务定向设计范例。 目前这些范例为我们提供了下面八个普遍原则。 ·服务共享一个正式契约 ·服务是松散耦合 ·服务提取潜在逻辑 ·服务可以重用 ·服务可以组合 ·服务是可发现的 ·服务是独立的 ·服务是无国籍的 这些原则是 “普遍的”，因为它们代表了行业层面的关于服务定向的观点。该服务定向由 SOA系统公司执行的研究所决定。 在文章的第二部分， 我们要通过讨论清单上的前两个原则：必须使用服务合同和创建服务间叫做“松散耦合”的关系来深入探讨这些原则。 服务合同的用途 服务被定义成使用一个或多个服务描述文档。 在 Web服务领域， 技术服务描述文档是典型的 WSDL定义和 XSD模式。该文档是又一越来越具重要性的文档形式。每个文档都可以被 分成服务元数据， 每一个服务元数据都提供和服务相关的信息。 我们可以把服务描述文档整体看做是建立了一个服务合同——一套必须被满足并被能为潜在的服务请求者所接受的条 件，以确保成功完成通信和互动。 ·服务端点 ·每个服务操作 ·每个由操作支持的输入和输出信息 ·每个信息内容的数据表示模型 ·服务和操作的规律和特点 因此， 服务合同界定了大量的解决方案环境的底层架构， 甚至可能提供的语义信息， 这些语义信息能够解释作为方案一部分的服务是怎样完成一个特殊任务的。 总之， 该信息确立了该协议的条件，服务的用户都应该遵循这个条件。 因为许多协议共享这个合同， 合同的设计就尤为重要。 同意合同的服务请求者便依赖于这个定义。因此，在合同最终发行前，应进行仔细的维护和校对。 在服务定向中，服务合同代表一个基础原则。因此，它能支持并使其它原则得以执行。例如服务抽象性、组合性、可发现性以及接下来要讨论的松散耦合。 怎样才算是松耦合呢？ 没人能预测一个 IT 环境将如何演进。自动化方案将如何发展，是集成化还是随着时间 的推移被取代，这些永远都不会被精确的规划出来，因为促使这些变化的要求对于 IT 环境来说是外在的， 应用服务定向的主要目标就是能够用高效的方法回应无法预测的变化。 通过在服务之间建立松耦合联系，我们就能实现其灵活性。 对于一个传统的分布式结构模型来说， SOA建立在一个概念之上，即把方案逻辑划分到 许多逻辑单位之中。 这些逻辑单位能够被集中在一起令商业工作自动化。 一个将 SOA和其它架构区别开的特征就是这些逻辑单位是如何被要求联系在一起的。 这就是耦合的来由， 软件程序间的耦合可被看做是代表测量依赖性的一种方法。 依赖性越强， 耦合就越紧。 而无依赖不表示一个去耦状态。 我们强烈推荐最大限度地减小 SOA里逻辑（服务）单位的依赖性。这种特定的关系被称作“松散耦合”并且通过将服务和请求者间 的依赖性限定到服务合同所表达的信息范围内， 同时在设计协议时不必要只针对某个特定的服务请求者，就可以实现松耦合。 如果坚持这个原则，新建的服务就会明显的独立于其它服务。这样就使正在标准化 SOA 的机构能够积累一系列服务， 作为相对独立的逻辑单位， 这些服务可以按照需要被配置到新的结构中。 当为了建立一个面向服务的企业而创建多种服务时， 这些服务可以被分成特定的服务模型。这就使他们在自己封装的逻辑方面更为专业。 在标准化一套服务模型时， 能够成功抽取更大的域。 这就使机构能够通过创建代表不同 域的服务层而在企业的特定领域有效的建立具有战略意义的松耦合联系。 通过这样做， 松耦合带来的利益会得到增大—最明显的是它促进了机构灵活性—。 这就展示了作为范例的服务 定向并没有局限于服务设计层面。它的原则可以在企业整个领域得以广泛应用。 下一步 在文章的第三部分， 我们将继续探讨另外两个原则， 其中一个是服务抽象性。 我们将扩展有关松耦合的解释， 并研究怎样通过让基础逻辑和被服务封装的技术独立演进把抽象性和 促进组织灵活性联系在一起的。 服务定向原则的第三部分：服务抽取性和服务重 用 抽取功能和技术 提及服务接口层面的提取， 原则上是鼓励人们建立类似黑盒的服务， 并有意隐藏潜在用户的基本详细资料。 通过规范的使用服务合同可以完成抽取。 将服务的公开信息限制在服务合同指定的范围内，就可以极大程度的在私人（隐藏）信息和公开（可消费）信息间实现分 离。 这里对逻辑服务代表事物的数量没有限制。 一个服务可能只是执行一个简单的任务， 或者在整个自动化方案被用作网关。对一个服务能使用的自动化方案的来源也没有限制。 举个例子， 单个服务可以揭示多种不同基础系统的逻辑。 事实上， 当我们在向服务模型标准