3.5 走近SaaS集成之谜

集成即服务是一个典型的企业应用集成（EAI）集线器（hub）/企业服务总线（ESB）的例子，它提供了云功能迁移，在任何企业和SaaS应用之间顺利地传输数据。用户订阅IaaS，因为它们能做任何其他的SaaS应用程序。云中间件是未来传统中间件解决方案的逻辑演变。也就是说，云中间件将作为服务提供。由于不同的集成要求和方案，还有一些中间件技术与产品，如兼容JMS的消息队列和集成主干，EAI、ESB、EII、EDB、CEP等。由于性能的缘故，需要利用集群、架构、网格以及联合使用集线器、中介和总线。

对于服务集成而言，它是企业服务总线（ESB）；对于数据集成，它是企业数据总线（EDB）。此外，还有面向中间件的消息（MOM）和消息代理，它们通过传送和接受的消息集成解耦应用。事件正在快速出现。复杂事件处理（CEP）引擎收到不同来源的多重事件流，实时处理这些事件流以便提取并计算出封装的知识，据此选择并激活一个或多个目标应用程序。从而在初始和目标应用程序之间应用轻型连接和集成。服务编制（orchestration）和编排（choreography）整合流程。通过ESB的服务交互集成松散耦合系统，而CEP则连接解耦系统。除了数据服务，混搭应用（mashups）执行并提供综合服务、数据和意见。因此，在企业IT堆栈的每一层或者每一级中，均有主管的集成模块，并为万众瞩目的动态集成酝酿指导方针。随着云使用的空前上升，所有这些集成软件势必迁移到云中。Amazon的简单队列服务（SQS）提供了一种简单的方法，应用程序通过云中的队列交换消息。理解一个熟悉的内部服务改写为云服务时发生了什么事情——SQS便是一个典型的例子。不过，这也有一些问题。因为SQS的复制跨越多个队列的消息，从队列中读取应用程序不能保证看到来自一个特定的读请求队列的所有消息。SQS也不会承诺按顺序恰好一次交付。这些简化使Amazon令SQS更具可扩展性，但同时也意味着开发人员必须有区别地使用来自内部消息队列技术的SQS。如果SaaS应用程序不运行在云基础设施上，则没有多大用处，同样，它们若不访问关键企业数据（通常锁定在不同的企业系统中）也没有多大价值。因此，对于提供用户最大价值的云应用而言，它们需要提供一个简单的机制，导入或者加载外部数据，导出或者复制它们的数据以报告或分析其目标，并最终使它们的数据与内部应用同步。这使SaaS集成主题变得重要起来。正如David Linthicum在其中一份“白皮书”中所言，从接近SaaS到企业的集成确实是选择的问题，这需要做出明智的选择。选择主要围绕利用架构模式集成的方法、集成引擎的位置并最终启用该技术。SaaS前所未有的增长意味着越来越多的软件组件开始迁移并寄居在外部SaaS平台。因此，在远程云平台与内部企业平台之间集成的需要（其中存储的客户和企业数据确保牢不可破、无可挑剔和坚不可摧的安全）已受到密切关注，并增强了产品供应商和SaaS供应商的想象力。SaaS集成为何异常困难？正如前面的一份“白皮书”所述，最近有一个中型造纸公司成了Salesforce.com的CRM客户。目前，该公司利用内部自定义系统，采用Oracle数据库跟踪库存和销售。Salesforce.com系统的使用提供了公司与客户和销售管理方面的显著价值。但是，存留在Salesforce.com系统内的信息相比存储在内部遗留系统内的信息（例如，客户数据）而言有点多余。因此，“保持原样”是一个模糊的状态。该状态经历各种无效成本，包括在两个不同的位置输入和维护数据的需要，最终公司会花费更多的成本。另一件令人烦恼的事：在考虑这种对偶运算时，流行的数据质量损失。这包括数据完整性问题，当使用不同的程序更新数据时，这是一种自然现象，在SaaS和内部部署系统之间并没有主动同步。在理解和界定了“存在”（to be）状态后，在源（即Salesforce. com）与目标（即利用Oracle数据库的现有遗留系统）之间提出了最佳的建议——数据同步技术。该技术能够提供两个系统之间的差异，包括应用程序语义、安全、接口、协议和原生数据格式的自动调解。最终结果是，在SaaS交付系统和遗留系统内的信息是完全紧密同步的，即输入到CRM系统中的数据也存在于遗留系统内，反之亦然，其他操作数据例如库存、项目出售等。“存在”状态进而完全消除了数据质量和完整性问题。这为一个月节省几千块钱直接或间接地铺平了道路，从研究和利用的集成技术中快速实现投资回报率（ROI）。多年来集成一直是学术界学习和研究的主题。集成使异构系统、网络和服务创建的秩序感一片混乱和一塌糊涂。集成技术、工具、技巧、最佳实践、准则、指标、模式和平台是多种多样的。集成不容易实施，成功解决棘手情况是一个大问题。网站的应用和数据孤岛使集成任务异常艰巨，因此频繁地为灵活和未来的集成选择一个同类最佳方案。首先，需要获得关于SaaS应用程序的特性和原则的概览，以取得一个合适的集成路线。SaaS应用程序的约束属性有：SaaS接口不断变化的动态特性。供给本地SaaS供应商（如Salesforce.com）的元数据的动态特性。管理防火墙之外的资产。大量的信息需要在SaaS和日常内部部署系统之间移动，这需要保持数据的质量和完整性。随着SaaS存放在云基础设施上，我们需要思考由云带来的干扰，并规定行之有效的解决方案。如果在本地集成时遇到困难，那么云的集成势必更加复杂。最可能的原因有：新的集成方案。云的访问或许受限。动态资源。性能。受限的访问。访问云资源（SaaS、PaaS及基础设施）比本地应用更受限。访问本地应用程序十分简单、快速。嵌入本地及自定义应用程序的集成点比较容易。即使是商业应用，在数据库触发器内引发事件并提供集成访问的钩子（hook）始终是可行的。由于不再有低级别的访问，一旦应用程序迁移到云，设计的自定义应用程序必须支持集成。企业将他们的应用程序放在云中或放在基于云的业务服务的订阅者那里，这些企业依赖于供应商提供集成钩子和API。例如，SalesForce.com Web服务API并不支持多个记录的交易，这意味着集成代码必须处理这种逻辑。对于PaaS而言，该平台可能支持平台上的应用集成。然而，平台到平台的集成仍然是一个悬而未决的问题。有一项协议——有限API将在一定程度上改善这种情况。但这些API必须能够处理所需的集成。应用程序和数据可以迁移到公共云，但应用程序供应商和数据所有者失去了急需的可控性和灵活性，大多数第三方云服务供应商并不提交他们的基础设施给第三方审核。鉴于这一转变，可见性是失败的另一重要因素。动态资源。云资源是虚拟和面向服务的。也就是说，一切都是以服务的形式展现出来的。鉴于这种动态因素席卷整个生态系统，应用程序版本和基础设施的变化对动态变化负责。这些显然影响了集成的模式。也就是说，紧耦合的集成是失败的，它们在云上还不稳定。很明显，低级别的接口应该遵循表述性状态转移（REST）的路线，这是一种简单的架构风格，也是订阅HTTP协议的标准方法。性能。云支持应用的可扩展性和资源的弹性性能。然而，任何人无法控制云中各个元素之间的网络距离。在大多数集成场景下，带宽不再是限制因素。但往返延迟却是一个无法回避的问题。由于延迟恶化，云集成的性能势必放缓。