釧助仁

摘 要 監(jiān)控類軟件作為電廠實現(xiàn)生產(chǎn)、運行、管理自動化的重要部分，為電廠實現(xiàn)生產(chǎn)運行設備自動監(jiān)視、自動控制、生產(chǎn)、運行、管理信息自動交換、快速發(fā)布起著重要的作用，但隨著電廠對生產(chǎn)運行需求越加規(guī)范及C/S架構本身存在的問題，采用C/S架構搭建的監(jiān)控類軟件已經(jīng)無法適應新時期的要求，出現(xiàn)了一些亟待解決的問題，而另一方面，電廠監(jiān)控類軟件中采用B/S架構搭建的軟件越發(fā)凸顯其優(yōu)越性，如軟件更新比較容易、使用比較簡單、數(shù)據(jù)維護更新簡單快捷、軟件故障率低、運行時間長等，因此，將C/S架構的軟件遷移至B/S架構的軟件成了電廠解決當前存在的問題的一種經(jīng)濟、有效的手段。本文就架構遷移進行探討其可行性。

【關鍵詞】C/S B/S 監(jiān)控類軟件 遷移評價體系 無縫遷移 逆向工程再造

1 論文研究的目的及意義

監(jiān)控類軟件作為電廠實現(xiàn)生產(chǎn)、運行、管理自動化的重要部分。為電廠實現(xiàn)生產(chǎn)運行設備自動監(jiān)視、自動控制；為生產(chǎn)、運行、管理信息自動交換、快速發(fā)布起著重要的作用。這些軟件的部署確實使電廠生產(chǎn)、運行、管理信息化的水平得到了提高，為電廠提高了生產(chǎn)過程的效率與安全性，提高了運行管理的及時性、全面性、準確性，減少了人力資源成本、維護成本、管理成本。但隨著電廠對生產(chǎn)運行需求由粗放式、手工式向精細化、自動化的轉變，以及日趨規(guī)范化的生產(chǎn)運行管理對軟件的可靠性、可維護性提出了更高的要求，電廠監(jiān)控類軟件中按照以前C/S架構搭建的軟件已經(jīng)無法適應新時期的要求，出現(xiàn)了一些亟待解決的問題，如：資源消耗率越來越高、進程阻塞現(xiàn)象頻頻出現(xiàn)、數(shù)據(jù)更新越發(fā)困難、數(shù)據(jù)垃圾難于清理、維護責任越發(fā)不合理、使用越來越不方便等；而另一方面，電廠監(jiān)控類軟件中采用B/S架構搭建的軟件越發(fā)凸顯其優(yōu)越性，如軟件更新比較容易、使用比較簡單、數(shù)據(jù)維護更新簡單快捷、軟件故障率低、運行時間長等，因此，將電廠C/S架構的監(jiān)控類軟件遷移至B/S架構，就成為了解決上述問題的一種可行方法。

但是，是否所有的監(jiān)控類軟件都適合采用B/S架構？是否當前的監(jiān)控類軟件都具有遷移的可能性？具有遷移可能性的軟件遷移后是否能確確實實解決遷移前存在的問題？需要遷移的軟件采用何種方式進行遷移、其遷移方案是什么？遷移后的軟件會帶來哪些優(yōu)勢？這些就是本文所要探討的內容。

2 C/S和B/S架構介紹和優(yōu)缺點比較

C/S和B/S是兩種截然不同的軟件架構，兩者所涉及的適用范圍、開發(fā)技術、管理模式和運行方法都存在較大的差異，軟件系統(tǒng)在兩者之間的遷移存在較大的難度，是一個系統(tǒng)性的工程。因此，在系統(tǒng)遷移初期必須做好系統(tǒng)遷移的可能性分析工作，了解C/S和B/S架構的相關知識，把握兩者間存在的技術特點、適用范圍和應用差異，解決系統(tǒng)遷移中涉及的技術、難點、工作量、資源配置和步驟等問題，以提高系統(tǒng)遷移的成功率。

2.1 C/S架構相關知識介紹

C/S（Client/Server）結構即客戶機與服務器結構。是軟件系統(tǒng)體系結構，具有很強的通信處理能力和圖像處理能力。但無論是二層網(wǎng)絡結構還是三層結構，必需在客戶端安裝相應軟件，需要客戶端的人為干預，加之軟件產(chǎn)品的更新?lián)Q代十分快。所以系統(tǒng)存在伸縮性差和維護工作量大的缺點。

2.2 B/S架構相關知識介紹

B/S（Browser/Server）結構即瀏覽器/服務器結構。Web方式是基于廣域網(wǎng)，通過網(wǎng)頁發(fā)送信息，所有與系統(tǒng)有關信息都可以通過瀏覽器訪問方式獲?。O少部分事務邏輯在前端實現(xiàn)），提升系統(tǒng)的可伸展性和降低客戶端維護量。

