Restful+OData：企业信息系统集成的简明之道

王 卫 列

(南瑞集团公司(国网电力科学研究院) 江苏 南京 211106)

Restful+OData：企业信息系统集成的简明之道

王 卫 列

(南瑞集团公司(国网电力科学研究院) 江苏 南京 211106)

企业都希望能复用已有的IT子系统，但在规划子系统服务的接口标准时普遍感到困难，针对这一问题，提出Restful+OData的技术方案。阐述了为什么这一方案能够简化接口标准设计，为企业信息系统集成提供了一个新的思路。实践结果表明，该方案对简化企业信息系统集成过程有一定的参考价值。

系统集成 服务接口 Restful OData 面向服务

0 引 言

现在一个企业内常包含多个信息化系统，且这些系统常常不是由一个开发商做的，各开发商使用的开发平台常不相同(如：J2EE、WCF等)。如果要基于这些系统进行集成，如形成高层决策系统，首先需要制定各子系统的服务接口标准。另外为了不同类型系统能互联，需要各子系统能提供具有开放性标准的接口，其中制定服务接口标准看似很简单，但具体实施时会发现非常困难。本文分析了其实施困难的原因，并提出了用Restful+OData方案来解决这个难题。

明确了构什么，有必要思考怎么构，点是线线相交所得，需要思考作怎样的两条线，就是思考点具有怎样的特征，假设点存在，追问与此点会有哪些相关定的量或定的关系.以本题为例，如图3，需要确定点B，分析点B特征，由AB=AC，即点B的轨迹就是以A为圆心，AC为半径的弧，即定长轨迹；∠ABD=30°，点A、D是两个定点，即点B的轨迹就是即定角轨迹.同时满足两个条件，即为两轨迹的交点.

1 集成的要求

随着IT技术的应用普及，现在一个企业里已经有不少信息子系统了，为了综合决策时更多地复用子系统、快速构建高层决策系统，对系统集成有如下一些要求。

1.充分认识制度控制的局限性，及时修订整改，重在腐败预防。内部控制理论的建立和实践是一个不断完善的过程。廉政建设中对其的借鉴和利用应突破其局限性，应当将眼光关注到制度未涵盖的例外事项。客观而言，有些党风廉政建设和反腐败的制度操作性更不强，原因是制度的制订者对廉政的虚与应付，阳奉阴违。因此，在实施中对制度中存在的问题做到及时发现及时修订整改十分必要。

(1) 子系统及接口的标准化 企业IT系统标准化可以避免受制于某些软件开发商，可以提高企业IT构建效率，利于系统持续改进。

而在Restful中，动词是和资源分离的，在Restful的请求行中，首先是动词(如：GET)，然后是指向要访问的资源(数据)的url。

若能形成这方面的标准，将为提高行业内IT系统构建的敏捷性打下基础。

例：GET http://server1/WdsData/X1

(3) 易于向互联网移植 随着业务的发展，企业的IT应用边界已不能再局限在局域网内了，而是需要越来越多地被部署在互联网上，为了避免重复投资，创建新应用时企业需要考虑其向互联网移植的便利性。

2 存在的困难

(1) 制定子系统接口标准 相对于子系统划分标准的制定，子系统接口标准的制定难度较大。究其原因，是因为我们常常使用动名词结构来制定API接口(如：GetX1Data(参数1，参数2，…)),但实际开发经验告诉我们，这样设计出的接口很难稳定下来。修改参数、增加接口都需要客户端改动代码后重新编译，而我们不可能一次性将接口标准制定得很完美，接口的频繁改动造成系统极不稳定，这给我们实现子系统接口标准化带来很大麻烦。

(2) 多种类型的应用和设备连接服务 企业内部的IT服务很多是前些年开发的，而现在的应用和终端设备类型大幅增长，所使用的开发语言也越来越丰富。除了传统的Java、.NET外，javascript、python、Ruby、Go等语言都需要能编写访问服务的代码，这时会发现以前的技术开发出的服务已不能为这些丰富的客户端提供连接了。

3 Restful+OData的解决方案

针对上述问题，Restful+OData的解决方案存在着一些天然的优势。

3.1 服务标准的挑选

