一开始，什么都没有
如果你仔细想想，标准和协议在任务完成后就会出现它们本来要简化的东西已经出现了一段时间了，没有两组是用同样的方法来做的。这适用于软件,移动开发如何成为标准化的最近的一个例子,你甚至可以创建一个应用程序,该应用程序将在所有主要的操作系统的工作(这不是很久以前当你必须使用不同的技术对不同型号的设备从同一家公司)。
因此，在一开始，当分布式计算的需求出现，不同的系统需要相互通信时，第一个解决方案并不是完全开放的。在70年代，最早记录的系统集成技术之一被称为EDI(电子数据交换)。它的开发是为了让公司能够无缝地交换有价值的文件。没有任何一种语言可以轻易实现的标准。相反，EDI提供了一组软件工具，可以让您执行交换。EDI的另一个关键方面是，交换的文档具有非常明确的格式，允许使用这些格式。
这与强迫XML进入消息格式不同，这是一种设计用来交换文档的协议，但是这些文档只能在符合一个已批准的标准(维基百科中的X12文档列表页面包含完整的列表)的情况下才能被转移。
此外，EDI支持不同的传输媒介，这不是很常见，现在一些最常用的集成协议都是在HTTP之上工作的，但是EDI支持HTTP，并支持FTP、e-mail、AS1等通道。
尽管EDI已经存在了40多年，并强制转换文件的标准，但许多政府内部使用它在组织之间共享文件。标准列表也在不断更新，因此一旦需要，就会添加新的标准。
通过RPC（远程过程调用）集成系统
RPC是在80年代开发的，它不是通过允许系统交换数字文档来集成系统，而是允许分布式系统通过远程执行过程(或子例程)相互集成，就像它是一个单一的系统一样。
追溯这项技术的起源有点棘手，因为有人会说，理论上的实施建议可以追溯到70年代，但最初的几项实际实施开始于80年代初。事实上，RPC一词是1981年美国计算机科学家布鲁斯·杰伊·纳尔逊发明的。
话虽如此，RPC有一个小问题，我将其归因于它是第一次尝试解决当时非常新的问题:实现是依赖于语言的。实际上，最初的一些实现实际上需要创建专用的编程语言，比如Lupine，它是RPC的第一个实际的实现，由Nelson和Andrew Birrel在XEROX开发。
RPC的第一个流行实现是Sun的RPC，现在称为ONC RPC，它被用作NFS(网络文件系统)的基础。
它是如何工作的呢?
您可以一直提取RPC到一个简单的客户机-服务器通信协议，其中调用代码充当客户机，执行子例程充当服务器。
通过提供一种简单的方法来复制远程过程的接口，它被标准化了。接口定义语言(简称IDL)用于定义接口，通过生成器，您可以获取这些IDL文件，并使用您选择的语言生成您自己的客户机和服务器存根。
在PRC通信期间，简化了客户端和服务器之间的交互
前面的图提供了RPC通信中涉及的不同组件的更多细节。虽然每个实现的细节可能各不相同，但它的基础是:
1、客户机应用程序与客户机存根绑定，客户机存根基本上是试图执行的远程过程的“伪”实例(相同的接口，但不是实际的过程)。
2、客户机代码执行存根，将所需的参数发送给它。
3、客户端存根将封送参数(这是“序列化”的时髦说法)并将它们传输到服务器存根。
4、服务器存根将依次分解包(这也是用于从接收到的序列化包中重新创建参数的代码)。
5、服务器存根将执行服务器代码，传递接收到的(现在已解组)参数。
来自过程调用的响应将经历相同的反向过程(编组、通过网络传输、编出和客户机代码的最终接收)并发送到客户机上。
这种方法的主要缺点之一是，它试图向开发人员隐藏服务器的非本地性，但无法自己处理网络问题。因此，开发人员需要在客户端编写网络错误处理代码，打破这种方法最初意图提供的假象(客户机和服务器之间没有任何东西)。
CORBA，朝着正确的方向迈出了一步
CORBA诞生于90年代早期，作为弥补RPC和其他类似尝试留下的鸿沟的尝试。尽管它们都成功地实现了分布式系统的通信，但它们并没有成功地提供使用不同技术构建的系统的异构集成方式。有些协议适用于某些语言，有些则不适用。
因此，由对象管理组(OMG)定义的公共对象请求代理体系结构试图提供一种语言和操作系统无关的方式，允许两个基于corba的系统相互交互。
从本质上说，CORBA是RPC的面向对象实现，它不关注用于创建系统的语言。效果同样的RPC,通过创建和发布共享服务IDL,尽管这个由OMG IDL设计和管理,和客户需要使用它们来创建存根以及服务器创建他们的骨骼(这将是之前的服务器存根)。
它还提供了许多其他好处，例如:
1、异构访问:语言和操作系统的自由是CORBA在先前的系统集成尝试中获胜的关键特性之一。
2、数据类型:IDLs允许开发人员在系统之间映射类型，考虑到这意味着在不完全兼容的技术之间进行映射。
3、更好的传输错误处理:CORBA允许应用程序确定调用是否由于网络问题或其他问题而失败。
4、最后，在编组要来回发送的参数时进行数据压缩。这是由爱奥纳公司(IONA)和西班牙电信公司(Telefonica)开发的，后来作为标准的一部分被加入其中。
SOAP API
尽管CORBA提供了很多好处，但是一旦W3C(万维网联盟)发布了他们的XML规范，系统集成就朝着不同的方向发展。突然之间，微软能够让主要的IT公司，比如IBM，开始采用他们在1998年左右创建的简单对象访问协议(简称SOAP)。
这一次，抽象层又被提出了，您实际上是在对外部服务执行远程请求，而不是像执行本地方法调用那样执行远程方法调用。
与以前的方案相比，这个新方案具有以下优点:
1、它独立于所使用的编程模型。它不受面向对象编程或过程编程的约束。
2、它是可扩展的。随着时间的推移，可以以无缝的方式向协议添加更新和改进。
3、它对通信层是中立的。SOAP可以通过HTTP、SMTP、TCP等任何协议实现。
在SOAP被定义之后，它成为一个更大的技术栈的基础，该技术栈将用于定义和使用Web服务。
这个技术栈由:
1、Web服务定义语言(WSDL)作为定义这些服务接口的手段。
2、SOAP作为消息传递协议，用于将数据从客户端传输到服务器并返回。
3、统一描述发现和集成(UDDI)协议，它允许全球范围内的服务在一个集中的发现平台中发布它们自己，允许寻找这些服务的客户在不知道它们在哪里的情况下找到它们。
下图显示了上述元素如何相互作用:
简单解释UDDI、客户机和服务之间的交互
基于SOAP的服务接管了系统集成空间一段时间，XML是新的标准，它带来了一些急需的好处，例如:
1、灵活性：您可以将XML用于任何您想要的东西，因此您的服务都是由它定义的，并且使用它传输数据。这种简化的开发只需要用户理解和解析一种语言。
2、验证：通过定义和使用XML模式，您可以使用另一种标准验证消息中的正确性。这简化了为新服务创建特别验证的任务，因为拥有标准验证语言导致跨所有语言创建验证工具和库。
3、人类可读的：这是当时的一个主要好处。其他解决方案将使用二进制协议对其数据进行编码，使人们无法直接读取数据并验证其格式和正确性。通过使其消息具有人类可读性的结构，它通过减少调试时间为开发人员提供了更好的体验。
最终，XML和强加在其消息上的笨重的格式SOAP也将成为其主要缺点之一，而其他更精简的选项将取而代之。
REST是新的SOAP
尽管它们同时存在，而且许多遗留服务仍然使用基于SOAP的web服务，但在过去5到10年里，出现了从SOAP转向REST的趋势。
REST表示具象状态转移，它是一种基于资源而不是动作的系统集成方式。我们已经从过程和方法调用转移到使用SOAP的远程操作调用，现在，我们甚至从操作转移到资源。REST背后的理念是，您的服务基于客户需要与之交互的资源，您在客户端和服务器之间传输的只是这些资源的状态，而不是其他。
这不是web服务的协议或样式指南，它只是Roy Fielding在2000年的博士论文中定义的体系结构样式。他的建议定义REST来利用HTTP的特性，例如响应代码(2xx和3xx表示成功响应，4xx表示客户端错误，5xx表示服务器错误)、动词(例如GET、POST、PUT等)和其他。随着时间的推移，HTTP只是可以在其上实现的众多协议之一。
REST的另一个关键方面(以前的集成解决方案中没有这种情况)是，它不强制在客户机-服务器通信期间传输数据的格式。实际上，它欢迎同一资源状态的不同表示，因此您可以使用使用XML的RESTful服务，而其他人则返回其资源的二进制表示。同时，您甚至可以拥有相同的服务，提供相同资源的两个版本。最后，是由服务和客户同意使用的最佳表示。这导致采用了一种更轻便、更简洁的方式，通过HTTP: JSON来回发送信息。您甚至可以声明，这种采用有点失控，因为现在许多开发人员实际上认为JSON是REST定义的一部分，因此，服务是RESTful的需求(如果您阅读Fielding的论文，就不会看到这种情况)。
虽然许多开发人员会发誓不使用REST，就像软件开发的所有方面一样，但是并没有什么灵丹妙药，而且就像之前的所有情况一样，REST也有它的缺点:
1、如果需要从多个资源中提取数据，通常需要客户端进行多次往返，以获得所需的所有信息。
2、HTTP增加的延迟在一些关键系统中可能是一个问题。
3、如果您的服务不能围绕资源构建，那么强制在其上进行REST将不会产生理想的结果。
4、客户机和服务器之间的交互本质上是异步的，当您需要在客户机和服务器之间进行类似套接字的通信时，会产生问题。
新技术
现在，我们将讨论系统集成的当前状态:GraphQL.4 它被定义为APIs的查询语言，它简化了一个与REST不同的任务:查询资源。它最初是由Facebook创建的，但由于是开源的，许多组织都在改进它。
GraphQL基本上提供的是一种查询资源的语言，这种语言是强类型的，因此可以尽早捕获错误(这就是松散类型系统(如REST)所发生的情况)。在这种情况下,请求和各自的响应都是基于json,但是客户允许定义正是他们想要的信息在他们的反应,包括相关资源与REST(你必须实现某种特别的解决方案或只是你的客户做很多请求得到的)。
GraphQL提出的体系结构使后端能够提供单个入口点，可以查询该入口点以获得任何可用资源。它也可以作为一个简单的“数据库包装”在某种意义上你创建一个服务,查询数据库和界面世界GraphQL,它也可以作为一个积分器,从多个远程数据源获取数据并结合在一起之前发送回客户机的响应。
总结
正如我在本文开头所述，系统集成从最初两个需要相互通信的系统开始就存在了。所使用的技术和与之相关的方法随着时间的推移而不断发展，每年都有新的和令人兴奋的方法来执行这些任务。
也就是说，仅仅因为EDI从70年代就存在了，或者仅仅因为REST比SOAP“更好”，并不意味着这些技术不再被使用。事实上，它们之所以被广泛使用，是因为较老的科技公司没有更新系统，要么是因为这样做会对它们的业务造成太大的破坏，要么是因为这样做成本太高。所以，如果你在你的下一个项目中碰巧发现这些老的技术，不要惊讶!
