行业应用软件第三方开发平台的研究与实践

祝金伟，左 春，，张 正

（1.中国科学院 软件研究所，北京100190；2.中国科学院研究生院，北京100049；3.中科软科技股份有限公司，北京100190）

0 引 言

目前，行业应用软件的开发模式有：SOA（service－oriented architecture）、SAAS（software－as－a－service）和 云 计算等。SOA解决了那些专业化所带来的信息竖井，使得不同行业的信息得以串联；SAAS一定程度上说明了市场和客户对于互联网应用的需求日趋增强；而云计算实现了IT基础设施的社会共享，充分利用了软硬件资源［1］。然而，随着企业信息系统的不断扩大，企业内部的软件系统逐渐模块化和接口服务化。模块化和接口服务化的软件不仅可以满足内部交互，同时也可以对外开放给一些商业合作伙伴。而SOA、SAAS和云计算等是只限于企业内部自身的开发模式，这样就会限制行业应用软件产业的发展，因此，需要一种新的开发模式，它不仅是企业自身的软件开发，也是其他合作伙伴的软件开发，这种开发模式需要一个开放的平台，也就是本文所设计和实现的行业应用软件第三方开发平台。这种以第三方开发平台为基础的开发模式，将会极大促进行业应用软件的创新和发展。

本文先设计了面向行业应用软件第三方开发平台的新的授权系统，接着分析和设计了基于保险行业应用软件的数据和服务，给出了行业应用软件的数据和组件依赖分析方法，给出了行业应用软件第三方开发平台API（application programming interface）的设计方法，为其他行业提供理论依据和实践参考，并在最后对基于保险行业的应用软件第三方开发平台进行了测试实验。

1 行业应用软件第三方开发平台授权方案

1.1 第三方开发平台授权问题的提出

第三方开发平台共涉及三种角色，分别是第三方开发平台服务商、第三方应用服务商和用户。三种角色的关系是：用户依赖于平台服务商和第三方应用服务商；第三方应用服务商依赖于平台服务商。对于用户来说，这种依赖关系存在一定的安全问题，其典型场景如图1所示。

图1 典型场景

在图1中，用户A登录第三方开发平台C后，用户A想要使用第三方应用B的编辑图片功能，而第三方应用依赖于第三方开发平台C的用户存取图片的服务。这种情况下，如果第三方开发平台C直接给予B获取用户图片的服务，那么用户A的信息安全就会大打折扣。因此，第三方开发平台C不能直接给予B获取用户图片的服务，应该在给予B这项服务前，要求用户A给予B一些授权。这也就是第三方开发平台授权系统产生的背景。

1.2 现有授权方案介绍

目前各大互联网公司的第三方开发平台采用的授权方案主要有 OAuth（open authentication）和 OpenID（open identity）。其中OAuth是专门为了解决第三方开发平台授权问题提出的，而OpenID的提出主要是提供一种让多个Passport无缝集成的方案，两者的初衷和架构是完全不同的，但是两者都能用于解决第三方开发平台中的授权问题。下面分别介绍这两种授权方案［2］。

OAuth方案是一个安全的授权标准，它允许第三方应用开发商无需使用用户的用户名和密码就可以获得相关资源，避免第三方应用开发商触及到用户的帐号信息。OAuth授权是开放的，它允许任何服务提供商对其进行扩展，实现自己的授权协议。OAuth授权有3个基本步骤：得到用户未授权的Request Token；得到经过用户授权的Request Token；使用Request Token换取可以访问资源的Access Token。总之，OAuth授权的特点可以概括为：简单；安全；开放。

OpenID方案是一个以用户为中心的数字身份识别框架，它通过 URI（uniform resource identifier）来认证用户身份，它不是一个注册程序，也不仅局限于某一网站的登录验证使用。OpenID协议是简单易用的，具有一处注册，到处应用的特性；OpenID协议也是容易扩展的，其授权过程也十分简单。OpenID的授权步骤是：用户登录网站（需支持OpenID），输入在OpenID服务网站注册的OpenID；所要登录的网站自动跳转到OpenID服务网站；用户在OpenID服务网站输入密码，验证后，自动登录到原网站。总之，OpenID授权的特点可以概括为：开放；分散；自由。

1.3 基于OAuth方案的改进授权

