基于Web Service和REST API的智慧校園SOA基礎框架設計

夏凌云，龔文濤

基于Web Service和REST API的智慧校園SOA基礎框架設計

夏凌云，龔文濤

首先介紹了“智慧校園”概念，并對國內高校的數字化校園過渡到“智慧校園”的過程中遇到的問題進行了分析和闡述，引入SOA概念，介紹了如何搭建SOA服務框架和利用SOA服務總線來對“智慧校園”的內部系統鏈接進行緊耦合的方案，并詳細介紹了兩種SOA服務的標準搭建模式：Web Service和REST API，闡述了“智慧校園”SOA服務框架的搭建過程和其中需要注意的事項，并分析了服務接口的加密方法和過程，敘述了服務接口的安全性如何得到保證。

智慧校園；面向服務的體系結構；解耦合；Web Service；REST API；HMAC

0 引言

智慧校園中“智慧”一詞可以追溯到2008年左右IBM公司提出的“智慧地球”概念。在其白皮書里指出，“智慧”的策略是“充分發揮先進信息技術的潛力以促進整個生態系統的互動，以此推動整個產業和整個公共服務領域的變革，形成新的世界運行模型”[1]。我們也可以說，智慧校園是“互聯網+”和“數字校園”的概括，是在數字校園的基礎上，將環境感知、物聯網和數字校園的信息服務相結合，加強了校園里人、物、環境之間信息的互聯和協作[2]，在學校內各個組織和個體之間形成多維互動關系，通過信息流在各個系統中的自由流動和利用，來實現校園生態系統的數字化升級。

智慧校園作為一個新理念在國內高校的智慧校園發展和建設過程中也遇到了很多新問題，由于數字校園內各個系統可能是由不同的軟件開發商和集成商設計實施，系統較為獨立，信息重復利用率低，通過建設統一數據平臺的形式，數字化校園里各個不同架構獨立的系統雖然大部分已經做到了數據和信息的共享，但是還是僅僅停留在單純數據層面，離智慧校園對信息在各個系統間自由流動的互動要求還相差甚遠。

在信息化快速發展的今天，開放、創新、協作和交互成為重點，高校內部應用系統和業務流程的更迭速度越來越快，面向服務的輕應用越來越多的取代原有的面向流程管理的老應用，原有數字校園的緊耦合已不能為智慧校園的基礎數據交互提供更好的支撐，如何借助智慧校園的理念，整合和改進“數字校園”的冗余數據變成一個研究熱點和難點。本文分析和總結了智慧校園的相關概念，給出了面向服務的體系結構（Service-Oriented Architecture，SOA），分析了其中的各個主要元素地位與作用，研究和總結了Web應用接口在SOA架構中的應用，安全層面就授權與加密的角度進行深入探討，提出了相應的安全策略和方法。

1 智慧校園和SOA

1.1 數字校園的緊耦合結構

經過近十年的發展，國內高校的數字化校園建設已經進入了成熟階段，一般來說數字校園系統是由各個業務系統和公用共享數據庫所組成。如圖1所示。

各個業務系統與公用共享數據庫之間，以及各個系統之間存在著數據和信息的單雙向傳遞關系。這樣就存在如下問題：第一是這些離散的系統架構相對獨立；第二是在系統部署期間實現的與其他系統和共享數據庫的數據傳遞是以實現特定功能和應用為目標，數據傳遞過程也缺乏標準化約束。所以數字校園是由各個業務系統緊密耦合組成的一個龐大系統，系統間的緊耦合主要表現在不同系統之間的接口相互依賴度非常高，導致各個獨立系統的軟件升級，系統業務流程的更改或新的業務系統的引入均需與其他關聯系統進行相應的數據對接和整合，尤其是新業務的不斷引入，更可能會導致系統間所需的數據傳遞過程數量指數級增長，導致管理和維護難度加大。

圖1 數字校園的緊耦合架構圖

1.2 SOA服務框架

面向服務的體系結構（Service-Oriented Architecture，SOA）并非一種全新和顛覆式的架構，相反SOA是隨著互聯網和信息系統的發展而逐漸進化而來的一種框架結構。SOA架構是一個典型的松散耦合架構，以網絡和Web作為基礎，使用XML，JavaScript Object Notation (JSON)等標準消息協議以允許多個獨立和分散的系統進行協同合作[3]。如圖2所示：

