应用系统间数据传输方式总结

转载自https://www.cnblogs.com/yanayana/p/8831303.html

 一、应用间接口技术

1.文件

两系统间约定文件服务器地址、文件命名规则、文件内容格式等内容，通过上传文件到文件服务器进行数据交互。

最典型的应用场景是批量处理数据：系统A在当天12点之前把要处理的数据生成到一个文件，系统B第二天凌晨1点进行处理，并把处理结果生成到一个文件，系统A第二天12点再进行结果处理。这种状况经常发生在A是事物处理型系统，对响应要求比较高，不适合做数据分析型的工作，而系统B是后台系统，对处理能力要求比较高，适合做批量任务系统。

以上只是说明通过文件方式的数据交互，实际情况B完成任务之后，可能通过socket的方式通知A，不一定是通过文件方式。

文件方式的优点：

(1)适合数据量大的情况，不会超时，不占用网络带宽。

(2)方案简单（只要接口双方约定好路径、格式、处理方式即可），实现简单、传输批量数据效率较高。避免了网络传输，网络协议相关的概念。

文件方式的缺点：

(1) 不太适合做实时类的业务

(2) 必须有共同的文件服务器，存在安全风险，文件可能被篡改，删除，或者存在泄密等。

(3) 格式没有统一标准，标准性差，当改变文件格式的时候，需要各个系统都同步做修改。

2.数据库共享数据方式

两系统间通过连接同一个数据库服务器的同一张表进行数据交换。当系统A请求系统B处理数据的时候，系统A Insert一条数据，系统B select 系统A插入的数据进行处理。

数据库方式的优点是：

1 相比文件方式传输来说，因为使用的同一个数据库，交互更加简单。

2 由于数据库提供相当多的操作，比如更新，回滚等。交互方式比较灵活，而且通过数据库的事务机制，可以做成可靠性的数据交换。

数据库方式的缺点是：

1 当连接B的系统越来越多的时候，由于数据库的连接池是有限的，导致每个系统分配到的连接不会很多，当系统越来越多的时候，可能导致无可用的数据库连接

2 一般情况，来自两个不同公司的系统，不太会开放自己的数据库给对方连接，因为这样会有安全性影响

 3.消息

基于消息中间件的接口机制主要通过消息传递来完成系统之间的协作和通信，消息中间件最突出的特点就是提供数据传输的可靠性和高效性，主要解决分布式的系统数据传输需求。Java消息服务（Java Message Service）是message数据传输的典型的实现方式。系统A和系统B通过一个消息服务器进行数据交换。系统A发送消息到消息服务器，如果系统B订阅系统A发送过来的消息，消息服务器会消息推送给B。双方约定消息格式即可。目前市场上有很多开源的jms消息中间件，比如  ActiveMQ, OpenJMS 。

消息方式的优点：

1 由于jms定义了规范，有很多的开源的消息中间件可以选择，而且比较通用，接入起来相对也比较简单；

2 通过消息方式比较灵活，可以采取同步，异步，可靠性的消息处理，消息中间件也可以独立出来部署。

消息方式的缺点：

1 学习jms相关的基础知识，消息中间件的具体配置，以及实现的细节对于开发人员来说还是有一点学习成本的；

2 在大数据量的情况下，消息可能会产生积压，导致消息延迟，消息丢失，甚至消息中间件崩溃。

 4.WebService

Web service是一个平台独立的，低耦合的，自包含的、基于可编程的web的应用程序，可使用开放的XML（标准通用标记语言下的一个子集）标准来描述、发布、发现、协调和配置这些应用程序，用于开发分布式的互操作的应用程序。

Web Service技术，能使得运行在不同机器上的不同应用无须借助附加的、专门的第三方软件或硬件，就可相互交换数据或集成。依据Web Service规范实施的应用之间，无论它们所使用的语言、平台或内部协议是什么，都可以相互交换数据。Web Service是自描述、自包含的可用网络模块，可以执行具体的业务功能。Web Service也很容易部署，因为它们基于一些常规的产业标准以及已有的一些技术，诸如标准通用标记语言下的子集XML、HTTP。Web Service减少了应用接口的花费。Web Service为整个企业甚至多个组织之间的业务流程的集成提供了一个通用机制。

首先客户端从服务器的到WebService的WSDL，同时在客户端声称一个代理类(Proxy Class) 这个代理类负责与WebService服务器进行Request 和Response 当一个数据（XML格式的）被封装成SOAP格式的数据流发送到服务器端的时候，就会生成一个进程对象并且把接收到这个Request的SOAP包进行解析，然后对事物进行处理，处理结束以后再对这个计算结果进行SOAP包装，然后把这个包作为一个Response发送给客户端的代理类(Proxy Class)，同样地，这个代理类也对这个SOAP包进行解析处理，继而进行后续操作。这就是WebService的一个运行过程。

