webservice 实现与his系统对接_[Share] EDI 及其他常见系统对接技术

近期，有客户提及：你们有没有对接技术相关的介绍，不同系统之间的对接技术，现在企业内部系统比较多，有自主开发的，有外部采购的，所以我们想了解一下对接技术相关的信息。

小知马不停蹄的做了下功课， 整理了相关信息，详情如下！

#### 系统对接方式

一般情况下，常见的不同系统之间的对接方式有两种，一种是消息集成，另外一种是 API 调用，两者各有利弊。

##### 消息

消息，是一个数据通道，可以对数据进行加密或对数据通道进行加密，安全性高，但是在进行大量数据传输时，可能会存在延迟。

##### API 调用

API，是调用 http 接口，知行 EDI 系统可以封装好接口，开放 API 供其它系统调用，不过这种方式就是安全性没那么高，但是具有实时性。

总的来说，消息传输具有高安全，高延迟的特点，而 API 则相反，具有低安全，低延迟的特点。如果是组织内部系统的对接，对数据的实时性要求较高，建议采用 API 调用方式，如果是组织内部和外部进行系统对接，对数据的安全性要求较高，建议采用消息的方式。

#### 常见的系统对接技术

小知带大家一起了解下常用系统对接技术，本文主要提及 EDI，Web 和 WebService，REST和JDBC。这五种对接方式，较于 EDI，大家应该更熟悉后面四种技术。其中，EDI 是 属于消息集成方式； Web 是 EDI 的一种临时替代方案； WebService，REST 和 JDBC 均属于 API 调用集成方式。

##### EDI

用于和外部交易伙伴做核心业务数据传输（解决的是企业间的问题）属于消息集成方式。

EDI 自 20 世纪 60 年代以来就被广泛使用，但如今它正在被应用于更多新的用途，使供应链自动化、数字转换成为可能，甚至成为工作流和业务流程自动化的一个关键部分。点击下方链接，对 EDI 进行全面的解读，帮您短时间内快速掌握 EDI 基础知识。

扩展阅读： <a style="color=blue;" href="[导读] EDI 是什么？ | EDI通信专家">EDI 是什么？</a>

如您想了解更多关于 EDI 知识，可联系 EDI 通信专家小知，很乐意为您答疑解惑。

##### Web

这里的 Web 是指一个 Web 页面，类似于 Portal 网站，通过提供指定用户及密码的方式，授权用户登录 Web 网页登录，去查看相关业务数据，并填写表单数据，提交给后台。 Web 方式是 EDI 的一种替代方案，主要提供给不具备 EDI 能力的合作伙伴使用，以此实现业务数据传输。

基于小知过往的实施经验，了解到提供 Web 方式的，汽车行业主机厂居多，比如 Tesla/特斯拉，上汽大众等。

##### WebService

WebService的特征：

- 基于 SOAP 协议的，数据格式为 XML

- 只支持 HTTP 协议

- 不是开源的，但可以被任意一个了解 XML 的人使用

- 只能部署在 IIS 上，WebService 是两个系统间的远程调用，使两个系统进行数据交互，如应用：天气预报服务、银行ATM取款、使用邮箱账号登录各网站等。

WebService核心组件：

- XML和HTTP

- SOAP： 简单对象访问协议

- WSDL： WebService 描述语言

- UDDI：统一描述、发现和集成协议

WebService 之间的调用是跨语言的调用，发送 Http 请求，使用的数据格式是 XML 格式。

假设一个 Web Service A 提供允许其他应用程序通过 URL 获取用户信息的功能：[GET] http://www.abc.com/{id}。id是用户的唯一标识符，请求此 URL 将获得用户信息。现在假设浏览器、手机、桌面应用程序的用户都要获取服务 A 提供的用户信息，这三者只需要请求服务 A 提供的 URL 地址，并输入用户 id 信息即可。至于这三个不同客户端的实现方式（编程语言）是什么与服务 A 没有任何关系，只要能够解析出服务 A 返回的 XML 文档即可。这样，应用程序之间交换数据就可以不用依赖于具体的语言和环境。这就好比不同国家不同语言的人，只要能够知晓对方语言的语法结构，两个人就可以进行交流。

目前，WebService 主要有两大流派：

