在IT基础设施中将各种应用软件的数据集成起来是一回事，因为相关方法和实践都经过检验，证明是可行的。但是，在服务导向架构(SOA)上实现数据集成则是另一回事，那可是个新挑战。
“SOA的引入，使数据与应用之间的差别日渐模糊。”SOA市场研究机构ZapThink公司的罗恩?施麦尔泽尔(Ron Schmelzer)总结道。当一套应用软件作为独立的服务，执行某些功能，其运行结果被传递到其他应用软件时，这些结果看起来很像数据。与此类似，对某项服务的查询会启动数据库中的进程，产生的结果看起来很像应用逻辑的导出结果。总之，在服务中，数据与应用逻辑已不再有明显的区别。
重要的是这些结果是否能与下一个操作进行集成。数据的集成目前有几种不同的方式。iWay公司、Software AG公司等企业的产品提供了一些源自于常规企业应用集成的新途径。比如，iWay就拥有一个包括300个适配器(Adapter)的程序库，这些适配器可将应用软件之间或应用软件与数据源之间连接起来。将这些适配器与iWay的Service Manager集成起来，便可解决如何将数据传输至其目的地的问题，从而将不同服务上的数据连接在一起。
香水和个人护理产品厂商科蒂公司(Coty)花了半年时间发现，iWay产品恰是它集成联合利华公司(Unilever)的化妆品业务所需要的。它于2005年末收购了后者。
科蒂的首席财务官(CFO)迈克尔?费绍夫(Michael Fishoff)要求首席信息官(CIO)戴夫?拜里(Dave Berry)，将两家公司面向客户的数据集成到一起，项目截止到去年6月30日。如果届时无法达成目标，两家公司原有的客户利益就势必受到影响，而且该公司还不得不继续维持两支销售团队、两条供应链、以及两套软件基础设施的现状。
在收购联合利华后不久，拜里就听说，美国联邦百货集团(Federated Department Stores)等大客户纷纷抱怨，两家公司合并后，他们的采购员得分别跟两家公司的销售代表洽谈，或者甚至要经过3个系统才能够拿下订单。
过去，联合利华旗下品牌克罗伊(Chloe)或者卡尔文?克莱恩(Calvin Klein)的香水订单得通过JD Edwards系统才能送达法国的里尔。而科蒂旗下热卖的品牌席琳?迪翁(Celine Dion)或者詹尼弗?洛佩兹(Jennifer Lopez)香水必须通过该公司位于德国卡塞尔的其自主研发的仓库管理系统才能下订单。给其他产品下订单也得通过科蒂位于美国北卡罗莱纳州分销中心中的Oracle销售系统才行。“如果我们自己编写代码，根本无法在半年内完成这几个系统的集成工作。”
而将JD Edwards系统与Oracle应用软件或者将Oracle软件与SAP系统连接起来，那正是iWay的连接器和适配器所要做的。拜里认识到，他需要将某些流程合而为一，正是这些流程导致客户从他的公司采购产品时会收到两张发票。
埃森哲公司(Accenture)的业务流程顾问接受了此项任务。埃森哲的业务分析师首先利用iWay的Service Manager产品来弄清楚科蒂不同的订单录入系统之间的差别，然后进行数据的转换过程。
Service Manager软件中有对JD Edwards和SAP系统有一个图形影射功能，每当业务分析师在这个图形影射上绘制业务流程图师，该软件就会自动在订单录入系统之间完成业务流程线条的数据的自动转换。直到将科蒂和联合利华的订单录入系统的输出结果整合起来，生成单一的发票时，这两个订单录入系统才能协同工作。
现任科蒂北美信息管理副总裁加里?盖兰特(Gary Gallant)负责这一艰难的系统集成项目，此前他曾担任联合利华首席IT经理。盖兰特发现，某一天的订单在发送到iWay系统中后，再也没有出现在公司的分销中心。原来这些订单被赋予了错误的格式，因而无法被转化为正确的目标格式，但是iWay并没有向任何人通报这一点。
“这简直是大海捞针，我们需要提高系统的透明度。”盖兰特回忆说。他最终找到了解决办法，即当订单被挂起在“重试”队列中时，系统会给管理员发送消息。
向来我们都是喜欢竞争的，而且是越血腥的竞争越好。这并不令人惊奇。那么，最近一直在谈论的有关SOA和SaaS的争斗又是怎样的情况?双方都在完全不同的平台之后毫不让步，彼此向对方口头上炫耀着自己这方面服务定义的优点，强调对方缺点。
随着两者的日益发展，已经有用户开始通过将SaaS和SOA进行合并来寻找显著的商业机会。在只取首字母的世界中，那些用户已经书面上用这两个广泛的概念进行了自己的伪数学计算，通过这样的方法使他们各自对服务的定义和谐起来：SaaS + SOA = SaaSOA
那么，到底SaaSOA会是怎么样一个稀奇古怪的东西呢。它将怎样被使用呢?在我们明确这点之前，让我们先花一些时间来看看SOA和SaaS实际上究竟有哪些差异。
对于那些SOA的应用来说，每个服务都是一个离散函数。这些离散函数可以和其他的服务整合起来，为像一个完整的订单到现金的工作流之类的更广泛的业务流程服务。
另一方面，一个SaaS的服务，简单的表示这样一个概念：传递软件其实和电话公司传递你的语音邮件服务的方法是一样的。你为了语音邮件要先拨号，然后你听到你自己的名字，接着你听到自己的信息，这就好像那个应用软件只属于你一个人一样。
这就是关键所在。SaaS是关于传递单独的一个软件给许多用户的技术，而SOA则是关于构建灵活的并可以再使用的软件的技术。如果你将这两者放在一起，你就会得到一个SaaS的解决方案，里面包含着使用SOA技术从而实现更为快捷的根据市场条件和用户需求的变化进行调节的目的。
在上面提到的电话的例子中，我们想象一下假设获得你最喜欢的队伍的体育得分的过程是一个SOA的服务。你的电话提供商将可以迅速将这些信息添加到你的SaaS应用软件语音邮件当中，而且允许你在处理你的语音邮件信息的死后收到你的队伍的得分。
实际上，像BEA系统公司以及Tibco软件公司等很多SOA的软件厂商都已经将触角伸向那些电话服务的提供商，为他们提供SOA的技术，将其作为提供商建立那样的SaaS服务的基础。
而像Progress软件公司等其他的软件厂商已经将SaaS列为SOA的书面上的一部分了。他们通过建立一个SaaS的架构并暴露出定义好的业务流程来进行SOA的应用程序软件的整合。Progress公司带着SOA软件和服务将这套框架卖给那些寻求建立SaaS解决方案的独立软件开发商。如果你觉得这些都听起来很牵强的话，我们不妨来看一看Progress已经拥有了一百六十多个多个这样的伙伴而且以及发布了超过四百个基于SOA的SaaS应用程序软件这个事实。
不过，SaaSOA也有一个方面已经被完全意识到了，那就是使用SOA作为链接企业和外部SaaS应用程序主机的方法。也许你现在会有些惊奇，SOA并不能和人对话。更正确的说法，他是和机器是一体的，在终端节点连接的可能是源于内部或者外部服务。例如，使用一个企业服务总线(ESB)，SOA的解决方案将转化不同的数据格式，调停不同的协议，并且能和谐的处理事务。想象一下如果一个内部部署了SOA的企业也使用了SaaS的应用程序软件，例如Salesforce.com。这个公司就能够使用它的企业资源总线把Salesforce.com和他的ERP系统以及CRM系统连接起来。Salesforce.com，毫无疑问的是，从2005年起就为这个目标而奋斗。但是，真正有影响里的，是直到SaaS的用户自己内部使用了SOA的基础设置时才来临。公司程序开发人员然后在其他地方也开始使用Salesforce.com的SOA服务，并宣称他是在企业内部互联网入口或者甚至在ERP系统自身当中的。
无论SOA是不是正在扮演一个SaaS应用程序软件基础的角色或者是能够提供有意义的把公司的资产和SaaS应用程序软件相连接服务的角色，有一件事情是确定的：这两个软件理念一点也不互斥。如果你能够将他们放在一个金属栏杆里面，让他们用拳头打个输赢的话，你将会以得到一个有力的摔跤双人组为结果，能够让工作成为一个能够支持灵活的软件传递和系统集成的——规则固定的SaaSOA。