祝金偉，左 春，，張 正

（1.中國科學(xué)院 軟件研究所，北京100190；2.中國科學(xué)院研究生院，北京100049；3.中科軟科技股份有限公司，北京100190）

0 引 言

目前，行業(yè)應(yīng)用軟件的開發(fā)模式有：SOA（service－oriented architecture）、SAAS（software－as－a－service）和 云 計(jì)算等。SOA解決了那些專業(yè)化所帶來的信息豎井，使得不同行業(yè)的信息得以串聯(lián)；SAAS一定程度上說明了市場(chǎng)和客戶對(duì)于互聯(lián)網(wǎng)應(yīng)用的需求日趨增強(qiáng)；而云計(jì)算實(shí)現(xiàn)了IT基礎(chǔ)設(shè)施的社會(huì)共享，充分利用了軟硬件資源［1］。然而，隨著企業(yè)信息系統(tǒng)的不斷擴(kuò)大，企業(yè)內(nèi)部的軟件系統(tǒng)逐漸模塊化和接口服務(wù)化。模塊化和接口服務(wù)化的軟件不僅可以滿足內(nèi)部交互，同時(shí)也可以對(duì)外開放給一些商業(yè)合作伙伴。而SOA、SAAS和云計(jì)算等是只限于企業(yè)內(nèi)部自身的開發(fā)模式，這樣就會(huì)限制行業(yè)應(yīng)用軟件產(chǎn)業(yè)的發(fā)展，因此，需要一種新的開發(fā)模式，它不僅是企業(yè)自身的軟件開發(fā)，也是其他合作伙伴的軟件開發(fā)，這種開發(fā)模式需要一個(gè)開放的平臺(tái)，也就是本文所設(shè)計(jì)和實(shí)現(xiàn)的行業(yè)應(yīng)用軟件第三方開發(fā)平臺(tái)。這種以第三方開發(fā)平臺(tái)為基礎(chǔ)的開發(fā)模式，將會(huì)極大促進(jìn)行業(yè)應(yīng)用軟件的創(chuàng)新和發(fā)展。

本文先設(shè)計(jì)了面向行業(yè)應(yīng)用軟件第三方開發(fā)平臺(tái)的新的授權(quán)系統(tǒng)，接著分析和設(shè)計(jì)了基于保險(xiǎn)行業(yè)應(yīng)用軟件的數(shù)據(jù)和服務(wù)，給出了行業(yè)應(yīng)用軟件的數(shù)據(jù)和組件依賴分析方法，給出了行業(yè)應(yīng)用軟件第三方開發(fā)平臺(tái)API（application programming interface）的設(shè)計(jì)方法，為其他行業(yè)提供理論依據(jù)和實(shí)踐參考，并在最后對(duì)基于保險(xiǎn)行業(yè)的應(yīng)用軟件第三方開發(fā)平臺(tái)進(jìn)行了測(cè)試實(shí)驗(yàn)。

1 行業(yè)應(yīng)用軟件第三方開發(fā)平臺(tái)授權(quán)方案

1.1 第三方開發(fā)平臺(tái)授權(quán)問題的提出

第三方開發(fā)平臺(tái)共涉及三種角色，分別是第三方開發(fā)平臺(tái)服務(wù)商、第三方應(yīng)用服務(wù)商和用戶。三種角色的關(guān)系是：用戶依賴于平臺(tái)服務(wù)商和第三方應(yīng)用服務(wù)商；第三方應(yīng)用服務(wù)商依賴于平臺(tái)服務(wù)商。對(duì)于用戶來說，這種依賴關(guān)系存在一定的安全問題，其典型場(chǎng)景如圖1所示。

圖1 典型場(chǎng)景

在圖1中，用戶A登錄第三方開發(fā)平臺(tái)C后，用戶A想要使用第三方應(yīng)用B的編輯圖片功能，而第三方應(yīng)用依賴于第三方開發(fā)平臺(tái)C的用戶存取圖片的服務(wù)。這種情況下，如果第三方開發(fā)平臺(tái)C直接給予B獲取用戶圖片的服務(wù)，那么用戶A的信息安全就會(huì)大打折扣。因此，第三方開發(fā)平臺(tái)C不能直接給予B獲取用戶圖片的服務(wù)，應(yīng)該在給予B這項(xiàng)服務(wù)前，要求用戶A給予B一些授權(quán)。這也就是第三方開發(fā)平臺(tái)授權(quán)系統(tǒng)產(chǎn)生的背景。