针对上述所提的企业需求和所要克服的困难，我们把主要分布式服务构建技术和他们对各种需求的适应性列表如表1所示。

建筑企业要想在复杂残酷的市场竞争中生存发展，首先要提高企业自身的综合素质。综合素质的提高对建筑企业能否在市场中立足至关重要。综合素质的高低是一个企业的面貌体现，是能否在市场竞争中占据主导地位的体现。如建筑企业综合素质较低，就无法对市场需求与走向进行理性分析与研究，导致逐渐被市场所淘汰或者摒弃。所以，建筑企业应该加强工程施工管理模式的创新，只有创新的理念才是提升企业综合素质的基础与保障。

表1 服务类型及其适应性

从表1可以看出，Restful技术仅对分布式事务不支持，其他方面都比较优秀，而我们的系统集成大多数是信息集成，如果没有对分布式事务要求，那么选择Restful是比较合适的。

3.2 化解动名词接口形式的缺点

Restful的技术是基于http的请求响应机制的(注：后面所讲的http报文就是指Restful使用的报文)，在http的请求行中也有动词。GET、POST、PUT、DELETE是http中最常用动词，那么为什么说Restful支持非动名词接口形式呢？

首先让我们来分析采用动名词形式接口的特点。假设我们要访问标志为X1资源的数据，我们为它设计了接口GetX1Data(参数1，参数2)，构成了动词+名词的函数名，这就是动名词形式接口。动名词形式接口发生变化时，需要服务端和客户端都重新编译、部署后才能使用，假设需求的不断增加，我又需要增添对X2，X3，…，Xn的数据访问，那么我们就需要分别为他们设计出GetX2Data,…，GetXnData。由于设计了新的接口后，需要重新编译、部署服务，客户端也需要重新编码来适应这些新的接口，两侧的频繁改动会使系统很不稳定。或许我们可以设计一个万能接口GetData(参数)，其中的参数使用一个非常易于伸缩的数据结构，看似问题解决了，但这个又会带来参数的标准化问题，而制定这个标准是很困难的。

要实现企业内IT服务的复用和组合，首先必须实现系统划分和接口的标准化。其标准化过程可分为两个部分，子系统划分标准化和子系统接口标准化。其中子系统划分标准是子系统接口标准的前提条件。

(2) 符合开放标准的服务 随着互联网和移动设备的技术发展，现在构建的IT服务，不能只考虑PC的连接，要考虑多类型应用和设备的连接，这对IT服务的开放性提出了越来越高的要求。

如此，尽管今后要访问的数据资源会不断增加，我们只需通过url指向不同的资源即可。

例：GET http://server1/WdsData /X2

从上面的例子可以看出，无论要访问的数据资源增加多少，从形式上看，只是与动词组合的url发生变化，访问命令只是动词和url的字符串组态形式而已，而软件通过组态设计可以很轻松地处理这种变化。

2.通过对折现率R取9%～11%的值，g取2%～6%，计算永续增长(第二种情况)和零增长(第三种情况)模型下的不同的投资因子，见表1和表2：

上面的例子中给出的是http请求报文的简单形式，让我们再分析一下http完整报文是否具有可组态性。

先看一下http报文的结构(注：要详细了解http的报文可阅读相关的RFC文档，这里只是简述)，报文分为请求报文和响应报文，其结构见表2。

表2 http报文结构

报文中的字符串是由ASCII字符组成，每部分的格式是有一定规则的。下面是一个具体请求报文的例子(见图1)。

图1 http报文举例

}

3.3 OData进一步标准化Restful服务

解析：从实物图中可以看出灯泡与滑动变阻器和电流表串联连接，根据实物图用各元件符号表示即可。从电源正极出发，依次经过开关、小灯泡、电流表、滑动变阻器，然后回到电源负极，最后把电压表并联在小灯泡的两端即可。

上面谈到Restful命令报文可组态化提供了巨大的灵活性，但是大家还是要认识到Restful只是一种思想，不是一种标准。虽然报文的结构是基于http标准，但报文结构的每一部分都保留了一定自由度，这种自由度对Web浏览应用没有什么负作用，但对于需要在应用间共享的服务，则显然会带来很大的麻烦。

