撰文/青潤（本文來自《程式員》雜志2003年3期）
國内軟體業曾有人對行業性軟體進行劃分，在幾個較大的行業中，排行前幾位的分别是：通信、電力、金融……
但從對技術的要求與和安全性的要求上來說，通信行業的計費和金融行業的交易都是并稱的。是以在通信行業軟體形成之初，計費就成為了通信行業的核心軟體，能否有實力作計費軟體成為在行業中是否具有實力的标志。于是也就形成了中國通信行業著名的“九七”工程！這是完成電信行業核心業務層面的資訊化工程。
繼“九七”工程之後，2001年，中國的各電信公司根據國外電信公司的資訊化程序和經驗，總結提出要建立中國電信公司的營運支撐系統，這個系統是基于“九七”工程外圍的營運支撐業務建構起來的，如果說“九七”工程是心髒，那麼營運支撐系統就是四肢！心髒是為了提供肌體的動力，四肢才可以通過各種形式來擷取利益，使心髒能繼續生存下去。營運支撐系統在中國電信集團公司被稱為“OSS”系統，全稱是“Operation Support System”，在中國移動通信集團稱為“BOSS”系統，全稱是“Business and Operation Support System”。
在電信集團提出建構營運支撐系統的同時，各電信分公司還在籌劃建構符合自己特點的ERP系統，與此同時，基于營運支撐系統之外的各種行業業務系統也開始了開發與規劃。
電信行業軟體曆程
一、九七工程
九七工程是中國通信行業軟體最初的形象。實際上在實施九七工程的時候，中國的通信行業基本上還是一家壟斷的狀态，那就是中國電信！
九七工程主要解決了電信行業最迫切需要解決的交換、計費、帳務、經營等最關鍵的業務過程。這些業務要求實時性非常強、對準确性的要求也非常高，因為系統的每一個資料都關系到電信的直接收入。
一些國内的軟體公司借着這股春風發展了起來，也有一些公司從此開始涉足軟體行業。
從技術和行業的應用成熟度來說，當時進行這項工程的條件是不具備的，但是，這項工程的實施卻是必須的。是以，在實施這個工程的過程中，不少系統都是多次返工，雖然達不到實際意義上的7×24，但是至少可以得到比其他方式更精确的資料資訊，這也就是這項工程的一大意義了。是以，在此後，盡管1997年早成為過去，但是九七工程這個名詞卻一直被沿用下來，以代表這個特殊的意義——中國電信行業的第一次資訊化。
二、OSS/BOSS系統
2001年，中國移動開始規劃“BOSS”系統，2002年各省移動公司分别制定了自己的“BOSS”系統的技術規範和業務規範，但是，離真正實施還有一段時間，因為中國移動還需要進行統一的規劃。
在中國移動制定規範的同時，中國電信集團也不甘落後，也開始制定自己的“OSS”系統的規範和實施規劃，并在其上海研究院進行相關的試驗。不過，因為其工作量過大，按照初步的估計，一個省級電信公司要實作“OSS”系統的規劃，至少需要五年，投入至少有3到5億以上的資金。按照這樣的估算，中國電信集團要實作全國的“OSS”規劃至少就需要90億以上的資金投入，是以，一直到現在，中國電信集團的“OSS”系統還仍然無法進入實施階段。
其他的電信營運商，諸如中國聯通、中國網通、中國鐵通等公司也都在紛紛籌劃自己的相關系統。
技術方案概述
一、B/S結構
随着軟體技術和網絡的發展，各種行業軟體業幾乎都在進行着B/S與C/S結構的争論和演化。雖然大家都認為B/S結構更先進一些，但是，在某些特定的行業和業務中，C/S結構的系統仍然有着非常重要的地位和不可替代的作用。
加上B/S結構産品的開發難度要遠大于C/S結構的系統，調試和測試工作都要比C/S結構的産品複雜得多。在此條件下，基于成本和效益的各種方案對此有很大的影響。
經過長時間的研究和探讨，通信行業的産品在體系結構上基本達成一緻：在業務操作實作領域采用B/S結構，在某些特殊的功能實作上适當地采用C/S結構。
二、多層結構選擇的必然
提到體系架構的選擇，電信行業的大多數業務對系統的實時性、穩定性要求都非常高，是以電信行業軟體業就成了所有軟體中開發難度最大的一種。
目前國際上流行的兩種軟體體系，都采用了多層體系來進行大中型系統和關鍵系統的構架。
電信行業項目的實施中，也大都采用了中間件進行整個體系的構架，在J2EE體系成型之前，大多數系統都采用C/C++進行開發，一些關鍵的業務實作則采用 Corba體系。随着Corba與J2EE的融合，兩大對立陣營的.Net與J2EE逐漸成型，電信領域的大型系統大部分都采用了基于Java的多層體系架構。如圖2所示：
Web伺服器：在Web伺服器上，部署的是系統的表現層，使用者通過浏覽器進行浏覽和資訊交換。
應用伺服器：主要提供元件的生存支撐環境，提供業務邏輯搭建的基礎。
三、體系架構的選擇
目前流行的兩大體系是.Net和J2EE。
由于微軟的産品大都穩定性、可靠性較差，雖然上手非常容易，但這恰恰不能達到電信行業對于可靠性的基本要求，是以，從體系到産品，微軟都被全部屏蔽于行業重點業務的實作之外。
J2EE體系得到了較多大型廠商的支援，同時融合了Corba對語言無關性的特征（雖然其真正的可用還需要一段時間）以及其他優勢，目前已經得到了絕大多數電信公司的認可，在通信行業領域内的開發商和內建商也都紛紛附和。
四、語言的選擇
對于語言的選擇，新的電信行業軟體做了非常慎重的考慮，既要保證效率和實時性，還要能提供足夠強大的穩定性，在J2EE推出之前，包括國外的電信行業項目也大都采用C/C++開發，但是，因為C++本身所固有的問題——記憶體洩漏，是以，系統的穩定性總是很難得到保障。
Java出現後，由于Java自身對C++的補充，穩定性方面得到了極大的提高。但，同時也發生了一個問題：因為Java需要運作在Java虛拟機上，經過這樣一次解析後，其運作效率和速度都受到了很大的影響，當進行大資料量查詢和統計分析的時候，Java的速度問題就很明顯了。是以，在一些特殊的功能實作方面，又需要使用C/C++來進行速度的提升。
五、最終決定
通過上面的描述，我們已經基本上把電信行業軟體開發的體系架構表述清楚了。圖3是筆者早先完成的一個基于J2EE架構的産品開發技術架構，僅供參考：
1 J2EE實作整體設計原則與思想
該系統的設計，采用了元件化的設計思想，同時根據項目的特點，對J2EE的實作架構進行了适當的改進，使之能更适應電信目前的要求和今後擴充的需要。
系統采用J2EE體系架構進行整體結構設計，這也是國際上流行的解決大型企業應用及關鍵性業務應用的優秀技術。
2 功能設計
通過J2EE技術架構實作電信行業系統的所有功能。
3 體系結構
該系統必須采用多層體系結構。建議采用如圖3所示的六層體系進行架構。
4 構架特點
下面按照資料庫層、資料管理層、事務處理層、會話處理層、邏輯控制層、前端表現層的順序對以上各層功能和特點進行詳細的描述：
（1）資料庫層
選用某種資料庫，提供資料存儲服務，同時，還需要提供災難備份和恢複功能。是以，目前，電信行業内部對資料庫的基本要求如下：
①支援ANSI/ISO SQL-89、ANSI/ISO SQL-92标準；
②支援中文漢字内碼，符合雙位元組編碼；
③支援主流廠商的硬體平台及作業系統平台；
④資料庫系統應具有良好的伸縮性；
⑤支援主流的網絡協定（如：TCP/IP、IPX/SPX、NETBIOS及混合協定）；
⑥具有良好的開放性，支援異種資料庫的互訪：
實作對檔案資料和桌面資料庫資料的通路；
實作對大型異種資料庫的通路；
能夠将原有異種資料庫向本資料庫無損失移植；
實作和進階語言互聯的能力；
支援XA、ODBC 3.0、X/OpenCLI、JDBC等工業标準；
支援分布式事務及兩階段送出功能。
⑦具有支援并行操作所需的技術（如多伺服器協同技術、事務處理的完整性控制技術等）；
⑧支援網絡上同構或異構資料庫之間資料的備援性複制；具有多種複制功能子產品（如實時複制、定時複制、雙向複制、多點方式下的N向複制、複制轉發，複制範圍可整表複制或表中部分行複制或修改單元複制）；
⑨支援聯機事務處理（OLTP），支援決策支援的建立，要求能夠實作資料的快速裝載、高效的并發處理和互動式查詢；
⑩支援C2或以上級安全标準、多級安全控制；
支援資料庫存儲加密及相應備援控制；
提供Web服務接口子產品，對用戶端輸出協定支援HTTP2.0、SSL等；
支援聯機存儲和備份功能（如錄音帶方式、CD光牒方式）；
應具有強的容錯能力、錯誤恢複能力、錯誤記錄及預警能力；
資料庫、表大小等技術參數可靈活設定，支援對多媒體資料及大資料量處理的技術需求；
應可以避免資料庫死鎖的出現，一旦死鎖能夠自動解鎖；
開發工具易使用、開發效率高、維護友善；
支援多種CASE工具。
上面對資料庫的各個方面都提出了要求，在電信行業内部，目前對于中小型非關鍵業務項目采用MS SQL Server 2000的比較多，大型項目基本上都避開微軟的體系和産品，而采用Oracle和DB2作為系統的資料庫選擇。
（2）資料管理層
這是整個系統中唯一進行資料通路、資料控制和資料安全校驗的部分，是系統中唯一與資料庫互動的部分，這也從另一個層面提高了資料安全性。
另外，由于有些電信行業系統的分布地域比較廣，采用這種方式有利于分布式資料的有效管理，可提高資料的使用率和有效性。
優點：專用的資料管理層屏蔽了系統的其他部分對系統資料庫的直接通路，增加了系統資料的隐蔽性，提高安全性和可管理性。
具體實作的時候，可盡量采用應用伺服器所提供的功能，采用容器管理實體Bean（也就是CMP Entity Bean）來開發資料管理層，這樣可以降低開發人員的開發工作量，提高效率，提高元件的可重用性。而且，當資料庫發生變化的時候，不需要做大量的編碼，通過應用伺服器本身就可以直接對這種變化做出相應的反應。
注：對于CMP和BMP的使用的基本觀點是這樣：對于完全建立的系統，也就是說沒有老系統的存在，或者可以忽略老系統的資料庫設計方式可能對新系統的資料庫設計造成的影響的時候，建議采用CMP的方式來開發Entity Bean，這樣就可以完全采用OO的方式從需求開始到分析設計和編碼實作都依托于OO的思想進行整體的規劃，系統實作也會相對比較合理。而對于不符合上述情況的系統，一般在前端流程實作和業務邏輯實作中可以考慮采用OO的過程，在資料庫管理層的實作中需要考慮與前端的配合外，資料庫管理層的設計和資料庫層的設計建議采用面向資料的過程進行規劃，否則，不僅僅使用者可能會對工期不滿，開發團隊也将面臨着資料抽取與轉換的難題。
（3）事務處理層
系統中進行事務處理的主要部分。這部分将根據具體的業務邏輯和實作進行業務控制和事務處理。在業務進行變化的時候，不影響系統的其他部分。
由于有些規則和制度會因為時間和各種情況有一定的變化，是以很多業務的具體處理流程和過程都需要修改，這樣的修改如果放在其他部分，就有可能影響到很多其他業務的正常開展。
優點：經過仔細考慮後，筆者認為：針對所有具體的業務增加專用的事務處理層，進行專項業務的處理和控制。提高系統整體的可重用性，降低系統各部分之間的耦合度。
通過這種方式，可以随時随地地增加一項業務，減少一個環節，都不會對其他部分造成大影響，除非這項業務有一些固有的特殊的頁面展示要求，否則都可以友善的達到上面的功能。
例如：在業務重組和舊制度廢除、新制度釋出的時候，可以先按照新制度定制好流程元件，在新制度釋出生效的時候，将舊元件卸下，新元件安裝即可。在現有的應用伺服器上使用時，甚至服務都不需要中斷，對于一個業務的更新，僅僅需要一兩秒鐘的時間就可以完成。
缺點：一定程度上，這對效率有所影響，但相對于Internet網絡狀況對系統性能的影響來看，這種架構模式對整個系統性能的影響仍然是很小的。
筆者建議：
①如果遇到大資料量查詢時，建議越過這種架構模式，直接通過安全的SQL連接配接方式從資料庫中盡快擷取資訊。
②對于大型的電子商務系統也可以借鑒這種體系架構，但對于僅僅在區域網路内工作的系統，就可以對本架構進行簡化，因為區域網路内的安全性相對較高，是以，可以考慮簡化以提高系統性能和運作效率。
（4）會話處理層
會話層，處理與前端展現的會話資訊，提供互動的第一個處理界面，處理簡單、穩定的事務。不處理複雜的事務和變化較頻繁的事務。
優點：提供對前端發送過來的請求和各種資料資訊的處理，目前端展現發生變化的時候，不會影響到背景的服務元件代碼。
提供對簡單事務的處理，這些事務一般是通用型的、基本上不發生變化的事務流程。如電信行業的批複流程、稽核流程等等。
（5）邏輯控制層
系統進行控制的部分。這部分将提供系統整體的控制，處理各個部分之間的關系，啟動各層間的操作和運作。同時它可以屏蔽前後兩層（前端表現層和會話處理層）之間的聯系，降低系統的耦合度。
優點：這是MVC中的控制層，在采用J2EE進行系統架構設計時，IBM非常推崇這種模式。在本系統的架構考慮中也認為采用這種模式是相當合适的，但同時考慮到這個系統的實際情況，本文對這種模式作了擴充，将模型層分成兩個部分，也就是資料管理層和事務處理層，具體原因已經在這兩個部分作了解釋。
這種模式是把控制權和所有權進行分離，當具體業務和會話表現等部分發生變化的時候，開發人員不需要修改控制層的代碼，使得整個系統中各個部分的權責更加明确，降低了維護的工作量。
（6）前端表現層
系統中提供資料展現的部分，屬于整個系統的UI。這也是使用者對整個系統最直接接觸的部分。将提供報表展現、報表定制和錄入、資料輸入和輸出、資訊浏覽釋出等等……
優點：這是一個完全獨立的表現層，如果設計的比較好，就可以做到：其樣式、風格都可以由美工進行直接的修改和設計。這些設計不會影響到任何背景的事務，是以，甚至可以做到随時更換風格。
5 性能實作
（1） 安全性
關于安全性的描述，請參見系統和資料安全管理中的描述。
（2）可靠性
系統的可靠性将在具體的項目開發過程中展現出來。因為每一項業務的添加與減少都對系統整體的穩定性産生一定的影響。開發過程中，隻要對設計進行嚴格的檢驗和測試就可以保證整個系統的可靠性。
（3）靈活性和擴充性
按照目前所規劃的技術架構，開發者可以随時在上面進行各個功能層的組合和分離，也可以将各個功能層分布在各個不同的伺服器上共同提供服務，是以整個系統無論是在實體結構上還是在邏輯結構上都具有很高的靈活性和擴充性。
對于業務元件，開發者/使用者可以對其進行業務分割和重組，以提高元件的使用率，對于今後其他系統的開發也具有技術積累的意義。
同時，這些業務元件可以根據業務狀況的變化進行更新和替換。比如說：某一項新的制度釋出生效前，開發者可以提前按照新的制度開發好完整的業務元件，在生效的那個時間點，将老元件取下，新元件安裝到伺服器上。這樣也就不會因為制度的變化影響到各個業務或者辦公流程的順利開展。
（4）實用性
系統的技術架構是專門針對項目的一些特性對J2EE原有的體系架構進行修改和完善後設計出來的。它既可以應付複雜多變的業務流程，對于一般十分穩定的業務流程也不會出現多餘的問題，且具有相當好的擴充性和靈活性。