1.2 現(xiàn)有授權(quán)方案介紹

目前各大互聯(lián)網(wǎng)公司的第三方開發(fā)平臺(tái)采用的授權(quán)方案主要有 OAuth（open authentication）和 OpenID（open identity）。其中OAuth是專門為了解決第三方開發(fā)平臺(tái)授權(quán)問題提出的，而OpenID的提出主要是提供一種讓多個(gè)Passport無縫集成的方案，兩者的初衷和架構(gòu)是完全不同的，但是兩者都能用于解決第三方開發(fā)平臺(tái)中的授權(quán)問題。下面分別介紹這兩種授權(quán)方案［2］。

OAuth方案是一個(gè)安全的授權(quán)標(biāo)準(zhǔn)，它允許第三方應(yīng)用開發(fā)商無需使用用戶的用戶名和密碼就可以獲得相關(guān)資源，避免第三方應(yīng)用開發(fā)商觸及到用戶的帳號(hào)信息。OAuth授權(quán)是開放的，它允許任何服務(wù)提供商對(duì)其進(jìn)行擴(kuò)展，實(shí)現(xiàn)自己的授權(quán)協(xié)議。OAuth授權(quán)有3個(gè)基本步驟：得到用戶未授權(quán)的Request Token；得到經(jīng)過用戶授權(quán)的Request Token；使用Request Token換取可以訪問資源的Access Token。總之，OAuth授權(quán)的特點(diǎn)可以概括為：簡單；安全；開放。

OpenID方案是一個(gè)以用戶為中心的數(shù)字身份識(shí)別框架，它通過 URI（uniform resource identifier）來認(rèn)證用戶身份，它不是一個(gè)注冊(cè)程序，也不僅局限于某一網(wǎng)站的登錄驗(yàn)證使用。OpenID協(xié)議是簡單易用的，具有一處注冊(cè)，到處應(yīng)用的特性；OpenID協(xié)議也是容易擴(kuò)展的，其授權(quán)過程也十分簡單。OpenID的授權(quán)步驟是：用戶登錄網(wǎng)站（需支持OpenID），輸入在OpenID服務(wù)網(wǎng)站注冊(cè)的OpenID；所要登錄的網(wǎng)站自動(dòng)跳轉(zhuǎn)到OpenID服務(wù)網(wǎng)站；用戶在OpenID服務(wù)網(wǎng)站輸入密碼，驗(yàn)證后，自動(dòng)登錄到原網(wǎng)站?？傊?，OpenID授權(quán)的特點(diǎn)可以概括為：開放；分散；自由。

1.3 基于OAuth方案的改進(jìn)授權(quán)

對(duì)比兩種授權(quán)方案，我們發(fā)現(xiàn)OpenID系統(tǒng)更像是分散式身份驗(yàn)證系統(tǒng)，其初衷是讓互聯(lián)網(wǎng)上的多個(gè)Passport能夠無縫集成，更加適合作身份驗(yàn)證，它需要網(wǎng)站支持OpenID，當(dāng)支持OpenID的網(wǎng)站越多時(shí)，其作用體現(xiàn)更大；而OAuth系統(tǒng)的初衷就是要解決授權(quán)問題，相對(duì)于OpenID，OAuth作授權(quán)系統(tǒng)，其優(yōu)勢(shì)不言而喻。而且，各大互聯(lián)網(wǎng)的第三方開發(fā)平臺(tái)也基本采用OAuth授權(quán)系統(tǒng)，如Google SubAuth、淘寶Top。實(shí)際上，OAuth已經(jīng)成了第三方開發(fā)平臺(tái)授權(quán)系統(tǒng)的實(shí)質(zhì)，因此，行業(yè)應(yīng)用軟件第三方開發(fā)平臺(tái)授權(quán)方案應(yīng)該借鑒OAuth授權(quán)方案。

