設計複合應用程式：元件設計

本文介紹為複合應用程式開發設計可重用性最大化的元件的一些基本方法。可以使用許多不同的策略提供最合適的元件。

複合應用程式是面向服務體系結構（Service Oriented Architecture，SOA）和上下文協作策略中的關鍵元素。它們為公司和組織提供業務靈活性，讓他們能夠快速響應市場的需求變化。複合應用程式由鬆散耦合的使用者介面元件組成，支援元件之間的通訊。元件可以在多個複合應用程式中重用。

能夠將多種技術組合成一個應用程式，這種能力可以提供巨大的業務價值。它可以保護和擴充套件公司現有的軟體資產，增加業務靈活性。與傳統的應用程式開發方式相比，建立複合應用程式要容易得多，這幫助公司快速且成本高效地響應業務需求。

粗粒度元件之間的這種鬆散耦合是複合應用程式體系結構的基礎。它還使位於不同地點的小組可以相互分享工作成果並進行協作。每個小組只需要瞭解元件的輸入和輸出，而不必掌握其內部邏輯。例如，一個部門正在開發會計應用程式，另一個小組正在開發銷售趨勢跟蹤應用程式。在複合應用程式體系結構中，可以將銷售趨勢跟蹤應用程式中的一些元件新增到會計應用程式中，從而按照會計學的上下文提供相關的資產檢視。同樣，在銷售趨勢跟蹤應用程式中也可以新增會計應用程式中的元件，從而按照資產的上下文提供會計資訊。隨著開發出的複合應用程式越來越多，在整個公司範圍內共享元件的機會會呈指數式增長。這種體系結構的目的就是讓總體大於部分之和。

複合應用程式模型是 IBM WebSphere Portal 開發人員已經熟悉的模型。這種方式已經擴充套件到 IBM Lotus Notes V8 中，這讓 Lotus Notes 開發人員能夠在複合應用程式中以元件形式提供他們的 Lotus Notes 應用程式。IBM Lotus Domino Designer V8 已經可以使用屬性代理，並提供一個更直觀的使用者環境。Lotus Notes V8 還支援插入 Eclipse 元件，所以複合應用程式可以是 Lotus Notes 元件和 Eclipse 元件的任意組合。這適合進行 on-the-glass 整合（將不同元件整合在同一使用者介面中）；如果進行擴充套件，還可以通過屬性代理讓元件可以相互操作。可以使用 Composite Application Editor 或 WebSphere Portal Application Template Editor 定義複合應用程式。

複合應用程式的元件開發不同於傳統的 Eclipse 或 Notes 應用程式開發。這種開發的目標是建立具有足夠靈活性的元件，讓它們可以簡便地部署在應用程式中，而不需要做重大修改。本文討論設計這樣的元件的方法，以及可以考慮採用的最佳實踐。

前提條件

本文假設您熟悉 Lotus Notes 中的複合應用程式。請參考 IBM Lotus Domino Designer Help 中的複合應用程式部分。

教程 “Customer interests composite application sample for IBM Lotus Notes V8” 可以幫助您獲得實踐經驗。它組合出一個基於 NSF 的複合應用程式，其中包含使用元件間通訊的 NSF 元件和 Eclipse 元件。

群策群力

複合應用程式元件的定義非常寬泛。可以做您希望的幾乎任何事情，這非常強大，但是也帶來了不確定性，比如應該做什麼以及如何建立一種標準的開發方法。請記住，本文中提供的元件分類僅僅是提出一種可能的方法。方法是無所謂對錯的，只是是否適合您的問題。如果您認為我們的建議適合您，那麼就採用它們。如果您有其他需求，也可以調整這些方法。

但是，僅僅通過建立複合應用程式，並不能實現這種整合。建立的元件的互操作性可能並不比兩個單獨的 Web 頁面更好。成功地部署元件應用程式體系結構的關鍵是建立一個論壇，讓開發人員在這裡討論不同的開發工作。一定要在組織中建立適當的開發過程來協調這些開發工作，將複合應用程式設計的潛在優勢儘可能轉換為真實的利益。

