实例解析基于SOA的架构思路2

来源：百度文库 编辑：神马文学网 时间：2024/05/01 05:00:28
此外，一个服务接口可能支持几个合同文本，例如，当一个服务接口有多个绑定。在网络服务的情况中每个WSDL文件指定一个绑定，因此为了支持不止一个绑定，服务接口必须要有多个服务合同文本。每个绑定与它自身的服务技术实现通信，或者更为普遍的情况是多个技术实现可能支持每个绑定，或者一个技术实现可能支持多个绑定。
无论如何，松散的耦合不仅仅意味满足不同用户的不同需要，它还意味着变更的创建。因为我们有适当的操作、管理的基础架构，这使得抽象服务、抽象接口、抽象技术实现中可以建立多对多对多关系，在松散耦合方式中我们能够对那些需求修改等变更做出反应，换句话说，不需要破坏任何事物。
例如，如果一个消费者修改了必需的数据格式，我们能提出一个新的合同文本，这也许需要服务接口和抽象服务之间媒介的一个新转换，但是不会直接影响服务接口或任何一个服务技术实现。另一个例子是需要升级或增加一个新的数据源来支持服务。这样的变更可能需要一个或多个服务接口的一个新的技术实现。但是如果那些接口的合同文本没有变化，那么抽象服务就不受影响，消费者也就不受影响。第三个例子是决策升级，这将改变服务接口和他们的技术实现间的基于上下文的路由行为。实际上，我们将这个基于上下文的路由应用视作管理变更而不是集成作业，因为这需要支持运行时间决策变更。
ZapThink的收获
用这种面向服务方法去技术实现抽象服务时，有一个引人注目的副作用：计算你有多少服务变得困难。当然，在这个例子中，从交易的角度来看你有一个顾客信息服务，但是实际上它可能有很多个服务合同文本，每个合同文本都有几个接口——并且随着时间流逝，那些接口的数量会发生变化。你怎么计算服务可能影响你的SOA成熟模型，甚至影响诸如你的软件许可成本等，因此这个问题远比它看上去的重要得多。
归根结底，最重要的事是记住顾客信息抽象服务只是一个简单的例子。在一般情况下，必须依据手头问题的特殊性，从多种SOA框架模式中挑选一个架构，正如我们近期的ZapFlash SOA基础框架模式和媒介方法所解释的。概括地说是松散耦合提出的架构挑战，这种挑战是计划和技术实现SOA基础框架的核心。构造服务抽象概念提出了一个交易的单一化表示法，但是需要深层次的额外的努力以使抽象概念成为一个具体的客观存在。这是SOA的工作：实现和维护松散耦合的交易服务是任何SOA技术实现成功的关键。
实例解析基于SOA的架构思路 实例解析基于SOA的架构思路2 基于J2EE架构的电子商务网站实例解析 基于SOA的体系架构设计 新中大发布国内首款基于SOA架构的管理软件 SOA对于软件架构设计的影响 架构设计师与SOA SOA:面向服务架构 下一代软件架构--SOA 架构设计师与SOA 基于ASP架构的电子商务平台的研制 基于模型、模式的技术架构设计 基于intel架构的网络课件开发 基于服务的建模和架构 基于服务的建模和架构 基于soap over jms的GSP架构 基于REST架构的Web Service设计 关于架构的一句话，还有一个实例 胡长城:我对SOA的反思SOA架构的本质 专题：SOA 面向服务架构 IPTV系统架构技术的深入解析 什么是基于B/S、c/s架构的系统设计 解析在SOA中实现语义互操作性(2), 插件式设计的架构模型与实例