例如：假设软件开发商A和B都实现了一个Restful 接口通过工号查询人员信息，因为没有统一的标准，那么其请求命令的报文可能各不相同，其中url是可能产生差异最大的一部分。

A的请求行中的url 可能是这样：http://Server/api/person/001。

B的请求行中的url 可能是这样：http://Server/api/person?id=001。

如果我们使用的Restful服务命令格式不能标准化，则会阻碍Restful服务在各应用之间的分享。

为了规范Restful，提高Restful在各应用之间的兼容性，微软提出了OData协议(OData v4已于2014年3月17日在OASIS投票通过成为开放工业标准)。它实现了在Restful中通过标准化的资源标识来访问任何数据。

图3展示了L=100个地面移动IoT设备的初始分布以及应用本文方法所确定的最优UAV布署效果.此次实验采用8个UAV，如图3(a)所示，100个IoT设备初始分布位置随机，基于通信节能策略，首先形成了8个最优分簇，其次在各簇聚类中心的影响下，UAV的布署位置实现最优，如图3(b)所示.

符合开放数据协议OData的Restful服务在各方面都得到了标准化，但由于篇幅所限，这里只能重点介绍一下对url结构的标准化(也是最重要的一部分)，让我们用一个例子来说明。

首先介绍一点基础知识，OData服务是可以自描述的，通过Restful的请求与响应可以获得该服务两个元数据文档：service document和metadata document。其中service document描述服务中提供那些数据，metadata document则描述服务中的数据结构。有了这两个元数据文档，我们就可以组态出各种标准化的url。

下面举一个OData的例子来说明这个问题。这里需要在数据集People中找出他的FirstName等于Vincent的某些人，其url如下：

http:/abc.com/svc/People?＄filter=FirstNameeq′Vincent′

上面的url可被划分成Service root、Resource path和Query option三个部分，各部分的内容如表3所示。

表3 示例url各部分对应的内容

前两个部分的格式标准由service document就可以限定，后面的Query option格式则可由相应的语法规则和metadata document限定。

″name″:″People″,

让我们先来看看服务的元数据之一service document是如何限定Service root和Resourece path的。

首先我们肯定知道该服务的http地址，例如：

http://abc.com/svc/

在实际授课过程中，我们以海军部队实际卫生学问题为出发点，通过上述教学内容、教学方法、教学手段以及考核方式改进，有效提高了学生海军卫生学学习热情和学习效果，也在一定程度上提高了学生发现、解决卫生学问题的能力。

其中abc.com是服务所在的服务器域名，然后我们就可以发出如下请求报文来获取service document，如：

GET /svc/ HTTP/1.1

Host: abc.com

Cache-Control: no-cache

（19）一些西方国家的环保主义者则成立了“绿党”或“绿色和平运动”，其宗旨是保护环境和恢复生态平衡。（1990·《人民日报》）

只要是OData数据服务，它就会返回相应的service document，类似如下的数据。

