首頁‎ > ‎電子期刊‎ > ‎

校園資訊系統整合模式-資訊契約服務架構的制定(上)


摘要

  • 文章編號:2005005
  • 投稿日期:2005/04/24
  • 作者:尤黎明、尤弘志、張騉翔
  • 備註:


摘要

在學校行政與教學普遍朝向數位化發展的同時,許多的資訊系統被建構來解決不同的需求,例如校務行政系統、數位學習系統、選課系統、圖書館系統等;在 這些系統建構的過程中,面臨到許多資訊系統間整合的問題,例如圖書館系統的會員名單可否直接取自校務行政系統中的學籍資料。網路服務(Web Services)的興起使得系統間的整合變為可能,藉由撰寫網路服務,可使現有系統間的資料藉由網際網路(Internet)傳遞到另一系統。在本論文 中,我們針對校園資訊系統的整合需求,以及目前網路服務的解決方案,提出校園資訊契約服務架構,試圖為校園資訊系統間整合的問題提供具體的解決方案。

關鍵詞:Web Services、網路服務、校務自動化。


1.前言

藉由網際網路(Internet)的興起,資訊得以無時間、空間的限制來進行傳遞,對於人們知識的累積及交流有了莫大的助益;近年來由於網路服務(Web Service)的興起,更使得網際網路應用程式之間得以整合,利用自動化流程彼此溝通。

目前資訊系統在整合上會面臨以下幾個挑戰:

多元的系統環境:在應用系統開發時我們可以有多元的系統環境,例如在作業系統的選擇上我們可以用Windows或Linux、在資料庫系統 的選擇上我們可以有My SQL、PostgreSQL、SQL Server…等、在開發工具的選擇上可以有Delphi、Visual Basic、Visual C++、用戶端可以是Windows、PDA、Web…等。我們所面臨到多元的系統環境若要整合的話,其示意圖如下。


 
  • 圖 1.多元的系統環境示意圖
  • 多元的應用系統:在校園當中會有不同的應用系統,我們面臨到的問題是如何整合各項校園資訊應用系統。


圖 1.多元的應用系統示意圖
  • 資源共享的安全性:當面臨到多個系統時,我們會遇到資源共享的安全性,例如同一份學籍資料可能會存在於學籍系統及學習支援系統,那麼若校 園資訊應用系統的使用者擁有學籍系統的學籍資料存取權限,是否也可存取學習支援系統內的學籍資料。並且也會面臨到系統單一登入的問題,使用者若經過某一系 統認證過後,是否就可直接登入其他系統。底下為其示意圖:


  • 圖 2.多元的應用系統示意圖

標準的制定:面對多元的應用系統整合,其中一個重要的關鍵即是制定標準,讓各個應用系統能依循同樣的標準,才能進行整合,例如學籍資料包含哪些欄位、成績資料包含哪些欄位,若無統一的標準,即使在技術上解決了上述幾點的問題,仍然無法達到整合的目的。

針對上述所面臨到的挑戰,本論文提出校園資訊契約服務(Campus Information Contract Service,簡稱CICS)架構,嘗試架構在現有的網路服務的技術之上,例如SAOP或DSA。當使用者透過應用程式呼叫網路服務並有實際的交易行為 時,資訊契約服務定義了一個完整的網路服務契約交易平台及架構(包括如何制定其交易合約、付款機制…等交易相關行為標準),使得校園內各項資訊系統間的整 合有可依循的參考。

2.文獻探討

2.1資訊系統整合

張緯良[7]出,資訊技術引進組織後所發生資訊流通方式的改變,對於員工工作內容的改變、組織結構的改變、以及生產力改變的幅度,都有顯著的影響。

吳琮璠、謝清佳[8],資訊系統特性包括垃圾進垃圾出、人機配合、快速性、即時性、經濟性、動態性以及整合性。90年代的資訊系統特性,打破了傳統組織功能部門的界限,以工作流程為主軸來設計整合型的資訊系統,強調共同整體資料庫,和跨部門的流程。

許麗玲[9]系統整合的文獻整理,歸納出「資訊系統整合度」的五種觀點,分別是「技術平台整合」觀點、「功能、資料與介面整合」觀點、「電腦應用整合層級」觀點、「供應鏈整合」觀點以及「企業間流程整合」觀點。

2.2Web Services/SOAP

Web Services的概念為應用程式可藉由透過撰寫網路服務的方式將其功能開放給網際網路上其它的應用程式所使用;藉由撰寫Web Services可使得在網際網路上不同的應用系統間的整合成為可能。

SOAP的全名為Simple Object Access Protocol,其由Don Box[1]所起草,制定了以XML為基礎的Web Services標準,並以HTTP為其預設的通訊協定。

XML(Extensible Markup Language)[2]提供了一套跨平台、跨網路、跨程式語言,而且不偏頗任何業者的資料描述方式。在此之前,任何遠端程式呼叫 (RPC) 和訊息傳遞 (messaging),都必須透過雙方系統都支援的通信協定和 API 來達成。XML 則提供了更大的彈性。

Http(Hypertext Transfer Protocol)[3]為W3C所制定之通訊協定,為每臺電腦所支援;SOAP藉由架構在XML及Http上可使得應用系統間整合的工作更為容易,由於 XML的格式為Plain Text可為所有平臺解讀,並且Http通訊協定也為每臺電腦所支援,故藉由SOAP所寫之網路服務亦可於任何平台及電腦上被呼叫。

2.3Document Service Architecture