如果您的公司有與體系結構討論會相似的活動，這可能是適合討論元件重用和互操作性的場合。如果公司比較小，甚至可以指定一個人作為資料型別所有者來專門負責這個方面。這樣的組織方式一定不要影響開發的速度。過分關注開發過程會抵消過程帶來的好處。相反，討論會應該是一個自由討論中心，各個開發小組可以在這裡相互交換想法，並發現從別人的工作成果獲益的機會。

元件的型別

對於元件可以由什麼東西組成，沒有什麼技術限制。從字面上說，元件是一個使用者介面部件，它們具有定義良好的入口點和出口點。為了幫助我們決定要構建的元件，我們來定義幾個元件類別。

複合應用程式能夠共享元件，這模糊了實際應用程式之間的界限。這是非常好的使用者體驗。使用者應該能夠執行他們需要的各種操作，而無需意識到自己從一個領域進入了另外一個領域。在元件開發方面，元件常常來自一個應用領域或者與其相關聯。它們具有互動點，可以通過互動點連線到其他領域；但是，在最靈活的設計中，這些互動是在組裝應用程式時而不是在元件設計階段確定的。在講求實際效果的開發專案中，常常根據應用領域劃分工作任務。在劃分工作時，常常要考慮資源、時間表和交付使用的成果，所以根據應用領域考察設計是比較合理的。

銷售趨勢示例由三個基本應用領域組成：

• 核心銷售趨勢應用程式，它跟蹤公司和銷售趨勢
• 一個討論應用程式，其中包含關於銷售趨勢的討論
• 一個法律應用程式，它跟蹤公司與客戶簽署的合同和修訂協議

以領域為中心的元件

以領域為中心的元件是建立的應用程式的基本部分。在建立一個涵蓋自己領域的功能的複合應用程式時，主要的使用者介面元素可能只與這個領域相關，只在這個領域的上下文中有意義。要確保有一組元件可以支援一個應用程式的所有現有功能，這常常是元件開發的第一個層次。如果要對現有的應用程式進行轉換，一種方法是首先確保在複合應用程式中有對應的功能。這些元件能夠以最快速的方式提供主要功能。這些元件可能在您的應用程式中多次使用，但是不太可能在另一個複合應用程式中使用。因此，為了提供更豐富的功能，這些元件的耦合可以緊密一些。

在 示例應用程式 中，CompanyList、SalesLeadList、SalesLeadDetail 和 SalesLeadEdit 等元件屬於以領域為中心的元件（見圖 1）。

圖 1. 以領域為中心的元件示例

領域上下文元件

以領域為中心的元件是一個應用程式領域的基本部分，而領域上下文元件是輔助部分。這些元件修飾應用程式中的檢視，提供與領域相關的資訊，但是它們採用與上下文相關的方式，或者只提供屬於某一資訊子集的資訊。在傳統的轉換過程中，領域上下文元件是開發的第二個層次。它們不是應用程式的基本工作所必需的，但是它們能夠顯示上下文資訊並減少頁面切換或複製/貼上，從而提高了易用性。因此，在其他複合應用程式中有可能需要它們。如果兩個領域中有共同的元素，那麼這些元件可以以相同方式提供領域相關資訊。

將應用程式轉換為複合應用程式的另一種方法是，首先以適合整合到其他複合應用程式中的方式開發一些上下文資訊元件。這種方法可以在採用複合應用程式體系結構時儘早享受重用帶來的好處。如果應用程式很大而且複雜，那麼整體轉換過程可能需要很長的時間。如果原來的應用程式使用另一種體系結構（例如，由後端系統支援的在文字終端上執行的綠屏應用程式），那麼整體轉換是沒有意義的。但是，正如 Web 服務可以提供對這些後端系統的訪問一樣，可以通過開發領域上下文元件，將資訊從這些系統中取出來（很可能要使用相同的 Web 服務），以便在新的複合應用程式專案中重用。

在 示例應用程式 中，CompanySummary、LeadSummary 和 LeadList ConstrainedByCompany 等元件屬於領域上下文元件。圖 2 說明如何將它們部署在討論和法律應用領域中，從而在它們的上下文中提供相關的核心資訊。

圖 2. 領域上下文元件示例

通用元件和工具元件

在開發複合應用程式時，常常會遇到並不專屬於您的應用領域的元素。開發複合應用程式的任何人都可能需要這些元件。

在示例應用程式中，Pager、Browser、RSSReader 和 MailSearch 等元件屬於工具元件。Lotus Notes 附帶幾個通用元件。例如，Lead Manager 示例應用程式（使用了名稱和地址簿元件）和 Managed Browser。

集中的活動

既然已經有了區分元件型別的框架，我們就來討論圍繞複合應用程式開發的開發過程。

首先，建立一個集中的論壇，讓開發小組能夠發表他們的複合應用程式開發計劃，這樣做的好處是無法估量的。一個小組的應用領域可能與另一個小組的應用領域毫不相關，但是從一個小組的開發工作中得到的經驗教訓可以應用於別的小組。讓各個小組能夠分享計劃並獲得反饋可以改進開發過程。

實現這種廣泛的交流的原因之一是，這可以促使形成複合應用程式開發的 “語言”。設計和開發複合應用程式的過程與其他應用程式開發過程是一樣的。它要求建立需求、規格說明、測試計劃和交付。複合應用程式的特殊之處在於，元件開發可能沒有確定的應用目標，而且可以以各種方式組合出應用程式。通過讓各個小組分享他們的過程（包括如何編寫規格說明、如何開發測試計劃以及如何組織交付），可以分享工作成果並節約資源。本系列後續的一篇文章 “Designing Composite Applications: Managing the Process” 將討論這些問題。

如果公司對專案開發的要求非常嚴格（比如專案必須符合某些法律法規），或者各個工作任務會產生廣泛的影響，那麼論壇可能應該更加正式，而且可能需要批准開發計劃，然後才能進行開發。在要求不這麼嚴格的環境中，批准可能只是個形式。但是，即使只是走個形式，在批准過程中也會交換更多的資訊，這會增加重用的可能性。

這些活動可以幫助開發以領域為中心的元件。但是，對於領域上下文元件幫助更大。因為設計這些元件的目標是在應用領域之外使用，所以公佈它們的開發計劃（以及在開發完成時演示它們的功能）會引起熱烈的反響。您的設計可能非常適合另一個小組的需要。別的小組可能希望做一點兒小改動，或者需要相同的元件，但是使用略有不同的資訊集。另外，因為別人主要關注他們自己的應用領域，所以他們希望知道您在自己的應用程式中如何使用他們的領域上下文元件。

小組集中討論的另一個好處表現在對通用元件和工具元件的決策上。可以向大家推薦元件，讓所有領域都使用它們，而不是隻限於一個領域。一些元件可能最初屬於一個小組。隨著其他小組開始使用它們，它們可能被轉交給其他小組，那些小組會新增他們需要的特性。隨著這個過程的發展，元件的特性會越來越豐富，而且只要保持嚴格的向後相容性，部署它的其他應用程式也會受益。

如果一個小組需要一個有可能跨領域使用的元件，當在集中討論會上提出計劃時，可能會出現另一種有利的局面。如果其他小組對這個元件感興趣，那麼他們可能願意為這個元件投入資源。例如，一個小組可以負責元件的開發，另一個小組負責測試。在大家的共同努力下，可以產生特性更豐富的元件和應用程式。

在示例應用程式中，有一個 Tag Cloud 元件。這個元件最初是為滿足示例應用程式的一些次要需求開發的。但是，另一個小組看到了我們正在使用這個元件，他們認為 Tag Cloud 元件會使他們自己的應用程式受益。他們接管了它的開發，用自己的特性來增強它。因為他們沒有破壞我們的示例應用程式所需的基本特性，所以我們可以繼續使用這個元件，而且從他們新增的特性獲得了好處。

對於討論會，最重要的技術問題是維護一組通用的資料型別。元件相互通訊的方法是將資料通過線連從屬性傳送到動作。如果這些線連的兩端不使用相同的資料型別，那麼線連就無法實現。兩個元件可能都有日期的概念，但是如果定義日期的方式（名稱空間、名稱、型別）不同，它們就無法相互連線。討論會（或者專門的資料型別所有者）可以維護在整個公司範圍內通用的資料型別定義列表。在每個小組公佈他們的開發計劃時，應該識別出屬性和動作所需的資料型別。對於與現有的公司資料型別定義匹配的資料型別，就使用通用定義。新的獨特的資料型別可以新增到公司資料型別定義列表中。

以領域為中心的元件常常只在這樣的元件之間相互通訊。它們定義的許多資料型別可能不會跨領域使用。但是，領域上下文元件在理想情況下會在許多領域中使用。對於這些元件，保持資料型別的一致性是非常重要的。

我們的目標是，儘可能增加元件的重用機會，減少組裝複合應用程式所用的時間，並允許業務使用者通過新增領域上下文元件、通用元件和工具元件，輕鬆地擴充套件和修改現有的複合應用程式。

元件模式

在為複合應用程式開發元件時，有幾種經常出現的模式型別。在為複合應用程式設計元件時，應該首先考慮這些模式。同樣，佈局模式可以幫助您安排元件集合的佈局，應用模式可以幫助確定整個應用程式的結構。

本系列後續的一篇文章 “Designing Component Applications: Design Patterns” 將詳細討論這些模式。

決定元件粒度

在決定將什麼東西實現為元件時，可以採用不同的方法。如果您正在從頭開始設計新的應用程式，那麼選擇前面提到的元件模式之一會有幫助。可以以適當的模式作為基礎，考察自己的應用程式的哪些部分符合這些模式。

對於新的應用程式，另一種有用的方法是反向推導。首先設想出應用程式的外觀和表現，然後判斷出實現這些所需的元件。如果首先用一系列螢幕來描述應用程式，例如在白板上畫出螢幕示意圖，就可以識別出常用的元素。對於那些在幾個應用程式頁面上完全相同或相似的使用者介面元素，可以考慮將它們實現為元件。

下一步是審查您畫出的示意圖，尋找那些屬於其他應用領域或者在其他應用領域中可能有意義的使用者介面部分。按照這種連續的劃分方法，可以將設計轉換為元件。

根據現有的應用程式設計元件既困難也容易。說它容易是因為您已經有了現成的應用程式設計。困難是因為必須在使用現有的東西和提高元件重用性之間進行權衡。

對於 Lotus Notes 應用程式，可以使用一些基本使用者介面型別。後續文章 “Designing Component Applications: Lotus Notes Components” 將詳細解釋一個把討論資料庫轉換為複合應用程式的示例，其中介紹的原理適用於許多 Lotus Notes 應用程式型別。

對於 Eclipse 應用程式，還有一個優勢，因為這種應用程式是基於檢視的，而檢視會直接轉換為元件。Lotus Notes V8 提供了更豐富的互動和重用功能；在將應用程式轉換為 Eclipse 應用程式時選擇的粒度可能不適合複合應用程式。通過使用 Eclipse 檢視（如果希望進一步劃分，也可以使用透檢視），可以應用連續劃分方法派生出元件。

元件之間的通訊

元件通過使用屬性和動作相互通訊。可以按照幾種不同的方式使用元件來實現操作。

屬性

屬性代表傳出的值。最簡單的方法是傳播一個簡單的資料值。例如，如果一個元件包含一系列資料條目，那麼它可以向外傳播一個代表當前選擇的條目名稱的屬性。在傳播這種值時，有多種選擇。資料條目常常包含許多資料項，例如名稱、部件編號、供應商編碼、庫存的數量等等。可以為每個資料項傳播一個單獨的屬性。對於複雜的大資料條目，這種傳播方式會非常複雜。目前的屬性代理實現只允許傳播可以表示為字串的資料條目，不能按原樣傳播複雜的條目。

解決這個問題的一種方法是定義一個執行序列化的方法。例如，可以用一個 XML 資料結構表示複雜條目的細節，然後將 XML 資料結構序列化成字串。Web 服務常常使用這種技術。但是，應該注意這種技術的一些缺陷。首先，每當修改一個資料元素時，都必須傳播整個結構。這種方法只適用於在後端上有關係的設定組。第二，這會減少這個元件與來自其他領域的元件相互操作的機會。儘管各個資料項可能具有相同的型別，但是如果整個資料結構是這個應用領域特有的，那麼其他元件必須瞭解這個資料結構的定義，才能使用它。這會破壞設計的鬆散耦合性質。

還可以用屬性實現事件通知。事件通知只在某些東西發生變化時傳播。例如，執行復雜操作的元件可以傳播它的狀態。當它開始提交時，它可以在狀態屬性中傳播一個值來表示這一情況。其他元件可以監聽這個狀態屬性，當它們連結的元件處於不適當的狀態時，它們可以禁用本身，以避免衝突或無效操作。

為了提高可重用性，各個元件應該避免指定應用程式流。相反，它們應該向外傳播它們的檢視狀態變化，從而將確定應用程式流的任務推遲到組裝時。這樣就可以用一個控制器元件處理各個元件之間的狀態遷移，實現整個應用程式流（同樣，這個任務也推遲到組裝時，而不是在設計時完成，因此提高了元件的可重用性）。

例如，在 Sales Lead 應用程式中，許多元件向外傳播一個稱為 ViewState 的屬性。這個屬性包含這個元件希望傳播到應用程式級的一個預定義值，這個值表示操作的型別或狀態遷移。例如，Company Edit 元件在儲存它之後將這個屬性設定為 #company.save，在單擊 Close 按鈕之後設定為 #company.close。在組裝應用程式時，各個元件被線連到一個頁面切換元件，這個元件將這些狀態通知對映為特定的頁面遷移。

動作

動作表示傳入的值。與屬性一樣，可以按照幾種不同的方式使用動作。

與屬性一樣，最簡單的方法是實現一個簡單的資料接收器。元件可以消費這個屬性並儲存它，供以後的操作使用；還可以執行一個面向資料的操作，比如更新一個編輯框的值。對於這些動作，資料型別直接對應它們代表的欄位。

另一種典型用法是動作直接對顯示產生影響。最常見的形式是，將一個索引傳遞給資訊獲取元件，這個元件查詢對應的資料記錄並顯示內容或內容的子集。產生的結果值還可以通過屬性進一步傳播。這種動作的資料型別通常是惟一 ID 或其他索引型別。對於列表元件，這可能是排序條件或搜尋條件。在其他場合，動作還可以控制元件的顯示模式，或者根據使用者的角色啟用或禁用元件。如果動作是一個索引，那麼它常常採用對應欄位的資料型別。對於更復雜的搜尋字串，可以定義一個特殊的型別；但是，為了提高互操作性，也可以考慮使用通用字串型別。

在本文的示例中，使用動作處理服務型的操作，但是這些服務只能接收一個引數。如果通過元件提供的服務需要多個輸入，那麼怎麼辦？目前，只能向動作傳遞一個引數。支援更復雜的服務有兩種方法。首先，可以採用與處理複雜屬性相同的方法；可以將所需的多個引數序列化在一起，形成一個字串型別的引數。例如，郵件元件可以接收一個包含 mailto: 字串的動作。這個字串實際上包含多個引數，包括 to、cc 和 bcc 地址的列表以及一個主題和郵件體欄位。與序列化的屬性值一樣，這樣做的缺點也是資料型別會成為這個動作所特有的，這會使互操作變得困難。另外，如果輸入值來自不同的元件，那麼將它們組合成單一的序列化字串是很困難的。

另一種方法是建立多個資料接收器動作，它們各自對應一個引數。然後在使用者介面中建立一種操作方式，例如按鈕、熱點或選單右擊。當觸發這個操作時，它獲取以前設定的值，如果所有非可選值都已經設定了，它就執行操作。（如果設定的值不夠，那麼使用者介面可以反映出這一情況。例如，可以禁用某個按鈕。）這種方法的優點是它基於簡單的型別，而且它適用於各種情況，比如在當前上下文中可能無法獲得所有資料，或者資料可能來自幾個元件。

結束語

複合應用程式體系結構使我們能夠將幾種技術組合成一個應用程式，輕鬆地向使用者提供關鍵的應用程式功能。這會大大提高使用者的工作效率。另外，用現有的可互操作元件建立特性豐富的複合應用程式可以提高開發組織的靈活性，讓他們能夠快速且成本高效地響應業務需求的變化。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14751907/viewspace-404349/，如需轉載，請註明出處，否則將追究法律責任。