企业软件越来越复杂，SOA的解决方案也越来越多。不可否认SOA是个好方法，但是也不是没有疑问。因为对于那些解决当前问题的企业级软件，模式驱动的方法也是需要的。模式驱动的方式可以在业务与IT之间搭起桥梁。它还可以提供灵活性，今天快速变化的市场非常需要这一点。但是，我们忘了大部分SOA还要面临这么一个问题：数据在哪里?
SOA的基本原则
关于SOA，有诸多的定义，但归纳起来，都拥有如下基本原则：
可以看到，所有这些基本原则都集中在服务和他们的功能上。这当然不是坏事情。因为服务的本质就是可复用、可分解、可重构等等。但是，所有的这些服务从哪里获取数据呢?
建立SOA网格是实现数据共享的一条可行途径。SOA网格相当于建立一个灵活的集群，对于一个SOA环境来说，这个集群是为内存接入、负载均衡和高可用性专门设计的。这种类型的集群能够跨越异构的、低成本的硬件设施工作集群，还能够根据需要在集群中动态地分派一个或多个备份系统。
利用自我修复管理和前瞻性负载均衡服务，以及在实时服务服务负载的分析基础上，清除最佳高可用架构设计的复杂性，能够建设一个持续可用的架构。当网格上的一个节点不可用，其他的节点可以接着执行任务。当新的节点启动，他们可以分担负载，增强整体的处理能力。简而言之，SOA网格将增强管理员主动控制和反馈运营事件的能力，从而减少对客户服务水平的影响。
在基于网格建立的SOA环境中，关键的一个部分是一个中间缓存层。这个中间层能够为SOA环境下服务使用的状态数据提供一个遵从开源协议JCache、内置、分布式的网格解决方案。
这个中间层要清除服务的记忆内存，目的是让其他的系统跨过网格。这将高效地提供一个分布式的共享内存池，以使得它们能够线性地切入一个异构的系统中。
在一个网格支持的，实时的服务导向的环境中，他们能够利用中间缓存层。应用或者服务放入网格中的所有的数据物体都是可以自动地被网格中所有其他的应用和服务使用和接入的。即使出现了服务器宕机事件，也不会丢掉哪一个数据实体。为了支持这种性能，可以用一组不间断运行的缓存服务器通过实时集群控制的方式来更新，从而共享数据。
这种方法的关键是保证每个数据总是有一个原始的所有者和增加的后端服务器来管理。这个数据可以是任何事情，从简单的变量到复杂的对象，甚至大型XML文档。从开发者的角度来看，服务通过一个规定的接口出入，简单地运行，就像访问一个Java地图和一个.NET字典一样。
从图1我们可以清晰地看到这种数据共享的实现过程。SOA网格执行将数据放到地图上的命令并且经过一个高效的网络协议而接触到节点p，该节点拥有原始的实例数据。这个原始节点依次复制更新数值到第二个节点B,作为备份。接下来，一旦相应的确认通知处理完毕，就会从控制回到服务。
反过来，当实例数据需要被服务营用接触的话，SOA网格将自动确定那些含有该实例数据的原始节点，并引导数据回到服务或者对它发出命令的业务目标上。有很大范围的操作都可以支持这些行为。
所有数据的集中可以放在网格中来进行，就像一个单独的操作行为。通过大量的原始和备份节点，网格可以将这些集中的内容分散到一定的比例。
还有一个好方案，可以使服务充分利用数据库的持续性。
内置接口的所有点都是要避免数据库持续性的过度。这被公认为在最大数据处理负载时的瓶颈。为了解决这个问题，一个SOA网格可以利用异步的后写排队，即最后更新成为一个数据库。强调异步和最后，是因为更新数据库的运作不应该打断支撑服务和应用服务的状态数据网格的更新。
这是一个适用于SOA的非常好的数据处理方式。总之，需要在数据和服务之间设定了一个层。现在，一个不可忽视的问题是，当我们设计这个层的时候应该记住什么?
服务之间共享数据还可以像B2B的信息共享空间(如图2所示)那样去做，特别是当服务只是在组织内发生时。因为这是服务的本质。服务或者更好的，更多的服务，应该有约定性、特定的接口，和清楚的上下文依据。由于这些特性，从理论上讲，不管服务是发生在组织外，还是组织内，并没有区别。
当我们试图在服务之间共享数据时，问题出现了：
对于这个问题，从数据方面来考虑，有三个尺度可以考量，即决策控制：谁来做与数据有关的决定;数据存储：数据存放在哪里，谁存储的;数据传递：数据是怎样传递的，谁在传递数据。
这三个尺度已经显现出来。B2B的电子商务架构给出了最重要的两种解决办法，即共享区间：所有的事情都集中在一起;点对点交易：所有的事情都去中心化。
值得注意的是，如果在一个SOA的环境中，数据共享得到足够关注的话，它应该不止上述这么一种解决办法。
图1
图2