根據(jù)OAuth授權(quán)協(xié)議，其授權(quán)詳細(xì)流程如圖2所示。

由圖2可知，OAuth授權(quán)流程的第一步和第二步的作用是要給第三方應(yīng)用軟件一個(gè)臨時(shí)且唯一的id，用以標(biāo)識(shí)該軟件。但當(dāng)該軟件已經(jīng)在第三方開發(fā)平臺(tái)中注冊(cè)過，其必然有一個(gè)唯一的id，不需要通過請(qǐng)求再給其生成一個(gè)id。而行業(yè)應(yīng)用（像金融保險(xiǎn)行業(yè)）涉及用戶切身利益，相比于互聯(lián)網(wǎng)第三方開發(fā)平臺(tái)的用戶數(shù)據(jù)，其用戶數(shù)據(jù)更加需要安全保證。因此，行業(yè)應(yīng)用軟件第三方開發(fā)平臺(tái)所面向的第三方廠商開發(fā)的應(yīng)用必須要向第三方開發(fā)平臺(tái)注冊(cè)，并實(shí)行實(shí)名制認(rèn)證。在這種情況下，可以去掉OAuth授權(quán)流程的第一步（即圖2中A）和第二步（即圖2中B），只保留第三步（即圖2中C）到第七步（即圖2中G），從而形成行業(yè)應(yīng)用軟件第三方開發(fā)平臺(tái)的授權(quán)流程如下：

（1）第三方應(yīng)用軟件向User Authorization URL發(fā)起請(qǐng)求，請(qǐng)求用戶授權(quán)的Request Token。

（2）第三方開發(fā)平臺(tái)首先引導(dǎo)用戶登錄，然后提示用戶，是否將某些受保護(hù)的資源授權(quán)給該應(yīng)用，完成用戶引導(dǎo)授權(quán)。

（3）用戶授權(quán)后，將Request Token換取成Access Token，第三方應(yīng)用軟件向Access Token URL發(fā)起請(qǐng)求。

圖2 OAuth授權(quán)流程

（4）第三方開發(fā)平臺(tái)向其頒發(fā)Access Token與對(duì)應(yīng)的密鑰，并返回給第三方應(yīng)用軟件。

（5）第三方應(yīng)用軟件在一定時(shí)間內(nèi)就可以使用Access Token訪問用戶授權(quán)的資源。

2 保險(xiǎn)行業(yè)應(yīng)用軟件第三方開發(fā)平臺(tái)的數(shù)據(jù)和服務(wù)

保險(xiǎn)行業(yè)應(yīng)用軟件是包含金融保險(xiǎn)領(lǐng)域知識(shí)的核心業(yè)務(wù)軟件，本質(zhì)上也是一個(gè) “綜合”管理信息系統(tǒng)，它管理的對(duì)象是金融保險(xiǎn)領(lǐng)域知識(shí)數(shù)據(jù)，管理的重點(diǎn)是圍繞 “合同管理”和 “項(xiàng)目管理”進(jìn)行。保險(xiǎn)領(lǐng)域的數(shù)據(jù)參考模型可以概括抽象為4類［3］：

記錄事實(shí)型庫結(jié)構(gòu)類——表示具體某一細(xì)分領(lǐng)域的結(jié)果性結(jié)構(gòu)，是領(lǐng)域縱向的、有多個(gè)元素復(fù)合而成的、記錄事實(shí)的結(jié)構(gòu)。

約束型庫結(jié)構(gòu)類——表示對(duì)相應(yīng)細(xì)分領(lǐng)域的記錄事實(shí)型庫結(jié)構(gòu)的控制約束結(jié)構(gòu)，是以細(xì)分領(lǐng)域?yàn)榭v向的、控制行為中的穩(wěn)定部分的結(jié)構(gòu)。

通用關(guān)系型庫結(jié)構(gòu)類——表示可以跨越不同細(xì)分領(lǐng)域，強(qiáng)調(diào)在記錄事實(shí)型和約束型結(jié)構(gòu)中主要元素之間的一些通用的、固有關(guān)系的結(jié)構(gòu)。

