软件质量保证SOA设计模式应用技巧：理解模式相互关系

软件质量保证SOA设计模式应用技巧：理解模式相互关系  SOA架构

关键字：SOA设计模式 模式相互

　　设计模式多年以来一直是IT领域的一部分。甚至出现了一个完整的模式团体来培育新模式的发展，并且要围绕应该如何说明模式以及相关的事情制定一些指南。

　　这是正确的，模式之间是相互关联的。要制定设计模式，你需要理解这些关系。这些关系对于SOA是特别重要的，因为SOA的实施范围一般要大于传统的应用。因此，SOA设计模式要涉及面更广，因此影响力也越大。

　　首先让我们了解一些基础知识并且回顾一下一种模式如何与另一种模式相关联。有许多不同类型的关系。但是，最重要的两个关系式依赖关系和支持关系。

　　为了应用一种模式，你也许需要使用另一个模式(或者已经使用了另一个模式)。这是很简单的依赖关系。但是，这对于理解为什么存在依赖关系是很重要的。例如，在SOA设计模式目录中，有一种模式称作“逻辑集中化”。它实际上建立一个规则，按照这个规则，对于任何指定的解决方案逻辑的再利用部分来说，仅存在一个正式的服务。这就减少了冗余的风险，最大限度实现了在一个指定区域的服务的再利用潜力。它还构成了不可知环境的基础。这是一种设计模式，用于单个服务中，以便为它提供多功能的范围(因为它对于任何逻辑来说都是不可知的，因此它仅限于一个单个的目的)。

　　不可知环境和逻辑集中化共享培育服务中的再利用这个共同的目标。虽然逻辑集中化建立了独特的逻辑单元，但是，不可知环境将保证拥有再利用潜力的人和单元都将仅仅限制在多用途逻辑中。这样，它们就成了纯粹的再利用服务。

　　简言之，你会提出理由说不可知环境依赖于逻辑集中化，因为没有集中化独特的逻辑体，就很难把它们分成不可知的单元。在应用逻辑集中化模式之前，使用不可知环境是没有意义的。

　　我们提到的另外一种关系是一种应用模式支持另一种应用模式。因此，与依赖性的关系不同，在这个案例中没有直接的依赖关系。这就意味着这些类型的关系很容易错过。一种支持性的关系简单地意味着一种模式帮助实现另一个模式的目标或者最终目的。

　　我们重新看一下逻辑集中化的例子。这个模式的目标是培育在服务中的再利用。然而，应用程序集成的历史已经教会了我们通过多个点对点的集成渠道实现连接，达到一个灵活性的架构，使负担沉重的企业能够继续发展，特别是面对业务变化的时候。

　　这与逻辑集中化有什么关系呢?设想一个包含若干数据库和一个老式的系统的服务。既使我们集中了这个服务代表的逻辑，我们仍然不能做任何事情来阻止通过传统类型的集成渠道直接访问这些基本的资源。这正是合同集中化进入这个环境的地方。

　　合同集中化设计模式限制外部访问一个服务，访问出版的技术合同(或者接口或者API)。这就意味着外部程序或者应用程序(我们可以指服务用户)不能接触这些基本的资源，因为这个唯一的进入点是这个服务合同。

原文转自：http://www.ltesting.net