DSA(Document Service Architecture)[4]由臺灣中等學校資訊管理人學會[5]尤弘志所制定,也是實現Web Services的解決方案之一;DSA與SOAP最主要不同的地方在於:

  • DSA的架構精神在於把XML視為文件(Document)的概念,並使其擔任分散式系統中間層的分析及設計要角,提供了真正以服務為基 礎的服務導向(Service-Oriented)架構;而SOAP只是將XML當傳輸媒介,其中間層採用的分析設計方法仍是物件導向(Object- Oriented)的方法,只是其物件設計較為簡單且為無狀態(Stateless)物件。
  • DSA提供了每個應用程式所需的基礎服務,包括版本控制、服務說明、權限控管、資源管理…等;網路服務撰寫者運用DSA可專注於網路服務本身提供的撰寫上,而不需理會一些繁瑣的細節。


3.校園資訊契約服務架構

校園資訊契約服務架構以DSA為基礎,將文件(Document)的概念加以延伸,把文件視為契約(Contract)的概念,提供了應用程式在網 際網路上整合更明確的語意定義;SOAP提供了整合的基本媒介及通訊協定、DSA則提供了整合的基礎服務及服務導向的設計方式、CICS則進一步提供了整 合的語意模型及應用程式間彼此呼叫的合約關係定義方式。 接下來分四節來討論校園資訊契約服務架構,首先談到校園資訊契約服務設計目標、第二段提到校園資訊契約服務運作方式、第三段提到了簡單文件定義語言、最後 提出了校園資訊契約服務架構。

接下來分四節來討論校園資訊契約服務架構,首先談到校園資訊契約服務設計目標、第二段提到校園資訊契約服務運作方式、第三段提到了簡單文件定義語言、最後提出了校園資訊契約服務架構。

3.1校園資訊契約服務架構設計目標


  • 校園資訊契約服務架構的設計目標如下:架構需能描述應用系統之互動關係,對於某一應用系統可開放給別的應用系統之介面需在此架構下能清楚地被定義。
  • 在應用系統的開放介面被清楚定義後,此介面需能進階的描述人們的契約關係,契約可能明示或默示某些資訊給付與受領之債權與債務。並且資訊之給付與受領使用數位化的媒介。
  • 此架構需能支援應用系統因契約關係所產生的互動關係。
  • 每一個使用數位化資訊的機構(關)、法人及自然人在校園資訊契約服務架構下各自使用一個具唯一身份識別性質的數位資訊代理介面。
  • 架構應能紀錄並追綜資訊之給付與受領,並應具互相對帳的功能,以協助債權與債務之實施行為之查驗。


3.2校園資訊契約服務架構運作方式

在校園資訊契約服務架構中有兩個核心的概念,其一為資訊契約服務(Information Contract Services),定義了網路應用程式資訊契約的介面,其二為領域功能物件(Domain Function Object),實作了特定領域的功能服務,例如呼叫某家出版商的配題服務、排課服務…等等。一個資訊契約服務包含了許多的領域功能物件,使其可實現資訊 的契約行為及關係。


 
  • 圖 4.校園資訊契約服務架構示意圖


資訊契約服務可分為受領者及給付者介面。資訊契約服務受領者介面定義了資訊服務消費者的交易資訊,例如受領者的身份認證資訊、交易紀錄…等等商品受領者的 交易所需資訊、行為及契約。資訊契約服務給付者介面定義了資訊服務提供者的交易資訊,例如給付者的商品資訊、收費模式…等等商品給付者的交所需資訊、行為 及契約。一個資訊契約服務至少需實作資訊契約服務受領者介面及資訊契約服務給付者介面其一的介面,或可兩者皆實作;亦即資訊契約服務必需為受領者或消費 者,或是兩者皆是。

資訊契約服務可處理實體商品的交易,例如紙本試卷的購買,也可以處理虛擬商品的交易,例如資料統計分析服務。其中虛擬商品交易資訊契約服務 的收費模式可分為計次、計時及計量:計次模式為呼叫單次領域功能物件的服務即計費一次;在計時模式中,在單位時間內的需收費多少,例如線上教材的閱讀時 間。

計量的概念較為複雜,在計次及計時的狀況中資訊契約服務可清楚的掌握計次及計時的概念,當使用者呼叫領域功能物件時會經由資訊契約服務,一 次的領域功能物件呼叫資訊契約服務即可為計次一次,而計時的情況可由使用者登入及登出的時間來瞭解;但計量的方式定義於領域功能物件,由資訊契約服務呼叫 領域功能物件,再由領域功能物件回報其量的多寡,例如有個領域功能物件名為「出測驗卷服務」,其收費模式是以使用者需要出多少題題目來收費,此多少題題目 即為量的概念。

資訊契約服務的交易方式可分為直接交易及間接交易。使用直接交易的方式使用者直接與提供服務的粢資訊契約服務接觸,資訊契約服務會接觸到使 用者的詳細身份資訊。使用間接交易的方式使用者用所謂的「電子提貨卷」來與資訊契約服務交易,資訊契約服務認卷不認人,使用者的身份資訊不會直接與資訊契 約服務接觸,具有保密及交易單純的好處,但需設有購買「電子提貨卷」的交易中心;另一種間接交易的方式稱之為代理人交易,使用者要與資訊契約服務交易時, 透過代理人來進行交易,提供服務的資訊契約服務只會有代理人的身份資訊,使用者請求代理人代為向資訊契約服務購買,代理人購買完後再將商品轉交給使用者; 例如學校代學生向教材廠商購買教材。

資訊契約服務與領域功能物件彼此的關係,領域功能物件本身並不會知道資訊契約服務的存在,也不會紀載著資訊契約,領域功能物件被動的接受資訊契約服務的呼叫,並且在領域功能物件被註冊到資訊契約服務時才會被資訊契約服務主動付予交易契約資訊。

Comments