論SOA技術的應用

摘要：
?本人于2010年7月參加國內某某知名港口供電業務系統的開發工作，在該項目中主要擔任系統架構師，主要負責該系統架構和網絡安全體系架構設計。經過近20年的港口信息化建設，港口供電系統已經建立了一些應用系統，但是，隨著港口供電業務的發展，有些系統已經無法滿足目前供電業務需求，同時存在已經開發的系統之間信息共享能力弱，系統集成度較低，系統擴展難的現象。 為了解決供電系統中復雜、分散、異構的數據信息之間交換，實現數據的高可復用性，同時適應新的業務需求，開發新的應用系統以適應日益增長的港口供電線系統信息化需求，實現系統平臺的易擴張性，易集成的特性，在供電業務系統中，我們采用WCF開發技術，建立了SOA架構。目前該項目已于2011年7月完工，從運行效果來看，達到了預期的目的，得到了同行和用戶一直好評，也說明SOA技術對實現企業信息系統的開發有著非常重要的意義。
正文：
?本人于2010年7月參加了國內某某知名港口供電業務系統的開發工作，在該項目中擔任系統架構師，主要負責系統架構和網絡安全體系架構的設計。經過近20年的港口信息化建設，港口供電系統信息化建設已經取得一些成績，建立了多個應用系統，如勞資系統、調度派工系統、財務管理系統、電費管理系統等。但是由于不同的系統在不同的時期開發，運行在不同的平臺上，采用不同的開發技術和規范標準，導致“信息孤島”現象存在，系統之間數據共享和交換較為困難。按照合同規定，該項目必須在1年內完成。為了在有限的時間內，開發出高效的應用系統，我們必須采用科學的開發方法，經過分析，我們采用WCF開發技術，運用SOA 架構來實現系統的功能需求。 經過需求分析，我們將該系統分為電費管理、財務業務一體化管理、安全護品管理、機電設備管理、物資管理、生產調度管理、流程申報管理、網上辦公管理、工程項目管理、報表及領導查詢管理模塊。在該系統中，我們前端程序采用微軟的.NET平臺中的C#進行開發，數據庫采用oracle進行數據存儲。通過對系統需求分析，我們采用以下方法實現： （1）電費管理模塊雖然已經有該應用系統，但是目前的電費管理計算方法已經發生很大變化，在新的系統中必須按照最新的電費計算方法開發，但是很多基礎資料，我們應該導入到后臺數據庫中。因此該部分應該采用淘汰老系統，復用有價值的數據方法開發。 （2）財務業務一體化管理、工程管理、流程申報管理、報表及查詢過管理是在新系統提出的新業務需求，需要全新開發。 （3）安全護品管理是我公司以前幫供電業務系統開發，而且也是基于WCF開放技術實現的，在新系統中，可以將此系統直接集成到新的供電業務管理系統平臺下。 （4）機電設備管理、物資管理、生產調度管理雖然已有的應用系統基本能滿足目前的業務需求，但是由于開發技術比較落后，系統維護困難，此外數據共享能力差，我們決定采用將數據集成到新的業務系統中，前端應用重新開發。 在該系統中，我們采用以下開發技術實現供電業務系統功能，系統采用層次架構設計風格來實現所有系統功能，在該系統是通過四層架構（client/contract/service/Host）的方式實現的。 首先，我們通過需求分析，將用戶需求分解為一個個服務。由于該系統涉及港口供電業務系統方方面面，在該系統中需要編寫很多服務。我們在前端編寫的客戶端界面以插件（plugin）的形式進行注冊，各個客戶端界面調用的服務通過統一的端口，以申請訪問服務器上的服務，在該系統中具體是通過顯示指定服務，同時依賴契約層方法實現和服務器上服務關聯的。安全護品模塊是我公司開發的，所以可以直接將該部分界面注冊到開發平臺下。 其次，中間契約層實現提供服務接口功能。中間層既要被服務層所用，也要為客戶端所用。我們通過契約層將所有的服務操作暴露給用戶，同時實現將所有的接口轉換為服務契約，客戶端所有需要的服務也在契約層上進行查找，客戶端無須知道每一個服務（service）是如何實現。中間契約層實際上就是定義了在該層有哪些可用的操作，以及每個操作的方法簽名。再次，服務實現層具體實現如何完成每一個服務，所有的服務層要和契約層相關聯，在該系統中服務層通過注冊表以訪問數據庫，實現和數據庫相關的所有操作。Host層的本質就是把一個Service置于一個運行中的進程中，并以Endpoint的形式暴露出來，并開始監聽來自Client端的請求。Host層通過XML語言描述實現和服務實現層以及契約層相關聯。等所有的系統功能完成后，將所有的服務注冊部署到相關的應用服務器，以提客戶端申請服務成功查找，進而實現系統的通信功能。 通過采用這種面向服務的架構給系統帶來了很大益處，實現了系統的高可復用性。如安全信息管理模塊、物資管理，港口其他單位的信息化需求較為相似，以后在為其他企業開發項目的系統的時候，只需要為該企業開通權限，允許調用此服務即可實現系統功能。對于以后新出現客戶需求，只要添加新的服務接口就可以，不需要搭建新的系統架構。同時通過此層次架構的開發，增強了系統網絡安全性，由于各個層次的功能明確，客戶端將無法直接訪問數據庫層，取而代之的是專門的應用服務器去訪問訪問服務，而其通過對服務器的訪問安全設置，提高了對數據庫的訪問安全性。此外，大大提供企業應用的集成度，在該系統中，港口供電系統的所有應用被集成到一個統一的平臺下，如財務部門、勞資人事部門、生成管理部分都需要調用人員信息，在統一的系統平臺下，該信息只要一次完成，多次調用即可，打破了傳統的同一個界面在不同的應用系統中要重復開發的現象。 該系統已經于2011年7月，成功通過了供電業務部門的驗收，大大提高了港口供電系統信息化管理水平，提高了港口供電系統生產效率，得到了用戶的肯定。但是目前該系統由于開發時間有限，該系統仍存在一些需要改進之處。由于港口供電業務系統平臺注冊的服務很多，系統用戶也很多，有些服務調用響應時間較長，如電費收取模塊本身計算較為復雜，在加上服務查找時間，導致客戶端獲取數據較慢。在今后，我們對采用層次架構風格系統要采用將應用服務器進行分類，將服務按功能發布到不同服務器上，同時要提供備份應用服務器，當其中一臺服務器無法工作時候，備用服務器要立刻啟動去工作。以較少服務的響應時間和保證系統通信正常。由于在該體統中數據共享程度高，在不同系統間進行數據讀取時候，要注意對輸入數據的校驗，如我們發現在人力資源管理系統中輸入的數據有些格式錯誤，數據不正確，這就要求系統提供智能化識別功能。同時對系統出錯的時候，要能夠有一定的容錯功能，要提供回滾功能，如在此系統中的流程申報出錯，要提示與此相關聯的所有操作都要撤銷。 在該系統中，由于使用了SOA技術，大大提高了系統開發效率，節省系統開發和維護成本，使系統具有更好的開放性、易擴展性，以及可移植性。從該項目完工后使用效果看，到達了預期目的，得到了用戶的好評。在今后的日子里，本人一定會更加努力鉆研專業基礎知識，提高自身水平，為國家信息化建設盡自己綿薄之力。

論SOA在企業信息化中的應用

摘要：
?2010年8月，我參與了某市級機關的電子政務系統建設項目，該項目的主要目的是開發一個通用性的框架平臺，其主要功能是提供一個統一、高效、具有強大的擴展能力的電子政務平臺，包括政府門戶、政務信息系統、業務辦公系統等系統均以服務的形式集成到該平臺中，并將接口暴露給用戶，同時將該市級機關原有的政務信息系統遺產進行通用化包裝，并集成至該電子政務平臺中，形成一個統一的、完整的系統。 筆者在該項目中擔任項目經理和系統分析師，主要負責項目的管理工作和系統框架的設計工作。在項目中，考慮到對高擴展能力、高集成能力和重用信息系統遺產的需要，我們最終采用了基于SOA架構的Web Service技術來實現該系統。該系統從2011年4月完工至今，運行情況良好，已經基本實現了預期的目的，充分證明了SOA技術對企業信息系統開發的重要意義，然而在實際使用當中，也有一些問題尚待解決。
正文：
?進入二十一世紀以來，我國電子政務建設有了長足的進展，各地政府紛紛建立了以縣、市、省三級結構的電子政務系統。在建設的過程中，有兩個問題很突出：一是系統的集成性和擴展性的問題，二是各單位原有的政務信息系統遺產的處理問題。 筆者于2010年8月，參與了某市級機關的電子政務系統建設項目，并在該項目中擔任項目經理和系統分析師一職。該項目的主要目的有兩點：一是開發一個通用性的電子政務框架平臺，提供一個統一、高效、具有強大的擴展能力和集成能力的電子政務平臺，包括政府門戶、政務信息系統、業務辦公系統等系統均以服務的形式集成到該平臺中，并將接口暴露給用戶；二是將該市級機關原有的政務信息系統遺產進行通用化包裝，并集成到政務平臺中，形成一個統一、完整的系統。 筆者在前期的需求分析調研當中，發現由于該市級機關的信息化政務建設工作起步較早，因而存在著信息孤島的問題，具體表現在該市級機關的信息化建設工作起步較早，各部門根據自己部門的實際需要，在不同的時間段，選擇了不同的廠商，采用了不同的開發平臺和后臺數據庫建設了自己部門級的政務信息系統，如財務處的財務處理系統、人事處的人事管理系統、以及各個業務部門的業務信息系統等，這些信息系統采用不同的開發平臺和數據庫系統，彼此之間的運行環境、數據格式互不兼容，并且由于各部門進行信息系統建設的時候采用各自為政的策略，沒有一個統一的規劃，造成了各部門的信息系統之間的業務流溝通不暢，信息無法共享，系統與系統之間缺乏通信接口，從而造成了信息孤島的現象，最終阻礙了該機關電子政務系統的發展。 經過上述的分析后，我們為此專門召開了項目會議，由于用戶提出要求保留和盤活該機關的政務信息系統遺產，并且在新系統建設當中，重點建設系統的集成能力和擴展性，經過會議的討論，最終我們決定采用SOA框架技術來進行該電子政務系統的建設。 SOA框架技術是一種將企業的現有的軟件系統進行重新包裝，并通過某種管理機制進行統一的管理，以構成一個統一的、集成的系統，在這個系統中，新開發的系統和舊有的系統之間通過異步消息機制進行數據通信和業務流協作，以達到新舊系統能夠無縫（最大限度地）協作，SOA最大的特點之一就是將所有的應用都看作服務，通過服務注冊中心進行統一的管理，因此SOA框架技術適用于對擴展性和集成性要求較高的場合。 SOA僅僅是一個面向服務的架構，還需通過具體的技術來實現。經過對該機關的基礎設施的調研，從現有軟硬件環境、該單位自有的技術人員的經驗和知識范圍等方面考慮，最終我們決定采用基于微軟的.net framework環境的Web Service技術來進行開發。 在具體的開發過程中，我們采用了.NET中的C#來開發客戶端應用，利用微軟的MS SQL SERVER開發后臺數據庫，應用以組件的形式在服務器上的服務管理中心進行統一的注冊，并暴露統一的接口給客戶端以供調用。服務管理中心是整個系統開發的重點，它在客戶端應用和后臺數據庫之間起到承上啟下的作用，整個服務管理中心實際上就是一個Web Service，負責管理服務器上所有的組件服務，我們利用.NET技術來實現服務管理中心。我們將新開發的服務模塊在服務管理中心中注冊，服務模塊采用基于XML的WSDL語言來進行模塊功能的描述，以便讓服務管理中心自動識別，并將功能接口暴露給客戶端以供調用，服務的功能接口采用SOAP協議以便客戶端進行服務的識別和數據交換。服務管理中心實際上是處于客戶端和后臺數據庫中間的一個結構層次，所有的服務都被包含在這個服務管理中心中，對于客戶端而言，在進行服務調用時，不必關心服務的具體位置和具體的實現方法，僅需向服務管理中心發送異步消息，該消息是基于SOAP和XML的，包含了例如客戶端提出的功能請求類型、數據格式等相關信息，該消息在服務管理中心的消息總線機制上進行發布和傳遞，當在服務管理中心中查找到所需要的服務后，就可以同該服務進行通信，并完成整個業務。 我們所采用的客戶端-組件管理中心-數據庫三層式開發方法，是基于SOA框架的典型應用，它具有擴展性和集成性好、利于功能擴充等優點，很好地滿足了用戶對擴展性和集成性的要求。然而至此，整個開發工作只能說是完成了一半，接下來我們還需要進行政務信息系統遺產的包裝和集成的工作。 由于SOA框架本身就支持對舊有系統的無縫集成，因此在對歷史遺產系統進行包裝和集成的時候，我們不需要修改舊有系統的任何代碼，只需要進行一些配置，將其在服務管理中心注冊并暴露統一的接口給用戶即可。在具體的工作中，我們為每個舊有系統編寫了關于系統配置、數據格式的WSDL文檔，該WSDL文檔是用XML語言編寫的，可以被服務管理中心自動識別，通過該WSDL文檔，可以將舊有系統在服務管理中心進行注冊，并將接口暴露給服務管理中心的消息總線機制，以便當客戶端發送服務請求時，能夠被舊有系統的接口識別，從而同客戶應用建立連接并進行數據操作和業務流操作。 綜上所述，我們將整個系統建設的重點放在兩方面：一方面是以集成性和擴展性為中心，采用基于SOA框架技術的Web Service技術進行開發，另一方面是利用SOA技術規范中的WSDL文檔規范，對舊有系統進行包裝和描述，使其能同新系統無縫集成，達到建立一個統一的、完整的、無縫的系統的效果，以發掘舊有系統的商業和技術價值，充分保護該機關的現有投資。 該市級機關的電子政務系統成功上線運行至今，運行情況出色，經用戶反映，政務辦公的效率大大提高，并且有效地減輕了有關工作人員的工作負擔。事實證明，在進行電子政務系統的建設時，采用SOA框架和基于SOA框架的實現技術可以有效地提高系統的集成性和可擴展性，并且充分地盤活實施單位的歷史信息系統遺產，保護實施單位的已有投資。 然而新版電子政務也非十全十美，經過一段時間的實際運行，發現了兩個問題：一是系統運行一段時間之后，其運行速度呈線型下降，據分析，應是由于所新加的服務應用的增多，導致服務管理中心的運行速度變慢，為此我們制定了一個定期重啟服務器的計劃，經測試，運行速度變慢的現象有所緩解；二是經客戶反映，包裝集成的舊有系統在實際運行中，有時會報錯，據分析，應是該系統服務的WSDL文檔編寫不規范所導致，因此我們為其重新編寫了WSDL文檔，經測試，故障排除。 結束語： 在二十一世紀的信息大潮的帶動下，我國電子政務的建設如火似荼，然而電子政務的建設對于我國而言，是一個長期的、艱巨的任務，絕非一蹴而就的一次性工作，筆者愿意以一己微薄之力，投入到這場信息化建設大潮當中，為我國的信息化建設貢獻一份微薄之力。

論UP（統一過程方法）的應用

摘要：
?2011年3月，我參加了某市供電公司《電力營銷管理信息系統》的開發工作，并擔任系統架構師一職，主要負責系統分析和架構設計。該系統包括業擴管理、計量管理、電量電費核算管理、收費與賬戶管理、線損管理等五個模塊。系統采用了Struts+Spring+Hibernate的主流Web應用框架，降低了開發的難度和成本，降低了組件的耦合度，增強了軟件的可維護、可擴展性。 項目的成功很大程度的歸功于項目開發采用了RUP模型，對整個的開發過程進行規范和改進。本文以該項目為例，結合作者的實踐，討論了UP（統一過程方法）在軟件開發中的應用。從初始階段建立業務模型并確定項目邊界，細化階段分析領域、選擇構件，構建階段把構件組合成產品，最后把軟件移交給用戶四個階段說明了UP的具體應用。重點介紹了分析領域、選擇構件。
正文：
?2011年3月，我參加了某市供電公司《電力營銷管理信息系統》的開發工作，并擔任系統架構師一職，主要負責系統分析和架構設計。該供電公司年供電量在10億度以上，計量點915個，大客戶209個。以前的業務流程是電話報裝、手工派單、自主開發的VFP系統算費、財務系統收費開票等。隨著供電量業務的擴展，原業務流程暴露出各環節分散，無法進行統一的管理，客戶的滿意度低。為了解決上述問題，該供電公司決定建設一套電力營銷系統。以系統的建設促進用電管理水平的提高，以電力信息化推動電力企業現代化。杜絕重復投資，整體規劃，實現用電管理信息的高速交互和決策，提升客戶的滿意度，降低管理成本。 系統采用了Struts+Spring+Hibernate的主流Web應用框架，開發工具采用MyEclipse10.0，硬件配置：兩臺IBM X3650安裝Oracle10g做數據庫服務器，在兩臺服務器上搭建了高級復制功能，保證數據庫中數據同步。兩臺IBM X3650以雙機熱備的方式做營銷應用服務器，兩臺服務器上運行著集群軟件，通過“心跳”來檢測對方的狀態，發現故障能自動切換。一臺IBM X3650做算費服務器。 RUP統一軟件開發過程是一個面向對象且基于網絡的軟件開發方法論。可以應付種類廣泛的軟件系統，不同的應用領域，不同的組織類型，不同的性能水平和不同的項目規模。UP是基于構件的，與其他軟件過程相比有三個顯著的特點：用例驅動、基本架構為中心、迭代和增量。正是由于UP具備上述特點，使采用UP模型的開發過程能提高團隊成產力，簡潔清晰的過程結構，為開發過程提供了較大的通用性。 根據RUP模型，我們把整個的開發過程分為：初始階段、細化階段、構建階段和交付階段。每個階段結束的時候都要安排一次技術評審，如果評審結果令人滿意就可進入下一階段。 1. 初始階段 初始階段的任務是建立業務模型、確定系統邊界。首先，我們采用用戶訪談、用戶調查和聯合討論會的方式捕獲用戶需求，詳細了解用戶對系統的預期目標，捕獲在系統招標書中沒有明確的性能指標。其次，我們專門召開了一次聯合討論會，會上參與的各方代表經過討論，就需求的優先等級達成一致意見。最后，對需求進行分析，確定了項目的目標、特性和用例模型，完成了《需求規格說明書》的初稿，并通過了用戶的評審。 2. 細化階段 細化階段的任務是分析問題領域、建立體系結構、選擇構件。通過對問題領域的分析，我們把系統劃分為5個主要模塊：業擴管理、計量管理、電費電量核算管理、收費與賬戶管理和線損管理。確立了軟件的整體架構，部件之間的交互接口，構件的設計與選擇。 基于構件的開發可以減少開發中重復的工作，降低開發成本，縮短開發周期，提高軟件的質量和靈活性。獲取構件有多種途徑，第一種是在現有構件庫中直接提取符合要求的構件，或對已有構件做適當的修改。第二是采購第三方構件，現在市場上有很多成熟的產品，比如開發平臺、數據庫平臺、各種通用構件等。第三是自己開發符合需要的構件，當構件庫和第三方構件沒有滿足需求時，必須自己開發滿足需要的構件。 該項目中上述的三種方法我們全部都用到了。在以前的項目開發中，我們提取了很多的可重用構件加入自己的構件庫。比如：權限管理對于任何管理系統都很重要，我們提取符合RABC（基于角色的訪問控制）模型的獨立授權構件，將權限與角色相關聯，通過成為適當角色的成員來獲得該角色的權限，簡化了授權的管理。該系統的流程要求根據業務需要可以配置，我們提取了工作流引擎，可以滿足流程的調度、圖形化的定義和管理。 市場上有很多成熟的構件，包括開源的和商業的，是不需要自己開發的。直接使用可以縮短開發周期，降低開發成本。我們采用的Struts+Spring+Hibernate框架就是典型的開源框架，可以讓我們把主要的精力放在業務的實現上，而不用去關心數據如何從數據庫中讀出和寫入，請求如何在各層之間傳遞等。報表是管理信息系統必不可少的功能，我們采用明宇公司的如意報表，滿足報表在Web下的設計、瀏覽、打印等功能。 有一部分構件是本系統獨有的，沒有現成的產品，必須自己開發。該系統對電費的計算有很多靈活的要求，變壓器容量的固定沖減、月度結算中變壓器容量的退補、特殊單位執行特殊電價、子表電量追加自動沖減母表等。根據這些要求，我們不能把算法寫死在程序中，而是自主開發了一個電費計算引擎，通過計算規則和電費計算相分離，實現了算法的方便配置修改，提高了電費計算的靈活性。 在細化階段我們更新了需求規格說明書和軟件體系文檔，選擇了適合的構件，并完成了用戶對其的評審。 3. 構建階段 構建階段的任務是把各種構件組裝成產品。我們采用基于功能和面向對象的組裝技術相結合，根據系統的需求，把各種渠道獲取的構件組裝成產品，并完成系統的集成測試和系統測試。每次迭代的成果都展示給用戶，讓用戶詳細了解進度，并提出反饋和改進意見，我們及時調整開發。該階段結束時，向用戶交付了系統的Beta版本。 4. 交付階段 交付階段的任務是把產品成功的分發給用戶。由于用戶要求是新的業務應用該系統，不存在新老系統的業務移交問題，所以交付階段比較簡單。首先，在用戶提供的環境下部署Beta版本，進行系統的Beta測試。其次，對各種錯誤和缺陷做出修改，增加文檔和培訓資料，并對用戶進行培訓。最后，配合用戶完成了驗收測試。 結束語： 該系統于2011年11月成功的通過了用戶的驗收，大大提高供電公司的用電管理水平，提高了客戶的滿意度，降低了管理的成本。項目的成功很大程度歸功于采用了RUP的開發模型，對整個開發過程進行規范和改進。在迭代的開發過程、需求管理、可視化建模、驗證軟件質量控制變更等方面，為每個開發成員提供了各階段必要的準則、模板和工具指導。 RUP雖然具備很多優點，但也存在一些不足，如：RUP僅僅是開發過程，沒有覆蓋軟件的維護和技術支持著兩個重要的過程。不支持組織內的多項目開發，導致組織內的大范圍重用無法實現。在度量管理、重用管理、人員管理等方面存在不足。在實際的應用中可以根據需求對其改進，可用OPEN、OOSP等其他軟件過程的相關內容對RUP進行補充和完善，使整個開發過程更加適合自己的項目。

論分布式數據庫的設計與實現

摘要：
?分布式數據庫系統把應用所需的數據存放在多個數據庫服務器上，完成某個數據操作要涉及到訪問多個服務器，這適用于某種特定需要的應用。 本文描述了我在主持設計開發的一個MIS系統中，為了達到了在低速網絡通道下有效提高應用程序性能的目的，使用Sybase分布式數據庫技術的過程。系統采用典型的C/S結構，但許多客戶端連接服務器的網絡采用電話線撥號，速度有限，傳統Windows界面的客戶端應用程序相應速度比較慢。考慮到B/S結構也避免不了大量數據從服務器端傳輸到客戶端，我認為WEB界面并不能有效解決這個問題，所以采用了優化數據庫結構的方法，把數據分兩部分存放，基礎數據放客戶機，會員資料主要采用鍵碼放服務器，應用程序再現數據時從服務器取鍵碼，到客戶機取對應的解釋，由于鍵碼的數據量少，網絡傳輸便快。在構建這個分布式數據庫系統的過程中，我著重研究并解決了數據同步和事務協調的問題，取得了良好的應用效果。我認為，分布式數據庫系統的技術在Intenet時代正當其道，大有發展前景。
正文：
?分布式數據庫系統把數據存放在多個數據庫服務器上，當應用提取所需數據時，要訪問多個服務器，綜合多點數據才能完成。 分布式數據庫技術在很多場合得到了應用。譬如某企業隨著業務量的擴大，原有數據庫服務器已經達到了容量和性能極限，如果不希望丟棄原有投資，可以建立另外一套新的數據庫，跟原有的系統組成一個分布式數據庫系統，給應用提供透明統一的數據訪問。還有，如果某企業分成多個業務部門，而且地域分散，可以在某個部門放置單獨的數據庫服務器，用于存放該部門最常用的數據，而部門和部門之間相互引用的數據可以通過分布式數據庫技術來方便地完成。分布式數據庫不是簡單地把集中數據庫分散實現，而是針對某種特定應用需要而誕生，它必然具有自己特有的性質和特征，需要在上面做許多的工作，來滿足應用的要求。 我在設計、開發一個MIS系統時，針對應用的需要而引入分布式數據庫技術，取得了良好的效果。 該系統針對會員資料的管理而設計，用于管理會員入會、繳納會費、申請資助、辦理資助審批、關系轉移、退會和注銷手續等等業務流程。分三個級別的應用權限——基層單位級、總公司級和集團公司級，各個級別只能操作各自范圍內的業務數據。該系統采用典型的C/S結構，后臺數據庫采用Sybase，前端應用采用PB開發工具來設計標準的Windows操作界面。我在其中任系統分析和數據庫設計的角色，擔任了調查業務需求、業務建模和數據庫建模、數據庫設計以及指導應用程序測試、優化系統和應用的性能等等一系列工作。 由于客戶端地域的分散，遍及多個省境內，許多使用該系統的基層單位連接服務器數據庫的網絡采用電話線撥號方式，速度有限，在使用客戶端應用程序時感覺界面速度很慢。經過分析，認識到許多操作都要從服務器中取數據，速度慢就慢在數據訪問上。服務器是沒有性能瓶頸的，問題出在網絡速度上。不可能要求眾多使用客戶改善和升級他們的網絡，只能充分挖掘軟件的潛力，來適應這種低速網絡的使用模式。 經探討，結合關系數據庫的知識，認識到，應用程序的每一次數據庫操作，都要訪問多個相關聯的表，其中，有會員資料表和基礎數據表，會員資料表中存放許多的鍵碼值，在基礎數據表中有鍵碼相應的解釋。鍵碼值的數據量比較少，而基礎數據是靜態的，幾乎不會更改。如果考慮把會員資料放在服務器上，基礎數據放在客戶端，當應用程序中訪問數據時，總是從服務器上存取會員資料，從客戶端提取會員資料中鍵碼的相應解釋。由于鍵碼的數據量少，便減少了網絡上傳遞的數據量，從而提高了界面的響應速度。 同時考慮到基層單位總是操作自己所屬的部分會員，增刪轉移操作少，會員列表比較固定，而每一項業務操作都涉及到要從會員列表中查找定位到某個會員，所以會員列表是最常訪問的數據項。把會員列表從會員資料數據中抽取出來，也放置在客戶端，這樣，便進一步改善了性能。 把數據分散存放只是工作的第一步，接下來要考慮應用程序怎樣訪問這種分布式數據。開發應用時，如果每一功能都針對兩個數據庫進行，就帶來了很多麻煩。所以，我們研究了Sybase的分布式數據庫技術，決定采用了CIS（組件集成服務）部件，來合并兩個數據庫成一個統一的分布式數據庫。應用程序只要連接一個數據庫，就可以透明統一訪問到兩個數據庫中的數據。 該技術具體實施方法是，在客戶端數據庫中建立一個對服務器數據庫的遠程訪問服務名，包含訪問地址、登錄用戶名、登錄密碼等等關鍵的連接信息；并且對服務器中會員資料數據表建立一個本地代理表，結構和服務器中遠程表完全一樣，它是訪問服務器中會員資料的中轉和代理。客戶端應用程序訪問本地代理會員資料表時，實際上是通過預定義的遠程訪問服務名中包含的連接信息到服務器中對應的實際會員資料表中訪問數據。這種訪問對于客戶端完全透明，感覺不到是從物理上獨立的兩個服務器中存取數據。所以，這種數據庫結構是典型的分布式數據庫。 部署這種分布式數據庫不是難事，只要在客戶端和服務器上安裝12.0版以上的數據庫服務器，在客戶端服務器上建立遠程服務名和代理表即可。由于Sybase數據庫的安裝支持腳本方式，在客戶端應用程序的標準安裝過程中，嵌入Sybase數據庫的安裝和配置腳本，就自動化地完成了所有工作。 在實際使用該分布式數據庫系統的過程中，遇到了幾個問題。第一，數據同步。客戶端基礎數據不是絕對靜態的，也有變化，因此在服務器端要設置一個統一的基準，稱為主點數據。客戶端總是復制使用，稱為復制點數據。如何及時感知到服務器端主點數據的變化，有效率地復制到客戶端，是個難題。Sybase針對這種應用場合，提供了復制服務器技術，但為了避免過于復雜，我們實際采用應用程序來管理同步。當服務器端主點數據有了更改時，保存一個相應的標識和時間戳，客戶端應用在登錄服務器時，檢查這種標識，一檢測到了數據有更新，就首先下載，然后再進入系統正常使用。這種方法實現起來，增加了額外的開發量，且不能判別繞過應用程序對數據的直接修改，但是，是最簡單和有效的方法。 第二個問題是事務協調問題。物理上獨立的兩個數據庫，在協同操作時，如果服務器正好停機或者網絡故障，完整的一個事務沒能完成，就會“事務崩潰”。雖然Sybase CIS內嵌了兩階段提交技術，能夠自動恢復。但是應用程序在這種情況下，敏感性不夠，操作界面會無端凝固，影響了使用的方便性。我們針對PB對于連接的判斷和感知，用了一個小小編程技巧，使應用程序能夠及時感知到數據庫連接故障，及時停止和恢復事務，使操作界面表現友好靈活。 以上遇到的這些問題，都找到了解決辦法。分布式數據庫技術的應用并不是非常復雜，它往往為解決特定問題、滿足特定需要而被采納，使用得當，會給應用帶來了許多便捷。 在當今信息社會里，互聯網絡帶來了相互連通的便捷，而且知識爆炸，數據的分布式訪問是個必然趨勢。潮流興起的XML技術，提供了各種平臺數據庫之間的一個公共數據訪問標準，可能會用來構建更加靈活、適應性更強的分布式數據庫技術。

論改進Web服務器性能的有關技術

摘要：
?基于Web技術的數據庫應用是當前應用的一個熱點，在用戶數目與通信負荷很大的場合，提高Web服務器性能是一個迫切的課題。本文從筆者參與某個銀行系統項目開發的經歷出發，闡述了提高Web服務器的性能應滲入到項目論證、選型、開發、運行和管理的各個環節，只有各個環節都能充分考慮到性能與質量的需要，系統的性能才是真正可保證的和可擴充的。 文章從系統的實際運行與相應的經驗出發，闡述了性能改進方面的一些具體措施。 比如：在本文中討論了Web服務器平臺的選型考慮；Web服務器的配置管理；應用系統本身的優化與預先設計系統時可擴性的性能保障等具體內容。 通過技術上的分析與改進，綜合性地運用多類措施與手段，在實際系統中，Web服務器運行的性能得到了一定程序的保證。
正文：
?我所在的單位是把目標定位于金融領域開發IT應用的一家信息技術公司。隨著金融電子化建設的發展和商業銀行之間市場競爭的加劇，各主要商業銀行不斷通過信息技術提供新的金融產品，并且希望整合市場渠道。比如主要的商業銀行不斷推出形形色色的網上銀行服務。在這種背景下，本人參與了開發新一代風上銀行產品，涉及提供網上個人理財服務、網上外匯買賣服務、網上企業服務等具有市場競爭力的產品。作為項目開發的組織者之一和主要的技術骨干，在整個項目開發過程中始終要處于第一線，從而在改進Web服務器性能、提高整個網上平臺系統性能方面收獲良多，在本文中簡要討論如下，希望與讀者們共享經驗。在Web服務器配置與優化方面，我有如下幾方面主要的體會： 第一方面是Web服務器選型考慮。 在Web服務器選型及網上平臺搭建這初，我們就已充公考慮整個網上平臺的性能及可擴展性問題，這一考慮為該系統的穩定性及擴展性能力方面打下了堅實的基礎。 某銀行原有的一些網上產品由于開發較早，故而采用的是老式的HTTP Server + CGI程序調用的方式。這時，每一客戶請求需要對應于后端系統的系統進程來運行CGI程序來處理，系統的開銷相當大，系統的擴展能力也很差，性能已不能滿足業務處理的需要，故而在為此銀行系統具體選型的時候，我們一開始就否決了這種方案。 通過市場上同類產品的比較選擇，我們選擇了國際商業機器有限公司IBM的Web Sphere產品系列作為該行網上銀行系統的建立平臺。作出這樣選擇是因為Web Sphere基于使HTTP Server和應用服務器相分離的整體架構，同時支持JSP、Servlet和企業級Java Bean等輕量級線程規范，所有的請求對應于應用服務器上的處理線程，系統的開銷低，效率非常高，同時Web Sphere整個體系結構相當的靈活，為適應擴展需要可以作不同的橫向和縱向擴展，從而可以滿足各銀行未來的擴展需要。 正是因為在一開始選型的時候我們就已考慮到未來的擴展需要，整個系統在接下來的幾次性能改進方面，我們大體上都能相對順利地達到了預期目標。 第二方面是Web服務器的性能配置。 在一開始系統上線的時候，由于系統的負荷不是很大，為了節省系統總擁有成本TCO投資，我們在一臺較低配置的IBM RS6000上投產了該系統。整個系統的HTTP服務器、應用服務器、通信服務器等均位于該臺機器上，由于初始投產時用戶不多，所以系統的性能基本上能令人接受。 但隨著業務的發展和用戶訪問量的增大，我們發現該服務器的響應變慢，系統的CPU利用率和內外存交換顯著增大。經過跟蹤，我們發現關鍵原因之一是系統的內存不足的緣故。由于網上服務器把大量用戶的會話信息保存在內存中供給應用系統使用，當內存不足時，大量Session信息被迫交換至硬盤，大量CPU時間消耗在等候內外存的交換上，系統效率迅速下降。 鑒于這種情況，我們把該服務器的內存由2GB擴充為4GB，同時相應調整用戶會話信息的保存時間，這樣整個系統的效率又回到較為理想的狀況。 由于新應用的不斷投產及數據庫操作的日益增加，我們后來逐漸監控到系統的數據庫處于繁忙狀態，系統的錯誤日志也記錄下了供應用服務器使用的數據庫連接處出現資源不足的情況。在這種背景下，我們認為整個系統由于硬件配置所限，應該進行橫向擴展，因此我們把數據庫服務器分離出來，配置到另一較高性能的服務器上，相應定義的數據庫資源也大幅增加，這樣整個系統的性能又處于較為理想的狀況。 第三方面是對應用系統進行相應的優化以提高性能。 Web服務器配置及相應的硬件擴展不失為解決系統性能問題的一條捷徑，但應用系統的優化也是應該重點加以考慮的，畢竟它能夠在投入較少的情況下提高系統的運用效率。 在開發的初期，我們就已經十分注意系統的利用效率，比如提醒程序員盡量不要利用用戶會話信息（Session）來傳遞大的對象，對于內存要注意回收等。同時，通過內部的交流會推廣與介紹一些小的，有用的編程技巧來提高開發人員的水平，通過代碼的抽查，希望能在早期就發現問題等。 在系統運行期間，我們通過監控發現，應用服務器所基于的Java虛擬機，其內存堆的空閑空間有不斷下降的趨勢，每隔若干天導致空間消耗殆盡，無法分配新對象空間，從而導致系統重啟。在排除了系統本身問題的原因外，我們確定為應用系統的開發有問題。通過從網上下載IBM公司檢測Java虛擬機的相關工具對JVM進行監控后終于發現系統內部存在著不能回收內存的對象，再通過查找相應的程序發現在該程序中有“環狀”的對象引用，從而導致對象使用后不能被垃圾收集器所回收。這個問題的解決過程雖然十分艱苦，但由于該問題不能通過升級硬件或增加資源配置而得到根本解決，會給系統帶來很大的隱患。所以，整個過程的分析與解決是完全值得的，更何況通過查找故障原因的過程，給整個項目組上了生動的一堂軟件質量保證課，對項目組的質量意識起了很大的促進作用。 所以說改進Web服務器的性能并不單純是系統管理方面的工作，它滲透到開發以及系統運行第一系列環節中。 第四方面預先考慮未來的擴展與性能需要。 隨著系統的發展及成熟，考慮到用戶訪問量的不斷上升，為了預留系統的發展空間，我們最近又對整個系統作了一個系統性的升級。通過引入多臺HTTP服務器及應用服務器并行工作提高整個系統吞吐量及單點故障克服能力。由于在一開始選型的時候就已經充分考慮到動態負載均衡及橫向擴展方面的需要，這一項的升級無需對整個系統的體系結構作根本的變革，對應用程序來說，更是沒有造成任何影響。 整個項目歷時近兩年，從這兩年的系統情況來看，整個系統是成功的。根據我親身的經歷，系統性能并不單純是系統運行與管理階段的問題，而是滲透在項目論證、開發以及運行的各個階段。只有各個階段都能充分考慮性能方面的需要，在實際運行時，整個系統的性能才可能真正有保障。在技術方面來看，可以綜合利用選型評估、硬件擴展、應用優化和系統配置優化等一系列的手段；比如在硬件擴展方面，又可以分為主要部件擴容，縱向升級、橫向升級等方面。在我們的項目實踐中，曾綜合地利用了上述的各種手段。比如某銀行的整個系統日訪問量不足1萬至現在的每日超過10萬次以上的點擊的發展情況來看，整個系統的性能保障及提高方案是比較成功的。

論基于UML的需求分析

摘要：
?2008年3月1日至12月20日，我參加了“數據安全訪問平臺”項目的開發，擔任系統分析員的工作。該項目是某行業用戶“數據中心二期”建設的主要內容，目標是：建立數據統一訪問接口及其使用標準，規范、約束和審計數據應用訪問數據庫的行為，對數據應用提供強制審計的技術手段。由于該系統是所有應用的基礎平臺，對系統的可靠性與性能有較高要求，同時由于沒有成熟的現有系統作為參照，該項目存在較高的風險。 本文結合作者實踐，討論了在項目中基于UML的需求分析。我們使用用例圖描述用戶與系統的交互；使用類圖描述系統的核心概念；使用部署圖描述系統的網絡部署；使用活動圖描述系統的應用流程。由于采用了UML中的多種技術，使得我們能從多個方面完整的把握需求，有效的保證到了需求工作的質量。最后，分析了需求工作中存在的問題和改進的方法。
正文：
?一、項目概述 2008年3月1日至2008年12月20日，我參加了“數據安全訪問平臺”項目的開發，擔任系統分析員的工作。“數據安全訪問平臺”是某行業用戶“數據中心二期”建設的主要內容。在一期建設中已建成數據的統一存儲和統一分發框架。但主要存在以下問題：無法獲得應用用戶對數據庫的操作日志；開發人員對數據庫的使用不規范，查詢的結果集過大，導致數據庫的性能大幅下降；應用直接使用數據庫的登錄數據庫，存在著一定的安全隱患。“數據安全訪問平臺”的目標是：建立數據統一訪問接口及其使用標準，規范、約束和審計數據應用訪問數據庫的行為，對數據應用提供強制審計的技術手段。 該項目具有較高的業務需求風險和技術風險。由于沒有成熟系統做為參照，該項目需求不是很明確，而且系統涉及甲方多個利益相關方，各方對系統的安全和審計功能、運行維護、可靠性、性能和易用性有者不同的觀點，某些觀點之間還存在沖突。同時系統作為“數據中心”的基礎設施之一，所有的應用系統都要通過本系統完成數據庫訪問。系統的可靠性和性能直接影響到應用系統的正常運行。整個系統分為6個子系統，包括JDBC驅動封裝子系統、ADO.Net驅動封裝子系統、WebService接口子系統、管理配置網站、存儲子系統（SQL Server2005數據庫，存儲配置信息）和監控子系統（數據庫網絡協議分析與連接控制）。 二、UML在需求工作中的應用 項目組采用一個精簡RUP開發模型指導項目的整個開發流程。在初始階段主要采用用戶訪談、用戶調查和聯合討論會捕獲用戶需求，進行初步分析，完成《需求規格說明書》初稿，通過用戶評審；在細化階段，對需求進行了細化，并在采用原型法驗證用戶需求，完成《需求規則說明書》更新稿，通過用戶評審，作為項目驗收的依據。 項目開發中，我們采用了統一建模語言（UML），并使用了Rational Rose工具。在需求工作中，我們主要使用了UML中的用例圖、類圖、活動圖和部署圖。 1、用例技術的應用 整個需求開發都是圍繞著用例技術開展的。首先，我們明確了系統的利益（查書）相關方、確定了系統邊界和建設目標，以及主要功能特性。由于系統涉及甲方多個利益相關方，包括：應用科、維護科、網絡科、信息中心領導和應用開發方，他們對系統的安全和審計功能、運行維護、可靠性、性能和易用性有者不同的觀點，同時本系統與已建成的網管系統和單點登錄系統存在著交互關系，這給確定系統的目標和邊界帶來一定的難度。項目初始階段開始，我們先通過用戶訪談、用戶調查了解了各個用戶對系統的觀點；隨后，我們召開了聯合討論會，會上我們描述了各個用戶的觀點，以及之間可能的沖突，供各方進行充分的討論，會議最后，信息中心的領導統一了各方的意見，對系統達成一致的目標，并明確了系統主要的功能特性，確定本系統了與網關系統和單點登錄系統的關系。 其次，我們建立用例模型，并細化關鍵用例。明確了系統的目標和主要功能特性后，我們采用用例模型對需求進行分析。整個系統包括六個用例包：訪問接口包用例包、審計信息管理用例包、用戶認證信息管理用例包、數據庫連接資源管理用例包、訪問控制信息管理用例包、數據庫連接監控管理用例包和審計日志管理用例包，共包含55個用例。對大部分用例我們只描述了一個基本正確流程，只對5個關鍵高風險用例進行了細化描述，包括：前置條件、后置條件、基本流、擴展流和相關約束。這項工作完成后，我們編寫了《需求規格說明書》初稿，提交用戶進行了審核。經過修改后，通過用戶評審，作為初始化階段的主要成果。 最后，細化用例模型。在細化階段，我們細化描述了所有的用例，完成《需求規則說明書》更新稿，通過用戶評審后，作為項目驗收的依據。 2、類圖的應用 用例技術描述了系統需求的動態結構，但對于需求特性和用例中出現的概念，并沒有統一的分析。我們使用類圖描述系統的核心概念。本項目中涉及的核心概念主要包括：邏輯連接、用戶、應用、受限角色、認證SQL語句、參數取值范圍的約束和查詢結果集的限制。在分析核心概念時，我們主要關注：概念之間的關聯關系，是否具有相同的生命周期，和具體的對應關系（一對多、多對多和多對一）。 3、部署圖與活動圖的應用 由于整個系統包含多個子系統，各個子系統部署在不同的節點，需要考慮用戶的網絡結構是否能支持。在需求階段，我們也描述了整個系統的部署。其中監控子系統比較特殊，由于其是通過分析Oracle數據庫的網絡數據包進行工作的，因此監控子系統必須接入核心交換機的鏡像端口。我們將部署圖與網絡科進行了確認。 我們使用活動圖描述系統的應用場景。由于本系統對應用系統的開發增加了一層管理，因此應用系統的開發方與信息中心存在一個交互流程：應用開發方首先使用本系統的開發版進行本地開發，并填寫基本配置數據；然后，在用戶的生產環境中部署應用，并提交基本配置數據；最后，信息中心的管理員對配置數據進行修改后，應用在生產環境中才能運行。我們使用流程圖描述了整個過程。用通道表示應用開發方和信息中心，并描述了各個通道內的流程以及通道之間的交互。 三、總結 由于沒有成熟系統做為參照，該項目具有較高的需求風險。由于在整個開發過程中使用了UML的用例圖、類圖、部署圖和活動圖，這使得我們能從多個方面完整的把握需求，有效的保證到了需求工作的質量。 本項目的需求工作中，我們也遇到的一些問題，主要是維護Word文檔與模型的一致性。我們使用RationalRose建模，使用Word寫文檔，通過截圖的方式將模型插入文檔，因此需要手工維護兩者的一致性。這種方式較繁瑣，容易出錯。今后的工作中，我們準備使用Rational公司的Soda工具，自動將Rose中的模型插入到Word文檔中。

論基于構件的軟件開發

