高功能低成本擴充容易的網路選課系統

陳偉銘
國立東華大學
花蓮縣壽豐鄉志學村大學路二段一號
TEL:(03)866-2500 轉1153
FAX:(03)866-2509
Email:wmchen@cc.ndhu.edu.tw

趙涵捷
國立東華大學
花蓮縣壽豐鄉志學村大學路二段一號
TEL:(03)866-2500 轉1501
FAX:(03)866-2509
Email:hcc@cc.ndhu.edu.tw

   

摘要

學生選課網路化在各大專院校都被視為是校園行政電腦化業務中極重要的一環。早期的校園網路選課由於受限於資料庫及網路技術的因素,通常都是以相當高額的成本,購買一套網路選課資料庫系統來提供學生上網選課。然而,有時由於選課型態的多元化,廠商對系統更新缺乏彈性,或是學生人數激增,造成系統容量不足,欲擴充系統容量不易,而使得選課效率不彰的情形發生。現今,由於電腦與網路技術的精進及設備成本的降低,建構網路選課系統已非難事。因此,本文章中將提出一套完全自行開發,兼具低成本、高效率且容量擴充容易的一套網路選課系統。希冀能解決目前校園網路選課的各項問題。

 

 

前言

學生選課是各個大專院校中非常重要的業務,因為選課的結果可以直接影響到學生當學期修習課程的內容,進而影響學生的整體學習方向及學程規劃。尤其目前各學校開課課程越來越多元化,學生可以修習的課程種類繁多,必須考慮到如何能提供學生對取得開課課程資訊以及選修課程時的一個方便又快速的管道。另一方面,由於一部份的課程資源有限,在僧多粥少的情形下,如何能提供一個符合限修要求而又公平的競爭機制,讓學生能夠順利選修自己所想要學習的科目,更是重要。選課網路化就是一個解決上述要求的好方法。

然而,網路選課必須考慮到的因素非常多。上至整體選課流程、選課操作方式的規劃,下至資料庫架構與容量、網路型態等各項資訊技術的考量,都會影響到整體選課效率與成本。以筆者所屬學校-國立東華大學-為例。本校是一所新成立的國立大學,學生人數由剛創校的七十餘人逐年增加到目前將近兩千人。而且每年人數增加的比例越來越高。在規劃網路選課系統容量時,如果規劃得太小,則因人數增加得太快很容易就造成系統超載。若規劃得太大,則又會流於成本過高,浪費公帑。同時,由於本校開課課程多元化,基於教學需求,網路選課系統必須能夠提供多種限修模式,並且能容易的因應限修模式的改變及增加。

為了要能夠增進學校行政效率、提供學生便利的選課服務並且要求以合理的成本建構系統。我們提出一套網路選課系統的完整架構,經自行開發完成後,實際的在學校運行一年多。本文中,我們將此開發經驗提供出來,希望能提供其他學校建構網路選課系統時的一個參考。

 

 

網路 Client/Server資料庫技術

一、較大型資料庫伺服主機(Two-Tier 架構)

主從式(Client/Server)資料庫是目前資料庫系統的主流。在初期的主從式資料庫設計上,通常是提供一個較大型資料庫伺服主機,搭配幾十個使用者端(Client)來做資料的處理(如圖一)。它的結構單純,架設起來也比較方便。因為整個架構只分為資料庫與使用者端兩層,故又稱之為 Two-Tier 架構。由於對於每一個上線到資料庫的使用者端,資料庫伺服器皆會提供給每一個上線的使用者端一段資料記憶區,做為資料存取的緩衝。因此,為了事先規劃到未來使用端數量擴增的須求,在選擇資料庫伺服主機時,不但要求有較大的計算容量外,也必須要求它的記憶體容量必須很大。對一個具有較高計算能力且又有很大記憶體容量的資料庫伺服主機而言,價格也相對的高出許多。通常架設一個較具規模的Client /Server資料庫系統包含硬體軟體動輒都要上百萬元的成本才可完成。

 

wpe1.jpg (17775 bytes)

圖一

 

 

進一步來說。當使用者端數量如果不斷地增加,使得原本主機設計的連線容量不足使用時,則就產生較麻煩的情形;第一、若是計算容量不足時,必須考量資料庫伺服主機是否可增加計算容量。第二、若是記憶體容量不足時,必須考量資料庫伺服主機是否可增加主記憶體容量。第三、若是網路頻寬不足時,必須考量是否可增加到資料庫伺服主機的網路頻寬。通常較大型資料庫伺服主機在各項容量的擴充性方面是較差的,或者是必須花費相當鉅額的成本,才能順利擴充。

當然,針對初期的使用狀況時,此種架構是足以應付的,但是以現今網路發展迅速的情形來看,若使用端增加速度太快,或增加數量變動無法正確預估時,則採用此種架構所導致容量不足時的解決方式,為求方便,通常便是換購一個容量更大、價格更昂貴的伺服器。為了減少不必要的成本開銷及降低系統擴充時的複雜度,必須提出另一套更具擴充彈性的資料庫架構才能應付這些問題。

 

 

二、多台較小型資料庫伺服器

 

為了解決大型伺服器的容量不足時,擴充不易的問題,我們可以改採另一種網路資料庫架構,如圖二所示:

wpe2.jpg (21634 bytes)

圖二

 

 

如上圖架構,我們可以採用容量較小、較低成本的資料庫伺服器提供使用端的資料庫存取服務(Server 1)。當使用端數量增加,而伺服器容量不夠時,便再加裝一台伺服器(Server 2)。以此類推,我們可以繼續加裝更多台的伺服器以應付越來越多的使用量。其優點是擴充性強,而且成本較低廉。但是,由於資料庫內儲存的各項資料表格必須分散到各個較小資料庫中,資料要求的一致性與關連性將不易達成。同時,使用端上線查詢資料的前端程式也因資料可能儲存在不同資料庫中而造成前端程式設計複雜化、維護不易的問題。而且若資料庫不斷地增加的話,其複雜的程度,似乎就不符合效益了。雖然多伺服器解決了擴充性的問題,卻也製造了另一個瓶頸。

 

 

三、中間層加入應用伺服器的架構(Multi-Tier 架構)

 

如果我們在資料庫伺服器與使用端之間架設了一台類似代理伺服器(Proxy Server)功能的機器,稱之為應用伺服器(Application Server),利用這台應用伺服器負責協調使用者端與各資料庫之間的連線存取動作。這樣我們就可以有效的解決前述的問題,如圖三所示:

wpe3.jpg (19398 bytes)

圖三

 

 

所謂應用伺服器就相當於是扮演資料庫伺服器與使用者端之間的仲介角色。當使用端想到資料庫伺服器內存取一筆資料時,必須先連線到應用伺服器,然後再由應用伺服器實際的向資料庫伺服器存取資料。由於多了應用伺服器的緩衝,資料庫的負載情形便可和緩許多。

 

 

校園網路課務系統的設計

一、網路選課資料庫系統的要求

 

校園網路課務系統大略來說有以下幾項要求:

 

(1).必須是主從式架構:由於網路課務系統所面對的是全校的師生,使用者端的數量相當龐大且上線時間點相當集中。因此必須根據功能的不同,讓部份執行作業由使用者端分擔,才能降低資料庫伺服器的負載。

(2).擴充網路連線的容量必須容易且成本必須合理:學校學生人數的成長是相當快速的,因此選課時的連線人數很容易達到容量的上限。當容量已不敷需求時,系統必須能夠以合理的成本輕易的擴充。

(3).使用者應可以在任何地方上網選課:由於網際網路發達,學生與老師皆可以在自己家裡連上學術網路。因此選課介面必須能跨越網際網路,使得學校師生們不必到親自到學校,就可以選課或取得(印製)課務資料。

(4).課務程式最好以網路物件導向方式設計:程式以物件導向方式設計可以簡化流程、縮短開發時間,而且除錯及版本更新容易。如果能再將物件網路化,則可以將有關網路的程式設計複雜度降至最低。如此在維護時或增進系統功能時,可以輕易的達成。

(5).具彈性的選課限修模式:由於現今學校開課的多元化,選課系統必須能因應校內系所各種不同的選課限修模式,

 

二、國立東華大學網路選課系統架構

 

本校網路課務系統是採取 Three-Tier 架構。目前我們共啟用了兩台資料庫伺服器,作業系統平台是Windows NT,資料庫管理程式則是採用 MS SQL 6.5。並且在資料庫與使用者端之間架設了三台應用伺服器。此三台應用伺服器的作業系統平台仍是Windows NT。系統內有我們自行設計的應用介面服務程式(Application interface srvice),作為使用者端與應用伺服器的連線(TCP/IP Session)及應用伺服器與資料庫連線(Database Session)的一個管理者的角色,如圖四。

 

wpe4.jpg (22143 bytes)

圖四

 

當分析整個學生選課的流程時,我們不難發現可以將整個流程粗分為兩個部份:資料庫端(或應用伺服器端),負責學生選課資料實際的儲存與管理。使用者端則包含使用者操作的圖形介面、全校開課課程資料的查詢、已選課程之顯示及選課衝堂判斷等功能。因此,實際程式開發時便是以此方式將功能分開設計。如此一來,資料庫負責的工作將較單純,負載也相對的減輕。

 

 

三、應用伺服器對資料庫連線的管理機制

 

由於系統採用主從式架構,選課各項操作功能、課程衝堂判斷等部份皆是由使用者端的 ActiveX 物件負責,只有剛開始學生選課資料的讀取及實際進行加、退選課程動作時才會真正進行資料庫存取。根據系統實際運作時的統計,當有 300 人連網選課(TCP/IP Session)時,同一時間對資料庫進行存取作業(透過Database Session 與資料庫溝通)的不超過 50 人。因此,我們在開發應用伺服器上的應用介面服務程式時就特別設計了一套 Database Session 的管理機制,以有效的降低資料庫的負載。如圖五:

 

appli.jpg (27167 bytes)

圖五

 

系統剛開始運行時,每個應用伺服器內的應用介面服務程式都會先主動與資料庫建立數十個資料庫連線(Database Session),假定共為 50 個連線。如果網路上有使用者端連線到應用伺服器時,應用介面服務程式會啟動對應的一個 Thread 來負責掌控(Handle)該連線與使用者端溝通。因此若使用者連線數達 300 人時,應用伺服器也會有相對的 300 個 Thread。

當某些使用者端需要進行資料庫存取動作時,所對應的 Thread 將會向 Database Session 管理模組提出使用 Database Session 的請求,以便對資料庫進行存取動作。如果目前還有可用的 Database Session,則管理模組將分配給請求的 Thread,而該 Thread 必須儘快的完成存取動作,並且立刻將 Database Session 歸還給管理模組以利其他 Thread 使用。如果目前已無可用之Database Session,則該 Thread 將進入等待模式,直到有可用的 Database Session 為止。

由於會同時進行資料庫存取的 Thread 並不多,因此每一個欲進行此動作的 Thread 幾乎都可以不必等待即可順利的完成工作。在此架構下,雖然有多達 300 人上線,由於應用伺服器的管制,對資料庫而言,最多卻只有 50 人上線而已!

 

 

四、應用伺服器的負載平衡(Load balance)策略

 

在 Multi-Tier 架構下,應用伺服器是直接面對使用者端。因此,必須以多台的叢集(Cluster)方式來分擔網路連線的壓力。但是必須考慮的是,如何能讓使用者端來的連線能夠平均的分配到每一台應用伺服器上,而不會因為過度集中到某一台機器上造成負荷不了而當機的情形。

有一種架構是獨立出一台電腦,專門負責調查每一台應用伺服器目前的負載情形。而每個使用者端要進行連線時,必須先向此電腦查詢目前每一個應用伺服器負載情形,並選擇負載最輕的一個進行連線。此方法的確可以精確的控制負載狀況。但是,由於其實際施行較複雜,且如果該台負責調查的電腦發生故障時,將失去負載平衡的功能,甚至將造成整個系統癱瘓。因此並不考慮採用。

我們採用的方式是:當使用者端要進行連線時,會先產生一隨機亂數以決定連上哪一台應用伺服器。待連上選定的應用伺服器之後,先向該伺服器詢問目前負載情形,如果負載情形尚可就可直接進行課務作業。如果負載情形嚴重,則使用者端將重新產生亂數以決定連接其他應用伺服器。此種方式雖無法精確的掌控每台應用伺服器的負載情形,但仍可保持一定的負載平衡,而且不會因為任何一台機器故障時,影響整個系統的運行。

 

 

五、多台資料庫的管理

 

為求資料庫擴充容易及成本因素考量,我們以多台較小型資料庫來取代大型資料庫。然而,如前所述,在此種架構下,雖然擴充彈性較好,但各項資料表格(Table)必須分散至各資料庫中。因此,資料庫管理將變得較為複雜。為了簡化使用者端程式,降低維護時的困難度,必須將此問題提前到應用伺服器及資料庫的層級解決。對於多個資料庫之間資料表格的一致性,我們可以利用資料庫所提供的 Replication 功能來解決。

Replication 是資料庫之間保持資料同步的一種機制。當某一資料庫(稱之為Publisher)內的資料表格被更動時,其他已設定成為 Subscriber 的資料庫將會隨之更新其內部對應的表格。當然,由於網路負載等不可預期因素,這種方式無法完全保證所有資料庫可以即時的同步更新資料。因此,對於有瞬間時效性考慮的資料處理就必須由應用伺服器內的應用介面服務程式來負責統籌處理。若有一些資料表格是存放於數台資料庫,對使用者端而言是以單純對資料庫存取的立場向應用伺服器提出需求。而應用伺服器則必須分析其所存取的資料表格分散情形,各別向對應的資料庫實際的存取資料。換句話說,應用伺服器本身將具有整合所有資料庫、延伸資料處理功能的能力。

 

 

