《云计算:原理与范式》一3.10 企业对企业集成服务-阿里云开发者社区

开发者社区> 华章出版社> 正文
登录阅读全文

《云计算:原理与范式》一3.10 企业对企业集成服务

简介: 本节书摘来自华章出版社《云计算:原理与范式》一书中的第3章,第3.10节,作者 (澳)Rajkumar Buyya James Broberg Andrzej Goscinski,更多章节内容可以访问云栖社区“华章计算机”公众号查看

3.10 企业对企业集成服务

对于连接地理上分散的企业而言,企业对企业集成(B2Bi)是具有针对性和互利合作的主流活动。产品供应商纷纷生产B2B集线器和套件,使参与企业间以标准兼容的方式顺利共享数据。现在,随着云的普及,用认真和真诚的态度努力放置云中的这些产品,用极少的投资和维护成本将B2Bi作为服务提供。云的思想和理念为从资本支出到运营开支转变和维持转换奠定了强有力和刺激的基础。
在B2Bi空间中有几个成熟的集成方法。为了实现更快的成功,在不断变化的IaaS场景中取得更好的回报和价值,可以捕获这些方法并使之资本化。B2Bi系统是IaaS的极佳候选,因为传统上利用B2Bi系统可以在制造商和它们的外部贸易伙伴(如零售、仓储、运输、库存系统)之间使业务流程自动化。这意味着,它们提供了这样的关键功能——用于连接内部和外部软件的应用程序到应用程序(A2A)的连接,即跨越企业防火墙的安全的数据交换。
与仅用于内部数据共享的纯企业应用集成(EAI)解决方案有所不同,B2Bi平台有能力通过公共网络对文件加密、管理大量的数据卷、传输批处理文件、转换成不同的文件格式,并保证数据的准确、完整、保密和交付。有确保在制造商及其外部供应商或客户之间沟通顺畅的能力,它们还在托管和安装的应用程序之间可靠地交流。
IaaS模式还充分利用由B2Bi厂商开发的适配器库提供与各个业务系统的快速集成。B2Bi合作伙伴专业知识渊博、经验丰富,他们为主要的ERP、CRM、SCM和其他打包的业务应用(packaged business application),以及从AS400到MVS和大型机的遗留系统提供了预构建的连接器。星型拓扑集中式架构的使用进一步简化了实施,该架构为系统管理提供了良好的控制。最终,这避免了客户端上放置过多的进程负担。在SaaS供应商的云中心安装集线器(hub),以完成类似重新格式化文件的重任。一个分支单元通常包含一个小的可下载的Java客户端,接着在每个用户站点部署该分支单元以处理如数据传输等基本任务。这也消除了昂贵的基于服务器的解决方案、数据映射和客户所在地的其他任务的需求。由于Internet是主要的通信基础设施,因此企业可以与他们世界各地的合作伙伴进行智能和系统协作以保持同步。
用于B2B场景的基于云的企业混搭集成服务[17]。对于生疏、情景和特定的B2B应用程序而言,大量的业务最终使用者有着巨大的需求。企业混搭和轻量级组合方法及工具是有前景的方法,它们释放授权最终用户的巨大的、尚未开发的潜力以开发或组装对齐,并意识到综合服务以克服“长尾”的窘境。当前,支持B2B协作的可用解决方案聚焦于长期业务关系的自动化,它们仍然缺乏提供给用户直观的方式,以根据用户的特定或情境需要修改或扩展这些解决方案。由于较长的开发周期和缺乏所需的业务知识,这类应用开发中的常规程序需要耗费大量的时间和人力。
特别是在支持B2B协作的领域中,目前产品的特点是高丰度、低范围。如以众多功能为重点的B2B分支,尽管支持电子协作,但小型团体甚至个人则缺乏可用性。另一个具有低范围、高丰度的极端解决方案,如Web站点、门户网站和电子邮件,缺乏标准化和公式化,这使得它们不适合自动化或特殊企业的需求。因此,新的开发方法需要克服这些障碍,涉及开发过程中的非技术性商业用户。为了解决这个长尾综合征,实现成本效益和效率的提高,并克服IT部门与经营单位之间的常规限制。
企业混搭应用是一种新一代基于Web的应用,似乎充分履行最终用户的个别和异构要求并促进最终用户开发(EUD)。为了缩短传统和费时的开发过程,这些新品种的应用由非专业程序员开发,往往以非正式、迭代和协作的方式组装现有的结构块(building block)。
SOA一直是组织的集成困境的一种有效解决方案。在SOA驱动的公司内,ESB用于集成不同的服务。然而,大多数ESB都没有被指定为跨组织的协作,因此在阐明和针对这种扩展协作时会出现问题。SOA简化和精简了新的服务及第三方服务的集成,然而熟练的和经验丰富的开发人员仍然可以完成它。最终用户通常不能实现想要的集成方案。在集成项目的高成本下,这导致不必要的僵化。因为集成项目持续更长的时间,尽管市场竞争要求积极主动地及时响应兴起的要求。
B2B集成中的另外一个挑战是进程的所有权和责任。在许多组织间的设置中,业务流程只有稀疏的结构和形式,而非松散耦合和基于特定合作。组织间的合作往往涉及越来越多的参与者,不断增加的参与者还绘制了大量的不同要求。另外,参与者可根据不同的角色、控制和优先权做事。从历史上看,合作的重点是根据一套规则管理团队的参与。
现在,对供应商和合作伙伴共同创新及客户共同创造的支持,其重点是转向支持参与者的合作,但参与者受到多个领域控制和不同过程和实践的限制。这表示从静态的B2B方法到新的动态的B2B集成游戏规则的转变,可以自适应行为并对任何意外干扰作出反应,可以允许快速配置和定制并管理和节制端到端业务流程使用的日益复杂性。
电子数据交换(EDI)转换器和受管文件传输(MFT)都有一个较长的历史,而B2B网关则在过去十年中才出现。然而,大多数可用的解决方案旨在支持中大型规模的公司,导致成本高、实施周期和时间长,这使得他们无法负担,对规模较小的组织也无吸引力。因此,这些产品并不适合短期合作,这需要用特定的方式设置。
企业混搭平台和工具。混搭应用善于结合不同的分布式资源,包括内容、数据或应用功能。资源表示混搭应用的核心结构块。人们可以通过API访问资源,其中API封装资源并描述可用的接口。小部件或小工具主要放在底层资源,为它们提供图形表示及从资源接收到的管道数据。管道可以包括运算符,如聚合、合并或过滤。混搭平台是一种基于Web的工具,它允许通过管道资源一起进入小工具和接线小工具来创建混搭应用。
企业混搭应用在B2B集成场景中极具优势,大家已意识到并为其做好准备。混搭应用能解决许多B2B分支的缺点,如硬接线连接的下游。混搭应用允许EUD和轻量级系统连接,可以使现有的轻量级解决方案更加丰富,如增加一定程度的规范和标准的网站或门户网站。混搭应用促进易于混合及转换各种内部和商业伙伴的信息来源。B2B操作中的复杂性往往与异构系统和平台有关。烦琐的集成进程及各种支持和软件维护的要求是当今动态B2B集成的一个主要障碍,对中小型企业来说更是如此。
混搭集成服务正在FAST项目中作为原型实施。图3.9中的体系结构是对原型层的说明,它描述了这些服务如何协同工作。该框架的作者对使用云基础设施和服务的服务技术实现前景做出了展望。
原型架构显示了服务和彼此之间的关系。中间方框内显示的是核心服务。中间方框下显示的是扩展服务,通过API允许使用第三方产品实现其功能。用户通过自己选择的混搭平台使用这些服务。通过API将混搭平台连接到混搭集成服务。
要想使用这些服务,用户必须确定自己对用户的访问控制服务。该服务连接到用户管理服务,从而控制用户及其设置。用户管理服务通过一个API连接,允许使用外部服务,如企业用户数据库。所有来自用户的数据通过转换引擎(translation engine)统一数据对象和协议,集成不同的混搭平台。转换引擎有一个接口,可以连接其他外部转换引擎以支持额外的协议和数据标准。被转换的数据转发给路由引擎(routing engine),这是混搭集成服务的核心。路由引擎处理混搭平台收到的各种输入,并转发给正确的收件人。人们可以通过API配置以许多规则为基础的路由。
为了简化这一架构,可以为最终用户提供Gadget。路由引擎还通过API连接一个消息队列。因此,不同的消息队列引擎是可连接的。消息队列负责存储和转发由路由引擎控制的消息。消息队列下面的持久性存储可存储大量的数据,它还可以通过API连接以允许可交换性。错误处理和监控服务允许跟踪消息流以检测错误,并收集统计数据。混搭集成服务作为一种基于云的服务托管。另外,还有一些基于云的服务提供集成服务所需的功能。这样,混搭集成服务可以重复使用,并充分利用现有的云服务加快实施。
消息队列。使用Amazon简单队列服务(SQS)可实现消息队列。SQS是一个Web服务,它为消息提供了一个队列,并存储这些消息直到其可以处理。混搭集成服务,尤其是路由引擎,可以将这些消息放入队列中,并在需要时再调出它们。
持久性存储。Amazon简单存储服务(S3)也是一种Web服务。路由引擎可以使用该服务存储大量的文件。

