在SOA网格中共享数据

　　SOA是一个好办法,但是SOA仅仅靠一大堆的服务和功能是无法发挥作用的,数据能否共享是SOA变成现实的关键。

　　企业软件越来越复杂,SOA的解决方案也越来越多。

　　不可否认SOA是个好方法,但是也不是没有疑问。因为对于那些解决当前问题的企业级软件,模式驱动的方法也是需要的。模式驱动的方式可以在业务与IT之间搭起桥梁。它还可以提供灵活性,今天快速变化的市场非常需要这一点。但是,我们忘了大部分SOA还要面临这么一个问题:数据在哪里?

　　SOA的基本原则

　　关于SOA,有诸多的定义,但归纳起来,都拥有如下基本原则:

　　IT设备被描述或表现为服务;

　　服务是真实世界业务活动的映射,包括企业业务流程或企业间业务流程;

　　服务有标准的协议;

　　服务的协议包含了顾客的紧耦合要求,同时也要包括周围环境对他们的松耦合要求;

　　服务通过一种理论上的接口来展现他们的功能性;

　　服务是可以重用的;

　　服务可以被用来组织成更高级的业务流程。

　　服务可以以通信活跃的元数据作为补充,这样就可以很快被发现和理解。

　　可以看到,所有这些基本原则都集中在服务和他们的功能上。这当然不是坏事情。因为服务的本质就是可复用、可分解、可重构等等。但是,所有的这些服务从哪里获取数据呢?

　　以网格的方式共享数据

　　建立SOA网格是实现数据共享的一条可行途径。SOA网格相当于建立一个灵活的集群,对于一个SOA环境来说,这个集群是为内存接入、负载均衡和高可用性专门设计的。这种类型的集群能够跨越异构的、低成本的硬件设施工作集群,还能够根据需要在集群中动态地分派一个或多个备份系统。

　　利用自我修复管理和前瞻性负载均衡服务,以及在实时服务服务负载的分析基础上,清除最佳高可用架构设计的复杂性,能够建设一个持续可用的架构。当网格上的一个节点不可用,其他的节点可以接着执行任务。当新的节点启动,他们可以分担负载,增强整体的处理能力。简而言之,SOA网格将增强管理员主动控制和反馈运营事件的能力,从而减少对客户服务水平的影响。

　　在基于网格建立的SOA环境中,关键的一个部分是一个中间缓存层。这个中间层能够为SOA环境下服务使用的状态数据提供一个遵从开源协议JCache、内置、分布式的网格解决方案。

　　这个中间层要清除服务的记忆内存,目的是让其他的系统跨过网格。这将高效地提供一个分布式的共享内存池,以使得它们能够线性地切入一个异构的系统中。

　　在一个网格支持的,实时的服务导向的环境中,他们能够利用中间缓存层。应用或者服务放入网格中的所有的数据物体都是可以自动地被网格中所有其他的应用和服务使用和接入的。即使出现了服务器宕机事件,也不会丢掉哪一个数据实体。为了支持这种性能,可以用一组不间断运行的缓存服务器通过实时集群控制的方式来更新,从而共享数据。

　　这种方法的关键是保证每个数据总是有一个原始的所有者和增加的后端服务器来管理。这个数据可以是任何事情,从简单的变量到复杂的对象,甚至大型XML文档。从开发者的角度来看,服务通过一个规定的接口出入,简单地运行,就像访问一个Java地图和一个.NET字典一样。

　　从图1我们可以清晰地看到这种数据共享的实现过程。SOA网格执行将数据放到地图上的命令并且经过一个高效的网络协议而接触到节点p,该节点拥有原始的实例数据。这个原始节点依次复制更新数值到第二个节点B,作为备份。接下来,一旦相应的确认通知处理完毕,就会从控制回到服务