SOA和EDA:用事件跨越解耦合服务边界(1)

发表于:2007-06-13来源:作者:点击数: 标签:
各种机构趋向于频繁的改变他们自身的结构。对面向服务和全球化的日益重视加强了这种趋势。结果,世界上大部分的组织都准备好迎接以独立、自治的服务供应商和服务消费者为特点的、以 网络 为中心的商务结构。现有的部分商业流程将被外包给外部的合作伙伴,同

各种机构趋向于频繁的改变他们自身的结构。对面向服务和全球化的日益重视加强了这种趋势。结果,世界上大部分的组织都准备好迎接以独立、自治的服务供应商和服务消费者为特点的、以网络为中心的商务结构。现有的部分商业流程将被外包给外部的合作伙伴,同时组织的各个部分和业务单位被转型为服务供应商。这些服务供应商不再仅仅只关注机构的内部,而且同样会在外部市场中寻求一席之地。

所有的一切都朝着随需应变(on-demand)的商业模式发展,在这种模式下,服务供应商对来自于外部环境的刺激——事件——做出反应。为了在一个充满竞争的市场中胜出,他们需要一种高层次的自治性,包括能够自由的选择合适的支持系统。分离程度的扩大能够产生出对于敏捷性的需求,当组织的构成不断变化时候,在服务之间的松耦合能够支持业务的连续的、不受阻碍的发展。

为了达到“真正的”敏捷性,支撑的应用系统必须做到对于机构的各种改变不可知,这些变化包括变化的责任和角色,外包或者内包,部门的拆分或者加强等等此类的重组。此外,业务流程适应机构变化的敏捷性必须不会受到支持它们的IT系统的限制。所有这些要求都可以用松耦合来满足。降低耦合的服务更容易在不干扰现有IT支持系统连续性的基础上,改造组织的结构。这就是所谓的机构敏捷性的基础。

应用搭建上的灵活性可以通过在定义良好的功能边界内使用共享的服务来完成。基于标准的技术对于敏捷性做出贡献,主要是能够解决对应用快速交付市场的担心(只要这些标准已经成熟并且采用了合适的工具)。敏捷性紧紧依赖于为了重新设计商务流程而对应用进行重构增加敏捷性的能力。最终的结果是降低的IT成本和更快的项目交付周期。

EDA和SOA都承诺能够增加整个机构层面上的敏捷性,但是两者采用不同的方式来做到。

EDA和SOA的关系

虽然EDA和SOA拥有共同的目标,我们如何知道何时使用事件驱动或面向服务的方法呢?那么让我们仔细想想在什么情况下,这两者种构架方式是最合适的。

和传统的分布式架构不同,EDA并不提倡同步的、命令-控制的消息交换模式。相反,它采用了基于异步的、发布-订阅模式,在这种方式下,发布者完全不知道订阅者的存在,反之亦然。服务的松耦合就意味他们只共享消息的语义。

假如你试图做到商业流程中各个步骤之间的独立性,那么EDA可以提供巨大的好处,尤其在联合的、自治的处理环境中。EDA被公认合适处理以下的情况:

  • 流程链中各个层之间的水平通讯
  • 需要跨越公认的功能单位边界的流程(包括内部和外部的边界)
  • 需要跨越物理单位界限的流程

然而,当试图利用商务流程中的内聚性的情况下,SOA则可以提供巨大的好处。它可以适用于以下的一些情况:

  • 功能分解之后上下等级之间的垂直交互
  • 功能上属于请求-应答类型的流程,比如人机对话的时候,用户等待应答
  • 具有交易特点的、具有提交及回退性质的流程

类似于EDA,SOA被经常通过消息框架来实现,该消息框架同样是利用异步消息模式来实现的请求-应答通讯。通过将请求的发行者和应答的消费者分离,同样将请求的消费者和应答的发行者分离,让系统的松耦合。但是,由于存在着一种普遍的误解,认为采用SOA就意味着使用Web Service所采用的那种(紧耦合的)RPC类型的架构,因此很多SOA实现采用了传统的、根生蒂固的同步交换模式。

为了建立一个SOA和EDA和谐共处的环境,有必要进行一些前期的分析。一个具有建设意义的准备步骤如下:

  • 1. 为商业需求建立一定粒度级别的功能模型,该粒度级别能够满足预期的自治性
  • 2. 勾画出该应用的地形图以便识别出受到影响的系统
  • 3. 将应用的地形图映射到对应的商业功能模型
  • 4. 鉴别出那些跨越功能边界的应用,它们是潜在的“敏捷性瓶颈”(对于那些需要跨越机构的外部边界的应用请给予较高的优先级)

其中第4步是在下面的章节中将会进一步讨论的解耦合服务边界(decoupled service boundaries)的基础。当我们寻找系统中的某些位置,在这些位置上EDA的发布-订阅模式可以作为连接这些边界、同时允许各个边界保持自己解耦合的状态的一种方式的时候,这些跨越边界的通讯正是我们感兴趣。

完成这样一个简单的流程,可以为引入一定程度的松耦合奠定基础,同时确定一个好的开始点,将这张技术地形图改进成兼俱SOA和EDA优点的、现代的、灵活的、可适应的环境。

松耦合和“解耦合点”

松耦合意味着独立。简单的说,松耦合的服务对彼此的依赖要比紧耦合的服务小。这个规则同样适合于功能和数据。当某个服务相关的数据被仅仅局限在该服务的功能边界内的时候,服务之间的耦合度就会增加(拉紧)。这种设计方法会增加服务之间为了访问被孤立的数据而形成对彼此依赖的概率。当以数据复制、避免保证数据传输和语义一致性的共享层之外的其他层共享等机制实现的数据冗余被允许的情况下,服务之间的耦合程度会降低(松开)。

保证跨越解耦合边界的数据冗余让松耦合更加强健。EDA适合这种情况,由于它支持在冗余环境中的数据的自动一致性。

当使用SOA和EDA的时候,找到“解耦合点”通常被证明很多帮助。这是通过寻找某些经常同时出现的商业流程部分,这些部分你可以确认它们会一起出现在任何一个组织单位中(具有强烈的内聚性和原子类型的业务功能)。它们就是“解耦合点”。这样,商业流程的功能构成会变得清楚。在各个业务功能之间的边界就是解耦合点。如果原子交易跨越了解耦合边界,那么回滚交易就需要在这些解耦合点实现。

如何安排事件来跨越解耦合服务的边界

图1:如何安排事件来跨越解耦合服务的边界

图1阐明了SOA和EDA之间一种可能的关系。在顶上的圆圈表示连接单个松耦合系统的解耦合点(事件)。无论在这些解耦合点上的服务是连接还是断开,都不会影响被连接的系统。不同域之间的所有的数据交换都发生在这些点,而不是在底下的层次。

在一个可重用的域(在图1位于底层)中,EDA的粒度可以进一步精细。EDA的粒度越精细,系统的灵活性也就好,尽管可重用的域也就越小。

假如在解耦合点使用基于SOAP的Web Service的技术,同时结合通用的基础架构(例如企业服务总线,enterprise service bus),那么和其他异构系统系统的连接将会变得很容易,包括SOAP包装的遗留系统,商业现货供应软件(COTS),ERP系统和外部系统的网关等(如图2所示)。

服务不再被直接耦合

图2:服务不再被直接耦合,而是通过由事件表示的解耦合点来连接

当谈到EDA和SOA,为了松耦合而奋斗——也可以说是为了灵活性和敏捷性——从所有的粒度级别来讲,都不失为一个好主意。当然,松耦合必须在现实的条件下慢慢实现,尤其是考虑到运行效率的时候。


共2页: 1 [2] 下一页

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

...