image

转换引擎。这主要集中在混搭平台可以连接理解的不同协议(如REST或SOAP Web服务)之间的转换。然而,如果转换的对象需要转换时,可能会连接到转换引擎。一方面,需要这种服务的A公司可以开发这样的服务,并把它连接到混搭集成服务。另外一种可能性是连接现有的转换服务,如Mule on Demand提供的许多服务,也是基于云计算的产品。
服务之间的交互。图3.9描述的是混搭集成服务平台交付和处理消息的过程。这一过程的先决条件是用户已经建立了一个收件人的路由。通过API收到来自企业混搭工具的消息后,首先检查消息发送者对外部服务的访问权限。只有授权消息发送者,才能处理收到的消息。也就是说,消息发送者有权利将消息传递到收件人并使用混搭集成服务。如果他没有被授权,处理过程则停止,并记录一个错误信息。错误日志信息将写入日志文件,它会驻留在Amazon的简单存储服务。如果已接受该消息,则放入Amazon的SQS服务消息队列中。如果需要,可以把该消息转换成另外一种格式,它也可以由外部的、基于云的服务完成。随后,这些服务就可以开始尝试将消息传递到收件人。评估消息的收件人是以存储在路由引擎中的规则为基础的,这些规则用户之前已配置过。最后,可以记录该消息的成功交付,若发生错误亦可记录。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享: