商務參考體系結構：企業對消費者

第 4 章：物理設計階段
Microsoft Corporation
2001年5月

摘要：本章討論了和商務參考體系結構應用程式 ConsolidatedRetail.com 有關的 Microsoft 解決方案框架 (MSF) 物理設計階段。在邏輯設計階段，專案開發小組將實際的物理設計約束應用到在邏輯設計階段建立的邏輯設計。這項活動的目標是標識一組元件，然後確定哪些元件已經存在以及哪些元件必須建立。在該階段的末尾，將結果記錄在明確定義的技術規範中，該規範將成為構建應用程式的藍圖。

簡介

物理設計階段是將實際的物理設計約束應用到邏輯設計的過渡階段。標識了邏輯元件之後，下一個任務就是分析哪些元件已經存在，哪些元件可以重複使用或進行修改，而哪些元件必須建立。

正如前文所述，物理設計過程是從開發人員的角度考慮的。該階段的成果是一個完整實現方案的設計或藍圖，同時編寫出了技術規範文件，開發小組將使用該文件來構建應用程式。

物理階段可以分為三個更小的任務階段，如下所示：

• 研究：在此階段，開發小組將確定物理基礎結構約束和解決方案需求，並處理這兩者之間的衝突。此外，開發小組還將確定預期的實現技術。
  
  
• 分析/合理化：開發小組將選擇要使用的實現技術，並確定如何滿足定義的業務需求。
  
  
• 實現：開發小組將選擇程式設計模型、指定元件介面並選擇開發語言。

本章的其餘部分將詳細討論這三個任務，並在適當的地方給出示例。

研究工作

物理階段涉及的第一個任務是研究和收集有關以下主題的資訊：

• 物理解決方案需求
  
  
• 物理約束
  
  
• 可供選擇的現有技術

客戶需求暗含在需求文件中，在邏輯階段進一步加以定義；不過開發小組可能需要研究並確定實際的約束和現有的技術。

確定物理解決方案需求

物理解決方案需求是專用於指導基礎結構設計的需求。在第 1 章中，我們定義了以下系統需求：

• 全球化
  
  
• 效能/可靠性
  
  
• 可擴充套件性
  
  
• 可用性
  
  
• 可管理性
  
  
• 安全性
  
  
• 可訪問性

以下章節將對每個主題進行詳細說明。

全球化（國際化）

全球化（或國際化）是開發程式核心內容需要經過的一個過程，在這個過程中，不再是基於單種語言或區域進行功能設計和程式碼設計，同時，編寫的原始碼更便於建立程式的不同語言版本。

全球化使您能將應用程式移植到不同的文化環境。在早期的程式設計中，這僅僅意味著支援多種語言（例如，支援 Unicode），但是現在進行全球化時，還要考慮選擇什麼樣的介面，例如確定顏色、導航佈局以及頁結構等。

進行全球化時，需要仔細審查應用程式或網頁中涉及的一些眾所周知的地理和文化問題。全球化的步驟包括：研究語言和文化問題，請語言專家校驗一些眾所周知的問題，如果可能的話，請特定銷售區域的公司代表校驗一些眾所周知的問題。

要支援這些文化差異，可以定義以下物理需求：

• 在資料庫中使用 nVarChar 而不使用 VarChar
  
  
• 提供自定義介面的能力

效能

效能一般用“系統總吞吐量”和“響應時間”來衡量。

系統總吞吐量

系統總吞吐量使用“每秒事務數 (TPS)”來衡量，反映了系統在執行服務請求的特定集合（稱為事務）方面的能力。對於電子商務應用程式，事務可能由以下依次執行直到結束的事件組成：

• 使用者來到站點。
  
  
• 使用者瀏覽目錄，找到想要的產品。
  
  
• 使用者將產品新增到購物車。
  
  
• 使用者註冊。
  
  
• 使用者結帳。

TPS 是系統每秒可以處理這些事務的最大數量。正如在業務需求中所述的，當使用以下開發配置時，將商務參考體系結構應用程式設計為每小時至少處理 4800 個這樣的事務：

• [(4) PIII 500mhz，1GB RAM，伺服器執行 IIS 和 Commerce Server]
  
  
• [(1) PIII 500mhz，1GB RAM，伺服器執行 SQL Server]

響應時間

響應時間是使用者請求和系統響應之間間隔的時間量，是使用者最關心的效能指標。響應時間通常用一個百分比和響應秒數來表示。例如，“所有請求中的 90% 應在 5 秒之內響應”意味著在使用者認為應用程式的執行出現問題之前，其所發請求中的 90% 必須在 5 秒之內得到伺服器的響應。

商務參考體系結構應用程式要求在 5 秒內響應全部請求中的 95%。

可擴充套件性

可擴充套件性是指新增資源時站點容量增加的能力。從使用者角度來看，這意味著當大量使用者同時訪問站點時，站點仍能提供可接受的響應時間。

我們在以前的章節中已經提過，提高可擴充套件性有兩個方法：“向上擴充套件”和“向外擴充套件”。

向上擴充套件

“向上擴充套件”就是通過採用更好和/或更快的 CPU、更大的 RAM、更快的磁碟等等來增強伺服器的處理能力。這種方法非常有效，尤其是在資料層上，該層上的一些大型資料庫需要相對較強的處理能力。不過，由於硬體成本隨處理能力的加強而按指數增長，因此，伺服器越接近頂端，這種方法就愈加不合算。

向外擴充套件

“向外擴充套件”則是指利用群集（也稱為“Web 領域”）中的多個伺服器來分擔處理工作量。Web 領域在硬體方面的花費更為合算，而且提供了更為靈活、可擴充套件的解決方案。當站點上的負載增加時，可以很輕鬆地將伺服器新增到 Web 領域中。

要啟用向外擴充套件，您必須避免使用伺服器特定的會話記憶體（例如 ASP 中的 Session 物件）保留資訊。其原因如下：

• 使用者會話將依附於特定伺服器（會話相關性），這會破壞動態地將請求分配給伺服器的網路負載平衡策略。此外，還會破壞伺服器領域的可靠性，因為當原伺服器發生故障（並丟失了其記憶體中的會話狀態資訊）時，就無法將使用者會話轉移到其他伺服器。
  
  
• 記憶體資源被前端伺服器耗費在存放使用者會話狀態的細節上，從而減少了可用於處理請求和快取記憶體內容的記憶體。如果一個受歡迎的站點能夠在短時間內吸引大量的使用者，則狀態維護方面的記憶體需求可能非常大。為了部分解決記憶體需求問題，Commerce Server 大量使用了快取記憶體。對配置檔案架構、折扣和商業活動都將進行快取記憶體。

可用性

可用性是指在任意時候客戶機能及時連線和使用資源的能力。

理解高可用性的一種方法是將其與“容錯”相對比。這些術語描述了測量可用性的兩個不同的基準。“容錯”被定義為在 100% 時間內的 100% 可用性（無論處於何種環境）。容錯系統的設計目的是“確保”資源的可用性。

高可用性的資源對於客戶機來說幾乎總是處於運作狀態並且是可訪問的。因此，它不能出現單點故障。伺服器群集和網路負載平衡是使系統資源保持可用的兩種方法。

部署站點之前，應將以下方法組合使用，防止伺服器出現故障：

• 地理位置分散的資料中心。
  
  
• 不間斷的雙重電源。
  
  
• 資料備份。
  
  
• 群集形式的伺服器，多個計算機所起的作用相當於單個伺服器的作用。
  
  
• 資料複製。
  
  
• 網路負載平衡，即由多個相同的伺服器分擔負載以確保可用性、可擴充套件性和完全一致的使用者體驗。

可管理性

可管理性是指執行站點管理任務的能力。對於電子商務應用程式來說，它包括對產品目錄、特價促銷、裝運費用、稅率、使用者帳戶進行配置，以及為站點使用情況、趨勢提供報告機制等等。

如果具有全面的管理基礎結構，業務經理就能對站點進行配置，以根據市場趨勢和競爭對手的活動採取相應的對策。

安全性

如果能確保最基本的窗體的安全性，也就確保了資料或裝置受到保護，防止未經授權的人訪問或使用它們。在電子商務應用程式的環境中，應該保護以下資訊：

• 敏感的使用者資訊
  
  
• 信用卡號
  
  
• 未公開的產品資料

應用程式安全性的設計主要包括三個方面的內容：“身份驗證”、“授權”和“加密”。

身份驗證

有兩種主要的方法可用於分散式解決方案（例如電子商務站點）中的使用者身份驗證。一般是用“假冒/委託”模型和“受託伺服器”模型來描述。

這兩種模型都假定使用了 n 層應用程式。在本示例中，使用者連線到中間層（具體是指 Web 領域），Web 領域依次訪問後端層（具體是指 SQL Server 資料庫）的資料或服務。這兩種方法的不同之處在於用來訪問後端資料的安全帳戶不同。

• “假冒/委託”模型

  在“假冒/委託”模型中，使用者向中間層應用程式提供安全憑據，然後，中間層應用程式使用使用者的安全憑據訪問後端資料庫。中間層應用程式實質上在“假冒”使用者，代表使用者檢索資料。

  圖 4-1 說明了“假冒/委託”模型：

圖 4-1：“假冒/委託”模型

• “受託伺服器”模型

  在“受託伺服器”模型中，中間層應用程式對使用者進行身份驗證，通常是校驗使用者名稱和口令的組合。中間層應用程式認為使用者的身份正確無誤後，它使用“自己的安全帳戶”訪問後端資料庫。除了通過中間層應用程式之外，使用者無權訪問後端資料。在這種方法中，實際上有兩種身份驗證操作。首先，Web 應用程式對使用者進行身份驗證，然後資料庫伺服器對 Web 應用程式進行身份驗證。

  圖 4-2 說明了“受託伺服器”模型：

圖 4-2：“受託伺服器”模型

授權

授權是指對特定使用者或服務授予訪問資源的許可權。使用者通過了身份驗證後，應能從應用程式請求特定的功能。可以向用戶分配許可權或“授權”，以便執行某些任務而不能執行其他任務。在安全環境中，將訪問級別限制為授權的使用者是非常重要的。

安全專家經常談論“最小許可權原理”。這是一個經驗法則，規定使用者應該具有足夠的許可權來執行所需執行的任務，“但不應該具有更多的許可權”。

加密

加密是確保安全的另一種方法，通過對資料進行編碼以防止未經授權的訪問。

根據加密的位置不同，加密可以在許多級別上進行。通常，加密可以在伺服器上、傳輸時或客戶機上進行。

• 伺服器加密

  伺服器上的加密是指對在伺服器基礎結構中儲存和傳輸的資料進行加密的過程。對伺服器基礎結構中的資料進行加密後，就能確保在出現違反安全性的事件時，訪問到的敏感資料由於被加密而毫無使用價值。

  使用者的信用卡資料就是應對資料加密的一個示例。當業務層在資料層中儲存使用者的信用卡資訊時，對該資料進行加密是非常重要的。如果某個黑客侵入了系統，並獲得了對儲存加密的信用卡資訊的表的訪問權，那麼該資訊對於黑客沒有任何用處。如果信用卡資訊未加密，則加重了應用程式對資料安全所負的責任。

• 傳輸加密

  傳輸加密專門用於處理在伺服器和客戶機之間傳送的資料。例如，使用者向伺服器提交 HTML 窗體時，使用者輸入到窗體中的資料使用超文字傳輸協議 (Hypertext Transfer Protocol，HTTP) 通過連線（例如 Internet）進行傳輸，然後由伺服器接收。

  在傳輸過程中，資料可能會被偷竊和篡改，這可以通過在傳輸時對資料加密來解決。在 Internet 上傳輸的資料可以通過以下方式加密：在 Web 伺服器上安裝安全證書，為站點配置安全套接字層 (Secure Sockets Layer，SSL) 埠，使用 HTTP 的加密形式 HTTPS 作為傳輸協議。

  伺服器證書可以從 http://www.microsoft.com/security/（英文）所列的認證機構之一處購買。您可以使用 Microsoft Certificate Services 釋出獨立的證書，這將允許您在單個伺服器上測試 SSL 安全性。請使用 Web Server Certificate Wizard 安裝證書，該向導可以通過 Internet Services Manager 中的站點屬性來訪問。

  構建實現 SSL 的站點時，應該意識到：將使用者從未加密會話定向到加密會話的超級連結或重定向操作必須包含 https:// 字首。這指定了使用者的瀏覽器將使用 HTTPS 與伺服器進行通訊。

• 客戶機加密

  客戶機加密專門用於處理駐留在客戶機上的資料。例如，如果某個檔案是公用的，但它被加密了，那麼只有具有正確的解密金鑰的使用者可以使用該檔案。

  對於一般的電子商務應用程式，客戶機加密不如傳輸和伺服器加密重要，但是某些情況下可能要求使用這種加密方式。

可訪問性

可訪問性是指從多種裝置或瀏覽器訪問站點的能力。Internet 正在以難以置信的速度向前發展，而訪問 Internet 的裝置也變得五花八門。因此，使電子商務應用程式可被多種裝置訪問並且在這些裝置上正常執行是一個非常艱鉅的任務。

支援多個客戶機的關鍵是將表示形式從內容中分離出來。許多方法可以做到這一點，其中包括編寫 ASP 頁中的邏輯來根據客戶機生成不同的響應，或將不同裝置重定向到替代站點。不過，將表示邏輯從內容中分離出來的最佳方法之一就是使用 XML。如果資料可以用 XML 來表示，那麼可以使用 XSL 樣式表為特定型別的客戶機呈現資料。通過應用不同的樣式表，可以為不同的客戶機表示同一內容。圖 4-3 說明了這個概念。

<iframe border="0" frameborder="0" height="230" marginheight="0" marginwidth="1" scrolling="yes" src="/china/msdn/images/raoverview15.gif" width="550" alt=""></iframe>

圖 4-3：將表示形式從內容中分離出來

確定可供選擇的現有技術

可供選擇的技術是指解決方案中可以使用的技術、產品或服務。利用現有的技術來實現功能在經濟上經常是很合算的，這樣就不必另外構建這些功能了。例如，構建 Web 應用程式時，您需要一個作業系統作為解決方案的基礎，但是沒有必要自己構建一個作業系統。

既然在每次構建應用程式時沒有必要自己構建一個作業系統，同樣也就沒有必要自己構建 Web 解決方案本身的所有部分。許多專家都認為：未來的整個應用程式將使用現有的服務來構建，這些服務只需重新加以組合就可構成一個應用程式。

因此，收集有關在解決方案中可以使用哪些技術的資訊很重要。在物理設計階段涉及的下一個任務中，設計小組將分析該資訊，並確定哪些技術（如果有的話）可以滿足正在討論的特定應用程式的需求。

作業系統

任何現代的應用程式都是在作業系統之上構建的。作業系統不僅提供了與硬體通訊的介面，還提供了構建應用程式的公共框架。選擇一個支援面向物件的方法和公共框架（應用程式可以在該框架上執行和通訊）的作業系統是很重要的。

Windows 2000 Server 平臺

Microsoft® Windows 2000 Server 為應用程式開發人員提供了一套內容豐富的功能。Internet 上許多主要的電子商務站點都是在 Windows 2000 上執行的，其中包括 Buy.com、BarnesAndNoble.com、Dell.com 和 Intel.com。

Internet 服務

基於 Web 的應用程式的另一個核心部分是 Internet 服務。基於 Web 的應用程式需要一個 Internet 服務平臺，該平臺負責基本的 Web 服務，例如響應客戶機的 HTTP 請求、HTTPS 請求和其他請求。一個好的 Internet 服務平臺還應該提供站點管理能力和動態內容程式設計模型。

Microsoft Internet Information Services

Microsoft® Internet Information Services (IIS) 是內置於 Windows 2000 中的 Web 伺服器。IIS 提供了一個內容豐富的 Internet 服務軟體包，包括 ASP、DAV、Web Folders、FrontPage Extensions、FTP、多站點宿主以及其他支援。

表示服務

正如以前在“可訪問性”一節中提到的，使內容和表示形式分離是非常重要的，只有這樣才能從多個客戶機訪問內容。進行這種分離對於簡化全球化工作也是非常重要的。

正如以前所述，將表示邏輯從內容中分離出來的一種方法是同時使用 XML 和 XSL。除了同時使用 XML 和 XSL 之外，還可以根據諸如 Browscap.ini 檔案、USER_AGENT 字串等等之類的實體，在 ASP 頁自身中構建複雜的頁邏輯。

Microsoft XSLISAPI 過濾器

可以實現表示服務功能的一個備選技術是 Microsoft® XSLISAPI 過濾器。ISAPI 代表 Internet 服務應用程式程式設計介面，是 IIS 的基礎。篩選器放置在 ISAPI 之上，並在 Web 伺服器接收客戶機或服務請求時提供相應的功能。例如，ASP 引擎 (ASP.dll) 是在 ISAPI 之上執行的擴充套件。

XSLISAPI 過濾器用於截獲所有對具有 XML 或 PASP 檔名擴充套件的文件的請求。PASP 檔名擴充套件專用於與 XSLISAPI 過濾器一起使用的應用程式。具有該擴充套件的檔案被認為是標準的 ASP 檔案（具有某些限制），這些檔案可以生成有效的 XML（而不是 HTML）輸出。然後，根據將 ISAPI 過濾器應用於直接請求的 XML 檔案的相同規則，轉換 PASP 指令碼的輸出內容。

圖 4-4 說明了 XSLISAPI 過濾器的概念：

<iframe border="0" frameborder="0" height="260" marginheight="0" marginwidth="1" scrolling="yes" src="/china/msdn/images/raoverview16.gif" width="550" alt=""></iframe>

圖 4-4：XSLISAPI 過濾器功能

資料服務

對於電子商務解決方案的構建而言，具備儲存、檢索和管理資料的功能也很重要。這些服務被封裝到一個數據庫伺服器中。對於企業資料庫伺服器來說，效能高、併發性好以及具備可擴充套件性是非常重要的。

SQL Server 2000

Microsoft® SQL Server 2000 是一種 SQL 資料庫伺服器，它提供了企業級效能、可擴充套件性和良好的併發性。它還提供了對 XML 的豐富支援、嚴密的安全性以及功能強大的分析工具。

商務平臺

如果從頭開始構建一個企業電子商務解決方案，將會耗費大量的時間和人力物力資源。如果充分利用現有產品中的電子商務功能，則會顯著縮短整個程式的開發時間，節約大量開發費用。

Microsoft® Commerce Server 2000 就是充分利用現有功能開發的。

Commerce Server 2000

Commerce Server 2000 是一個綜合性產品，它將電子商務解決方案的許多功能封裝到一個軟體包中。Commerce Server 2000 提供了高階的管理功能、較強的可擴充套件性和良好的效能。有關詳細資訊，請訪問 Microsoft Commerce Server 網站，其 URL 是：http://www.microsoft.com/commerceserver（英文）。

分析/合理化

物理設計階段的研究工作完成之後，緊接著要進行分析和合理化方面的工作。分析和合理化是指對研究過程中收集的資訊進行分析，並基於這些資訊作出決策。

使用現有的技術

當設計小組考慮使用現有技術時，必須權衡所有可能影響解決方案的因素。以下列出了可能的因素，但不一定全面：

• 能力：該技術是否能實現業務功能？
  
  
• 所有權成本：該技術在經濟上是否合算？需要考慮產品、開發、升級、許可證、部署和運營方面的費用。
  
  
• 經驗：該技術要求開發人員具有哪些經驗和專業技能？是否會有培訓費用？是否有未知的費用？
  
  
• 成熟和創新：該產品是否是成熟的？它是否已被市場接受？該產品是否有創新性，是否使用了最新的技術？它是否仍是流行的？
  
  
• 部署：該技術是否難以實現？
  
  
• 可支援性：該技術是否可以獲得支援？
  
  
• 體系結構：該技術是否實現了一個可接受的體系結構？該體系結構是否滿足企業的需求？
  
  
• 可擴充套件性：該技術是否可以擴充套件以滿足發展要求？
  
  
• 互操作性：該技術是否可以和組織中現有的系統協同工作？
  
  
• 效能：該技術是否可以提供所需的效能？
  
  
• 可靠性：該技術是否可以滿足應用程式的可靠性需求？
  
  
• 可用性：該技術是否可以處理應用程式需求，而不會導致解決方案失敗？
  
  
• 可管理性：該技術是否易於管理？
  
  
• 安全性：該技術是否符合安全性需求？
  
  
• 標準相容性：該技術是否與公認的標準相容？

其他因素，例如專案時間表和預算約束以及可能牽涉到的其他內部專案，都應該考慮在內。

Windows 2000 Server

Windows 2000 Server 是商務參考體系結構的作業系統，因為它提供了一套專門為企業應用程式設計的功能。其中包括以下功能：

• 伺服器型別的選擇：Windows 2000 Server 平臺可在多種伺服器上執行。在商務參考體系結構解決方案的環境中，應用程式既能向上擴充套件也能向外擴充套件是非常重要的。根據應用程式負載需求，組織可以選擇在兩個或多個執行 Windows 2000 Server 或 Windows 2000 Advanced Server 的伺服器上部署解決方案。要獲取最佳效能並允許將負載分佈在多個伺服器上，請使用 Microsoft 2000 Datacenter Server 網路和網路負載平衡 (NLB)。
  
  
• 可擴充套件性：通過使用 Microsoft Windows 2000 群集服務和網路負載平衡，Windows 2000 Advanced Server 和 Datacenter Server 可以進行向外擴充套件。

通過使兩個伺服器運行同一應用程式、共享公共的儲存機制，群集服務確保了連續的服務。如果這些伺服器之一出現故障，另外一個可以接管。由於構建了系統基礎結構中的冗餘，應用程式就可以使停機時間降為零。

圖 4-5 說明了群集的概念。

圖 4-5：群集形式的伺服器

Windows 2000 Advanced Server 和 Datacenter Server 還可以通過 NLB 進行向外擴充套件，在這種方法中，將多個伺服器作為具有單個 IP 地址的單個單元顯示，應用程式負載均勻分佈在這些伺服器上。當 NLB 設定中的一個伺服器出現故障時，NLB 自動檢測出現故障的系統，將其負載轉移到其他系統，然後重新啟動計算機。

圖 4-6 說明了 NLB 的概念。

圖 4-6：網路負載平衡

• 可用性：通過使用 Windows 2000 Advanced Server 或 Windows 2000 Datacenter Server 中的群集服務和 NLB 服務，Windows 2000 Server 提供了具有高可用性的解決方案。將 NLB 服務和群集服務一起使用可以消除單點故障。
  
  
• 可靠性：Windows 2000 Server 平臺實現了“5 個 9”的可靠性，即確保了正常執行時間高達 99.999%，這相當於每年的停機時間小於 5 分鐘。在企業電子商務環境中，停機意味著損失幾百萬美元的直接收入，還會給客戶帶來煩惱、招致他們的抱怨。因此，可靠的作業系統是企業解決方案不可分割的一部分。
  
  
• 效能：Windows 2000 Advanced Server 和 Datacenter Server 實現了對稱多處理 (Symmetric Multiprocessing，SMP) 支援，它使伺服器有效用於 Advanced Server 的處理器高達 8 個，用於 Datacenter Server 的處理器高達 32 個。此外，Advanced Server 還包含增強的記憶體功能，使伺服器可具有高達 8GB 的記憶體；對於 Datacenter Server，允許伺服器的記憶體達到 64GB。
  
  
• 可管理性：Windows 2000 Server 提供了一套種類繁多的工具，允許您管理網站並連線 Microsoft Management Console (MMC)，以便在一個集中的位置管理伺服器功能。Windows 2000 中的某些管理功能包括事件記錄、效能監視、終端服務以及 Windows 管理規範 (Windows Management Instrumentation，WMI)。
  
  
• 安全性：Windows 2000 提供了一個安全的環境，通過 Active Directory、安全性/身份驗證協議以及通訊加密，嚴格控制對檔案或服務的訪問。
  
  
• 元件服務：Windows 2000 COM+ 服務為開發人員和管理員提供了應用程式功能。這種內建的功能允許開發分散式事務應用程式，而不必開發支援最小單位的事務或非同步操作的底層基礎結構。您可以在以下位置查詢有關 Windows 2000 Server 的詳細資訊：http://www.microsoft.com/Windows2000（英文）。

Microsoft Internet Information Services (IIS)

Microsoft IIS 隨 Microsoft Windows 2000 一起提供，它提供了使用 Internet 提交內容的豐富平臺。由於 IIS 完全是在作業系統級別上整合，因此它允許開發和部署直接寫入計算基礎結構中的解決方案。

IIS 為商務參考體系結構解決方案提供了 Internet 服務，因為它隨作業系統一起提供並具有內容豐富的功能集。兩個關鍵的 IIS 功能是 Active Server Pages (ASP) 和 Internet 服務應用程式程式設計介面 (ISAPI)。

XSLISAPI

XSLISAPI 過濾器為商務參考體系結構解決方案提供了表示服務。使用 XSLISAPI 過濾器後，內容可以和表示形式完全分離，從而允許自定義內容傳送而無需修改 ASP 程式碼。

如果不想同時使用 XML 和 XSL，還可以使用另一方法：在 ASP 頁本身中構建複雜的頁邏輯。不過，此方法有兩個主要的缺點：第一，程式碼中複雜的顯示邏輯可能難以管理；第二，執行這種邏輯需要龐大的開銷。

XSLISAPI 截獲對具有 XML 或 PASP 檔案擴充套件的文件的所有請求。PASP 檔名擴充套件專用於與 XSLISAPI 過濾器一起使用的應用程式。具有該擴充套件的檔案被認為是標準的 ASP 檔案（具有某些限制），這些檔案可以生成有效的 XML（而不是 HTML）輸出。

然後，根據發出請求的裝置，XSLISAPI 過濾器使用 XSL 樣式錶轉換 PASP 或 XML 頁的 XML 輸出，將轉換後的輸出內容傳送給客戶機。

使用 XSLISAPI 過濾器還有另一個好處，即能按不同的技能組分配相應工作量，從而使開發過程更易於管理。例如，圖形設計人員可以按自己的介面規範建立 XSL，而 ASP 開發人員只需要考慮如何將正確的資料傳遞到介面。

SQL Server 2000

SQL Server 2000 為商務參考體系結構解決方案提供了資料服務。它提供了一個完整的企業資料庫解決方案，Commerce Server 2000 將依賴於它的資料服務。對於許多電子商務解決方案，只需要在 Windows 2000 Datacenter Server 上安裝一個群集形式的 SQL Server 即可提供所需的可擴充套件性級別。對於儲存資料量極大的站點，可以在多個伺服器上建立 SQL Server 資料庫，並用“分散式分割槽檢視”來實現跨物理伺服器的資料存取與更新。

Commerce Server 2000

開發小組之所以選擇 Commerce Server 2000，是因為它是為 Windows 2000 平臺構建的，並且為電子商務應用程式提供了一套內容豐富的開發、部署和管理工具。Commerce Server 提供的大約 80% 的物件是在邏輯階段定義的，開發所需的費用很低。這些物件是作為可用於 ASP 頁的 COM 物件實現的。

Commerce Server 2000 提供了以下功能：

• 與其他服務和軟體功能整合：因為 Commerce Server 2000 是專門為 Windows 2000 設計的，因此其體系結構可以和作業系統完全整合。Commerce Server 充分利用了 Windows 2000 Server 中的 COM+ 功能，為企業電子商務應用程式提供了堅實的基礎。

  Commerce Server 還可以和 Microsoft® BizTalk™ Server 很好地整合，以便降低某些流程管理功能和外部通訊的負擔。

• 管道元件：“管道元件”是一組可配置的自定義 COM 物件，它們被依次呼叫來執行特定的業務流程。在 Commerce Server 解決方案中，大多數自定義業務類可以作為管道元件實現，以便可以用簡單的方法來管理業務流程。（管道元件只不過是實現人們熟知的介面 (IpipelineComponent) 的一些 COM 元件）。這樣就允許 Commerce Server 將管道元件標識為適合於 Commerce Server 的元件，然後可以被管道呼叫。

  在參考體系結構應用程式中，管道元件用於處理諸如“客戶訂單處理”這樣的流程，並確保按順序執行處理訂單所需的任務。

• 管理基礎結構：為電子商務站點設計和構建管理框架不僅要耗費大量資源，而且其工作量一般要大於電子商務應用程式本身的開發工作量。Commerce Server 的管理基礎結構是吸引人們最終使用 Commerce Server 的主要因素。

  Commerce Server BizDesk 隨 Commerce Server 一起提供。BizDesk 是基於 DHTML 的應用程式，在 IE 5.5 或更高版本上執行，允許管理員遠端管理拍賣、促銷活動、目錄、訂單和使用者，並提供了一套內容豐富的分析工具。

  因為 BizDesk 是完全基於 DHTML 的，它還可以用於遠端管理在 Commerce Server 之上構建的電子商務解決方案。這種方法將 BizDesk 應用程式負載置於客戶機上，不會影響電子商務站點的效能。

滿足業務需求

確定了可以使用的現有技術之後，開發小組必須確定這些技術如何滿足以前提到的業務需求。為了滿足這些需求，開發小組必須就工具、過程和方法作出某些關鍵決策。應該能在必須滿足的特定業務需求的環境中檢視這些決策。

全球化

正如以前提到的，全球化是指將應用程式移植到不同文化環境中的能力。為了滿足該需求，提供給使用者的內容和表示形式必須進行“全球化”。在全球化期間，可以將內容分為以下兩種型別：

• 靜態內容 — 介面上可以找到的內容以及介面本身。
  
  
• 動態內容 —“動態構建”並顯示給使用者的內容。

以下各個小節說明了涉及的問題以及對兩種內容全球化所作出的關鍵決策。

靜態內容

靜態內容包括介面上的文字和介面本身，必須針對指定的文化或語言進行本地化。XSLISAPI 過濾器是這樣進行本地化的：允許開發小組對於不同語言使用不同的介面設計，然後將應用程式部署為不同的網站或不同的虛擬目錄。通過使用該方法，使用者可以選擇自己的語言，然後重定向到相應的站點。

注意：參考體系結構應用程式並未進行全球化；不過，該應用程式使用了 XSLISAPI 過濾器，因此具有實現全球化的能力。

動態內容

動態內容由應用程式“動態”生成的內容組成。

如果應用程式將要支援不同語言，它必須支援不同的字符集。Unicode 標準是包含世界上所有語言的字元的字符集。使用 Unicode 標準確保了所有語言可以在動態資料中表示。要支援 Unicode 標準，所有儲存字元資料的資料庫欄位必須使用諸如 nVarChar、nChar 等等的資料型別。同時，業務層必須支援 Unicode 的使用。

因此，商務參考體系結構解決方案在整個應用程式中始終使用 Unicode 標準。

效能

要獲得最佳效能，設計小組必須作出多個關鍵決策。首先，要使系統總吞吐量（即應用程式的總體效率和效能）最大化，為此設計小組應解決以下關鍵問題：

• 封送
  
  
• 語言選擇
  
  
• 非同步處理

使封送最小化

提高系統吞吐量的一種方法是使封送最小化，要做到這一點，最好的方法是減少網站對其他位置上的元件的遠端過程呼叫。許多電子商務站點駐留在專用 Web 伺服器的領域中，而業務元件則位於單獨的應用程式伺服器群集中。雖然這個體系結構可有效確保系統的安全性，尤其是當應用程式伺服器通過防火牆或包過濾交換機與 Web 領域分開時更是如此；但是該體系結構將對響應時間造成負面影響，因為對元件的每次呼叫都必須通過網路連線進行封送。

商務參考體系結構應用程式將元件部署在網站所在的同一伺服器上，因此它避免了跨網路的封送，縮短了響應時間。（Commerce Server 提供了參考體系結構應用程式使用的大多數業務元件，這些元件將安裝在 Web 伺服器上。）

語言選擇

語言選擇也會影響效能。例如，雖然為 Commerce Server 管道建立的元件可以用指令碼語言來編寫，但是對於企業應用程式，元件應該使用更低階的語言（例如 Microsoft® Visual Basic® 開發系統或 C++）來構建以獲得最佳效能。雖然類似於 ADO 這樣的元件在 Visual Basic 元件和 C++ 元件中執行的速度幾乎相同，但是複雜的業務例程在 C++ 中執行得更快一些。因此，選擇 C++ 作為商務參考體系結構應用程式中所有元件的構建語言。

非同步處理

為了使響應時間最小化，許多過程應被設計為非同步執行。例如，在使用者結帳時，在他收到介面響應之前，不必等待系統傳送電子郵件進行確認。

可擴充套件性

解決可擴充套件性問題可能是一個非常艱鉅的任務。擴充套件應用程式的第一個方法是向上擴充套件，主要是為單個伺服器配置效能更好的硬體，從而提高速度。對於向上擴充套件來說，雖然所需考慮的設計因素相對較少，但是這種滿足需要的方法過於昂貴，因為硬體價格隨效能呈指數上升。

解決可擴充套件性問題的另一個方法是新增更多的伺服器，這種方法被稱為“向外擴充套件”。雖然向外擴充套件在硬體方面更為合算，但是它需要考慮更多的設計因素。正如以前所討論的，向外擴充套件的最大問題是維護會話資訊。

為了成功進行向外擴充套件，商務參考應用程式應滿足以下要求：

• 不使用 ASP Session 物件來維護會話狀態，因為它引入了伺服器會話親合力，並要求 IIS 維護記憶體中的會話狀態。
  
  
• 在 Commerce Server 物件的協助下，兩個頁請求之間的使用者會話狀態被儲存到資料庫中，並可被新的頁請求檢索。雖然這種會話維護方法對於每個頁請求來說導致了某些額外的資料庫開銷，但是它可以很好地滿足站點的可擴充套件性需求。單個高階資料庫伺服器（或群集）可以為整個前端伺服器領域提供狀態儲存服務。
  
  
• 當用戶登入時，會將一個每會話 cookie 傳送給使用者，並作為“查詢欄位”來檢索相關使用者帳戶的狀態資料。每會話 cookie 不儲存在使用者的硬碟上，因此即使在最具安全意識的使用者瀏覽器上也可以啟用它們。如果在使用者瀏覽器中禁用了每會話 cookie，使用者將無法登入到站點。

可管理性

如果選擇 Windows 2000 Server 和 Microsoft Commerce Server，將會擁有強大的管理基礎結構。正如以前所述的，Commerce Server 提供了 BizDesk 中的功能強大的管理介面，而 Windows 2000 通過 Microsoft Management Console 和其他元件也提供了功能強大的管理介面。

安全性

為了滿足為參考體系結構應用程式定義的安全性需求，設計小組就以下問題作出了選擇：

身份驗證

在“假冒/委託”和“受託伺服器”這兩個可用的模型中，設計小組選擇了“受託伺服器”模型作為商務參考體系結構應用程式的身份驗證方案。

因為“假冒”模型要假冒每個使用者，因此解決方案必須為訪問站點的每個使用者管理帳戶。在基於 Intranet 的小型應用程式中，使用者很少，並且限制是基於使用者的，因此“假冒”模型可以很好地執行；但是，在較大的解決方案中，“假冒”模型很快會難以控制。因此，設計小組選擇了更為簡單的“受託伺服器”模型，它提供了更好的效能，管理起來也更為方便。

授權

為了遵循物理階段的“研究”部分中所述的最小許可權原理，設計小組是這樣選擇部署和設計方案的：

• IIS 虛擬根目錄許可權：部署後，應將站點設定為對虛擬根目錄具有隻讀許可權。
  
  
• NTFS 許可權：部署後，用於匿名訪問的 Windows 帳戶對包含 Web 應用程式檔案的資料夾只具有隻讀許可權。
  
  
• 匿名客戶的許可權：商務參考體系結構解決方案應使用 cookie 來標識未進行身份驗證的使用者，當用戶希望結帳或訪問任何配置檔案管理頁時，應將他們重定向到“登入”頁。
  
  
• 已驗證客戶的許可權：即使是通過了身份驗證的使用者，也應該對他們加以適當限制。例如，系統管理員可以使用 Commerce Server BizDesk 工具，通過對使用者隱藏或只允許只讀許可權，限制對特定配置檔案設定的訪問。

至於資料庫本身，存在的授權問題就更多。使用者對資料庫具有的唯一直接許可權是分配給中間層應用程式（本示例中是 Commerce Server）的帳戶具有的許可權，且該帳戶許可權應被限制為向站點提供資料服務所需的最小許可權。因此，語句許可權（例如 Drop Table）未分配給該帳戶。

加密

作為一個應該易於安裝和檢查的示例應用程式，商務參考體系結構應用程式沒有實現加密。不過，在電子商務系統產品中，傳輸諸如口令或信用卡細節這樣的敏感資料時，應該使用加密會話。

雖然在電子商務產品環境中加密是必要的，但是在傳輸不敏感的資料時，應避免對連線使用 SSL。這是因為建立加密會話時需要一定的開銷，其中涉及將伺服器的公開金鑰傳送到瀏覽器，以及生成和交換加密會話所使用的會話金鑰。

瀏覽器獨立性

參考體系結構應用程式使用 XSLISAPI 過濾器來滿足瀏覽器的獨立性需求。它提供了將內容和表示形式分離的一流機制，這對於合理處理不同瀏覽器的功能非常必要。

實現

物理階段的最後一步是將有關約束、需求和技術方面的決策應用到邏輯設計，並實際定義物理實現方案。在此階段中，將確定程式設計模型、元件介面和每個元件的內部結構。

標識元件

商務參考體系結構的各個元件將在此“開發人員指南”的第二部分中進行詳細討論。將在該部分中說明編碼方法、使用的元件，以及程式碼片斷和它們的定義。有關詳細資訊，請參考程式碼本身提供的開發人員註釋。

建立規範

在“實現”階段結束時，開發小組必須將作出的決策文件化，形成一個詳細的技術規範。該文件將成為構建應用程式的藍圖，開發小組在組建專家組、編制一覽表、分配任務及建立測試和部署計劃時，都要用它作參考。

總結

本章介紹了確定應用程式實際將包含哪些元件、使用哪些技術的物理設計階段，該階段可細分為三個更小的階段；並概要說明了開發商務參考體系結構應用程式 ConsolidatedRetail.com 期間所作選擇的依據。在整個專案開發週期中，物理設計階段的最終目標是將實際的物理設計約束應用到邏輯設計，並編寫出一個合理的技術規範來指導開發工作。

本指南的下一部分將著重介紹在“商務參考體系結構：企業對消費者”應用程式中提供的實際程式碼。正如以前所述的，此應用程式是作為一個參考示例開發的，在作為產品使用時需要進行一些修改。