对比两种授权方案，我们发现OpenID系统更像是分散式身份验证系统，其初衷是让互联网上的多个Passport能够无缝集成，更加适合作身份验证，它需要网站支持OpenID，当支持OpenID的网站越多时，其作用体现更大；而OAuth系统的初衷就是要解决授权问题，相对于OpenID，OAuth作授权系统，其优势不言而喻。而且，各大互联网的第三方开发平台也基本采用OAuth授权系统，如Google SubAuth、淘宝Top。实际上，OAuth已经成了第三方开发平台授权系统的实质，因此，行业应用软件第三方开发平台授权方案应该借鉴OAuth授权方案。

根据OAuth授权协议，其授权详细流程如图2所示。

由图2可知，OAuth授权流程的第一步和第二步的作用是要给第三方应用软件一个临时且唯一的id，用以标识该软件。但当该软件已经在第三方开发平台中注册过，其必然有一个唯一的id，不需要通过请求再给其生成一个id。而行业应用（像金融保险行业）涉及用户切身利益，相比于互联网第三方开发平台的用户数据，其用户数据更加需要安全保证。因此，行业应用软件第三方开发平台所面向的第三方厂商开发的应用必须要向第三方开发平台注册，并实行实名制认证。在这种情况下，可以去掉OAuth授权流程的第一步（即图2中A）和第二步（即图2中B），只保留第三步（即图2中C）到第七步（即图2中G），从而形成行业应用软件第三方开发平台的授权流程如下：

（1）第三方应用软件向User Authorization URL发起请求，请求用户授权的Request Token。

（2）第三方开发平台首先引导用户登录，然后提示用户，是否将某些受保护的资源授权给该应用，完成用户引导授权。

（3）用户授权后，将Request Token换取成Access Token，第三方应用软件向Access Token URL发起请求。

图2 OAuth授权流程

（4）第三方开发平台向其颁发Access Token与对应的密钥，并返回给第三方应用软件。

（5）第三方应用软件在一定时间内就可以使用Access Token访问用户授权的资源。

2 保险行业应用软件第三方开发平台的数据和服务

保险行业应用软件是包含金融保险领域知识的核心业务软件，本质上也是一个 “综合”管理信息系统，它管理的对象是金融保险领域知识数据，管理的重点是围绕 “合同管理”和 “项目管理”进行。保险领域的数据参考模型可以概括抽象为4类［3］：

记录事实型库结构类——表示具体某一细分领域的结果性结构，是领域纵向的、有多个元素复合而成的、记录事实的结构。

约束型库结构类——表示对相应细分领域的记录事实型库结构的控制约束结构，是以细分领域为纵向的、控制行为中的稳定部分的结构。

通用关系型库结构类——表示可以跨越不同细分领域，强调在记录事实型和约束型结构中主要元素之间的一些通用的、固有关系的结构。

代码／单元素库结构类——表示在以上三种结构中独立元素的结构，简称代码库。

保险行业应用软件管理操作可以概括抽象为一个 ｛环境、对象、操作｝的三元组［4－5］。环境是指保险构件所处的运行环境；对象是指金融保险领域知识数据；操作为构件对领域对象进行的处理，包含增删改查等共计28种［4］。保险行业核心业务应用软件的数据是松耦合的，服务是紧耦合的。保险行业应用的外挂的规划是核心业务系统发展的一个热点问题，而外挂的规划也就是OpenAPI（第三方开发平台所提供的API接口）的规划。

一般来说，OpenAPI都是REST形态的。表述性状态转移（representational state transfer，REST）是一种针对网络应用的设计和开发方式。基于http协议的REST符合SOA的思想，是SOA的互联网化，是互联网轻量级的web服务。REST风格的优点在于，可以降低开发的复杂性，提高系统的可伸缩性，权限控制可以部分依托于已有的传输协议。但鉴于保险行业应用软件遗留系统众多，重新开发难度较大，保险行业应用软件第三方开发平台可以采用类REST形态。这样对于原有系统的改造较小，对于逻辑抽象来说更加容易。

2.1 数 据

2.1.1 请求数据

2.1.1.1 请求 URL

请求URL采用类REST形态的URL格式，如：http：／／Env／object...？［param］。

Env是环境层；object是领域数据对象，可以有多个分层；param是参数。

每一个这样的URL都代表一个资源，符合REST的思想。

2.1.1.2 请求参数

参数部分共分为两种，系统参数和业务参数，系统参数是URL中必须要有的参数，业务参数视情况而定。

主要系统参数描述：

Api＿Name：所调用的API接口名称。

App＿Id：注册应用时平台为其生成的Id。

Session＿Key：用户授权的Session Key。

Timestamp：请求发送的时间戳。

Format：指定响应格式。

Version：所调用的API协议版本。

主要业务参数描述：

User＿Id：用户Id。

Fields：其它业务参数列表。

2.1.1.3 参数加密

采用Md5加密算法为参数加密，密钥采用注册应用时分配到的应用密钥app＿secret或者用户session密钥（Md5加密算法略）。

2.1.1.4 用户ID加密

将用户数据给第三方应用软件之前，需要对用户UserId做一次对称变换，目的是要隐藏用户的真实UserId，从而避免被扫号，同时又可以避免维护真实UserId与给第三方应用软件用的UserId间的映射关系。因此，平台在接收到第三方调用API时传递的UserId参数时，需要用对称变换算法将其重新还原（对称加密算法略）。

2.1.2 响应数据

目前成熟的数据传输格式有xml格式和json格式。XML格式统一，符合标准，但传输量大，不易解析；json格式简单，传输量小，但数据不容易理解。两种方式各有利弊，对于大数据量的传输，一般采用xml格式，小数据量的传输，采用json格式。

第三方开发平台的响应数据格式是由用户通过Format系统参数指定的，其值为xml或json，默认为json。

2.2 数据和组件依赖

在行业应用软件开发中，有大量的数据和组件交织在一起，易产生数据和组件重复冗余操作，组件分类设计不明晰。因此，需要分析和研究数据和组件的依赖关系，分类和设计好组件，这也是OpenAPI的基础。在分析和研究数据和组件依赖的之前，我们先阐述如下定义：

定义1 数据依赖［6］：数据依赖有多种类型，如：函数依赖、多值依赖和包含依赖等，数据依赖是模式分解的基础。有研究者用逻辑语言的语句对这些数据依赖进行了描述，谓词逻辑描述是

在该逻辑描述中，｛X1，…，Xn｝，｛Y1，…，Ym｝和｛Z1，…，Zk｝均为变量集合；φ是谓词逻辑语句的前提，ψ是谓词逻辑语句的结论。

定义2 组件依赖［7，9］：给定组件A与B，若A对B至少有一次依赖运算且B对A没有依赖运算，则称组件A依赖于组件B，记作A B。

定义3 参数依赖［8－9］：给定组件A与B，［X1，…，Xn］为A的输入参数［Y1，…，Ym］为B的输入参数，若A B，则［Y1，…，Ym］数据依赖于［X1，…，Xn］，称A［X1，…，Xn］参数依赖于B［Y1，…，Ym］，记作 A［X1，…，Xn］→B［Y1，…，Ym］。

性质1 依赖传递性［10］：若X依赖于Y，Y依赖于Z，则X依赖于Z。X、Y和Z属于同一属性变量集合。

在软件开发过程中，数据之间的依赖和组件之间的依赖影响整个系统的稳定性以及质量，依赖能够设计得适当，整个系统会是一个和谐的整体。在行业应用软件第三方开发平台中，这种依赖的重要性更为明显，进行依赖性分析更为重要。依赖分为直接依赖和间接依赖，且有强弱之分，为更好的对依赖进行分析，我们给出依赖强度的概念如下：

定义4 依赖强度［7］：若A B，A在N次使用中共调用B有M次（通过参数依赖，改变参数输入，看返回结果得到），则称 A对B的依赖强度为 M／N，记作P（A B）＝M／N，P的范围为0～1。当0＜P＜0.5时，我们称A弱依赖于B；当0.5＜＝P＜＝1时，我们称A强依赖于B；当P＝0时，我们称A与B无关系。

根据依赖强度，我们可以判定该组件是否是关键组件或是量化其重要性，从而分析优化其数据和功能，利于第三方开发平台的API分类提取，利于整个平台系统的性能提升。

假设有A、B、C和D这4个组件，其依赖关系如图3所示。

图3 组件依赖示例

显然，A、C和D依次直接依赖，B、C和D依次直接依赖。那么，我们假设P（A C）＝6／10，P（C D）＝2／10，P（B C）＝8／10。

根据性质1，可知A D，且P（A D）＝（6＊2）／（10＊10）＝12／100；同理P（B D）＝16／100。

其中，P（A B）＝0，P（B A）＝0，P（D B）＝0，P（D C）＝0，P（D A）＝0，P（C B）＝0，P（C A）＝0。

由此，得出A、B、C和D四个组件的依赖强度矩阵［7，11］，如下

通过该依赖强度矩阵，我们可以快速分清各个组件之间的依赖关系，也可以计算出各个组件的被依赖强度。被依赖和被依赖强度的定义如下：