{

″@odata.context″:″http:/abc.com/svc/＄metadata″,

″value″:[

{

″name″:″Photos″,

″kind″:″EntitySet″,

″url″:″Photos″

},

{

在互联网快速发展的背景下，网络学习资源日益增多，随之产生的是资源的质量和共享的问题。为了避免资源浪费，更高效快捷地建设学习资源，有效扩展沟通平台课程，在制作课程时应遵守相关标准。2017 年，在中共中央组织部的领导下，中国干部网络学院开展了中国干部网络教育标准的研制工作，截止到2018 年10 月，第一批10 项标准，已经通过国家标准立项，这10 项标准的主要内容如表2 所示。

″kind″:″EntitySet″,

″url″:″People″

用扫描电子显微镜测试4种喷墨打印纸的表面微观结构，并以纸张的扫描电镜(SEM)图和青色油墨网点的平均直径为质量标准，检验纸张质量的优劣性，并与模型评价结果进行对比，以检验模型的合理性。

}

该服务会返回相应的metadata document，如下：

上面的例子是一个修改某product实体的一个请求包。可以看出，它和动名词形式的接口不同，在于这个请求命令完全可以通过字符串按规则组态而成。据此客户端软件完全可以通过组态来实现对服务的访问，这相比那些需要事先编译好的软件，其灵活性大大增强了，这大大提高了客户端软件对服务接口变化的适应性。

从上面的元数据描述可以得知，从这个服务中可以获得两种数据集(EntitySet)Photos和People，其Resourece path分别为Photos和People。

假设你要访问People这个数据集，那么url前面两个部分的组合是：

http://abc.com/svc/ People

至此，url中的Service root和Resources path已经成为确定格式了。

针对后面的Query option，OData制定了极为丰富的标准化参数来控制数据的输出，很多Sql查询的功能都具有。如：＄select、＄filter、＄orderby、＄expand、＄count、＄skip、＄top、＄search、＄format等，它具有严格的语法规则，严格控制了Query option的格式。另外在写Query option中的查询参数(如：＄filter=FirstName eq ′Vincent′)时会涉及到数据集中的数据结构，其中FirstName就是数据集People中对应实体的数据结构成员。至于数据集Photos和People的数据结构则可以通过访问metadata document获得。访问metadata document的url已经在service document中的第一条数据中告诉你了。

使用该url向该OData服务发送报文来获取相应的metadata document：

GET /svc/＄metadata HTTP/1.1

Host: abc.com

Cache-Control: no-cache

]

与单纯的句酷批改网反馈方式相比，学生对三稿式人机结合的写作教学模式的态度更加积极，他们认为后者反馈的准确性和清晰度显著高于前者（P=0.000），学生能更好地理解反馈信息并进行修改。此外，学生认为三稿式人机结合的写作教学模式能更全面关注到他们作文中的问题，包括篇章结构、写作内容的一致性与连贯性、词汇、语法、长句等，两种模式有显著差异（P=0.000）。由这两点可以看出，学生很认可三稿式人机结合的写作教学模式，因为它具体、全面，弥补了句酷批改网单一反馈模式的不足。至此，第三个假设得到验证。上文五篇作文的三稿成绩呈递增状与这一结论相一致。

2.1 两组患者的临床治疗效果对比 实验组患者41耳的临床治疗有效率为87.80%，其中，22耳为治愈，14耳为好转，5耳无效；对照组患者37耳的临床治疗有效率为64.86%，其中，11耳治愈，13耳好转，13耳无效。治疗后实验组患者的临床治疗有效率显著高于对照组，差异有统计学意义(χ2=5.766，P=0.016)。

第二，输入搜索内容为：随机抽取一整段文字。如果在百度和谷哥的浏览器上显示有80%以上的红色字，则可判定该文章有一稿多投的嫌疑。

image/jpeg

我们从上面的元数据文档中可以看到实体集People对应的实体数据类型是Person，而Person中有个属性就是FirstName，这样的属性就可以用在Query option中了。

如此，再按OData规定的语法，Query option部分也被标准化了，这样整个url都被标准化了。

OData不仅仅是对url进行了标准化，其标准化是全方位的，它包括OData协议规范、OData URL约定、OData通用架构定义、OData json格式、OData ABNF、OData数据聚合。OData协议是集数据技术的大全，从数据描述到操作都有非常周到的设计，您所需要的功能特性一定能在OData中找到。

3.4 方案优点

下面让我们来分析一下，采用Restful+OData服务相对于其他服务有那些优点。

1) 直观易用，非软件人员可以参加接口设计 使用Restful+OData做出的服务是DaaS模式，它好似将一张张数据表呈现给客户端，非常直观。过去在设计动名词形式的接口时，似乎只有软件开发人员才可以参加设计。现在由于所提供数据的直观性，非软件开发人员也可参与到接口的设计中，这样能使得接口标准能在更广泛的范围内得到研究，利于早日形成接口标准。

2) 客户端易于调整，利于接口的调整 制定子系统接口标准的整个过程，不可能一蹴而就，期间不可避免地需要调整。由于基于Restful+OData的客户端命令的可组态性，较之其他形式的接口调整就方便得多。服务端接口调整后，软件开发商只要获得该服务的Service Document和Metadata Document，很快就可以通过组态将软件功能调整好，这减少了接口调整的负担，有利于最终接口标准的形成。

