行業應用軟件第三方開發平臺的研究與實踐

祝金偉，左 春，，張 正

（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.］