定义5 被依赖：若有且只有A1…An共N个组件依赖于B，则称B被A1…An依赖，记作B（A1…An，其被依赖强度记作P（BA1…An）或者P（B），计算公式为

根据计算式（2），P（C）＝（P（A C）＋P（B C））／2＝（0.6＋0.8）／2＝0.7

因此，C的被依赖强度很高，属于关键部件，而D的依赖强度不高，不是关键部件。在分类和设计时，应该着重关注C。

综上，依赖分析在行业应用软件第三方开发平台设计中占有着重要作用，我们也提出了关注有效部件的方法，下面的分类设计就是采用这样的方法来设计的。

2.3 API分类设计

保险行业应用软件有着大量的数据和丰富的功能，其中，保险核心业务系统包含了主要的内容，从语义和功能上来讲，保险核心业务系统的组件库中共收录组件29个，包含接口3908个。然而，保险核心业务系统由来已久，其数据规模越来越大，其组件也越来越因交错引用而更加纷繁芜杂。而第三方开发平台所要提供的功能是要高效和安全的，同时又要容易被业务外行上手，保证不会出现重复调用和产生冗余或者错误数据，这就要求我们对已有的功能组件进行依赖性分析，切断组件循环依赖并找出关键组件进行改进优化，并对功能组件进行分类，从而形成保险行业应用软件的API。

API分类设计的步骤如下：

（1）根据语义和业务功能，先进行第一层粗粒度的划分。

（2）在第一层划分的基础上，再对具体功能组件进行依赖性分析，得出依赖关系，根据依赖关系，进行第二层划分。同时，也可以得出依赖强度，根据依赖强度进行组件优化或再设计。

（3）根据API方法签名的不同和语义知识，设计API。通过以上步骤，最后得出的API层次是一个3层的分类结构。其中，第一层包含投保类、批改类、保单类、权限类、理赔类、条款类、付款类等共计29大类。下面以保单类再进行下一层的划分。保单类包含保单生成组件（记为A）、保单下载组件（记为B）、保单验真组件（记为C），其中B A，C B。通过测试可以得出P（B A）＝0.84，P（C B）＝0.24 ，P（A）＝0.84，P（B）＝0.4，P

（C）＝0.2。由此可得A仅被B依赖，且依赖强度较高，应该合并A与B，而C与A、B依赖强度弱，可以单独存在。那么，保单层就分为了两类，即保单下载组件（包含保单生成功能）和保单验真组件。最后，根据方法签名的不同和语义知识，设计保单类的部分OpenAPI如下：

保单下载：policy.downLoad.getPolicy（String policy－No）。

保单验真：policy.verify.verify（Policy policy）。

3 保险行业应用软件第三方开发平台实践和分析

行业应用软件第三方开发平台包含两部分内容，一是行业应用软件第三方开发平台授权，二是行业应用软件第三方开发平台提供的数据和服务。保险行业应用软件第三方开发平台实践是基于我们所提出的类OAuth授权方案和保险行业应用软件第三方开发平台所提供的数据和服务而进行的实践，本实践主要是模拟第三方应用开发商对第三方开发平台API进行调用，用以说明上述理论的正确性和实践上的可行性。下面以某用户登录某SNS网站（假设此网站有通过我们的保险行业应用软件第三方开发平台所提供的API开发的车险电子保单下载和验真应用）下载车险电子保单为例。

在该SNS网站上，用户点击下载车险电子保单按钮，将会启动下载车险电子保单应用，应用调用加密算法为参数加密，形成请求授权的URL，请求方式为Get。

平台接收到请求后，引导用户登录和授权，用户登录和授权后，将Session＿Key和经过对称加密的User＿Id返回给第三方应用。第三方应用收到这两个返回值，形成访问授权的URL，请求方式仍然为Get。

平台再次接收到请求后，验证Session＿Key和User＿Id，解析传入参数（验证和解析代码略），调用平台API policy.downLoad.getPolicy，返回xml格式的电子保单（电子保单略）。

经过1000多个测试用例的安全测试，未发现我们的授权方案有安全漏洞，证明了我们的授权方案是可靠的，可依赖的。但在做并发和效率测试，当请求达到500以上时，平台效率明显降低，经过诊断，发现其瓶颈在于：平台硬件资源不够好；平台API效率不够高；平台尚未支持分布式部署。解决这几方面的瓶颈是今后的研究重点。总体上而言，我们的第三方开发平台是安全和完备的。

