服務導向架構
(SOA)之校園全方位收費平台
陳啟煌
臺灣大學計算機及資訊網路中心
[email protected]
摘要
為了強化資訊系統服務層面，臺灣大學於2005 年9 月建置了校園線上收費平台，提供校內系統線 上收費機制，在系統設計階段，考量除由計資中心 自行開發之核心校務系統外，另有校內各系所自行 開發之報名網頁亦有線上收費需求，故採用服務導 向架構(Service-Oriented Architecture)來建構此收費 平台，截至2008 年 8 月，已有校內 33 系所單位申 請採用此收費服務，累計已產生23,611 筆繳款單紀 錄，一如系統設計預期，此收費平台成功地應用到 校園內多項收費機制，校內各系所多使用本平台服 務來收取研討會或活動報名費，去年舉辦的TANET 2007 研討會亦是。 服務導向架構在業界已倡導多年，但是引進校 園資訊系統的實例並不多見，在本篇論文中，我們 藉分享此服務導向架構校園收費平台之建置及運 作經驗，以此三年的系統運作經驗，證明服務導向 架構確實能花揮其優點，成功將線上繳費機制推展 至校內各應用。希望本論文能發揮拋磚引玉的效 果，讓更多校務系統採用服務導向架構設計。 關鍵詞：服務導向架構、網路繳費機制、網路列印Abstract
In order to enhance the information system services, National Taiwan University built an e-payment platform for web users in Sep, 2005. In the system development phase, we consider that not only the core systems developed by computer center but also the systems of departments need the e-payment service. Therefore, we adapt the Service-Oriented Architecture to build this e-payment platform. As of Aug, 2008, there were 33 departments use this e-payment service. And there were 23,611 e-bill records generated by this platform. As expected, this e-payment platform meets the purpose of design and used by many campus applications in NTU. Many departments use this e-payment service to charge the conference registration fee, and the TANET 2007 is one of them.
Service-Oriented Architecture have been advocating for many years. However, there were few successful reference systems in campus administration. In this paper, we share this e-payment platform development experience. And this platform has been
operation for the last 3 years in NTU. We show as a proof that the Service-Oriented Architecture can really provide online services to cooperation systems. By sharing this development experience, we hope we can see more campus information systems using the Service-Oriented Architecture in the near future.
Keywords: Service-Oriented Architecture, E-Payment,
Web Printing.
1. 前言
1.1 緣起 E 化資訊系統的建置提供使用者一個虛擬通 路，每個人無論在世界哪個角落都能隨時申辦所需 各項業務，不受辦理單位上下班時段限制。尤其在 此節能減碳的年代，少用馬路多用網路能替環境保 護盡一份心力。但是資訊化系統流程的某些環節尚 缺線上完成的機制，例如線上收費機制。雖近年來 政府及銀行陸續提供線上繳費的平台，似乎可以解 決線上收費的問題，也有學校引進校園資訊系統應 用[7]。但是若將收費機制寫入某一校務系統，代表 的是收費核帳權限也隨之進入個別系統。收費核帳 牽涉金流在資訊系統算是相對敏感資料，故如此作 法僅能將收費機制實做在核心的校務系統內。 學校跟其他企業或政府組織不同，除行政單位 外校內存在很多教學研究單位，這些單位每年有機 會舉辦多項國內外研討會、營隊、演講、教育訓練 等活動。這些活動未必是以學校層級來舉辦，故行 政流程由系所自行負責，拜資訊教育普及，系所多 可聘僱兼職人員或工讀生來幫忙撰寫系上自行舉 辦之活動報名網頁，倘若活動需要報名費用則亦需 線上收費機制。受法規限制行政規費需入學校帳 戶，且需由出納單位代表開戶，系所無法自行開設 私戶，故收費機制僅能由校方統一提供。雖台灣大 學已規劃全校共用的活動報名網頁服務，但因僅能 針對一些共同性質需求設計；系所如有特殊需求的 活動仍無法納入該系統。如何讓系所單位自行撰寫 的報名網頁亦可具有線上收費的功能，且不需花費 太多行政及程式開發成本，是值得研究且實際的課 題。1.2 服務導向架構導入校園資訊系統
近年來資訊系統開發廠商一直在提倡服務導 向架構(Service-Oriented Architecture) ，如 IBM[2] 及 Microsoft[3]皆提出服務導向架構系統整合方 案，服務導向架構的特性為：使用開放的標準(Open standard)、低隅合(loosely coupled)程式介面及分散 式架構(distributed)，恰與本平台設計理念相符，故 本收費平台採用服務導向架構來設計，期能透過預 先制訂好的服務介面讓各子系統可獨立設計；但若 需合作時又可合作無間。本論文嘗試利用服務導向 架構來建構一校園收費平台，整合代收銀行提供的 所有收費管道，提供校園全方位線上收費解決方 案。
2. 系統需求及解決方案
2.1 系統需求 除線上收費系統所需的功能外，系統設計需能 滿足以下等系統需求，才能確保系統運作無虞。 2.1.1 安全性 收費機制牽涉到交易行為及金流，故資訊系統 的安全性一定要優先考量，不容交易資料被竄改、 假冒等情事發生，否則系統將無法順利運作。 2.1.2 跨平台及程式語言 前端報名網頁程式分屬不同單位開發，自然無 法要求統一作業平台及使用同一種程式語言開發 系統，故跨平台及跨語言是一定要達成的需求，否 則無法與各前端網頁互動(Interoperability)。 2.1.3 穩定性 因為提供全校各單位收費機制，故需維持 24 小時全天候的系統服務，需預防服務停擺(downtime) 的發生，因隨時需與前端網頁維持即時互動，故系 統穩定性是非常重要的需求。 2.2 採用方案 考量以上三種系統需求，經過研究分析後，採 用之解決方案說明如下。 2.2.1 安全性 與其他前端系統互動皆透過網路傳輸，為避免 資料在傳輸時遭到有心人士竊聽或竄改，交易全程 使用SSL(Secure Socket Layer)加密，杜絕網路傳輸 漏洞產生。 服務需先登記，由系統產生一組帳號密碼。交 易 進 行 中 會先 認 證 帳 號密 碼 之 正 確性 再 提 供 服 務，以防有其他網頁冒用進而竊取資料。 服務大多在校內建置，故構築最後一道防線， 限制前端程式存取 IP，非正常授權之 IP 位置伺服 器不提供服務，杜絕駭客刺探系統漏洞。 2.2.2 跨平台及程式語言 採 用 服 務 導 向 架 構 (Service-Oriented Architecture)來設計本收費平台，透過開放的協定如 SOAP (Simple Object Access Protocol), XML 文件達 成系統互動功能，並利用PDF 格式提供網路列印服 務，服務導向架構的特性，不限制程式語言及作業 平台，故可達到跨平台及跨語言的需求。2.2.3 穩定性
為了提供不中斷的服務，系統架構需考量負載 平衡(Load Balance)及容錯(Fault tolerance)設計。
在網頁伺服器採用高可用度(High Availability) 系統設計以滿足負載平衡需求，利用windows server 的 Network load balance 技術, 達成網頁高可用度 功能，由一群伺服器提供服務，只要任一台伺服器 正常運作即可對外提供正常服務，亦可觀察伺服器 負載情形增減網頁伺服器數目，發揮負載平衡的優 勢。
在資料庫伺服器採用叢集式(Cluster)架構滿足 容錯需求，採用Windows Server Cluster 功能，建 置一叢集伺服器由兩台伺服器組成，將資料庫服務 設定為該叢集服務項目之一，如此只要有一台伺服 器正常運作，資料庫即可正常服務，達成容錯的要 求。
3. 系統設計與實做
3.1 系統架構 本收費平台系統架構如圖1 所示： 圖 1 系統架構收費機制係由前端各收費單位報名網頁、收費 系統模組及代收銀行系統模組三部分所構成，在提 供服務前，各收費單位需先在收費系統模組登記一 組帳號密碼及伺服器IP 位址，供呼叫服務時認證使 用。 使用者在各單位報名系統的使用者介面輸入 資料，執行到線上收費功能時，單位報名網頁會透 過SOAP 協定傳遞 XML 文件至收費系統模組。之 後收費系統模組處理完相關並回傳一組唯一的 14 碼虛擬繳費帳號交由前端單位報名網頁顯示給使 用者，有關收費系統模組詳細設計及功能運作於下 節3.2 分模組詳述之。 使用者獲得此虛擬繳費帳號即可透過 ATM 轉 帳、網路銀行等虛擬通路繳費或印出繳費單到銀行 臨櫃繳納或交由便利超商代收。 銀行完成繳費交易後將相關銷帳資料傳至收 費系統模組進行銷帳，使用者繳費可透過原報名查 詢繳費狀態，並進行後續相關作業。 有關報名網頁與收費系統模組如何利用 SOAP 協定互相交換XML 文件，最主要是利用 xmlhttp + DOM(Document Object Model)達成 XML 文件傳遞 及XML 處理，ASP 程式碼片段如圖 2，(其他程式 語言亦支援類似物件) 圖 2 SOAP 程式碼片段 3.2 系統模組 本 收 費 平 台 採 用 服 務 導 向 架 構 (Service-Oriented Architecture)，模組功能以提供的 服務(Service)來切割，最主要可分繳費單、銷帳、 列印、信用卡橋接、及使用介面模組所組成，其功 能詳述如下： 3.2.1 繳費單模組 此模組提供產生繳費單服務，供前端各單位收 費報名網頁呼叫，收費相關資料以 XML 文件儲存 範例如下： 其中包含認證所需資料，及繳費單所需欄位資 料，本模組將相關資料寫入收費系統資料庫後， 依照給號原則產生14 碼虛擬繳費帳號，回傳給原 呼叫報名網頁。 14 碼虛擬繳費帳號組成如下，4 碼為學校代 碼、2 碼為單位碼(校內單位識別)、7 碼為流水號、 末碼為檢查碼，檢查碼係由與銀行約定之原則算 出，用以驗證繳費金額並防止使用者線上繳款時 輸錯帳號。
9 6 1 6 3 1 0 0 0 3 1 3 9
1
學校代碼
單位碼流水號
檢查 碼 3.2.2 銷帳模組 本模組最主要有兩個功能一為收取銀行銷帳 資料用以銷帳；二為回應前端收費網頁詢問回傳相 關銷帳結果。 銀行定時將繳款成功的虛擬繳費帳號及繳款 結果傳至本銷帳模組，本模組即時啟動銷帳功能並 將銷帳結果即時寫入收費系統資料庫。 當使用者在前端報名網頁查詢個人繳費情形 時，報名網頁會以 14 碼虛擬繳費帳號傳至銷帳模 組詢問銷帳情形，銷帳模組會回傳銷帳 XML 文件 如下，前端報名網頁處理該 XML 文件即可得到銷 帳結果並回應使用者。3.2.3 列印模組 目前金融繳費管道眾多，雖可利用網路 ATM 或網路銀行等虛擬通路轉帳；但皆須收取若干手續 費，故仍有部分使用者選擇免手續費之實體通路繳 費，如銀行臨櫃、便利超商代收等，如使用實體通 路繳費則需列印出紙本繳費單，本模組負責產出代 收銀行所接受的實體繳費單。 某些通路(如郵局)需將繳費單送入專用機器打 印辨認，對於繳費單列印格式有一定的規範，故網 路列印需達到絕對定位的功能，本系統採用PDF 格 式列印。早期 PDF library 多為國外所撰寫，在中 文double bytes 處理有些問題，本系統捨棄引用國 外現成的程式庫，改採參考 PDF 格式規範[1]自行 開發PDF library； 由於自行開發 library 故可對程 式做最佳化，以增快PDF 產出速度及減少耗用系統 資源；除此之外具備擴充性不會被現成library 所限 制住，可自行增加所需功能(如中文直書)，此為套 用現成 library 不一定能做到的功能。圖 3 為 PDF 繳費單範例。 圖 3 PDF 格式繳費單 3.2.4 信用卡橋接模組 網路的世界無遠弗屆E 化系統也不限只用於國 內，部分校內單位需要有境外收費機制，如外籍生 入學、成績單申請規費、或國際研討會外籍註冊費 等，傳統繳費管道僅能利用匯款或現金支票支付， 除了曠日廢時外，手續費十分高昂甚至比本來要收 取的規費高(如成績單)。現今大學對於國際化努力 不遺餘力，提供一快速便捷低成本的境外收費管道 是十分必須的。 最適合跨國交易的管道應屬信用卡交易。但是 不同於一般的繳款通路，為了保障刷卡者信用卡資 料不致外洩，信用卡線上刷卡機制需在銀行專屬網 頁進行，本系統恰好利用服務導向架構的特性，將 銀行線上刷卡的網頁整合進系統。 在使用者選擇以線上刷卡付款時，報名網頁除 依照 3.2.1 繳費單模組產生繳費資料外，並將網頁 導向銀行線上刷卡專屬網頁如圖4 所示，並將繳費 單資料傳入該網頁。當使用者在該刷卡網頁填入信 用卡相關資料後，銀行即時處理後會將該筆交易之 結果及授權碼傳回本系統並將網頁導回，由本模組 接手將結果寫入收費系統並回傳至前端付款網頁。 圖 4 合作銀行線上刷卡網頁 3.2.5 使用者介面模組 本收費系統模組設計除提供沒有使用者介面 之服務供前端其他收費單位報名網頁呼叫外；考量 某些單位亦有少量手動輸入之繳費單需求，故本系 統亦提供統一使用者介面供各收費單位及繳款人 使用。當收費單位登入系統時會進入管理介面如圖 5，可清楚呈現單位所屬之繳款單及銷帳情形。 圖 5 管理端使用者介面
另一使用介面則提供一般繳款人使用如圖6， 輸入收費單位及繳費ID 後可以查詢個人歷次繳費 記錄及銷帳情形如圖7，如有需要亦可透過本介面 補印繳款單。 圖 6 繳款人登入介面 圖 7 繳款人使用者介面
4. 成果與效益分析
本收費平台運作近三年來已有校內 33 個收費 單位申請使用，累計已產生23,611 張繳費單。 以服務導向架構設計出來本收費平台，除正常 提供線上收費服務外，在此檢視原本系統設計的三 大需求：安全性、跨平台跨語言、穩定性。 在安全性方面，系統運作以來未曾發生繳費單 異常或銷帳異常狀況，足見系統正常運作，未受外 來攻擊導致系統錯誤。 在跨平台跨語言方面，主要系統模組是以ASP 在Windows 2000 平台上開發，外單位收費網頁採 用的平台有Linux, Windows 等，所使用程式語言有 ASP, PHP, MS .Net C#, VB 等，已囊括大部分普遍 使用的網頁語言，故毫無疑問地達成跨平台跨語言 的要求。當初為了推廣此收費平台，以ASP 寫作範 例程式供其他單位呼叫時參考，目前已有5 種程式 語言之範例程式可供後申請者參考，加快收費平台 使用的推廣。 在穩定性方面：此系統需達到 24 小時全天候 運作，為了驗證穩定性，除了在測試期系統利用使 用網頁壓力測試(web stress test)工具測試各模組網 頁外，對於線上系統亦定期分析其Web Log 觀察服 務的運行狀態。進行壓力測試的環境為一台具有兩顆 Xeon 3.0GHz CPU 配備 3G 記憶體的伺服器，Client 為 IBM T40 筆記型電腦，連接到 Gigabit Switch 組成 一個封閉的區域網路，並在測試伺服器上同時安裝 資料庫及網頁服務。壓力測試軟體採用 Microsoft web application stress[4]，模擬 100 個 Users 不斷進 行繳費單產生程序，持續5 分鐘。同時觀察伺服器 上效能監視器，設定觀察 %Processor Time, Bytes Total/Sec, Request Execution Time, Requests Queue, Requests Time Out, Request Wait Time, Memory Available MBytes 等指標。從圖 8 壓力測試報告可 看出，5 分鐘內共產生 126,317 張繳費單，平均每 秒可產生421.82 張繳費單。從圖 9 效能監視器指標 Requests Time Out=0 表 示 無 繳 費 單 產 生 Time Out，Requests Queue 平均 90，Request Wait Time 平 均 0.237 秒，表示使用者等候的時間並不長，且此 數據遠高於未來正式營運時的需求。 進行壓力測試除可看出系統處理容量外，還可 藉由觀察記憶體使用，找出程式是否有 Memory Leak；或從資料庫連結數量看出是否有未還的資料 庫連結要求，避免留下日後上線時難找的未爆彈。 圖 8 壓力測試報告 圖 9 效能監視器畫面
運行中的系統監測部分，將Web Server Log 利 用Log Parser[5] 匯入資料庫，分析每個繳費單產生 伺服器所花費的時間(time-taken)的時間，以追蹤控 管伺服器效能是否足夠。 採用SOA 架構後大部分系統功能轉成 Services 形式提供服務，有利於壓力測試與效能調校，藉由 分析 Services 所花費的時間，挑選常被 Call 用的 Services 做最佳化找出系統瓶頸，以花揮伺服器最 大的效能，達成利用有限的資源提供最優質的服務 的目標。 除了觀察其他監測指標外，為了證明本系統為 24 小時全天候運作，特將繳費單依照產生時段統計 如表1，可得知即使是凌晨亦有繳費單能成功產生。 表1.繳費時段統計數
繳費時段
繳款單數量
%
00:00:00-00:59:59 929
3.93%
01:00:00-01:59:59 448
1.90%
02:00:00-02:59:59 244
1.03%
03:00:00-03:59:59 122
0.52%
04:00:00-04:59:59 74
0.31%
05:00:00-05:59:59 68
0.29%
06:00:00-06:59:59 95
0.40%
07:00:00-07:59:59 171
0.72%
08:00:00-08:59:59 574
2.43%
09:00:00-09:59:59 1,311
5.55%
10:00:00-10:59:59 1,745
7.39%
11:00:00-11:59:59 1,805
7.64%
12:00:00-12:59:59 1,620
6.86%
13:00:00-13:59:59 1,703
7.21%
14:00:00-14:59:59 1,810
7.67%
15:00:00-15:59:59 1,690
7.16%
16:00:00-16:59:59 1,599
6.77%
17:00:00-17:59:59 1,353
5.73%
18:00:00-18:59:59 926
3.92%
19:00:00-29:59:59 818
3.46%
20:00:00-20:59:59 970
4.11%
21:00:00-21:59:59 1,095
4.64%
22:00:00-22:59:59 1,252
5.30%
23:00:00-23:59:59 1,189
5.04%
2005/9/26-2008/8/16 收費資料庫分時統計結果 本平台最主要的效益為加快繳費及銷帳速度 及提供各單位收費機制，依照網路繳費行為分析研 究[6]指出傳統臨櫃與 ATM 轉帳使用等待時間，臨 櫃平均需花費40 分鐘；而 ATM 轉帳僅需 5 分鐘。 近年來隨著 ATM 讀卡機普及，各銀行提供更便捷 之Web ATM 服務，故此數據應該可再下修，保守 估計平均可省去每名繳費者 35 分鐘繳費時間。由 系統自動化銷帳不需以往人工銷帳，可使作業流程 簡化加速線上申辦流程，可大幅提昇行政效率。 本平台使用服務導向架構，各收費單位僅需按 照服務(Service)的規範，運用自己的程式語言來呼 叫收費平台所提供之相關服務，省去每個單位需重 複開發相同的收費模組，可節省程式開發人力及縮 短開發時程。5. 結論
透過本收費平台的服務，除了核心校務系統 外，也可讓校內各單位自行開發的網頁具有收費機 制，以加速及普及 E 化系統應用在校園各項事務 上，經過三年的運作驗證以服務導向架構確實可將 共用的服務提供給不同的開發者使用，達到節省系 統開發時間及降低開發成本的效益。 本平台已達成線上收費的大部分功能，唯剩下 繳款後一個步驟開立收據，雖台灣大學已完成收據 開立電子化，但受限於法令需認關防，各個收費單 位仍需領用印有台大關防之空白收據套印，故無法 透過網路開立電子收據，財政部近年來已推出電子 發票平台，希冀未來可推動電子收據，屆時本系統 只要新增一模組來開立電子收據，使整個繳款機制 均可在線上進行。參考文獻
[1] Adobe Systems Incorporated PDF Specifications (http://www.adobe.com/devnet/pdf/pdf_reference. html)
[2] IBM Service Oriented Architecture SOA Solution (http://www-306.ibm.com/software/solutions/soa/) [3] Microsoft SOA & Business Process Web Site
(http://www.microsoft.com/SOA/)
[4] MS TechNet:Microsoft web application stress (http://www.microsoft.com/taiwan/technet/itsoluti ons/ecommerce/maintain/optimize/d5wast_2.aspx? mfr=true)
[5] Microsoft Download Center About Log Parser 2.2 (http://www.microsoft.com/downloads/details.aspx ?FamilyID=890cd06b-abf8-4c25-91b2-f8d975cf8c 07) [6] 江怡慧、陳怡樺，＂網路銀行使用者之行為分 析＂，產業金融季刊，第107 期，89.06 ，88-102 頁。 [7] 盧信彰, “整合金融網路之線上及時繳費機制 研究,＂ TANET 2007 台灣網際網路研討會論 文。