代碼／單元素庫結(jié)構(gòu)類——表示在以上三種結(jié)構(gòu)中獨(dú)立元素的結(jié)構(gòu)，簡稱代碼庫。

保險(xiǎn)行業(yè)應(yīng)用軟件管理操作可以概括抽象為一個(gè) ｛環(huán)境、對(duì)象、操作｝的三元組［4－5］。環(huán)境是指保險(xiǎn)構(gòu)件所處的運(yùn)行環(huán)境；對(duì)象是指金融保險(xiǎn)領(lǐng)域知識(shí)數(shù)據(jù)；操作為構(gòu)件對(duì)領(lǐng)域?qū)ο筮M(jìn)行的處理，包含增刪改查等共計(jì)28種［4］。保險(xiǎn)行業(yè)核心業(yè)務(wù)應(yīng)用軟件的數(shù)據(jù)是松耦合的，服務(wù)是緊耦合的。保險(xiǎn)行業(yè)應(yīng)用的外掛的規(guī)劃是核心業(yè)務(wù)系統(tǒng)發(fā)展的一個(gè)熱點(diǎn)問題，而外掛的規(guī)劃也就是OpenAPI（第三方開發(fā)平臺(tái)所提供的API接口）的規(guī)劃。

一般來說，OpenAPI都是REST形態(tài)的。表述性狀態(tài)轉(zhuǎn)移（representational state transfer，REST）是一種針對(duì)網(wǎng)絡(luò)應(yīng)用的設(shè)計(jì)和開發(fā)方式。基于http協(xié)議的REST符合SOA的思想，是SOA的互聯(lián)網(wǎng)化，是互聯(lián)網(wǎng)輕量級(jí)的web服務(wù)。REST風(fēng)格的優(yōu)點(diǎn)在于，可以降低開發(fā)的復(fù)雜性，提高系統(tǒng)的可伸縮性，權(quán)限控制可以部分依托于已有的傳輸協(xié)議。但鑒于保險(xiǎn)行業(yè)應(yīng)用軟件遺留系統(tǒng)眾多，重新開發(fā)難度較大，保險(xiǎn)行業(yè)應(yīng)用軟件第三方開發(fā)平臺(tái)可以采用類REST形態(tài)。這樣對(duì)于原有系統(tǒng)的改造較小，對(duì)于邏輯抽象來說更加容易。

2.1 數(shù) 據(jù)

2.1.1 請(qǐng)求數(shù)據(jù)

2.1.1.1 請(qǐng)求 URL

請(qǐng)求URL采用類REST形態(tài)的URL格式，如：http：／／Env／object...？［param］。

Env是環(huán)境層；object是領(lǐng)域數(shù)據(jù)對(duì)象，可以有多個(gè)分層；param是參數(shù)。

每一個(gè)這樣的URL都代表一個(gè)資源，符合REST的思想。

2.1.1.2 請(qǐng)求參數(shù)

參數(shù)部分共分為兩種，系統(tǒng)參數(shù)和業(yè)務(wù)參數(shù)，系統(tǒng)參數(shù)是URL中必須要有的參數(shù)，業(yè)務(wù)參數(shù)視情況而定。

主要系統(tǒng)參數(shù)描述：

Api＿Name：所調(diào)用的API接口名稱。

App＿Id：注冊(cè)應(yīng)用時(shí)平臺(tái)為其生成的Id。

Session＿Key：用戶授權(quán)的Session Key。

Timestamp：請(qǐng)求發(fā)送的時(shí)間戳。

Format：指定響應(yīng)格式。

Version：所調(diào)用的API協(xié)議版本。

主要業(yè)務(wù)參數(shù)描述：

User＿Id：用戶Id。

Fields：其它業(yè)務(wù)參數(shù)列表。

2.1.1.3 參數(shù)加密

采用Md5加密算法為參數(shù)加密，密鑰采用注冊(cè)應(yīng)用時(shí)分配到的應(yīng)用密鑰app＿secret或者用戶session密鑰（Md5加密算法略）。

2.1.1.4 用戶ID加密

將用戶數(shù)據(jù)給第三方應(yīng)用軟件之前，需要對(duì)用戶UserId做一次對(duì)稱變換，目的是要隱藏用戶的真實(shí)UserId，從而避免被掃號(hào)，同時(shí)又可以避免維護(hù)真實(shí)UserId與給第三方應(yīng)用軟件用的UserId間的映射關(guān)系。因此，平臺(tái)在接收到第三方調(diào)用API時(shí)傳遞的UserId參數(shù)時(shí)，需要用對(duì)稱變換算法將其重新還原（對(duì)稱加密算法略）。

2.1.2 響應(yīng)數(shù)據(jù)

目前成熟的數(shù)據(jù)傳輸格式有xml格式和json格式。XML格式統(tǒng)一，符合標(biāo)準(zhǔn)，但傳輸量大，不易解析；json格式簡單，傳輸量小，但數(shù)據(jù)不容易理解。兩種方式各有利弊，對(duì)于大數(shù)據(jù)量的傳輸，一般采用xml格式，小數(shù)據(jù)量的傳輸，采用json格式。

第三方開發(fā)平臺(tái)的響應(yīng)數(shù)據(jù)格式是由用戶通過Format系統(tǒng)參數(shù)指定的，其值為xml或json，默認(rèn)為json。

2.2 數(shù)據(jù)和組件依賴

在行業(yè)應(yīng)用軟件開發(fā)中，有大量的數(shù)據(jù)和組件交織在一起，易產(chǎn)生數(shù)據(jù)和組件重復(fù)冗余操作，組件分類設(shè)計(jì)不明晰。因此，需要分析和研究數(shù)據(jù)和組件的依賴關(guān)系，分類和設(shè)計(jì)好組件，這也是OpenAPI的基礎(chǔ)。在分析和研究數(shù)據(jù)和組件依賴的之前，我們先闡述如下定義：

定義1 數(shù)據(jù)依賴［6］：數(shù)據(jù)依賴有多種類型，如：函數(shù)依賴、多值依賴和包含依賴等，數(shù)據(jù)依賴是模式分解的基礎(chǔ)。有研究者用邏輯語言的語句對(duì)這些數(shù)據(jù)依賴進(jìn)行了描述，謂詞邏輯描述是

在該邏輯描述中，｛X1，…，Xn｝，｛Y1，…，Ym｝和｛Z1，…，Zk｝均為變量集合；φ是謂詞邏輯語句的前提，ψ是謂詞邏輯語句的結(jié)論。

定義2 組件依賴［7，9］：給定組件A與B，若A對(duì)B至少有一次依賴運(yùn)算且B對(duì)A沒有依賴運(yùn)算，則稱組件A依賴于組件B，記作A B。

定義3 參數(shù)依賴［8－9］：給定組件A與B，［X1，…，Xn］為A的輸入?yún)?shù)［Y1，…，Ym］為B的輸入?yún)?shù)，若A B，則［Y1，…，Ym］數(shù)據(jù)依賴于［X1，…，Xn］，稱A［X1，…，Xn］參數(shù)依賴于B［Y1，…，Ym］，記作 A［X1，…，Xn］→B［Y1，…，Ym］。

性質(zhì)1 依賴傳遞性［10］：若X依賴于Y，Y依賴于Z，則X依賴于Z。X、Y和Z屬于同一屬性變量集合。

在軟件開發(fā)過程中，數(shù)據(jù)之間的依賴和組件之間的依賴影響整個(gè)系統(tǒng)的穩(wěn)定性以及質(zhì)量，依賴能夠設(shè)計(jì)得適當(dāng)，整個(gè)系統(tǒng)會(huì)是一個(gè)和諧的整體。在行業(yè)應(yīng)用軟件第三方開發(fā)平臺(tái)中，這種依賴的重要性更為明顯，進(jìn)行依賴性分析更為重要。依賴分為直接依賴和間接依賴，且有強(qiáng)弱之分，為更好的對(duì)依賴進(jìn)行分析，我們給出依賴強(qiáng)度的概念如下：

定義4 依賴強(qiáng)度［7］：若A B，A在N次使用中共調(diào)用B有M次（通過參數(shù)依賴，改變參數(shù)輸入，看返回結(jié)果得到），則稱 A對(duì)B的依賴強(qiáng)度為 M／N，記作P（A B）＝M／N，P的范圍為0～1。當(dāng)0＜P＜0.5時(shí)，我們稱A弱依賴于B；當(dāng)0.5＜＝P＜＝1時(shí)，我們稱A強(qiáng)依賴于B；當(dāng)P＝0時(shí)，我們稱A與B無關(guān)系。

根據(jù)依賴強(qiáng)度，我們可以判定該組件是否是關(guān)鍵組件或是量化其重要性，從而分析優(yōu)化其數(shù)據(jù)和功能，利于第三方開發(fā)平臺(tái)的API分類提取，利于整個(gè)平臺(tái)系統(tǒng)的性能提升。

假設(shè)有A、B、C和D這4個(gè)組件，其依賴關(guān)系如圖3所示。

圖3 組件依賴示例

顯然，A、C和D依次直接依賴，B、C和D依次直接依賴。那么，我們假設(shè)P（A C）＝6／10，P（C D）＝2／10，P（B C）＝8／10。

根據(jù)性質(zhì)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四個(gè)組件的依賴強(qiáng)度矩陣［7，11］，如下

通過該依賴強(qiáng)度矩陣，我們可以快速分清各個(gè)組件之間的依賴關(guān)系，也可以計(jì)算出各個(gè)組件的被依賴強(qiáng)度。被依賴和被依賴強(qiáng)度的定義如下：

定義5 被依賴：若有且只有A1…An共N個(gè)組件依賴于B，則稱B被A1…An依賴，記作B（A1…An，其被依賴強(qiáng)度記作P（BA1…An）或者P（B），計(jì)算公式為

根據(jù)計(jì)算式（2），P（C）＝（P（A C）＋P（B C））／2＝（0.6＋0.8）／2＝0.7

因此，C的被依賴強(qiáng)度很高，屬于關(guān)鍵部件，而D的依賴強(qiáng)度不高，不是關(guān)鍵部件。在分類和設(shè)計(jì)時(shí)，應(yīng)該著重關(guān)注C。

綜上，依賴分析在行業(yè)應(yīng)用軟件第三方開發(fā)平臺(tái)設(shè)計(jì)中占有著重要作用，我們也提出了關(guān)注有效部件的方法，下面的分類設(shè)計(jì)就是采用這樣的方法來設(shè)計(jì)的。

2.3 API分類設(shè)計(jì)

保險(xiǎn)行業(yè)應(yīng)用軟件有著大量的數(shù)據(jù)和豐富的功能，其中，保險(xiǎn)核心業(yè)務(wù)系統(tǒng)包含了主要的內(nèi)容，從語義和功能上來講，保險(xiǎn)核心業(yè)務(wù)系統(tǒng)的組件庫中共收錄組件29個(gè)，包含接口3908個(gè)。然而，保險(xiǎn)核心業(yè)務(wù)系統(tǒng)由來已久，其數(shù)據(jù)規(guī)模越來越大，其組件也越來越因交錯(cuò)引用而更加紛繁蕪雜。而第三方開發(fā)平臺(tái)所要提供的功能是要高效和安全的，同時(shí)又要容易被業(yè)務(wù)外行上手，保證不會(huì)出現(xiàn)重復(fù)調(diào)用和產(chǎn)生冗余或者錯(cuò)誤數(shù)據(jù)，這就要求我們對(duì)已有的功能組件進(jìn)行依賴性分析，切斷組件循環(huán)依賴并找出關(guān)鍵組件進(jìn)行改進(jìn)優(yōu)化，并對(duì)功能組件進(jìn)行分類，從而形成保險(xiǎn)行業(yè)應(yīng)用軟件的API。

API分類設(shè)計(jì)的步驟如下：

（1）根據(jù)語義和業(yè)務(wù)功能，先進(jìn)行第一層粗粒度的劃分。

（2）在第一層劃分的基礎(chǔ)上，再對(duì)具體功能組件進(jìn)行依賴性分析，得出依賴關(guān)系，根據(jù)依賴關(guān)系，進(jìn)行第二層劃分。同時(shí)，也可以得出依賴強(qiáng)度，根據(jù)依賴強(qiáng)度進(jìn)行組件優(yōu)化或再設(shè)計(jì)。

（3）根據(jù)API方法簽名的不同和語義知識(shí)，設(shè)計(jì)API。通過以上步驟，最后得出的API層次是一個(gè)3層的分類結(jié)構(gòu)。其中，第一層包含投保類、批改類、保單類、權(quán)限類、理賠類、條款類、付款類等共計(jì)29大類。下面以保單類再進(jìn)行下一層的劃分。保單類包含保單生成組件（記為A）、保單下載組件（記為B）、保單驗(yàn)真組件（記為C），其中B A，C B。通過測(cè)試可以得出P（B A）＝0.84，P（C B）＝0.24 ，P（A）＝0.84，P（B）＝0.4，P

（C）＝0.2。由此可得A僅被B依賴，且依賴強(qiáng)度較高，應(yīng)該合并A與B，而C與A、B依賴強(qiáng)度弱，可以單獨(dú)存在。那么，保單層就分為了兩類，即保單下載組件（包含保單生成功能）和保單驗(yàn)真組件。最后，根據(jù)方法簽名的不同和語義知識(shí)，設(shè)計(jì)保單類的部分OpenAPI如下：

保單下載：policy.downLoad.getPolicy（String policy－No）。

保單驗(yàn)真：policy.verify.verify（Policy policy）。

3 保險(xiǎn)行業(yè)應(yīng)用軟件第三方開發(fā)平臺(tái)實(shí)踐和分析

行業(yè)應(yīng)用軟件第三方開發(fā)平臺(tái)包含兩部分內(nèi)容，一是行業(yè)應(yīng)用軟件第三方開發(fā)平臺(tái)授權(quán)，二是行業(yè)應(yīng)用軟件第三方開發(fā)平臺(tái)提供的數(shù)據(jù)和服務(wù)。保險(xiǎn)行業(yè)應(yīng)用軟件第三方開發(fā)平臺(tái)實(shí)踐是基于我們所提出的類OAuth授權(quán)方案和保險(xiǎn)行業(yè)應(yīng)用軟件第三方開發(fā)平臺(tái)所提供的數(shù)據(jù)和服務(wù)而進(jìn)行的實(shí)踐，本實(shí)踐主要是模擬第三方應(yīng)用開發(fā)商對(duì)第三方開發(fā)平臺(tái)API進(jìn)行調(diào)用，用以說明上述理論的正確性和實(shí)踐上的可行性。下面以某用戶登錄某SNS網(wǎng)站（假設(shè)此網(wǎng)站有通過我們的保險(xiǎn)行業(yè)應(yīng)用軟件第三方開發(fā)平臺(tái)所提供的API開發(fā)的車險(xiǎn)電子保單下載和驗(yàn)真應(yīng)用）下載車險(xiǎn)電子保單為例。

在該SNS網(wǎng)站上，用戶點(diǎn)擊下載車險(xiǎn)電子保單按鈕，將會(huì)啟動(dòng)下載車險(xiǎn)電子保單應(yīng)用，應(yīng)用調(diào)用加密算法為參數(shù)加密，形成請(qǐng)求授權(quán)的URL，請(qǐng)求方式為Get。

平臺(tái)接收到請(qǐng)求后，引導(dǎo)用戶登錄和授權(quán)，用戶登錄和授權(quán)后，將Session＿Key和經(jīng)過對(duì)稱加密的User＿Id返回給第三方應(yīng)用。第三方應(yīng)用收到這兩個(gè)返回值，形成訪問授權(quán)的URL，請(qǐng)求方式仍然為Get。

平臺(tái)再次接收到請(qǐng)求后，驗(yàn)證Session＿Key和User＿Id，解析傳入?yún)?shù)（驗(yàn)證和解析代碼略），調(diào)用平臺(tái)API policy.downLoad.getPolicy，返回xml格式的電子保單（電子保單略）。