4 结束语

本文提出了行业应用软件第三方开发平台的构建框架，即包含两部分内容：授权和数据服务。通过分析行业应用软件数据和服务的特征，改进了互联网普遍采用的OAuth授权方案，提出了基于数据依赖和组件依赖分析的行业应用软件第三方开发平台的服务分类，并以保险行业应用软件的第三方开发平台为实践，论证了我们的授权方案的正确性和证明了基于依赖分析来分类的合理性，证明了我们所提出的行业应用软件第三方开发平台的构建框架的可行性。

当今，互联网的蓬勃发展为互联网行业第三方开发平台提供了前所未有的机遇，互联网行业OpenAPI发展如火如荼，这也正预示着行业应用软件的第三方开发平台即将迎来曙光，本文也正是为其投石问路。今后，我们的工作将会以此为基础，反复设计和观察行业应用软件的第三方开发平台，提高行业应用软件的第三方开发平台的响应效率和易用性等问题，逐步完善行业应用软件第三方开发平台。

［1］CEN Wenchu.Analyses on open API［J］.Programmer，2009，9（1）：94－99（in Chinese）.［岑文初.Open API分析和实践［J］.程序员，2009，9（1）：94－99.］

［2］XU Tong，LEI Tinan.OpenlD and OAuth combination of technologies used in the construction of teaching resources library［J］.Software Guide（Educational Technology），2009，8（10）：69－71（in Chinese）.［许彤，雷体南.OpenlD与OAuth技术组合应用于教学资源库建设［J］.软件导刊（教育技术），2009，8（10）：69－71.］

［3］ZUO Chun.The dictionary and database structure in the industry application software［J］.China Computer World，2007，28（44）：B9－B11（in Chinese）.［左春.行业应用软件中的词根表和库结构［J］.计算机世界，2007，28（44）：B9－B11.］

［4］YAO Weizhi，ZUO Chun，WANG Yuguo，et al.Interface matching of insurance component based on semantic［J］.Computer Engineering and Design，2009，30（2）：469－473（in Chinese）.［姚伟志，左春，王裕国，等.基于语义的保险构件接口匹配研究与实现［J］.计算机工程与设计，2009，30（2）：469－473.］

［5］ZHANG Zheng，ZUO Chun，WANG Yuguo，et al.Domain component interface identifier matching based on semantic［J］.Journal on Communications，2007，28（5）：73－79（in Chinese）.［张正，左春，王裕国，等.基于语义的领域构件接口名称匹配方法［J］.通信学报，2007，28（5）：73－79.］

［6］HU Yanli，ZHANG Weiming，LUO Xuhui，et al.Dependencies theory and its application for repairing inconsistent data［J］.Computer Science，2009，36（10）：11－15（in Chinese）.［胡艳丽，张维明，罗旭辉，等.基于数据依赖的数据修复研究进展［J］.计算机科学，2009，36（10）：11－15.］

［7］WANG Li，LI Zhishu，YIN Feng.Testing sequence optimization model based on dependency relation of components［J］.Journal of Beijing University of Posts and Telecommunications，2007，30（2）：38－41（in Chinese）.［王 莉，李志蜀，殷锋.基于组件依赖的测试序列优化模型［J］.北京邮电大学学报，2007，30（2）：38－41.］

［8］Egor Bondarev Peter，Peter de With，Michel Chaudron，et al.Modelling of input－parameter dependency for performance predictions of component－based embedded systems［C］／／EUROMICRO Conference on Software Engineering and Advanced Applications，2005：36－43.

［9］LIN Hongkang，LI Yuying，RUAN Qunsheng.Data depende－nce and separation－application of abnormal data［J］.Computer Science，2011，38（5）：203－207（in Chinese）.［林宏康，李豫颖，阮群生.数据依赖与异常数据分离－应用［J］.计算机科学，2011，38（5）：203－207.］

［10］QUAN Lixin.Composition of web services based on data dependency specification［J］.Science Technology and Engineering，2008，8（23）：6376－6378（in Chinese）.［全立新.基于数据依赖信息的 Web服务合成［J］.科学技术与工程，2008，8（23）：6376－6378.］

［11］YAN Zhao，LIU Lei.Method of program automatic parallelization based on data dependence［J］.Journal of Jilin University（Science Edition），2010，48（1）：94－98（in Chinese）.［闫昭，刘磊.基于数据依赖关系的程序自动并行化方法［J］.吉林大学学报（理学版），2010，48（1）：94－98.］