系统集成的下一代进化:“区块链即集成”(系统集成阶段)
下面由小编针对系统集成的下一代进化:“区块链即集成”为您答疑解惑,希望能给您带来有一些有效参考。
多年以来,让企业/组织最为头疼的一个问题就是自己的系统没有较强的集成性,而且难以形成一个基于特定行业的去信任网络(trustless network)。
不过现在,区块链和分布式账本技术(DLT)可能成为实现这一颠覆性愿景的基础。
企业级集成对于一些大公司和大型机构组织而言,他们的应用程序和 APP 大都是在“孤岛”中独立运行,这些“孤岛”往往需要共享数据和功能才能“步调一致”地运行。
对于单个企业而言,如果想要实现数据和业务流程共享,就必须要与其他系统和应用程序进行对接,而这个过程就被称为“企业应用程序集成”(EAI:Enterprise Application Integration)。
另一方面,在共享数据和功能的时候,企业/组织往往希望寻求一种能够控制方式来管理整个流程,也只有在这种情况下,他们才能放心地把关键业务流程集成(或自动化)扩展到组织外部。
这其实是“企业应用程序集成”的一种扩展,可以通过一种被称为“B2B 集成”的消息标准交换结构化数据来实现。
从根本上来说,“企业应用程序集成”和“B2B 集成”这两个专业术语都是指跨越多个系统(有时也涉及多方)的数据和功能集成过程。
然而需要注意的是,企业内部系统和业务流程会不断发展,而支持 B2B 统一化的技术也在不断进步。
企业/组织系统集成技术的进化到目前为止,我们似乎很少看到某一个企业/组织的系统集成技术成为主流,因为这种技术的发展通常是建立在彼此支持的基础之上,而现实世界里的商业竞争往往让企业/组织之间变得越来越封闭。
在此,我们并不是要专注于某个特定技术、或是某个特定的年份,而是尝试观察最近几十年来的发展,以便让大家了解为什么说区块链会是下一个技术迭代的关键要素。
下表是集成技术的进化历史概览:接下来,我们要探讨上表中列出的每个进化过程中是如何实现技术进步的。
数据集成数据集成是最古老的跨系统信息访问机制之一,它具有以下两个主要示例:1、通用数据库方法被用于企业内部的系统集成:2、文件共享方法被用于企业内部和企业之间的数据交换。
借助FTP等通用协议,文件共享让应用程序数据在不同设备和操作系统之间被交换。
但是这两种方法都不是实时的,而且只能通过批处理的方式才能完成数据集成操作,因此在可扩展性和可靠性方面都存在一定的局限性。
功能集成数据集成提供了非实时的数据交换,而这里将要描述的功能集成则提供了实时的数据交换和功能交换:1、远程过程调用(Remote procedure call)通过“隐藏”了网络和数据编组复杂性,将基于套接字的低级别集成进行了重大优化,但是它其实是一个依赖于语言的、早期点对点的客户端-服务器架构。
2、对象请求代管者体系结构(Object request broker architecture)使用公用对象请求代管者体系结构(CORBA)、分布式组件对象模式(DCOM)、以及远程方法调用(RMI)实现,并引入了代管者组件,该组件允许不同语言的多个应用程序重复使用相同的基础结构并以P2P的方式相互通信。
此外,公用对象请求代管者体系结构模型还具有命名、安全性、并发性、事务性、注册表、预计与语言无关的接口定义概念。
3、消息传递在应用程序之间引入了时间解耦(temporal decoupling)的概念,并确保异步消息传递。
(耦合是指两个或两个以上的体系或两种运动形式间通过相互作用而彼此影响以至联合起来的现象。
解耦就是用数学方法将两种运动分离开来处理问题,常用解耦方法就是忽略或简化对所研究问题影响较小的一种运动,只分析主要的运动。
)到目前为止,我们已经看到了许多技术进步,但是他们主要关注的是系统集成而不是应用程序集成。
从批处理到实时数据交换、从点对点到 P2P、从同步到异步,所有这些方法都不关心、或是不控制他们交换的数据类型,也不会强制验证数据。
尽管如此,这种早期的集成基础设施通过交换基于电子数据交换(EDI)格式的数据来实现 B2B 集成,但是他们其实并不了解企业数据和业务流程,或者只了解了其中的一部分。
使用公用对象请求代管者体系结构,我们可以更早地尝试应用程序接口、以及对应用程序集成有用的服务。
面向服务架构面向服务架构(SOA)的主要目的,其实是推出一系列 Web 服务标准:1、XML 提供了与语言无关的数据交换格式:2、SOAP 提供了通用消息格式:3、WSDL 提供用于描述服务接口的独立格式。
这一切都是构成Web服务的基础,这些标准与企业服务总线(ESB)和业务流程管理(BPM)相结合,使集成更专注于业务集成语言。
相比之下,之前的技术更多地是在系统层面进行集成。
ESB 全称为 Enterprise Service Bus,即企业服务总线。
它是传统中间件技术与 XML、Web 服务等技术结合的产物。
ESB 提供了网络中最基本的连接中枢,是构筑企业神经系统的必要元素。
ESB的出现改变了传统的软件架构,可以提供比传统中间件产品更为廉价的解决方案,同时它还可以消除不同应用之间的技术差异,让不同的应用服务器协调运作,实现了不同服务之间的通信与整合。
从功能上看,ESB 提供了事件驱动和文档导向的处理模式,以及分布式的运行管理机制,它支持基于内容的路由和过滤,具备了复杂数据的传输能力,并可以提供一系列的标准接口:另一方面,BPM,即业务流程管理,是一种以规范化的构造端到端的卓越业务流程为中心,以持续的提高组织业务绩效为目的的系统化方法,常见商业管理教育如 EMBA、MBA 等均将 BPM 包含在内。
Web 服务让系统不再盲目地交换数据,而是按照机器可读的合约和接口定义来交换数据,此类合约能够让某个系统和其他系统进行交互之前理解、并验证数据。
这里还包含了微服务架构,就其核心而言,微服务架构构建、并改进了面向服务架构和企业服务总线——此阶段的主要进化,是围绕分布式系统从Web 服务向基于表述性状态传递的交互过渡。
表述性状态传递(英文:Representational State Transfer,简称REST)是 Roy Fielding 博士在 2000 年他的博士论文中提出来的一种软件架构风格,它是一种针对网络应用的设计和开发方式,可以降低开发的复杂性,提高系统的可伸缩性。
目前在三种主流的 Web 服务实现方案中,因为 REST 模式的Web 服务与复杂的 SOAP 和 XML-RPC 对比来讲明显的更加简洁,越来越多的 Web 服务开始采用 REST 风格设计和实现。
例如,Amazon.com 提供接近 REST 风格的 Web 服务进行图书查找:雅虎提供的 Web 服务也是 REST 风格的。
总之,这个阶段中,在通用协议基础上,分布式系统也能获得通用标准和合约定义(contracts definitions)。
基于区块链的集成虽然利用通用协议和标准对交换数据有一定帮助,但服务合约却无法提供隐藏在合约背后、并在远程系统上运行的业务流程信息。
一个业务请求可能在合约层面上有效,但在业务流程的某个状态下无效,这种情况会在两方之间进行集成的时候——比如在客户端-服务器模型、以及在 P2P 模型中多个参与方之间进行集成的时候产生很多问题。
有时多个参与方也会是同一业务流程的一部分,有时业务流程也会被其中一方而非所有各方拥有。
而这种能够让多方互动正常运作的先决条件,就是要确保共同业务流程及其当前状态的透明度。
所有这一切,都让能够在多方之间实施分布式业务流程的区块链技术变得极具吸引力。
通过共享业务流程和包含状态,基于区块链技术的集成模型扩展了共享协议和服务合约,而且所有参与实体都能以智能合约的形式共享同一业务流程。
本文到此结束,希望能给网友您带来不错的体验。