經(jīng)過1000多個(gè)測(cè)試用例的安全測(cè)試，未發(fā)現(xiàn)我們的授權(quán)方案有安全漏洞，證明了我們的授權(quán)方案是可靠的，可依賴的。但在做并發(fā)和效率測(cè)試，當(dāng)請(qǐng)求達(dá)到500以上時(shí)，平臺(tái)效率明顯降低，經(jīng)過診斷，發(fā)現(xiàn)其瓶頸在于：平臺(tái)硬件資源不夠好；平臺(tái)API效率不夠高；平臺(tái)尚未支持分布式部署。解決這幾方面的瓶頸是今后的研究重點(diǎn)?？傮w上而言，我們的第三方開發(fā)平臺(tái)是安全和完備的。

4 結(jié)束語

本文提出了行業(yè)應(yīng)用軟件第三方開發(fā)平臺(tái)的構(gòu)建框架，即包含兩部分內(nèi)容：授權(quán)和數(shù)據(jù)服務(wù)。通過分析行業(yè)應(yīng)用軟件數(shù)據(jù)和服務(wù)的特征，改進(jìn)了互聯(lián)網(wǎng)普遍采用的OAuth授權(quán)方案，提出了基于數(shù)據(jù)依賴和組件依賴分析的行業(yè)應(yīng)用軟件第三方開發(fā)平臺(tái)的服務(wù)分類，并以保險(xiǎn)行業(yè)應(yīng)用軟件的第三方開發(fā)平臺(tái)為實(shí)踐，論證了我們的授權(quán)方案的正確性和證明了基于依賴分析來分類的合理性，證明了我們所提出的行業(yè)應(yīng)用軟件第三方開發(fā)平臺(tái)的構(gòu)建框架的可行性。

當(dāng)今，互聯(lián)網(wǎng)的蓬勃發(fā)展為互聯(lián)網(wǎng)行業(yè)第三方開發(fā)平臺(tái)提供了前所未有的機(jī)遇，互聯(lián)網(wǎng)行業(yè)OpenAPI發(fā)展如火如荼，這也正預(yù)示著行業(yè)應(yīng)用軟件的第三方開發(fā)平臺(tái)即將迎來曙光，本文也正是為其投石問路。今后，我們的工作將會(huì)以此為基礎(chǔ)，反復(fù)設(shè)計(jì)和觀察行業(yè)應(yīng)用軟件的第三方開發(fā)平臺(tái)，提高行業(yè)應(yīng)用軟件的第三方開發(fā)平臺(tái)的響應(yīng)效率和易用性等問題，逐步完善行業(yè)應(yīng)用軟件第三方開發(fā)平臺(tái)。

［1］CEN Wenchu.Analyses on open API［J］.Programmer，2009，9（1）：94－99（in Chinese）.［岑文初.Open API分析和實(shí)踐［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技術(shù)組合應(yīng)用于教學(xué)資源庫建設(shè)［J］.軟件導(dǎo)刊（教育技術(shù)），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）.［左春.行業(yè)應(yīng)用軟件中的詞根表和庫結(jié)構(gòu)［J］.計(jì)算機(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）.［姚偉志，左春，王裕國，等.基于語義的保險(xiǎn)構(gòu)件接口匹配研究與實(shí)現(xiàn)［J］.計(jì)算機(jī)工程與設(shè)計(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）.［張正，左春，王裕國，等.基于語義的領(lǐng)域構(gòu)件接口名稱匹配方法［J］.通信學(xué)報(bào)，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）.［胡艷麗，張維明，羅旭輝，等.基于數(shù)據(jù)依賴的數(shù)據(jù)修復(fù)研究進(jìn)展［J］.計(jì)算機(jī)科學(xué)，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）.［王 莉，李志蜀，殷鋒.基于組件依賴的測(cè)試序列優(yōu)化模型［J］.北京郵電大學(xué)學(xué)報(bào)，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）.［林宏康，李豫穎，阮群生.數(shù)據(jù)依賴與異常數(shù)據(jù)分離－應(yīng)用［J］.計(jì)算機(jī)科學(xué)，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）.［全立新.基于數(shù)據(jù)依賴信息的 Web服務(wù)合成［J］.科學(xué)技術(shù)與工程，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）.［閆昭，劉磊.基于數(shù)據(jù)依賴關(guān)系的程序自動(dòng)并行化方法［J］.吉林大學(xué)學(xué)報(bào)（理學(xué)版），2010，48（1）：94－98.］