2.3 C/S和B/S架構的比較

C/S與B/S是過去10年世界開發(fā)模式技術架構的兩大主流技術，兩種技術本身存在許多的優(yōu)點，都擁有一定的市場份額和客戶群，但隨著技術的不斷發(fā)展和主流應用向B/S或更高級的ERP、中間件技術傾斜，C/S架構開始走上了下坡路。

2.3.1 C/S架構的優(yōu)勢與劣勢

（1）應用服務器運行數(shù)據(jù)負荷較輕。最簡單的C/S體系結構的數(shù)據(jù)庫應用由兩部分組成：客戶應用程序（前臺程序）和數(shù)據(jù)庫服務器程序（后臺程序）。運行前臺程序的機器稱為客戶電腦，運行后臺程序的機器稱為應用服務器。如需要對數(shù)據(jù)庫中的數(shù)據(jù)進行操作時，客戶程序會自動尋找服務器程序，向它發(fā)出請求，服務器程序根據(jù)事先預定的規(guī)則作出應答，送回結果，所以應用服務器運行數(shù)據(jù)負荷較輕。

（2）數(shù)據(jù)的儲存管理功能較為透明。數(shù)據(jù)庫中數(shù)據(jù)的儲存管理功能，是由客戶機和服務器分別獨立進行的。對于工作在前臺程序上的最終用戶，是“透明”的，他們無須過問背后的過程，就可以完成自己的一切工作。但在C/S體系下，數(shù)據(jù)庫不能真正成為公共、專業(yè)化的倉庫，它受到獨立的專門管理。

（3）C/S架構的劣勢是維護成本高且投資大。首先，如果需要建立兩地間的“實時”數(shù)據(jù)同步，就必須在它們之間建立實時的通訊連接，才能保持兩地的數(shù)據(jù)庫服務器在線運行，這樣網(wǎng)絡管理人員要同時對服務器與客戶端維護管理，這需要復雜的技術支持和高昂的投資。其次，傳統(tǒng)C/S架構的軟件需要針對不同的操作系統(tǒng)開發(fā)不同的版本，由于軟件的更新?lián)Q代快，導致高代價和低效率。以此同時在JAVA語言出現(xiàn)之后，B/S架構更加猛烈沖擊C/S。

2.3.2 B/S架構的優(yōu)勢和劣勢

（1）簡化了客戶端。B/S架構的軟件只需管理服務器，不同的客戶機上無需再安裝不同的應用程序，所有的客戶端只是瀏覽器。

（2）簡化了系統(tǒng)的開發(fā)和維護。系統(tǒng)的開發(fā)者不需要再為不同級別的用戶開發(fā)不同的應用程序，所有的功能都能在服務器上實現(xiàn)，只要為不同級別的用戶設置不同的權限，不需要再對客戶端做任何維護。

（3）客戶端操作變得更簡單?？蛻舳酥皇且粋€簡單易用的瀏覽器，使用者無需接受任何專門的培訓就可以直接使用。

（4）成本降低，選擇更多。在服務器操作系統(tǒng)上可以選擇windows或Linux，都不影響客戶端運行。其中Linux安全性高、免費（包括數(shù)據(jù)庫也是免費）。

（5）應用服務器運行數(shù)據(jù)負荷較重。B/S架構管理軟件只需安裝在服務器端，所有用戶的大部分需求都通過瀏覽器在服務器端實現(xiàn)。所以應用服務器運行數(shù)據(jù)負荷很重，一旦發(fā)生服務器“崩潰”等問題，后果不堪設想。為此許多用戶都有備份，以防萬一。

2.3.3 C/S與B/S架構優(yōu)缺點比較

總結以上介紹，我們可以得出如表1所示的C/S架構和B/S架構優(yōu)劣分析表。

2.4 C/S遷移至B/S架構的難點

根據(jù)金蝶軟件、IBM、Amazon公司在過去10年實施C/S至B/S架構的案例情況，本文認為，C/S遷移至B/S架構至少存在以下兩個難點：

2.4.1 C/S客戶端能否部署在服務器

采用C/S架構的系統(tǒng)，其客戶端和服務器端承擔了相當?shù)臉I(yè)務處理工作，因此，如何將客戶端中承擔業(yè)務處理的程序遷移至服務器？能否無縫遷移至服務器？遷移的工作量有多大？遷移后的程序能否和服務器端程序整合？這些就是C/S客戶端在遷移過程中會遇到的難點問題。

2.4.2 B/S架構能否達到C/S客戶端的性能