程式設計考量與系統概述

一、自行開發的應用伺服器程式與以 ActiveX form 物件為使用者操作介面

 

現今有多種網路資料庫架構都是建構在Web 瀏覽的模式上,以求使用者介面統一與版本控制容易。諸如:CGI程式處理方式、以Java 語言為基礎的資料庫架構、Active Server Page(ASP)或 DCOM/ActiveX 為基礎的 Multi-Tier 架構等。

CGI 程式處理方式由於架構過於簡單,雖然建構容易,然而面對大量的使用者連線時,其應付能力值得懷疑。Java 語言雖然具有跨平台的能力,但是目前在資料庫方面的應用仍未成熟、執行速度亦需改善。而且因其現有的軟體開發環境仍嫌不夠理想,開發速度較慢。以ASP為基礎或DCOM/ActiveX 為基礎的 Multi-Tier 架構已可提供相當規模的網路資料庫架構。但是,對於前面所述:應用伺服器對多台資料庫時的統籌管理、使用者連線與Database連線的管理機制以及應用伺服器的負載平衡控制方面的設計,仍嫌彈性不夠。且就 ASP 而言,其使用者端的程式指令功能略嫌不足(以 VB Script 為主),使用者端能分擔的系統負載有限。

為此,我們決定自行開發專門的應用網路資料庫物件,以便能全面而極具彈性的提供前述之功能。應用網路資料庫物件分為應用伺服器端的Server物件與使用者端的Client物件。由於設計此物件的同時也封裝了所有網路介面與自行開發加密處理的部份,程式將變得很容易撰寫及維護,並且資料不易被破解。

使用者端的程式主體則採用ActiveX Form 物件。雖然,目前 ActiveX 物件面臨到無法跨越其他平台的問題,但是由於大多數的人仍是使用PC平台,且ActiveX 擁有幾項特點,因此當初我們決定採用:

第一、ActiveX為機械碼型態程式,執行速度快,設計上較能夠多分擔整個系統的負載。

第二、ActiveX 物件的程式設計環境佳,有很多程式語言都可以輕易的製作。因此,開發速度較快。

第三、也是很重要的一點。網路選課容易牽涉到一些選課糾紛問題。使用ActiveX物件可以很輕易的被設計於選課過程中,追蹤記錄使用者在什麼時後、網路上那一台電腦選課(甚至記錄 MAC Address、CPU ID等),作為未來產生糾紛時一個有力的佐證。

第四、由於我們的設計理念是希望所有課務表格皆能夠在網路上直接列印,又希望印製的表格能夠精緻好看,而不是由使用 HTML 語法所產生較粗糙的Hard Copy畫面。目前也只有 ActiveX 可以達成此項功能。

為求能很快速又符合需求的架設網路課務系統,我們暫時選擇了使用ActiveX 物件。未來,等待 Java 的環境、技術更成熟時,我們只要將使用者端的程式改寫成 Java 語言,則跨平台的問題將很容易的解決。

 

 

二、目前系統提供的功能

 

系統目前已完成的項目有二。第一項是提供學生網路查詢開課課程資料及網路初、加退選功能。學生可以於選課期間上網選課,隨時得知目前各開課科目選修人數(見圖九),或針對有人數限修之科目取得自己目前選修排名順序以利選課抉擇的參考(見圖八)。由於教學需求,本校目前共有六種限修模式,系統可以完全的處理這些限修方式,也可以很輕易的增加或修改限修模式。圖六到圖八為選課時的操作畫面。

 

 

圖六

圖七

圖八

圖九

圖十

圖十一

 

 

 

第二項是提供網路各項表格查詢及列印功能。本系統提供各系所直接上網列印學生選課確認單、選課人數統計表、各開課科目選修學生名單、學生成績單等功能,操作畫面見圖十與圖十一。

 

 

結語

選課系統在本校初次運行時,仍不免發生一些事先沒有考慮到的問題,譬如說:有些學生因由校外連線到校內,而因網路速度過於緩慢或因其他因素不適用於 Web 瀏覽方式等問題。而我們也後續的以同樣的資料庫架構所開發的BBS選課系統來解決此問題。然而,整體的系統架構運行至今,仍然一切正常。待本校學生增加至三千人以上時,系統只要在添購一至二台 PC 電腦作為應用伺服器,就可以輕易的提升容量,因應三千人選課的需求。

目前我們成員正積極開發以同樣架構為基礎的網路課程綱要、課程規劃資料庫系統及課程編排系統,以求將來能讓整個課務作業全面網路化。再配合學生學籍資料庫網路化後,希望能整體的增進學生相關行政業務工作效益,提供學子們簡捷完善的服務。