圖2 SOA三角色

SOA架構使用了3種角色（服務提供者，服務使用者和注冊中心）和3種基礎操作（發布、查找和綁定），來實現各個系統間的信息傳遞接口和傳遞流程標準化[4]。

SOA不局限于一種語言，也不是一種具體的技術，而是一種設計方法和體系。SOA服務框架分為數據集成層、服務層、業務層和表達層[5]。數據集成層為各個業務信息系統定義統一協議和訪問接口，將各種結構化和非結構化的信息數據以統一的接口放入數據總線，并在數據總線上按標準的格式進行傳輸；服務層用于將數據總線上的數據實例化，包裝成一個一個具體的服務包。數據集成層和服務層是智慧校園SOA基礎框架的核心，它們向位于業務層和表達層的各個信息系統提供標準化的數據服務。

1.3 智慧校園系統的解耦合

如上所述，智慧校園整體生態系統中，存在著各式各樣不同架構的應用系統，很多應用系統采用了不同的操作系統（Windows Server或 Linux）和不同的后臺數據庫（SQL Server、Oracle、MySQL等等），隨著各種應用在智慧校園系統中的覆蓋廣度和業務深度的高速發展，同時還帶來了越來越多的半結構化和非結構化數據資源傳遞和共享需求，不同架構的應用系統之間數據和消息傳遞過程變得越來越復雜。

在長期的建設過程中，我們逐步采用了SOA總線架構來實現各個應用系統的解耦合，在保持各個子系統框架和功能的前提下，將需要開放的數據和功能封裝成服務并放置于SOA總線上，屏蔽不同系統之間的異構技術，構建一個具有較大自由度的，邏輯上統一的，技術上開放的，面向服務的智慧校園動態協作體系，以此實現智慧校園信息系統的整體集成。

2 智慧校園中面向服務的框架實現

智慧校園面向服務的框架實現包括很多環節，核心的來說，主要包括智慧校園的SOA構建與設計，包括Web Service和Web API在其中的研發與應用，在這個過程中，授權和加密是安全加固的核心方法。

2.1 智慧校園的SOA框架

智慧校園的SOA框架如圖3所示：

圖2 智慧校園SOA框架

從下往上依次是：

智慧校園數據基礎層：由各個應用系統的不同的數據庫和非結構化數據組成，包含了智慧校園系統的所有基礎數據資源，執行由上一層發送來的各種指令，負責所有基礎數據的底層操作。

智慧校園數據整合層：由原數字化校園的統一數據平臺演化而來，對下層通過數據同步、復制和交換獲取各個應用系統的基礎數據，并將獲得的數據進行梳理和整合，再通過一定的信息標準，進行數據標準化轉換和協議標準化轉換，將數據打包成標準服務往上一層級發布。

智慧校園SOA總線：智慧校園的系統設計中，SOA服務總線可以視為輕量級的ESB（Enterprise Service Bus，企業服務總線）。總線型的系統數據交換設計方案能克服原有“點對點”方式的設計中很多諸如子系統之間的緊耦合，相互調用關系錯綜復雜，異構系統兼容性差等的缺點，是一種被SOA框架設計中廣泛采用的松散耦合集成方式。總線型的系統設計，借鑒了計算機硬件設計中的總線設計思想，以服務為單位，將各個子系統所能提供的服務標準化的放入服務總線，在南北方向上均提供統一的服務入口和出口，以便各個子系統間的相互調用，大大簡化子系統之間的集成拓撲結構和相互依存關系。

智慧校園SOA服務庫：SOA服務庫用于接受智慧校園SOA總線上各個子系統的基礎服務，形成智慧校園的基本服務庫。然后通過面向服務的框架思想，將各個基本服務按業務需求組合成相應的應用服務庫，提供給各個智慧校園子系統使用。

智慧校園SOA服務中心：用于定義、發布、授權和管理智慧校園的SOA應用服務，所有應用系統只需在此就能查找自己所需要的所有服務接口。如此一來，應用之間的服務調用只需在服務中心查找對應的服務端點，而不需要了解對方應用內部的具體信息，消除了應用系統間的硬編碼所帶來的緊耦合，提高了服務的可重用性，提升了業務系統的部署效率和數據利用效率。