- 基于 SOAP 的 WebService : SOAP（简单对象访问协议）是一种基于 XML 的协议，用以访问 Web Service。其接口以机器可处理的格式进行描述，称为 WSDL(Web服务定义语言)文档。通过使用标准的的 XML 文档来描述 Web Service，在 XML 文件中，会详细记录接口的信息，如消息的格式、传输协议以及交互的位置等信息。

- 基于 REST 的 WebService ：REST（Representational State Transfer）是一种软件架构，它使用 JSON 来描述数据格式，最重要的是 HTTP 传输协议对 REST 来说是非必须的。

WebService 属于 API 调用集成方式。

##### REST

REST 是一种设计 API 的模式。最常用的数据格式是 JSON。由于 JSON 能直接被 JavaScript 读取，所以，以 JSON 格式编写的 REST 风格的 API 具有简单、易读、易用的特点。

REST 是Representational State Transfer（表现层状态转移）的缩写，它是由罗伊·菲尔丁（Roy Fielding）提出的，是用来描述创建 HTTP API 的标准方法的，他发现这四种常用的行为（查看（view），创建（create），编辑（edit）和删除（delete））都可以直接映射到 HTTP 中已实现的 GET,POST,PUT 和 DELETE 方法。

REST 是面向资源的，这个概念非常重要，而资源是通过 URI 进行暴露。URI 的设计只要负责把资源通过合理方式暴露出来就可以了。对资源的操作与它无关，操作是通过 HTTP 动词来体现，所以 REST 通过 URI 暴露资源时，会强调不要在 URI 中出现动词。比如：左边是错误的设计，而右边是正确的。

GET /rest/api/getDogs --> GET /rest/api/dogs 获取所有小狗狗

GET /rest/api/addDogs --> POST /rest/api/dogs 添加一个小狗狗

GET /rest/api/editDogs/:dog_id --> PUT /rest/api/dogs/:dog_id 修改一个小狗狗

GET /rest/api/deleteDogs/:dog_id --> DELETE /rest/api/dogs/:dog_id 删除一个小狗狗

左边的这种设计，很明显不符合 REST 风格，上面已经说了，URI 只负责准确无误的暴露资源，而 getDogs/addDogs...已经包含了对资源的操作，这是不对的。相反右边却满足了，它的操作是使用标准的 HTTP 动词来体现。

REST 很好地利用了 HTTP 本身就有的一些特征，如 HTTP 动词、HTTP 状态码、HTTP 报头等等，REST API 是基于 HTTP 的，所以你的 API 应该去使用 HTTP 的一些标准。这样所有的 HTTP 客户端（如浏览器）才能够直接理解你的 API（当然还有其他好处，如利于缓存等等）。REST 实际上也非常强调应该利用好 HTTP 本来就有的特征，而不是只把 HTTP 当成一个传输层这么简单了。

HTTP 动词

- GET 获取一个资源

- POST 添加一个资源

- PUT 修改一个资源

- DELETE 删除一个资源

实际上，这四个动词实际上就对应着增删改查四个操作，这就利用了 HTTP 动词来表示对资源的操作。

通俗的讲 REST 就是：

- 看 Url 就知道要什么

- 看 http method 就知道干什么

- 看 http status code 就知道结果如何

更简洁的来说，就是用 URL 定位资源，用 HTTP 描述操作。

REST 是属于 API 调用集成方式。

##### JDBC

JDBC（Java Data Base Connectivity,java数据库连接）是一种用于执行 SQL 语句的 Java API，可以为多种关系数据库提供统一访问，它由一组用 Java 语言编写的类和接口组成。JDBC 提供了一种基准，据此可以构建更高级的工具和接口，使数据库开发人员能够编写数据库应用程序。

JDBC 是对数据库操作的接口抽象，而不同数据库厂商的数据库驱动程序则对应 JDBC 接口实现，通过抽象出 JDBC 接口，应用程序和实际的数据库驱动，即JDBC实现解耦。

常用的 JDBC 接口包括：Driver 接口、Connection 接口、Statement 接口、ResultSet 接口。

JDBC API 允许用户访问任何形式的表格数据，尤其是存储在关系数据库中的数据。

执行流程：

- 连接数据源，如：数据库。

- 为数据库传递查询和更新指令。

- 处理数据库响应并返回的结果。

JDBC是属于 API 调用集成方式。

以上的资料集锦，希望对阅读本文的有缘人提供一定的帮助。如有描述不妥或有争议的地方，欢迎一起探讨。