这些言论对于业务流程顾问或者软件工程顾问来说都是很平常的。随着数据管理或数据存储数量的增长，他们会告诉你同样的事情：客户已经对service-enablement和面向服务架构(SOA)念念不忘了。
最近由SHARE(独立主机用户群体)发起的一项SOA调查结果显示：四分之一的公司目前已投入SOA的努力，另外的三分之一则在考虑或在计划实施SOA的过程中。
讽刺的是，许多专家指出：相对较少的实施者预计了在他们开始实施SOA之后，SOA负责人之间的矛盾将如何妨碍他们的项目。这种矛盾不仅仅是人与人之间和过程惯性的问题――即使这两者都是SOA实施中可怕的壁垒――而是在于导向的不同。
Madsen的一个客户最近展开了一项较为简单的SOA实施行动。应用软件架构师将此行动看作为坚定的企业服务总线项目(ESB)：他通过ESB的有色眼镜看待这一项目，因此我们并不意外看到他制定了一个计划使用企业服务总线作为该公司SOA行动的支柱。Madsen承认这并不是一个非主流观点，但在这个公司案例中，一个以ESB为中心的观点使得原本可以很简单的整合项目变得复杂了。换句话，这个组织其实能够在不使用全面ESB路线(这要求从最近收购的软件供应商那里采购和实施ESB)的情况下就达到其所想要达到的结果。
实施ESB需要引入另一层的提取(如：在ESB本身可能消费的容器中打包或已经打包好的服务)并且需要组织除了其现存的应用程序服务器投资之外去使用一个品牌的应用程序服务器。除此以外，它也引入了一个充分的潜伏期时间：通信不能在服务终端之间直接进行，而要通过作为服务通信导管的ESB来进行。
Madsen说这只是诸多例子中的一个而已，他最近进行BEA AquaLogic ESB和Mule开源ESB的深入研究。
但是，他并不是最终否定SOA和ESB信徒。他指出：“在这种情况下，(使用ESB的情况)有一些非常复杂的东西本不应该如此复杂。”他还补充道，ESB中的SOA使他想起了另外一种全面再利用技术：分布式对象系统(CORBA)。
那么，问题在哪里呢?数据联盟专家复合软件公司的市场副总裁Bob Eve认为问题应该归结为导向的不同――如果不是理念的不同的话： ESB推行者来自火星，而数据管理领袖则来自金星; 反之亦然。Eve想要突出的一点是他们的思维方式不同。
Eve说：“在SOA世界中，存在着事务(导向)型人士、旧的企业应用系统集成(EAI)人士，而现在他们都是从事ESB的。他们同时是事务导向的也是业务流程导向的。在涉及到数据时，他们是单向读写的。这些开发人员使用的范例基本上都是过程逻辑的一种。”
Eve认为数据管理类型倾向于使用更广阔的视角。数据界人士习惯于以数据集合的形式来进行思维。他们不撰写编码，而是在表格之间寻找连接点。这才是他们的思维方式。他们是属于98%读取类。Eve指出“我认为在SOA世界中发生的事情是这样的，起初它确实是由那些尝试将应用程序合成的人主导的――EAI人士。而目前，数据导向的人士也开始发表自己的声音，这将带来大的变化。”
他还说：讽刺的是Web 2.0类型，如那些与企业应用程序集成或企业数据管理都无关的开发人员。
Eve指出：“Web 2.0人士将问题看作一个他们想要加入的大的数据集。他们从一个很新鲜的角度来处理这个问题。他们并没有陷入仅仅考虑事务类型或数据集的情况。他们也并不认为自己必须要拥有ESB，而只是在寻找一个最整洁、最有效的途径来集成他们的资源。”
那些执行SOA策略的客户在面对如何分配ESB支持与数据管理之间的鸿沟问题时必定会遭遇到不可避免的窘境。来自IT服务构造性企业的项目总监Brad Marshall说道，最突出的一点，你不能把一个重点的SOA项目完全就是单纯的按照SOA的做法来做。当然，也不是因为周围的人(或者仅仅只是其竞争对手)采用了更简单的ESB路线所以就去采用ESB的做法。公司应及时的接受SOA所能带来的转变，例如它可能会需要更新或替换现有的资产或服务，它会计划引入新的业务流程(或重组现有的工作流程)等等。
在另一个角度来说，在公司有一个明确的变化需求的时候可以考虑采取一个大的SOA项目计划。即便如此，Marshall继续强调公司需要清楚的对技术解决方案有一个准确的评估：正如你可能并不是完全有必要一个绝对成熟的数据整合平台去构建一个全面的数据仓库，不需要一个完全成熟的ESB应用(在保证必要应用的前提下)去实现SOA。他强调，在某些情况下之所以有些项目会出错是因为在其实施过程中过分的沉迷于某些特别的技术和解决方案，不管是对于内部的成员也好或是对外的集成商也好，这样一来会影响更多全面的功能选择。
文章来源于领测软件测试网 https://www.ltesting.net/