Web Service大体上分为5个层次:

 1. Http传输信道

 2. XML的数据格式

 3. SOAP封装格式

 4. WSDL的描述方式

 5. UDDI  UDDI是一种目录服务，企业可以使用它对Webservices进行注册和搜索

Web Service也叫XML Web Service WebService是一种可以接收从Internet或者Intranet上的其它系统中传递过来的请求，轻量级的独立的通讯技术。是通过SOAP在Web上提供的软件服务，使用WSDL文件进行说明，并通过UDDI进行注册。
XML：(ExtensibleMarkup Language)扩展型可标记语言。面向短期的临时数据处理、面向万维网络，是Soap的基础。
Soap：(SimpleObject Access Protocol)简单对象存取协议。是XML Web Service 的通信协议。当用户通过UDDI找到你的WSDL描述文档后，他通过可以SOAP调用你建立的Web服务中的一个或多个操作。SOAP是XML文档形式的调用方法的规范，它可以支持不同的底层接口，像HTTP(S)或者SMTP。
WSDL：(WebServices Description Language) WSDL 文件是一个 XML 文档，用于说明一组 SOAP 消息以及如何交换这些消息。大多数情况下由软件自动生成和使用。
UDDI (Universal Description, Discovery, and Integration) 是一个主要针对Web服务供应商和使用者的新项目。在用户能够调用Web服务之前，必须确定这个服务内包含哪些商务方法，找到被调用的接口定义，还要在服务端来编制软件，UDDI是一种根据描述文档来引导系统查找相应服务的机制。UDDI利用SOAP消息机制（标准的XML/HTTP）来发布，编辑，浏览以及查找注册信息。它采用XML格式来封装各种不同类型的数据，并且发送到注册中心或者由注册中心来返回需要的数据。

（）调用原理

    

 实现一个完整的Web服务包括以下步骤：

◆ Web服务提供者设计实现Web服务，并将调试正确后的Web服务通过Web服务中介者发布，并在UDDI注册中心注册；（发布）
◆ Web服务请求者向Web服务中介者请求特定的服务，中介者根据请求查询UDDI注册中心，为请求者寻找满足请求的服务；（发现）
◆ Web服务中介者向Web服务请求者返回满足条件的Web服务描述信息，该描述信息用WSDL写成，各种支持Web服务的机器都能阅读；（发现）
◆利用从Web服务中介者返回的描述信息生成相应的SOAP消息，发送给Web服务提供者，以实现Web服务的调用；（绑定）
◆ Web服务提供者按SOAP消息执行相应的Web服务，并将服务结果返回给Web服务请求者。（绑定）

（2）调用方式：

1. Net下采用GET/POST/SOAP方式动态调用WebService的简易灵活方法(C#)
webservice 的调用有3种方式
1). httpget 
2). httppost
3). httpsoap
soap 的优点是可以传递结构化的数据，而前两种不行。
btw, soap 最终也是使用 HTTP 传送 XM

WebService方式的优点：

1 适用于网络上不同系统的分布式应用、标准性好、扩展性好、耦合度低；

2.内容由标准文本组成，任何平台和程序语言都可以使用；格式的转换基本不受限制，可以满足不同应用系统的需求。

Webservice方式的缺点：

1 不适合用于实现大批量数据交互的接口。

注：以上描述还需细化，webservice有多种方式，参考：

企业服务总线（ESB）在RESTful架构集成中的作用 

RESTful Webservice

Web Service进阶(七)浅谈SOAP Webservice和RESTful Webservice

XML+HTTP风格架构和RESTful风格架构的webService

Webservice RPC风格 SOAP,REST风格各之间的对比

 5.API

API（ApplicationProgramming Interface，应用程序编程接口）是一些预先定义的函数，目的是提供应用程序与开发人员基于某软件或硬件得以访问一组例程的能力，而又无需访问源码，或理解内部工作机制的细节。

API方式的优点：

1 降低了系统复杂性；

API方式的缺点：

1.对API的学习成本；

2.必须定义统一的开放式API 标准，否则会提高应用代码的维护成本。

 

举例：下面具体来分析一个场景，来看看系统之间数据传输的应用

场景目前业务人员需要导入一个大文件到系统A，系统A保存文件信息，而文件里面的明细信息需要导入到系统B进行分析，当系统B分析完成之后，需要把分析结果通知系统A。

 