3) 利于子系统划分的标准化 虽然企业内的子系统类型进行了标准化划分，但与企业内的实际子系统不一定是一一对应的。例如企业子系统规划为A、B、C标准系统，实际上的子系统为甲、乙、丙、丁，需要我们通过面向服务将甲、乙、丙、丁系统映射成标准化的A、B、C系统(见图2)。

图2 实际系统到标准子系统的映射

因为Restful+OData实现的是数据服务，对外公布的是一个个实体集，如同设计数据库的一张张表，技术概念非常形象、直观，可非常方便地实现所需的数据映射，所以非常利于子系统划分的标准化。

4) 与其他系统更好的对接 由于Restful就是在互联网中产生的，这个天然的优势使得将系统移植到互联网非常方便。而现在云计算大多部署在互联网上，这种标准化的数据服务也使得它可以非常容易地成为云计算的数据源，为企业未来的应用前景打好了基础。

由于互联网技术的普及，众多设备和开发语言都支持与Restful服务的连接，较之以前技术所提供的服务，提供的数据服务可以在更多应用之间共享，使得以后企业的IT应用更加丰富。

3.5 案例分析

下面我们用一个简单的案例来说明Restful+OData方案的优势。

假设某水电厂有三个业务子系统：发电监控系统、水情测报系统、闸门监控系统。我们要在此基础上进行系统集成，形成综合决策系统(注：篇幅所限，本文以简单的数据综合输出为例)，例如我们要输出如下的综合数据表(见表4)。

表4 水电厂某输出表格

其中的数据需要分别从三个子系统(发电、水情、闸门)中抽取，具体见表5。

表5 从各子系统抽取的数据

如果用OData服务来提供数据，那么我们需要在各子系统中发布相应的EntitySet，这些Entity就相当于子系统的API接口，假设各子系统公布的EntitySet如表6所示。

表6 各子系统公布的EntitySet

围绕这些EntitySet，我们可以进行非常丰富的数据操作。

下面我们以其中的发电监控子系统为例，来介绍如何使用OData服务。

假设发电监控子系统OData服务的http地址为：

http:/abc.com/powerdata

首先我们需要知道服务中发布了哪些内容，这些信息可以通过访问OData服务的Service document获得，需要向OData服务发出如下的http请求：

GET/powerdata/HTTP/1.1

Host:abc.com

Cache-Control:no-cache

服务响应此请求时会在包体中返回相应的service document，它告知该系统发布了哪些EntitySet。

例如：

{

″@odata.context″:″http://abc.com/powerdata/＄metadata″,

″value″:[

{

″name″:″PowerOut″,

″kind″:″EntitySet″,

″url″:″PowerOut″

}

]

}

从中我们可以看到该系统发布了一个名称为PowerOut的EntitySet。要进一步了解该EntitySet的数据结构，可以通过访问OData服务的metadata document获得，需要发出如下的http请求：

GET/powerdata/＄metadataHTTP/1.1

Host:abc.com

Cache-Control:no-cache

服务响应此请求时，会返回所有实体集的数据结构定义。

例如：

从中我们可以看出实体集PowerOut的数据结构被定义在POType中，其中的Property非常类似数据库中的表字段定义。

至此，客户端已经明白了该服务的发布内容以及相应的数据结构，后面就可以根据OData标准中的语法标准来组态各种数据访问命令了。

例如：我们要访问1号站点和2号站点2010年11月10日9点的数据，可以发出如下http请求：

GET/powerdata/PowerOut?＄filter=dteqdatetimeoffset′2010-11-10T09:00:00Z′∧(stationId=1∨stationId=2)HTTP/1.1

Host:abc.com

Cache-Control:no-cache

服务端在接收到该请求后，会将返回数据放在返回包的包体部分，例如：

{

“value”:[

{

“dataId”:1026

“dt”:”2010-11-10T09:00:00Z”

“stationId”:1

“powerOutput”:63.5

“waterUsed”:4.24

},

{

“dataId”:2038

“dt”:”2010-11-10T09:00:00Z”

“stationId”:2

“powerOutput”:0.0

“waterUsed”:0.0

}

]

}

客户端接收到上述的JSON数据，可以很容易地进行解析并处理。