摘要：
?2011年3月，我有幸參加了沈鐵設計院綜合管理信息平臺(簡稱：信息平臺)項目的開發工作，并擔任系統架構師一職，負責系統的架構設計及核心構件的開發工作。該系統是沈陽鐵道勘察設計院有限公司委托開發的，項目于2011年底驗收，滿足客戶方提出設計、生產、經營、管理的需求。 本文以信息平臺為例，討論基于構件的軟件開發，簡單說明為什么要用構件開發及獲取構件的方式，接著詳細介紹了通過一次登錄后可以任意跳轉到其它各子系統的單點登錄構件、數據庫訪問構件、展現信息的層次結構的目錄樹構件、方便設置文檔格式的活動表單構件等系統主要的構件以及開發過程，開發策略，加強構件復用程度，提高軟件的開發效率，縮短軟件的開發時間。文章最后簡略說明幾種構件技術的發展趨勢。
正文：
?2011年3月，我有幸參加了沈鐵設計院綜合管理信息平臺(簡稱：信息平臺)項目的開發工作，并擔任系統架構師一職，負責系統的架構設計及核心構件的開發工作。該系統是沈陽鐵道勘察設計院有限公司委托開發的，項目于2011年底驗收，滿足客戶方提出設計、生產、經營、管理的需求。 信息平臺包含有企業門戶、綜合辦公、設計生產、經營計劃、技術質量、人力資源、檔案管理、信息中心、公司決策、后臺管理等十個子系統。為利用好以前各種硬件平臺的投資，選擇信息平臺運行于windows+sqlserver2005 平臺上，采用.net開發技術。采用四層B/S架構，這四層分別為界面層、外觀層、業務邏輯層及數據訪問層，信息平臺的各種功能基本具有這四層架構。系統的主要功能有：通過一次登錄后可以任意跳轉到其它各子系統的單點登錄；采用目錄樹構件來展現數據的層次結構；活動表單構件方便用戶編輯格式化的文檔數據等服務。這些功能都以Web service接口的方式公開給各應用系統調用，有了這些基礎功能，應用系統就可以省去單點登錄，用戶格式化的信息編輯，信息的層次展現等功能的開發和維護，縮短開發周期和降低開發成本。 信息平臺采用了基于構件的開發方式，基于構件的軟件開發是一種自底向上的，基于包裝好的構件來構造應用系統的方法，它主要包含構件的檢索與獲取，理解與評價構件，修改構件，組裝構件，應用與布署等工作。基于構件的開發涉及到構件的獲取問題，目前構件的獲取主要有三種方式：公司產品庫，第三方構件和自主開發，因為考慮到需求變化時構件的修改問題，我們只采用了從產品庫獲取和自主全新開發兩種方式。 鑒于我們公司具有多年的項目積累，我們從公司的產品庫中選擇合適的構件，對于與需求類似的構件，進行修改后，做好構件的版本記錄。經過我們的分析、篩選和比對，發現以往項目中經常用到的單點登錄模塊，只需要改進一下驗證方式就可以復用到新系統中；接著從共用的底層模塊中，發現了數據庫訪問模塊，只要在靈活性和可替換性方面加強一下，也達到我們復用的標準；最后發現目錄樹和活動表單這兩個模塊，幾乎是最成熟的，除了界面外其它不用修改，可以直接復用。 接下來詳述一下組成系統的主要構件： 1.首先介紹一下，單點登錄構件(SSO)，SSO可以讓用戶登錄信息平臺后，可以跳轉到任意其它應用系統，進入其它系統時無需再次登錄，免除用戶每使用一個應用系統就得再次登錄的重復操作，需要接入的應用系統只要到信息平臺注冊，按照規范配置即可實現這一功能。當用戶進行頁面請求時，就會被SSO捕獲(采用.net 的 httpmodule機制)，SSO首先判斷是當前客戶端是否存在在該用戶的Cookie，如果不存在則跳轉到信息平臺的登錄頁面，要求通過后會跳轉到用戶所請求的頁面，完成一次SSO過程。驗證用戶的合法性，有幾種情況：第一種是對用戶的密碼進行MD5加密后與數據庫進行比對，同時還要對用戶登錄的計算機與數據庫進行比對；第二種是判斷用戶是否插入登錄鑰匙盤。只要有一種驗證通過即視為驗證成功，不再進行下一步驗證，對于這種需求，由于項目初期還不知以后會有多少種驗證方式，所以從構件庫獲取之后，在設計上增加職責鏈的設計模式，以適應增加新的驗證方式提高擴展性。 2.數據庫訪問構件，從構件庫獲取后，抽象出一套規范的數據訪問接口，以后構件的修改不會影響到其它調用的程序。為了解決以后還可以替換成其它類型的數據庫平臺，采用了“倚賴注入”的理念，即抽象工廠模式，通過配置文件配置數據庫操作的具體實現構件(類)，來生成實例，這樣就可以實現以下場景：比如數據庫從 sqlserver2005替換成oracle，只要使用oracle數據庫訪問構件，然后配置在配置文件中，即可以完成不同數據庫平臺的切換，其他程序無須改動，做到平滑過渡，提高系統穩定性。 3.活動表單構件，這個構件是直接從產品構件庫提取出來的，只做了界面調整，為信息平臺的企業門戶內的通知公告、院內新聞、重要精神等等欄目使用，用戶在創建發布的信息時，可以對發布的內容在活動表單編輯器內設置字體、格式、段落等排版信息。同時支持附件上傳功能。 4.目錄樹構件，這個構件也是直接從產品構件庫提取出來，為信息平臺的設計生產的單項設計項目的信息進行構件復用，項目樹結構由六級節點組成。Root根節點為零級節點由項目名稱表示，一級節點由設計階段表示，二級節點由單項工程名稱表示，三級節點由專業表示，四級節點由功能區(工作區、輸入區、提資區、收資區、成品區等)表示，五級節點即葉節點由功能屬性名(圖紙、文字、圖片、其他等)表示；還有人力資源子系統的組織機構樹等。 5.在界面層的設計中，因為構件庫中沒有相應的控件，只好采取自主全新開發，如時間段選擇控件，文本框智能提示控件，基于flash的多文件上傳控件，以及用戶/部門選擇控件。這些控件還提供了日常的數據驗證功能，開發時跟.net服務器控件一樣，拖拉到開發頁面即可，讓開發人員把精力集中在系統的業務功能實現上，而非技術細節，縮短了界面層的開發周期，也為后續項目積累了基礎控件。 該系統采用基于構件的開發方法，從構件庫中獲取構件，并采用了“依賴注入”，抽象工廠，后期綁定等技術，提高擴展性、靈活性和穩定性。對于構件庫沒有的進行了自主全新開發，開發完成后加構件庫，為后續項目開發提供構件。這種開發方法保證了系統質量并按期通過驗收。 雖然從產品構件庫中獲取到大部分的構件，但構件本身的修改不是件容易的事情，如上述所提的單點登錄(SSO)構件，數據訪問構件都需要資深的開發人員采用一些如“依賴注入”，抽象工廠，后期綁定等技術，提高擴展性、靈活性和穩定性；而構件庫沒有用自主全新開發的，比如flash批量上傳文件控件還涉及flash,Ajax等技術，用戶/部門選擇控件對javascript技術的要求也特別高，這就要求構件開發人員的選拔和培訓成了一件緊迫的工作，在以后的項目中會更加重視這一工作，培養合格的構件開發人員，讓更多合格的構件加入到產品構件庫，提高公司的整體開發效率。 目前主流的構件技術標準有三種：Corba，EJB和COM/Dcom/Com+，Corba是OMG組織制定的一種標準，這種標準易于擴充和修改，具有較高的通用性和適應性；EJB是JAVA體系的，憑借JAVA跨平臺的優勢，用EJB技術部署的分布式系統可以不限于特定的平臺Com/Dcom/Com+是微軟公司研發的，主要用于windows平臺，對windows支持度高。 最后展望一下構件技術的發展趨勢，隨著企業業務的開展，信息技術的不斷應用，企業集成的問題越來越突出，構件將向SOA架構靠攏(服務也是一種構件)，構件間通過ESB方式進行通信，實現各應用的松耦合，提高靈活性和擴展性，以支撐不斷變化的企業業務需求。

論基于構件的軟件開發(二)