A 系统A先保存文件到文件服务器。

B 系统A 通过webservice 调用系统B提供的服务器，把需要处理的文件名发送到系统B。由于文件很大，需要处理很长时间，所以B不及时处理文件，而是保存需要处理的文件名到数据库，通过后台定时调度机制去处理。所以B接收请求成功，立刻返回系统A成功。

C 系统B定时查询数据库记录，通过记录查找文件路径，找到文件进行处理。这个过程很长。

D 系统B处理完成之后发送消息给系统A，告知系统A文件处理完成。

E 系统A 接收到系统B请求来的消息，进行展示任务结果

 

 参考：

应用系统之间数据传输的几种方式

远程通信的几种选择（RPC，Webservice，RMI，JMS的区别）

Webservice工作原理及实例

Web Service

 

二、应用间数据传输的解决方案

1.EAI（Enterprise ApplicationIntegration，企业应用集成）

是将基于各种不同平台、用不同方案建立的异构应用集成的一种方法和技术。EAI 通过建立底层结构，来联系横贯整个企业的异构系统、应用、数据源等，实现企业内部的 ERP、CRM、SCM、数据库、数据仓库，以及其他重要的内部系统之间无缝地共享和交换数据。有了 EAI，企业就可以将企业核心应用和新的 Internet解决方案结合在一起。

 

2.ETL(extraction,transformation and loading)

ETL即数据抽取（ Extract）、转换（ Transform）、装载（ Load）的过程。最初 ETL 的设计是为了方便建立数据市场和数据仓库，并将它们升级为批处理方式。而下一代的 ETL 工具则在许多功能上做了扩展，使其能够适用于企业的应用集成，并且其中的一些工具将能够起到 EAI 某些工具的作用。但是 ETL 还不能取代 EAI，下一代 ETL在应用集成领域中还只是 EAI的补充。但是随着 ETL技术的发展，企业在建立基于批处理数据仓库的系统集成工具时，将越来越关注对 ETL的选择，同时 EAI和 ETL之间的界限也将变得越来越模糊。

 ETL 工具适合数据集成， EAI 工具则适用于流程操作。下一代 ETL 工具更加适用于解决两个系统间数据的批量或者实时同步工作，特别是当大量巨大的数据在两个系统间提取、转换和存储时， ETL 的优势更加明显。 EAI 则适用于工作流和商业流程管理的需求，特别是擅长处理大量小事务。 
对于交互式流程，如果它没有扩展工作流的需求，没有复杂数据的转换的需求，或者需要批量实时数据的合并处理，则 ETL 工具将是比较好的选择。 
ETL 工具比较适合于数据集成的工作，如应用系统之间的数据同步和点对点的单步交互工作；需要实时数据处理的工作中包含了大量的数据处理、复杂的数据传输和数据运算，它同样适合采用 ETL 工具。 
上面这些工作，即便是有些具体的处理需要通过 EAI 工具编程实现，我们还是可以用 ETL 中的工具来处理。因为 ETL工具主要是通过关系型数据库来实现大量数据操作的，所以使用这类工具来传输大块的数据将取得更好的效果。 
EAI 工具无疑是最适合流程集成的工具，如果流程中包含了大量的传输，那么它就必然包含了对业务流程的管理和实时交互的流程。

3.ESB全称为Enterprise Service Bus，即企业服务总线。

它是传统中间件技术与XML、Web服务等技术结合的产物。ESB提供了网络中最基本的连接中枢，是构筑企业神经系统的必要元素。ESB的出现改变了传统的软件架构，可以提供比传统中间件产品更为廉价的解决方案，同时它还可以消除不同应用之间的技术差异，让不同的应用服务器协调运作，实现了不同服务之间的通信与整合。从功能上看，ESB提供了事件驱动和文档导向的处理模式，以及分布式的运行管理机制，它支持基于内容的路由和过滤，具备了复杂数据的传输能力，并可以提供一系列的标准接口。

未完待续

三、概念解释

1. 什么是SOA

SOA（Service-OrientedArchitecture)既服务导向架构，是指为了解决在inernet环境下业务集成的需要，通过连接能完成特定任务的独立功能实现的一种软件系统架构。该定义的学术味道较浓，但其核心思想并不难理解：让应用不受限于技术，让企业轻松应对商业服务变化和发展的需要。目前，SOA的实现手段主要包括：Web Serice（网络服务）、ＣＯＲＢＡ和ＪＩＮＩ等。

2. 为何要使用SOA