注意上面例子中的数据请求命令中所含的Query option(Filter)只是一个简单的数据过滤。实际上OData的标准中含有类型非常丰富的Query option，提供类似SQL语句的功能，因此围绕发布的PowerOut实体集，可以有非常丰富的数据输出。这个特点使得在数据需求发生变化，我们的接口形式可以保持稳定。

另外当需求发生变化时，OData标准还保证了很强的适应性。无论是实体集的数据结构增加Property(类似数据库中的表增加字段)，还是数据需要分组统计，OData都提供了相应的设计。总之在数据集相对稳定的情况下，围绕这些数据集，我们能产生千变万化的操作。

OData不但能输出独立的数据，还可输出关系数据。有些自动生成工具可以将关系数据库发布为OData服务，可想而知OData的功能是多么的强大和灵活，它能充分满足你对信息发布的需求。

信息系统集成很多时候就是客户端和服务端的相互磨合，而采用Restful+OData技术，提高了两端的相互适应性，减少因需求变化而付出的代价，因而简化了信息系统集成的过程。

4 结 语

Restful+OData的技术价值相当于PC时代的ODBC，它为我们打通了系统数据互联的通道。OData的技术内涵相当丰富，它是IT界长期以来数据技术的结晶，各种数据查询和操作功能应有尽有，不仅提供了极强的数据服务功能，甚至连动名词形式的接口都能提供，绝大部分应用的需求都能满足。

当您需要标准化企业内的子系统，同时想为各种应用和设备提供最广泛连接时，它应该是一个不错选择。

[1] Thomas Erl，Benjamin Carlyle，Cesare Pautasso . SOA与REST：用REST构建企业级SOA解决方案[M]. 北京：人民邮电出版社，2014.

[2] 谢鹏寿.基于SOA的制造业集成服务平台构建方法[M].国防工业出版社，2013.

[3] 全国信息技术标准化技术委员会SOA标准工作组.中国SOA最佳应用及云计算融合实践[M].电子工业出版社，2012.

[4] 中国电子技术标准化研究所. SOA用户指南[M].电子工业出版社，2008.

[5] 汪芳琴, 谢强, 丁秋林. 基于REST的Web服务研究[J]. 机械设计与制造工程,2009, 38(23):44-47,52.

[6] 许卓明, 栗明, 董逸生. 基于RPC和基于REST的Web服务交互模型比较分析[J].计算机工程, 2003,29(20):6-8.

[7] 冯新扬, 沈建京. REST和RPC:两种Web服务架构风格比较分析[J].小型微型计算机系统, 2010, 31(7):1393-1395.

[8] 张少敏, 张帆, 王保义. 基于REST和IEC61970的智能电网数据集成方法[J].电力自动化设备, 2012, 32(8):124-129.

[9] 程冬梅, 王瑞聪, 刘燕,等. 基于REST架构风格的物联网服务平台研发[J].计算机工程与应用, 2012, 48(14):74-78,157.

[10] 戴亚娥, 俞成海, 尧飘海,等. 基于REST架构风格的Web 2.0实现[J]. 计算机系统应用, 2009, 18(7):165-168.

[11] 钟约夫. 基于RESTWeb服务的资源定位方法研究[J]. 自动化与仪器仪表, 2010(5):8-10.

[12] 李久刚, 唐新明, 汪汇兵,等. REST架构的WebGIS技术研究与实现[J]. 测绘科学, 2011, 36(3):85-87.

RESTFUL&ODATA:ASIMPLIFIEDWAYFORENTERPRISEINFORMATIONSYSTEMINTEGRATION

Wang Weilie

(NARIGroupCorporation(StateGridElectricityPowerResearchInstitute),Nanjing211106,Jiangsu,China)

All companies hope that the existing IT system can be reused， but it is difficult to program the interface standards of subsystem service, thus Restful+OData technical solution is provided. The reason of why this solution can simplify interface standards design to provide a new approach of enterprise information system integration. Experiments results indicate that the proposed solution can be referred in simplifying enterprise information system integration.

System-integration Service-interface Restful OData SOA

2017-06-05。王卫列，教授级高工，主研领域：电力系统软件开发。

TP3

A

10.3969/j.issn.1000-386x.2017.12.028