從智慧校園系統的具體建設過程來說，底部的智慧校園基礎層和整合層是前期數字化校園建設的結果，其將基礎數據和信息利用諸如Oracle ODI等方式集中到了一個共享的數據庫平臺中，業務系統直接與數據整合層中的數據對接。但隨著子系統數量的快速增加，這種集成方式造成的系統間緊耦合情況已不能適應智慧校園的建設需求。因此有必要引入SOA服務框架，利用SOA總線、服務庫和服務中心來搭建智慧校園的SOA框架，讓數據和信息以服務為單位與各個子系統進行對接，實現各個子系統的松耦合連接。

2.2 Web Service在SOA中的應用

智慧校園SOA服務框架并不局限于某一個語言和技術，而是一種設計思想和方法，智慧校園SOA服務總線、服務庫和服務中心是整個面向服務框架的核心部分。它們需要既能在不同應用系統間相互傳輸，又能被各種異構系統廣為接受的數據傳輸和信息交換標準，因此基于 Web和 HTTP（Hypertext Transfer Protocol，超文本傳輸協議）的網絡服務成為了業界的一種較為廣泛的合理選擇，其中 Web Service和REST API尤其被大部分應用系統所接受。

Web Service在當前已經是一種被廣泛成熟采用的跨平臺信息交互技術，其具體細節本文不再累述。簡單地說，Web Service運用標準的Web接口對外提供服務，利用HTTP協議傳輸數據，使用XML作為數據標準，通過WSDL和SOAP協議對外提供標準的RPC調用方法。由于這些協議和標準已經被不同編程語言和平臺廣泛接受，所以通過Web Service來實現能夠服務于各個異構系統的SOA框架也隨之成為可能。Web Service服務的創建既可以使用Microsoft .NET也可以使用Java，在我們的智慧校園建設過程中更多的采用了.NET的模式。

構建流程如下：在 VS2013 C#里選擇新建一個網站（ASP.NET Web應用程序），然后在其內部添加一個 Web服務頁面，命名為jwxt.asmx，并在其內部輸入以下代碼段：

[WebMethod(Description="教務系統學生成績,輸入參數：學號；輸出參數：json格式信息")]

其中JWXX_CHENGJI是Web Service的方法名，字符串 account是本方法的輸入參數，內容為某學生的學號，JWXT類是教務系統后臺數據庫的實際讀寫類，該類對處于2.1所述的“智慧校園數據整合層”中教務系統數據進行讀寫操作，其中的ChengJiInfo方法的實現了按學號的成績查詢功能，最后JWXX_CHENGJI方法的return代表將查詢結果返回給該Web Service的調用者。

在將該頁面發布到網站后，該Web Service服務就能被其他系統方便的調用了，在大多數開發環境下，直接引用jwxt.asmx或jwxt.asmx?WSDL頁面URL，就能直接對頁面內包含的方法進行遠程 Web調用。從這里可以看出，Web Service在為第三方調用提供了標準的接口和方式的同時，還能對外部系統屏蔽自身系統的內部邏輯，較好的解除了各個系統之間的相關性，一個系統只需要了解和調用其它系統提供的服務接口就可以方便得使用其相關功能和數據資源。

2.3 Web API在SOA中的應用

作為許多的Web協議設計者，Roy Thomas Fielding在他的論文中首次提出了REST（REpresentation State Transfer，表述性狀態傳輸）概念[6]，和SOA相似，REST不是一個標準，而是一種基于網絡的軟件架構設計風格和原則，經過多年發展和實踐檢驗，REST風格的Web服務設計現在以其易于使用和接受的優點，成為各個Web2.0服務提供者（包括Yahoo、Google 和 Facebook）基于SOAP和WSDL的Web Service架構更為簡單的替代辦法[7]。在智慧校園的SOA服務框架實現過程中，也逐漸加入符合REST風格的RESTful Web服務來補充和替代前述的Web Servcie服務。

REST Web服務的框架，主要應該遵循以下四個基本原則[7]，同時結合以往專家學者對RPC模型和REST模型進行的詳細比較和論述[8]，我們可以看到REST Web服務的優勢和特點：

顯式的使用 HTTP方法：遵循 RFC2616[9]所定義的HTTP/1.1協議，并將其中定義的POST、GET、PUT、DELETE四個標準HTTP動作與SOA服務中對數據資源的CRUD（Create, Read, Update, Delete）四種操作方法一一對應；

