SOA和EDA:用事件跨越解耦合服务边界
EDA和SOA都承诺能够增加整个机构层面上的敏捷性,但两者采用不同方式……
【IT专家网】各种机构趋向于频繁的改变他们自身的结构。对面向服务和全球化的日益重视加强了这种趋势。结果,世界上大部分的组织都准备好迎接以独立、自治的服务供应商和服务消费者为特点的、以网络为中心的商务结构。现有的部分商业流程将被外包给外部的合作伙伴,同时组织的各个部分和业务单位被转型为服务供应商。这些服务供应商不再仅仅只关注机构的内部,而且同样会在外部市场中寻求一席之地。
所有的一切都朝着随需应变(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优点的、现代的、灵活的、可适应的环境。
- 本文关键词:

