【正文】 連接字符串和環(huán)境變量）存儲在外部元數(shù)據(jù)庫（如 XML 配置文件）中，可以在生產(chǎn)環(huán)境中方便地更改這些值，而無需編輯或重新編譯應用程序。有關使用元數(shù)據(jù)（描述數(shù)據(jù)及其環(huán)境的數(shù)據(jù)）的詳細信息，請參閱第 3 章“安全性、運行管理和通訊策略”中的“設計通訊策略” 。● 使用可插入的類型。如果可以使用多種方法來實施某個應用程序邏輯部分，則定義一個接口并讓應用程序加載在運行時實施該接口的相應類是非常有用的。這樣，就可以在部署應用程序后“插入”實施該接口的其他組件，而無需對它進行修改?？梢詫⑼耆?6 / 36定的類型名稱存儲在配置存儲中，并在運行時使用它們實例化對象。在使用這種方法時，必須確保已對配置存儲進行相應的保護，以防攻擊者強制應用程序使用他或她自己設計的組件?！?接口設計。對組件接口進行設計，使所有公用屬性和方法參數(shù)具有相同的類型。通過使用相同的類型，可以減少組件及其使用者之間的相關性。 安全性在設計應用程序時安全性始終是一個主要的考慮事項，尤其是可以通過 Web 訪問應用程序時。安全性決策在很大程度上取決于安全策略。無論安全策略的具體細節(jié)是什么，都應該始終考慮以下建議：● 評估風險。在應用程序設計期間，花一些時間評估每個實施或部署決策所帶來的風險。切記，要考慮內(nèi)部風險以及外部黑客造成的風險。例如，可以使用安全 HTTP 連接來防止客戶信用卡號碼在通過 Inter 傳輸?shù)秸军c的過程中被“竊取” ，但是，如果隨后將信用卡號碼以純文本的形式存儲在數(shù)據(jù)庫中，則未經(jīng)授權的員工就有可能會非法獲取該號碼?！?應用“最少權限”原則。最少權限原則是一個標準的安全性設計策略，可確保每個用戶帳戶“有且僅有”執(zhí)行其必要任務所需的權限級別。例如，如果應用程序需要讀取文件中的數(shù)據(jù)，則應該給它使用的用戶帳戶分配讀取權限，而不是修改或完全控制。不應給帳戶分配多余的權限。● 在每個安全區(qū)域的邊界執(zhí)行身份驗證檢查。應該始終在“入口處”執(zhí)行身份驗證。在確定有效的身份之前，不應允許用戶進程在給定安全區(qū)域中執(zhí)行任何任務?！?仔細考慮用戶上下文在異步業(yè)務過程中的作用。切記，在應用程序異步執(zhí)行業(yè)務任務時，用戶上下文的意義比同步執(zhí)行任務要小。應該考慮對異步操作使用“受信任的服務器”模型，而不是使用模擬/委派方法。 易管理性企業(yè)運行管理策略決定了需要管理的應用程序的特征。應該在應用程序中設計規(guī)范，以便公開運行狀況監(jiān)視、服務級別協(xié)議 (SLA) 驗證和容量規(guī)劃所需的關鍵管理信息。操作管理策略涉及應用程序每時每刻的運行，并涵蓋如異常管理、監(jiān)視、業(yè)務監(jiān)視、元數(shù)據(jù)、配置和服務位置等問題，如圖 所示。27 / 36圖 操作管理策略的各個方面 異常管理異常管理包括捕捉和引發(fā)異常、設計異常、傳遞異常信息以及向不同的用戶發(fā)布異常信息。所有應用程序都應實現(xiàn)某種類型的異常處理來捕捉運行時錯誤。如果可能，應捕捉并糾正異常。如果無法糾正錯誤狀態(tài)，應用程序應為用戶顯示有用的消息，并出于調(diào)試目的提供某種記錄或發(fā)布異常信息的方法。異常管理功能包括：? 捕捉和引發(fā)異常? 設計異常類? 傳遞異常信息? 發(fā)布異常信息? 用戶界面組件中的異常管理? 業(yè)務進程組件中的異常管理? 數(shù)據(jù)訪問組件中的異常管理? 業(yè)務實體組件中的異常管理注意：有關在基于 .NET 的應用程序中處理異常的詳細信息，請參見 MSDN 上的“Exception Management”（異常管理） 。有關 Microsoft 提供的、實現(xiàn)大綱設計的異常管理參考生成塊，請參見 MSDN 上的“Exception Management Application Block for .NET”（.NET 異常管理應用程序塊） 。 監(jiān)視需要規(guī)范應用程序，使操作人員可以觀察應用程序的運行狀況、服務級別協(xié)議 (SLA) 遵從性和伸縮/容量管理。有關如何規(guī)范應用程序的詳細準則，請參見 MSDN 上的“Monitoring in .NET Distributed Application Design”（.NET 分布式應用程序設計中的監(jiān)視） 。28 / 36應用程序可以從以下監(jiān)視類型中獲益：? 運行狀況監(jiān)視：組件運行正常嗎？是否有暫時的鎖定、掛起、進程退出、被阻塞的隊列等？? SLA 遵從性：業(yè)務進程是否在要求的參數(shù)內(nèi)運行？集成的服務是否滿足預期要求？應用程序或服務是否滿足調(diào)用方的性能和運轉要求？? 伸縮管理：是否為組件處理的任務正確設計了用來部署組件的計算機、場或網(wǎng)絡？是否能從可用的資源預測性能？? 業(yè)務監(jiān)視：是否能使業(yè)務進程更加高效？是否能更早地做出重要決定？企業(yè)高效業(yè)務處理的瓶頸是什么？ 通過監(jiān)視應用程序或服務的正確部分，可以回答這些不同的問題。并非所有的監(jiān)視類型任何時候都需要處于活動狀態(tài)。例如，可以決定在計劃應用程序的下一個版本之前監(jiān)視業(yè)務因素。監(jiān)視功能包括：? 業(yè)務監(jiān)視? 用戶進程組件中的監(jiān)視 ? 業(yè)務進程組件和工作流程中的監(jiān)視? 數(shù)據(jù)訪問組件中的監(jiān)視 配置應用程序需要配置數(shù)據(jù)才能在技術上運行。修改策略行為（安全、操作管理和通信）的設置被認為是配置數(shù)據(jù)。 配置數(shù)據(jù)在用戶級、計算機級和應用程序級的 .NET 配置文件中維護。此處存儲的自定義配置可以用任何架構定義，并且可以使用應用程序中的 ConfigurationSettings 類輕松訪問?？紤]配置安全敏感性非常重要，例如不要將 SQL 連接字符串以明文形式存儲在 XML 配置文件中，特別當它們包含 SQL 憑據(jù)時。應該僅限適當?shù)牟僮鲉T訪問安全信息，并且為了增加安全性，可以考慮給信息加上數(shù)字簽名以確保配置數(shù)據(jù)未被篡改。 配置數(shù)據(jù)可以存儲在許多位置，每個位置都有自己的優(yōu)點和缺點：? 應用程序 XML 配置文件：在此處存儲配置數(shù)據(jù)使應用程序客戶端可以離線工作，并且此模型容易實現(xiàn)。對于胖客戶端應用程序，此方法可能會提高更改管理成本，因為它要求所有客戶端具有相同的配置信息。在服務器環(huán)境中，使用 Application Center 服務器或 Microsoft Active Directory 目錄服務，或通過復制批文件，可以很容易地推送配置更改。注意重新加載應用程序配置數(shù)據(jù)需要重新啟動 AppDomain。不過，如果 檢測到配置文件中有更改，它會重新啟動 AppDomain。應用程序配置文件用純文本格式存儲，這可能是不能接受的安全風險。例如，在大多數(shù)方案中，不要在應用程序配置文件中存儲包含用戶名和密碼的連接字符串。? SQL Server 或應用程序數(shù)據(jù)存儲：這是應用程序托管配置數(shù)據(jù)的常見存儲位置，但是對于應用程序元數(shù)據(jù)而言，甚至還有更多的存儲位置。如果在此29 / 36處存儲配置，建議將元數(shù)據(jù)和業(yè)務數(shù)據(jù)分別保存在不同的 SQL Server 數(shù)據(jù)庫中。訪問數(shù)據(jù)庫通常會影響性能，因此應考慮緩存數(shù)據(jù)。? Active Directory：在組織內(nèi)部，可以決定將應用程序元數(shù)據(jù)存儲在 Active Directory 中。這樣可使域上的客戶端能夠使用元數(shù)據(jù)。還可以使用 Windows ACL 保護 Active Directory 中的信息，確保只有授權用戶和服務帳戶可以訪問這些信息。? 構造函數(shù)字符串：如果使用基于 Enterprise Services 的組件，可以將配置數(shù)據(jù)添加到組件的構造函數(shù)字符串中。? 用于特殊情況的其他位置：這些位置包括 Windows Registry、Windows Local Security Authority (LSA) 存儲和自定義實現(xiàn)。它們用于非常特殊的情況，對于計算機和部署機制有額外的應用程序特權要求。? 可能也提供版本控制和部署功能的第三方配置管理解決方案。? ? 頻繁訪問配置數(shù)據(jù)和元數(shù)據(jù)可能會影響性能，特別是當遠程存儲數(shù)據(jù)時。為了防止影響性能，可以在內(nèi)存中緩存應用程序托管配置數(shù)據(jù)和元數(shù)據(jù)。但是，需要確保沒有增加安全漏洞，未向錯誤的應用程序代碼公開敏感信息。如果緩存配置數(shù)據(jù)，最好指定刷新速率和頻率，在預設的時間刷新緩存的數(shù)據(jù)，而不是在相對時間間隔（例如，強迫配置緩存整點刷新，而不是“上次刷新后一小時” ）刷新緩存的數(shù)據(jù)。這有助于操作員在特定的時刻及時了解應用程序所基于的配置數(shù)據(jù)。? 表示層中的配置? 用戶進程組件通常需要以下配置設置：? 到達業(yè)務進程組件和數(shù)據(jù)訪問組件的位置信息。? 資源的連接數(shù)據(jù)（例如，連接字符串或文件路徑） ，這些資源處理保持長期運行的進程的用戶進程數(shù)據(jù)。 服務代理中的配置為使用 Web 服務、消息隊列或其他一些方式連接到外部服務，服務代理需要配置信息。配置架構和數(shù)據(jù)取決于所訪問的具體服務。數(shù)據(jù)訪問組件中的配置數(shù)據(jù)訪問組件通常需要以下信息：? 它們需要具有將邏輯數(shù)據(jù)源名稱映射到物理連接參數(shù)（例如，將“銷售”數(shù)據(jù)庫映射到實際的連接字符串）的能力。? 如果數(shù)據(jù)訪問組件執(zhí)行動態(tài)數(shù)據(jù)路由，需要有配置數(shù)據(jù)來表示路由參數(shù)（例如，客戶區(qū)域） 、算法（例如，散列算法）和路由目標（例如，數(shù)據(jù)庫的連接字符串） 。通常在一個單獨的實用程序組件中打包動態(tài)數(shù)據(jù)路由邏輯。 30 / 36 元數(shù)據(jù)要使應用程序更容易更改運行時條件，可能需要提供有關應用程序本身的信息。將應用程序設計為在某些特定位置使用元數(shù)據(jù)，可以使應用程序更容易維護并且能夠適應更改，而無須付出很大代價進行再開發(fā)或部署?？稍谝韵聝蓚€主要時期內(nèi)在應用程序中使用元數(shù)據(jù)：設計時：例如，可以使用有關數(shù)據(jù)庫的信息生成代碼、存儲過程、.NET 類、甚至是經(jīng)常重復的模式的用戶界面組件。在開發(fā)過程中使用元數(shù)據(jù)可以節(jié)省反應開發(fā)時間、減少團隊之間的通信需要、集中和“保持”專門的技能，而且可以加強設計、命名和實現(xiàn)標準。這樣，生成的組件的行為更容易預測，而且不容易出錯，因此可以提高開發(fā)人員的工作效率。不過，這種方法要求有專門的知識，還需要額外的開發(fā)工作來創(chuàng)建模板和組合模板與元數(shù)據(jù)的代碼。運行時：如果對應用程序中經(jīng)常更改的地方使用適當?shù)脑獢?shù)據(jù)，應用程序可能更容易維護。例如，可以決定從元數(shù)據(jù)中提取用戶界面列表或網(wǎng)格的標頭，從而無須在應用程序中對它們進行硬編碼。在建立組件之間的關系或處理可預測模式（如驗證規(guī)則）時，應用程序也可以利用元數(shù)據(jù)。不過，就性能而言，在運行時使用元數(shù)據(jù)的開銷通常是很大的，因此，應該在應用程序生命周期的早期測試和配置應用程序設計?？梢栽O計組件公開有關它們自身的元數(shù)據(jù)，但僅當應用程序打算使用這些數(shù)據(jù)時才應該這樣做；否則，元數(shù)據(jù)可能會成為安全漏洞。在運行時使用元數(shù)據(jù)時，使用高級技術可以避免性能問題，例如在應用程序正在運行時 使用 .NET 映像類隨時生成代碼并進行編譯。這種設計方法很復雜，由于它所需要的技能和運行時代碼編譯及元數(shù)據(jù)存儲的安全問題，建議僅在最復雜的情況下使用。在大多數(shù)情況下，用 .NET 腳本可以很容易地實現(xiàn)運行時自定義。有關 .NET 腳本的更多信息，請參閱 MSDN 上的“Script Happens .NET”如前面“配置”中論述的那樣，元數(shù)據(jù)可以存儲在多個位置。對于集中式存儲，可以使用 SQL Server 數(shù)據(jù)庫或 Active Directory。如果要沿程序集分布元數(shù)據(jù)，可以在 XML 文件中實現(xiàn)此操作，甚至可以自定義 .NET 屬性。 性能要獲得較好的用戶體驗和有效地利用硬件，應用程序和服務性能是至關重要的。雖然可以在系統(tǒng)建立后通過優(yōu)化系統(tǒng)實施和代碼來提高性能，但一定要在體系結構和設計階段就考慮到性能問題?？赡芤趹贸绦蛟痛_定、開發(fā)、測試等不同階段中執(zhí)行這一過程，以確保達到性能目標或及早調(diào)整預期目標：1. 為特定操作定義可測量的性能要求（例如，在一定利用率下的吞吐量和/或延遲，如“在特定的硬件配置下，平均 CPU 使用率為 70% 時為 50 個請求/秒” ） 。2. 進行性能測試：對系統(tǒng)進行負載測試并搜集配置信息。3. 分析測試結果：應用程序是否達到性能目標？4. 如果應用程序沒有達到性能目標，確定應用程序中的瓶頸。 （有關用于確定性能瓶頸的工具，請參閱此列表結尾引用的文章。 ）31 / 366. 系統(tǒng)外延要求 與廣東移動統(tǒng)一信息平臺（門戶）的整合要求建立新的管理支撐系統(tǒng)時，應與廣東移動統(tǒng)一信息平臺整合。統(tǒng)一信息平臺的整合作用主要包括以下方面：? 統(tǒng)一用戶管理平臺：統(tǒng)一信息平臺作為統(tǒng)一用戶管理平臺，管理著全公司最完整的用戶信息。它的數(shù)據(jù)來源是公司人力資源管理系統(tǒng)，因此信息更新及時、唯一。統(tǒng)一信息平臺再把用戶信息同步給其他應用系統(tǒng)，如綜合應用管理系統(tǒng)。向綜合應用管理系統(tǒng)的用戶信息同步，主要是同步給目錄同步組件，可參加本規(guī)范第 4章“組件的結構與功能”的相關章節(jié)。同步接口的詳細信息，請參見《廣東移動統(tǒng)一信息平臺應用接入規(guī)范》 。? 統(tǒng)一認證平臺：統(tǒng)一信息平臺作為統(tǒng)一認證平臺，為其他應用系統(tǒng)提供了統(tǒng)一的認證服務。這種認證服務體現(xiàn)為以下兩種方式，具體的接口信息請參見《廣東移動統(tǒng)一信息平臺應用接入規(guī)范》 。? 單點登錄（SSO）：用戶訪問統(tǒng)一信息平臺后，可以直接訪問其他應用系統(tǒng)而不需要再次登錄（即實現(xiàn)了單點登錄功能） ，如綜合應用管理系統(tǒng)。? 認證服務：用戶登錄應用系統(tǒng)時，如綜合應用管理系統(tǒng)，不在應用系統(tǒng)本地做認證，而是將認證功能重定向到統(tǒng)一信息平臺（調(diào)用統(tǒng)一信息平臺提供的相應接口，如 web service 接口） ，認證通過后返回確認信息。? 統(tǒng)一信息展示平臺：統(tǒng)一信息平臺作為統(tǒng)一的信息展示平臺，將多個系統(tǒng)中的關鍵信息展示在統(tǒng)一的界面上（典型應用如待辦工作的統(tǒng)一展示） ，提高辦公效率。為此，統(tǒng)一信息平臺提供了相應的接口方式，如 web s