由于C/S中顯示部分由客戶端承擔，因此，C/S能有效調用本地資源，提供高質量、高速度、快速響應的客戶端顯示界面，而B/S架構雖然由性能強勁的服務器承擔幾乎所有的業(yè)務處理工作，但由于采用瀏覽器（Brower）作為客戶端，其本身的HTML語言自身存在的表現(xiàn)力不足、接口不夠強壯、反應不夠靈敏和缺乏趣味性的表現(xiàn)力能否達到C/S客戶端的顯示效果、響應速度？能否提供用戶與C/S客戶端媲美的使用體驗？是C/S遷移至B/S架構的過程中遇到的又一個難題。

3 遷移方案設計

3.1 無縫遷移

監(jiān)控類軟件遷移至服務器，其三個組成部分，一是系統(tǒng)所用的數(shù)據(jù)庫，二是用驅動程序，三是用客戶端，均可無需太多修改的遷移至windows服務器，然后用ASP或PHP編寫網(wǎng)頁查詢頁面，將該數(shù)據(jù)庫中的歷史數(shù)據(jù)和當前數(shù)據(jù)傳至網(wǎng)頁頁面進行顯示，此方案只需修改數(shù)據(jù)庫的配置文件，增加一個網(wǎng)頁查詢程序，即可完整的實現(xiàn)原監(jiān)控類軟件系統(tǒng)的所有功能，遷移時間短、工作量小，但由于程序內部沒有進行重構或優(yōu)化，原有的進程阻塞、數(shù)據(jù)結構不合理、數(shù)據(jù)大量冗余、數(shù)據(jù)更新不方便等問題依然存在，同時由于業(yè)務處理工作仍由客戶端完成，服務器資源利用率不高，系統(tǒng)與服務器整合度不足反而降低了系統(tǒng)的運行效率。

3.2 部分代碼重用的逆向工程再造

逆向工程再造是軟件工程的一個重要的軟件開發(fā)思想，其通過對系統(tǒng)源代碼、界面和部分文檔的逆向思考，提取出該系統(tǒng)的需求說明，構造出系統(tǒng)的內部數(shù)據(jù)結構，分析出系統(tǒng)的數(shù)據(jù)庫設計，給出系統(tǒng)的類、模塊、方法等技術說明，然后在這些逆向文檔的基礎上對系統(tǒng)進行重新開發(fā)，開發(fā)過程中重用原系統(tǒng)的部分代碼和設計方法，能有效整合和優(yōu)化新系統(tǒng)與新平臺的資源，提升新系統(tǒng)的運行效率，解決原系統(tǒng)存在的諸多問題，但由于要進行逆向構造，對技術人員的要求比較高，開發(fā)周期較長。

4 總結和展望

B/S架構雖然比C/S架構有著更多的優(yōu)越性，但B/S架構也存在著一些問題，如B/S架構采用瀏覽器交換數(shù)據(jù)，由于瀏覽器本身安全性需要第三方安全軟件的保護，因此，采用B/S架構的系統(tǒng)安全性不如C/S高；其次，B/S架構在當前雖然已經(jīng)采用了許多提高交互度的技術，如Ajax，但和C/S一整套的客戶應用相比還是太有限；再次，B/S的響應速度也暫無法和C/S相比。

對于電廠而言，信息的安全性和可靠性遠高于技術的先進性，因此，不能單純的將B/S架構視為監(jiān)控類軟件的首選，而應該結合系統(tǒng)的應用范圍、安全要求、性能要求等進行綜合判斷，選擇最合適的系統(tǒng)架構。就如德國的架構大師Frank Buschman所說的一樣：沒有一種架構是萬能的。

隨著新一代的開發(fā)架構，如ERP、中間件、云架構等技術的興起，以及新的客戶端交互技術的出現(xiàn)，B/S架構會慢慢吸收眾家之所長，不斷完善，使自身被更多的用戶所喜愛。

參考文獻

[1]Gerard Bimont.火力發(fā)電廠電子監(jiān)控技術[J].華東電力，2008（02）：41-43

[2]王清，趙輝等.基于B/S、C/S模型協(xié)調控制的電廠遠程監(jiān)控系統(tǒng)研究[J].天津理工大學學報，2009（10）：36-38.

[3]佟鵬，高建強等.基于B/S模式的電廠性能監(jiān)測系統(tǒng)研究[J].熱力發(fā)電，2003（10）：67-69.79.

[4]郭小寶，王爽心.基于B/S結構的電廠經(jīng)濟指標在線監(jiān)測系統(tǒng)[J].自動化博覽，2005（05）：56-58.

[5]Xu Zhigao，Gao Zhengping，Si Fengqi.Real-Time Information System of Power PlantBased on B/S Computing Mode[J].Journal of Southeast University（English Edition），2002（01）：80-83.

作者單位

德宏師范高等?？茖W校 云南省德宏傣族景頗族自治州芒市 678400