標準的URI目錄結構：使用URI[10]（Uniform Resource Identifier，統一資源標識符）來作為服務地址發布形式，利用URI的標準性和直觀性來使服務接口更易于被使用者理解和調用；

支持多種數據表示格式：在數據傳輸中可以由調用端通過設置HTTP頭中的Accept參數來指定采用XML，JSON或者其它數據標準作為數據交換格式，使得接口可以被不同平臺和架構的系統，使用不同編程語言的客戶端調用，大大增強了接口的可用性和適配性；

服務提供端無狀態設計：服務提供者不負責保存和維護當前業務所處的狀態，而是把這部分工作交給服務使用者，以此來省略服務提供者和使用者之間同步會話的過程，降低服務提供者接口和組件的設計和實施難度。

針對在智慧校園 SOA服務框架的搭建過程中使用REST服務，上述的第一個和第二個特性利用標準的顯式接口方法和統一資源標識，增強了服務接口的可讀性，從而大大簡化SOA注冊中心的設計；第三個特性提供給了SOA服務多重表示性，保證了SOA服務可以被不同平臺和設備以不同的數據標準調用；第四個特性在簡化服務接口設計的同時，為智慧校園SOA服務框架提供了靈活的并行部署能力，服務提供者免于負責與服務調用者的會話維護和狀態保持任務后，更容易實現負載均衡和冗余，為智慧校園“云”架構和“云”服務的實現打下堅實基礎。

滿足 REST規范的 RESTful服務提供者可以由.NET Web Api或者Java Restlet來實現，我們在智慧校園SOA框架搭建中，采用了.NET Web Api來構建RESTful服務，采用“/api/{控制器名}/{方法名}/”的格式來定義 URI，現以用戶信息服務為例，說明 RESTful服務的發布情況如表 1所示：

表1 相關函數對應信息表

Accept參數都指定為了JSON格式，在實際使用中也可以調用者的需要設置為Xml或者其它格式。可以看出，通過將HTTP動作與資源實際操作做了映射后，結合統一標準的 URI來對接口進行顯示調用非常直觀和方便，可以很好的降低系統間的耦合度。需要額外指出的是，在服務端響應每個請求時，也需按RFC定義返回不同的HTTP狀態碼，比如正常響應時的HTTP 200（OK,請求成功），以及HTTP 404（NotFound，未發現資源）、HTTP 405（MethodNotAllowed，不允許的方法）、HTTP 401（Unauthorized，授權錯誤）等等狀態碼，而不是統一返回HTTP 200并附加錯誤提示的方式，避免系統間接口相互操作時的響應錯誤識別。

2.4 授權和加密

無論是Web Service還是REST API服務，都是智慧校園服務框架暴露給外界的接口，其安全性非常重要，需要具備訪問控制功能來防止非授權方利用服務接口對后臺資源進行非法讀取、更改或刪除。在這里我們采用了基于RFC-2104的HMAC[11]（keyed-Hashing for Message Authentication，鍵值-哈希消息授權）來對服務使用者來進行身份驗證。

利用HMAC機制，服務中心在每個服務調用者申請授權的時候為其分配兩個一一對應的字符串：access-key和access-secret，同時將其告之所申請服務的服務提供者。其中access-key可以在網絡中傳輸，主要用于申明和識別服務調用者，access-secret只保存在本地，用于對服務消息的hash簽名加密。HMAC主要利用HTTP HEADER里的字段來進行身份簽名，一個簡單的簽名流程如表2所示：

利用HTTP HEADER里的HTTP-Verb、URI和Date字段，以及服務中心為其分配的 access-secret，組合成一個待簽名字符串，并將這個字符串進行 SHA-1(Secure Hash Algorithm1[12]，安全哈希算法 1)加密，最后將得到的 Hash值做Base64[13]轉換后和access-key以“:”作為分隔符一起加入HTTP HEADER的Authorization字段。

表2 源HTTP HEADER簽名信息

當服務提供方接收到以上Web請求后，首先根據請求HEADER中的Authorization字段前半部分（access-key）識別請求來源，并在其后臺查詢該 access-key對應的access-secret，按照相同的方法將access-secret、HTTP-Verb、URI和 Date字段組合后同樣進行 SHA-1加密，將得到的Hash簽名再與Authorization字段中后半段的簽名進行對比，如果完全相同則表示該請求的access-key和access-secret相互對應，請求來自于已被SOA注冊中心授權的正式服務使用者。在上述的例子里，簽名包含的Date字段用作時間戳，當請求里的Date字段所代表的UTC時間與服務器UTC時間差大于一定數值后（一般可設為 15s-120s），服務器可認為簽名過期而直接丟棄請求包，可用于防止請求包被截獲后的復制攻擊或非法調用；簽名中包含的HTTP-Verb和URI是用于確認該請求動作和指向資源的正確性。一般來說，包含這幾個HEADER參數簽名的請求，基本上就能保證接口的授權驗證，不過在更高驗證需求下，還可以將其它HTTP HEADER參數加入待簽名字符串中一并進行簽名驗證。另外，也可以采用更為安全的 SHA-2[12]來替代 SHA-1作為HMAC的簽名算法，并且使用HTTPS協議代替HTTP在網絡傳輸時對數據進行密文傳輸。

3 總結

在智慧校園的SOA服務框架建設過程中，基于對系統兼容性和穩定性原因，既采用了Web Service也采用了REST API來作為服務標準，在一些老系統中主要使用了 Web Service接口，不過隨著技術發展和成熟，服務提供者的建設重心逐漸轉移到伸縮性更好、交互性更強、接口更簡單的RESTful服務，并以此基礎，實現了一些智慧校園應用，取得了不錯的效果。

[1] IBM.智慧地球贏在中國白皮書[EB/OL].http://www-935.ibm.com/services/cn/bcs/iibv/strategy/smarter_planet .html,2014-05-28.

[2] 宗平,朱洪波,黃剛,許建真.智慧校園設計方法的研究[J].南京郵電大學學報(自然科學版),2010,30(4):15-19,51.

[3] 凌曉東.SOA綜述[J].計算機應用與軟件, 2007(10).

[4] 王衛星.王晨光.基于 SOA的企業信息系統集成框架[J].計算機工程, 2010(18).

[5] 李文璟.邱雪松. 基于SOA的IP網管系統間動態協作體系結構[J].通信學報,2008(12).

[6] Fielding R. T Architectural styles and the design of network-based[M]. Software Architecture, 2000.

[7] IBM. 基于 REST 的 Web 服務：基礎[EB/OL] https :// www.ibm.com/developerworks/cn/webservices/ws-restful/ 2008-12-22.

[8] 許卓明,栗明,董逸生.基于RPC和基于REST的Web服務交互模型比較分析[J].計算機工程, 2003(20).

[9] RFC 2616: Hypertext Transfer Protocol--HTTP/1.1 http://www.ietf.org/rfc/rfc2616.txt.

[10] RFC3986:Uniform Resource Identifier (URI): Generic Syntax[S] http://www.ietf.org/rfc/rfc3986.txt.

[11] HMAC: Keyed-hashing for Message Authentication http://www.ietf.org/rfc/rfc2104.txt.

[12] Secure Hash Standard (SHS)[S]:http://csrc.nist.gov/ publications/fips/fips180-4/fips-180-4.pdf.

[13] RFC 4648:The Base16,Base32,and Base64 Data Encodings[S] http://www.ietf.org/rfc/rfc4648.txt.

Design of Smart Campus SOA Foundation Framework Based on Service Web and API REST

Xia Lingyun, Gong Wentao
(Internet and Education Technology Center, China University of Petroleum (East China), Qingdao 266580,China)

With the continuous development of information construction of the school, on the stability of machine operation of the increasingly high demand for the room temperature and humidity data real-time monitoring, this paper presents the design of equipment room environment monitoring system based on temperature and humidity, making final implementation to control the room temperature and humidity information, so that the managers can monitor and manage the room.

Temperature; Humidity; Monitoring

TP393

A

1007-757X(2016)09-0051-04

2016.05.10）

夏凌云（1980-），男，四川瀘州人，中國石油大學（華東），網絡及教育技術中心，碩士研究生，工程師，研究方向：互聯網技術、計算機軟硬件技術和物聯網技術，青島 266580龔文濤（1984-）男，湖北潛江人，中國石油大學（華東），網絡及教育技術中心，碩士研究生，工程師，研究方向：網絡信息安全，青島 266580