面向服务架构（SOA）是一种应用框架，它着眼于日常的业务应用，并将它们划分为单独的业务功能和流程，即所谓的服务。SOA 使用户可以构建、部署和整合这些服务，且无需依赖应用程序及其运行计算平台，从而提高业务流程的灵活性。这种业务灵活性可使企业加快发展速度，降低总体拥有成本，改善对及时、准确信息的访问。SOA 有助于实现更多的资产重用、更轻松的管理和更快的开发与部署。在当今的业务环境中，变化是毫无疑问的，因此快速响应客户需求、市场机遇和外部威胁的敏捷性比以往任何时候都更显重要。各种企业都认识到组件化、模块化、互操作和可伸缩基础设施的价值：

组件化：利用标准化的应用程序和资源服务接口

互操作：实现应用程序和/或资源之间的轻松信息交换

模块化：混合搭配、添加删除、业务流程与基础设施

可伸缩：从现有资源起步，随需添加其他资源

3. SOA与Web Service何为区别

SOA 不是Web服务

Web服务是实现SOA的方式之一。

在SOA时代下，ESB为SOA的实施提供了底层架构的技术支持。SOA从根本上来说就是要解决两个问题:重用和异构，但是作为信息化系统建设永远要面对的两个难题，解决的方法却并不简单，所以SOA的体系庞大而复杂。更重要的是ESB为分散服务提供了交互、组合和治理的基础架构。有了它，SOA才能释放自己的最大价值。 IBM为ESB定义了四个必备的功能:“路由器”——根据信息内容，在不同应用和服务之间进行信息传输和路由;“转换器”——进行应用之间的通信协议转换;“翻译机”——进行应用之间的消息格式转换;“收发室”——处理来自不同渠道的业务事件(同步传输，异步传输，发布/订阅等方式)。其中“路由器”和“收发室”都是针对服务的重用而设计的，而“转换器”和“翻译机”则专门用来解决异构的通信问题。针对重用和异构这两个难题，倪晓兵认为ESB提供了两个核心的功能，服务的管理和数据的转换。那么ESB到底是什么呢?业内对ESB的定义是:它是由中间件技术实现并支持SOA的一组基础架构，支持异构环境中的服务、消息以及基于事件的交互，并且具有适当的服务级别和可管理性。

5. SOA,ESB之间的关系

首先，ESB不是SOA。SOA的最常见的实现方式方式是SCA和JBI，而SCA的实现需要ESB，相反JBI则不需要ESB，可以参看本人对 JBI和SCA分析解读的文章。其次，因为IBM和Oracle（收购了BEA和SUN的牛X公司）都推崇SCA模式的SOA，因此SCA实际上已经成为SOA的事实标准，说道SOA，最先想到的就是SCA模式了。最后，ESB是SCA架构实现不可缺少的一部分，ESB产品脱离了具体的应用外，没有任何意义。ESB的作用在于实现服务间智能化集成与管理的中介。通过 ESB可以访问所集成系统的所有已注册服务。

6. SOA,ESB,WebService的关系

SOA是方法论，就像建筑学一样，指导性质的；

ESB是建筑图纸，理顺整个建筑的架构；

Web S是具体的建筑材料，就好像预制板；

7. 什么是RPC?

RPC就是想实现函数调用模式的网络化。客户端就像调用本地函数一样，然后客户端把这些参数打包之后通过网络传递到服务端，服务端解包到处理过程中执行，然后执行的结果反馈给客户端。 RPC（RemoteProcedure Call Protocol）——远程过程调用协议，是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。它假定某些传输协议的存在，如 TCP或UDP，以便为通信程序之间携带信息数据。通过它可以使函数调用模式网络化。在OSI网络通信模型中，RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。 RPC 工作原理

运行时,一次客户机对服务器的RPC调用,其内部操作大致有如下十步：

1.调用客户端句柄；执行传送参数

2.调用本地系统内核发送网络消息

3.消息传送到远程主机

4.服务器句柄得到消息并取得参数

5.执行远程过程

6.执行的过程将结果返回服务器句柄

7.服务器句柄返回结果，调用远程系统内核

8.消息传回本地主机

9.客户句柄由内核接收消息

10.客户接收句柄返回的数据

8.Web Server：是一种开发web服务的技术规范，按照web services规范开发的web服务组件，可以用来进行企业应用系统集成。

传输服务： 必须确保通过企业总线互连的业务流程间的消息的正确交付，传输还包括基于内容的路由功能。

多种服务集成方式：如HTTP ，WEB等。

通信：服务发布、订阅，响应请求，同步异步消息，路由和寻址等；

服务安全： 认证和授权、不可否认和机密性、安全标准的支持等；

服务质量： 事务，服务的可交付性等；

服务等级： 性能、可用性等