摘要：
?2011年3月，我有幸參加了統一網管應用平臺（UNMP）項目的開發工作，并擔任系統架構師一職，負責系統的架構設計及核心構件的開發工作。該系統是省移動分公司網絡維護中心委托我們開發的，在該項目立項前，該部門存在大量的第三方應用系統，這些系統之間存在大量重復的功能，所以提出了建設UNMP作為各應用系統的支撐平臺。UNMP主要功能有：單點登錄、用戶管理、集中授權、消息通知、日志管理、告警管理、系統監控、定時服務等。該項目于2011年底通過驗收，滿足客戶方提出的作為各應用系統支撐平臺的需求。 本文以UNMP為例，討論基于構件的軟件開發，簡單說明為什么要用構件開發及獲取構件的方式，接著詳細介紹系統主要的構件以及開發過程，開發策略。文章最后簡略說明幾種構件技術及展望構件技術的發展趨勢。
正文：
?2011年3月，我有幸參加了統一網管應用平臺（UNMP）項目的開發工作，并擔任系統架構師一職，負責系統的架構設計及核心構件的開發工作。該系統是**省移動分公司網絡維護中心委托開發的，項目于2011年底驗收，滿足客戶方提出的作為各應用系統支撐平臺的需求。 以前該部門存在大量各種各樣的應用系統，這些應用系統的開發平臺、架構、語言截然不同，硬件也不盡相同，部門系統維護人員維護的難度很大，各應用系統重復采集數據給網絡帶來額外負擔，也浪費了采集帶寬和資源，系統之間存在大量的重復功能。為解決上述問題，需要建立統一網管應用平臺（UNMP）來有效整合各種應用系統，規范各類開發和維護。同時這個平臺也可以為新增的應用系統提供規范約束和指導，提高開發效率和降低開發成本。 為利用好以前各硬件平臺的投資，選擇UNMP運行于windows+sqlserver2005平臺上，采用.net開發技術。采用四層B/S架構，這四層分別為界面層，外觀層，業務邏輯層及數據訪問層，項目的各種功能基本具有這四層架構。系統的主要功能有：通過一次登錄后可以任意跳轉到其它各系統的單點登錄；用于統一管理各應用系統用戶信息；為各系統提供收發短信/彩信的消息服務；還有日志管理和告警管理；還有為其它功能提供短信、監控、同步用戶、同步工作流待辦待閱信息等的定時服務。這些功能都以webservice接口的方式公開給各應用系統調用，有了這些基礎功能，應用系統就可以省去單點登錄，用戶管理，收發短信等功能的開發和維護，縮短開發周期和降低開發成本。 因為UNMP是個平臺系統，接入的各種應用系統繁多，影響面廣，開發周期短，所以復用性，穩定性和擴展性要求比較高，團隊最終采用了基于構件的開發方式，基于構件的軟件開發是一種自底向上的，基于包裝好的構件來構造應用系統的方法，它主要包含構件的檢索與獲取，理解與評價構件，修改構件，組裝構件，應用與布署等工作。基于構件的開發涉及到構件的獲取問題，目前構件的獲取目前主要有三種方式：自身企業庫，第三方構件和自主開發，因為考慮到需求變化時構件的修改問題，我們只采用了從企業庫獲取和自主全新開發兩種方式。 鑒于公司在電信行業多年的項目積累，我們整理了以往成功實施的項目，形成企業構件庫，針對性的選擇合適的構件，對于與需求類似的構件，進行修改后，做好構件的版本記錄。企業構件庫構建，采用從成功實施過的項目中，抽取共用的，底層的一些模塊，封裝其內部邏輯，為外部提供一致的調用接口，形成可復用的構件。經過我們的分析、篩選和比對，發現以往項目中經常用到的單點登錄模塊，只需要改進一下驗證方式就可以復用到新系統中；接著從共用的底層模塊中，發現了數據庫訪問和日志管理模塊，只要在靈活性和可替換性方面加強一下，也達到我們復用的標準；最后發現的定時服務和短信組件這兩個模塊，幾乎是最成熟的，除了界面外其它不用修改，可以直接復用。 接下來詳述一下組成系統的主要構件： 1、首先介紹一下，單點登錄構件（SSO），SSO可以讓用戶登錄UNMP后，可以跳轉到任意其它應用系統，進入其它系統時無需再次登錄，免除用戶每使用一個應用系統就得再次登錄的重復操作，需要接入的應用系統只要到UNMP注冊，按照規范配置即可實現這一功能。當用戶進行頁面請求時，就會被SSO捕捉（采用.net的httpmodule機制），SSO首先判斷是當前客戶端是否存在該用戶的cookie，如果不存在則跳轉到UNMP的登錄頁面，要求用戶進行登錄，如果存在則傳遞到業務層進行解密，驗證解密后的用戶信息是否合法，用戶類型是否合法，驗證通過后會跳轉到用戶所請求的頁面，完成一次SSO過程。驗證用戶的合法性，有幾種情況：第一種是臨時用戶只跟本地數據庫進行比對；第二種是AD（活動目錄）用戶，則需要調用AD的接口進行驗證；還有一種是省portal類型的用戶，需要調用portal提供的驗證接口。只要有一種驗證通過即視為驗證成功，不再進行下一步驗證，對于這種需求，由于項目初期還不知以后會有多少種驗證方式，所以從構件庫獲取之后，在設計上增加職責鏈的設計模式，以適應增加新的驗證方式提高擴展性。 2、數據庫訪問構件，從構件庫獲取后，抽象出一套規范的數據訪問接口，以后構件的修改不會影響到其它調用的程序。為了解決以后還可以替換成其它類型的數據庫平臺，采用了“依賴注入”的理念，即用抽象工廠模式，通過配置文件配置數據庫操作的具體實現構件（類），來生成實例，這樣就可以實現以下場景：比如數據庫從sqlserver2005替換成oracle，只要實現oracle數據庫訪問構件，然后配置在配置文件中，即可以完成不同數據庫平臺的切換，其它程序無須改動，做到平滑過渡，提高系統穩定性。 3、日志構件和數據庫訪問構件一樣，也規范了一套日志接口，采用“依賴注入”等理念。因為UNMP作業平臺系統，對日志功能要求比較高，如果現有的日志構件表現不佳，需要隨時能替代成其它的日志構件，而不影響現有的程序。 4、定時服務構件和短信構件，這兩個構件是直接從企業構件庫提取出來的，只做了界面調整，定時服務采用windows服務的方式，為注冊的程序提供按時間段，時間點，某月某日，每星期某天等方式執行。利用該構件可以為同步用戶、告警、系統監控、及工作流待辦待閱信息等提供定時執行的機制。短信構件是調用華為iod（短信網關）接口，實現短信的接收和發送，具有多線程，短信隊列，同步控制等功能，第三方應用系統通過調用webservice接口，把短信信息寫入UNMP數據庫，然后由短信構件進行短信的發送和接收。 5、在界面層的設計中，因為構件庫中沒有相應的控件，只好采取自主全新開發，如時間段選擇控件，文本框智能提示控件，基于flash的多文件上傳控件，以及用戶/部門選擇控件。這些控件還提供了日常的數據驗證功能，開發時跟.net服務器控件一樣，拖拉到開發頁面即可，讓開發人員把精力集中在系統的業務功能實現上，而非技術細節，縮短了界面層的開發周期，也為后續項目積累了基礎控件。 該系統采用基于構件的開發方法，從構件庫中獲取構件，并采用了“依賴注入”，抽象工廠，后期綁定等技術，提高擴展性、靈活性和穩定性。對于構件庫沒有的進行了自主全新開發，開發完成后加構件庫，為后續項目開發提供構件。這種開發方法保證了系統質量并按期通過驗收。 雖然從企業構件庫中獲取到大部分的構件，但構件本身的修改不是件容易的事情，如上述所提的單點登錄（SSO）構件，數據訪問構件都需要資深的開發人員采用一些如“依賴注入”，抽象工廠，后期綁定等技術，來提高擴展性、靈活性和穩定性；而構件庫沒有采用自主全新開發的，比如flash批量上傳文件控件還涉及flash、Ajax等技術，用戶/部門選擇控件對javascript技術的要求也特別高，這就要求構件開發人員的選拔和培訓成了一件緊迫的工作，在以后的項目中會更加重視這一工作，培養合格的構件開發人員，讓更多合格的構件加入到企業構件庫，提高企業的整體開發效率。 目前主流的構件技術標準有三種：Corba，EJB和Com/Dcom/Com+，Corba是OMG組織制訂的一種標準，這種標準易于擴充和修改，具有較高的通用性和適應性；EJB是java體系的，憑借java跨平臺的優勢，用EJB技術部署的分布式系統可以不限于特定的平臺Com/Dcom/Com+是微軟公司研發的，主要用于windows平臺，對windows支持度高。 最后展望一下構件技術的發展趨勢，隨著企業業務的開展，信息技術的不斷應用，企業集成的問題越來越突出，構件將向soa架構靠攏（服務也是一種構件），構件間通過ESB方式進行通信，實現各應用的松耦合，提高靈活性和擴展性，以支撐不斷變化的企業業務需求。