行業(yè)應(yīng)用軟件第三方開發(fā)平臺的研究與實踐

祝金偉，左 春，，張 正

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

0 引 言

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

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

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

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

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

圖1 典型場景

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.1 數(shù) 據(jù)

2.1.1 請求數(shù)據(jù)

2.1.1.1 請求 URL

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

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

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

2.1.1.2 請求參數(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：注冊應(yīng)用時平臺為其生成的Id。

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

Timestamp：請求發(fā)送的時間戳。

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ù)加密，密鑰采用注冊應(yīng)用時分配到的應(yīng)用密鑰app＿secret或者用戶session密鑰（Md5加密算法略）。

2.1.1.4 用戶ID加密

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

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

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

第三方開發(fā)平臺的響應(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è)計不明晰。因此，需要分析和研究數(shù)據(jù)和組件的依賴關(guān)系，分類和設(shè)計好組件，這也是OpenAPI的基礎(chǔ)。在分析和研究數(shù)據(jù)和組件依賴的之前，我們先闡述如下定義：

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

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

定義2 組件依賴［7，9］：給定組件A與B，若A對B至少有一次依賴運算且B對A沒有依賴運算，則稱組件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ù)之間的依賴和組件之間的依賴影響整個系統(tǒng)的穩(wěn)定性以及質(zhì)量，依賴能夠設(shè)計得適當(dāng)，整個系統(tǒng)會是一個和諧的整體。在行業(yè)應(yīng)用軟件第三方開發(fā)平臺中，這種依賴的重要性更為明顯，進行依賴性分析更為重要。依賴分為直接依賴和間接依賴，且有強弱之分，為更好的對依賴進行分析，我們給出依賴強度的概念如下：

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

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

假設(shè)有A、B、C和D這4個組件，其依賴關(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四個組件的依賴強度矩陣［7，11］，如下

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

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

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

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

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

2.3 API分類設(shè)計

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

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

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

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

（3）根據(jù)API方法簽名的不同和語義知識，設(shè)計API。通過以上步驟，最后得出的API層次是一個3層的分類結(jié)構(gòu)。其中，第一層包含投保類、批改類、保單類、權(quán)限類、理賠類、條款類、付款類等共計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依賴，且依賴強度較高，應(yīng)該合并A與B，而C與A、B依賴強度弱，可以單獨存在。那么，保單層就分為了兩類，即保單下載組件（包含保單生成功能）和保單驗真組件。最后，根據(jù)方法簽名的不同和語義知識，設(shè)計保單類的部分OpenAPI如下：

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

保單驗真：policy.verify.verify（Policy policy）。

3 保險行業(yè)應(yīng)用軟件第三方開發(fā)平臺實踐和分析

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

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

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

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

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

4 結(jié)束語

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

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

［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技術(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］.計算機世界，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）.［姚偉志，左春，王裕國，等.基于語義的保險構(gòu)件接口匹配研究與實現(xiàn)［J］.計算機工程與設(shè)計，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é)報，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］.計算機科學(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）.［王 莉，李志蜀，殷鋒.基于組件依賴的測試序列優(yōu)化模型［J］.北京郵電大學(xué)學(xué)報，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］.計算機科學(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)系的程序自動并行化方法［J］.吉林大學(xué)學(xué)報（理學(xué)版），2010，48（1）：94－98.］