1. 軟件架構概述
從需求分析到軟件設計之間的過渡過程稱為軟件架構。只要軟件架構設計好了，整個軟件就不會出現坍塌性的錯誤，即不會崩潰。
架構設計就是需求分配，將滿足需求的職責分配到組件上。
軟件架構為軟件系統提供了一個結構、行為和屬性的高級抽象，由構件的描述、構件的相互作用(連接件)、指導構件集成的模式以及這些模式的約束組成。
軟件架構不僅指定了系統的組織結構和拓撲結構，并且顯示了系統需求和構件之間的對應關系，提供了一些設計決策的基本原理。
解決好軟件的復用、質量和維護問題，是研究軟件架構的根本目的。
軟件架構設計包括提出架構模型，產生架構設計和進行設計評審等活動，是一個迭代的過程。架構設計主要關注軟件組件的結構、屬性和交互作用，并通過多種視圖全面描述特定系統的架構。
軟件架構能夠在設計變更相對容易的階段考慮系統結構的可選方案，便于技術人員與非技術人員就軟件設計進行交互能夠展現軟件的結構、屬性與內部交互關系。
軟件架構是項目干系人進行交流的手段，明確了對系統實現的約束條件，決定了開發和維護組織的組織結構，制約著系統的質量屬性。
軟件架構使推理和控制的更改更加簡單，有助于循序漸進的原型設計，可以作為培訓的基礎。
軟件架構是可傳遞和可復用的模型，這通過研究軟件架構可能預測軟件的質量。
架構設計確定了整體架構及被使用的軟件和硬件的布局。架構設計是一個非常復雜的過程，通常由經驗豐富的架構設計師和顧問來完成。第一步是將非功能性需求細化為更詳細的需求，然后用于幫助選擇要使用的架構以及每個設備上部署的軟件構件。在一個客戶機-服務器架構中，還需要決定是使用兩層、三層還是N層架構。然后，需求和架構設計被用來開發硬件和軟件規格說明。在設計架構時主要有四類非功能需求比較重要：
- 操作需求確定了系統執行所需的運行環境以及這些環境可能隨時間發生哪些變化；
- 性能需求主要關注如響應時間、容量和可靠性等非功能性需求問題；
- 安全需求是保護信息系統免受無論是否是有意的行為而造成損毀和數據丟失的能力；
- 文化和政治需求取決于系統將要被使用的國家。
軟件架構設計與生命周期
- 需求分析階段。需求分析和SA設計面臨的是不同的對象:一個是問題空間;另一個是解空間。從軟件需求模型向SA模型的轉換主要關注兩個問題:如何根據需求模型構建SA 模型。如何保證模型轉換的可追蹤性。
- 設計階段。是SA 研究關注的最早和最多的階段，這一階段的SA研究主要包括:SA 模型的描述,SA 模型的設計與分析方法，以及對SA設計經驗的總結與復用等。有關SA 模型描述的研究分為3個層次:SA的基本概念(構件和連接子)、體系結構描述語言ADL、SA模型的多視圖表示。
- 實現階段。最初SA研究往往只關注較高層次的系統設計、描述和驗證。為了有效實現SA設計向實現的轉換，實現階段的體系結構研究表現在以下幾個方面。
- 研究基于SA 的開發過程支持，如項目組織結構、配置管理等。
- 尋求從SA 向實現過渡的途徑，如將程序設計語言元素引入SA 階段、模型映射、構件組裝、復用中間件平臺等。
- 研究基于SA 的測試技術。
- 構件組裝階段。在SA設計模型的指導下，可復用構件的組裝可以在較高層次上實現系統，并能夠提高系統實現的效率。在構件組裝的過程中，SA設計模型起到了系統藍圖的作用。研究內容包括如下兩個方面。
- 如何支持可復用構件的互聯，即對SA 設計模型中規約的連接子的實現提供支持。
- 在組裝過程中，如何檢測并消除體系結構失配問題。
在構件組裝階段的失配問題主要包括:由構件引起的失配、由連接子引起的失配、由于系統成分對全局體系結構的假設存在沖突引起的失配等。
- 部署階段。SA 對軟件部署作用如下。
- 提供高層的體系結構視圖來描述部署階段的軟硬件模型。
- 基于SA 模型可以分析部署方案的質量屬性，從而選擇合理的部署方案。
- 后開發階段。是指軟件部署安裝之后的階段。這一階段的SA 研究主要圍繞維護、演化、復用等方面來進行。典型的研究方向包括動態軟件體系結構、體系結構恢復與重建等。
- 動態軟件體系結構。現實中的軟件具有動態性，體系結構會在運行時發生改變。運行時變化包括兩類:軟件內部執行所導致的體系結構改變;軟件系統外部的請求對軟件進行的重配置包括兩個部分的研究:體系結構設計階段的支持、運行時刻基礎設施的支持。
- 體系結構恢復與重建。對于現有系統在開發時候沒有考慮SA的情況，從這些系統中恢復或重購體系結構。從已有的系統中獲取體系結構的重建方法分為4類:手工體系結構重建、工具支持的手工重建通過查詢語言來自動建立聚集、使用其他技術(如數據挖掘等)。
構件
構件是一個獨立可交付的功能單元，外界通過接口訪問其提供的服務。
構件由一組通常需要同時部署的原子構件組成。一個原子構件是一個模塊和一組資源。原子構件是部署、版本控制和替換的基本單位。原子構件通常成組地部署，但是它也能夠被單獨部署。
構件和原子構件之間的區別在于，大多數原子構件永遠都不會被單獨部署，盡管它們可以被單獨部署。相反，大多數原子構件都屬于一個構件家族，一次部署往往涉及整個家族。
一個模塊是不帶單獨資源的原子構件。
一個單獨的包被編譯成多個單獨的類文件——每個公共類都有一個。
模塊是一組類和可能的非面向對象的結構體，比如過程或者函數。
構件的特性是:
- 獨立部署單元；
- 作為第三方的組裝單元；
- 沒有(外部的)可見狀態。
一個構件可以包含多個類元素，但是一個類元素只能屬于一個構件。將一個類拆分進行部署通常沒什么意義。
對象的特性是:
- 一個實例單元，具有唯一的標志。
- 可能具有狀態，此狀態外部可見。
- 封裝了自己的狀態和行為。
構件接口
接口標準化是對接口中消息的格式、模式和協議的標準化。它不是要將接口格式化為參數化操作的集合，而是關注輸入輸出的消息的標準化，它強調當機器在網絡中互連時，標準的消息模式、格式、協議的重要性。
面向構件的編程(COP)
關注于如何支持建立面向構件的解決方案。“面向構件的編程需要下列基本的支持:
——多態性（可替代性）；
——模塊封裝性（高層次信息的隱藏）；
——后期的綁定和裝載(部署獨立性)；
——安全性(類型和模塊安全性)。”
構件技術就是利用某種編程手段，將一些人們所關心的，但又不便于讓最終用戶去直接操作的細節進行了封裝，同時對各種業務邏輯規則進行了實現，用于處理用戶的內部操作細節。目前，國際上常用的構件標準主要有三大流派:
- EJB(Enterprise Java Bean)規范由Sun 公司制定，有三種類型的EJB，分別是會話Bean(Session Bean)、實體Bean(Entity Bean)和消息驅動Bean(Message-driven Bean)。EJB實現應用中關鍵的業務邏輯，創建基于構件的企業級應用程序。
- COM、DCOM、COM+:COM是微軟公司的。DCOM是COM的進一步擴展，具有位置獨立性和語言無關性。COM+并不是COM的新版本，是COM的新發展或是更高層次的應用。
- CORBA（Common Object Request Broker Architecture，公共對象請求代理體系結構）標準主要分為三個層次:對象請求代理、公共對象服務和公共設施。最底層是對象請求代理ORB，規定了分布對象的定義(接口)和語言映射，實現對象間的通訊和互操作，是分布對象系統中的“軟總線”。
在ORB之上定義了很多公共服務，可以提供諸如并發服務、名字服務、事務(交易)服務、安全服務等各種各樣的服務;
最上層的公共設施則定義了組件框架，提供可直接為業務對象使用的服務，規定業務對象有效協作所需的協定規則。
一個POA實例通過將收到的請求傳遞給一個伺服對象（Servant)來對其進行處理。伺服對象是CORBA對象的實現，負責完成客戶端請求。
POA是對象實現與ORB其它組件之間的中介，它將客戶請求傳送到伺服對象，按需創建子POA，提供管理伺服對象的策略。
CORBA對象可看作是一個具有對象標識、對象接口及對象實現的抽象實體。
之所以稱為抽象的，是因為并沒有硬性規定CORBA對象的實現機制。由于獨立于程序設計語言和特定ORB產品，一個CORBA對象的引用又稱可互操作的對象引用（Interoperable Object Reference）。從客戶程序的角度看，IOR中包含了對象的標識、接口類型及其他信息以查找對象實現。
伺服對象（servant）是指具體程序設計語言的對象或實體，通常存在于一個服務程序進程之中。
客戶程序通過對象引用發出的請求經過ORB擔當中介角色，轉換為對特定的伺服對象的調用。在一個CORBA對象的生命期中，它可能與多個伺服對象相關聯，因而對該對象的請求可能被發送到不同的伺服對象。
象標識（Object ID）是一個用于在POA中標識一個CORBA對象的字符串。它既可由程序員指派，也可由對象適配器自動分配，這兩種方式都要求對象標識在創建它的對象適配器中必須具有唯一性。
Calculator.idlinterface Calculator {long add(long a, long b); };
CalculatorClient.javaimport org.omg.CORBA.ORB; import org.omg.CosNaming.NameComponent; import org.omg.CosNaming.NamingContextExt; import org.omg.CosNaming.NamingContextExtHelper;public class CalculatorClient {public static void main(String args[]) {try {// 初始化 ORBORB orb = ORB.init(args, null);// 獲取命名服務上下文org.omg.CORBA.Object objRef = orb.resolve_initial_references("NameService");NamingContextExt ncRef = NamingContextExtHelper.narrow(objRef);// 通過命名服務查找對象NameComponent path[] = ncRef.to_name("CalculatorService");Calculator calculator = CalculatorHelper.narrow(ncRef.resolve(path));// 調用遠程方法long result = calculator.add(3, 5);System.out.println("3 + 5 = " + result);} catch (Exception e) {System.err.println("ERROR: " + e);e.printStackTrace(System.out);}} }
CalculatorServer.javaimport org.omg.CORBA.ORB; import org.omg.CosNaming.NameComponent; import org.omg.CosNaming.NamingContextExt; import org.omg.CosNaming.NamingContextExtHelper; import org.omg.PortableServer.POA; import org.omg.PortableServer.POAHelper;// 伺服對象實現 class CalculatorServant extends CalculatorPOA {public long add(long a, long b) {return a + b;} }public class CalculatorServer {public static void main(String args[]) {try {// 初始化 ORBORB orb = ORB.init(args, null);// 獲取根 POA（可移植對象適配器）引用POA rootpoa = POAHelper.narrow(orb.resolve_initial_references("RootPOA"));rootpoa.the_POAManager().activate();// 創建伺服對象實例CalculatorServant calculatorImpl = new CalculatorServant();// 獲取對象引用org.omg.CORBA.Object ref = rootpoa.servant_to_reference(calculatorImpl);Calculator href = CalculatorHelper.narrow(ref);// 獲取命名服務上下文org.omg.CORBA.Object objRef = orb.resolve_initial_references("NameService");NamingContextExt ncRef = NamingContextExtHelper.narrow(objRef);// 將對象綁定到命名服務NameComponent path[] = ncRef.to_name("CalculatorService");ncRef.rebind(path, href);System.out.println("CalculatorServer ready and waiting ...");// 等待客戶端請求orb.run();} catch (Exception e) {System.err.println("ERROR: " + e);e.printStackTrace(System.out);}} }代碼說明
Calculator.idl：定義了一個簡單的Calculator接口，其中包含一個add方法，用于實現兩個整數的加法運算。CalculatorServer.java：
- 初始化
ORB。- 創建一個
CalculatorServant實例，它是Calculator接口的具體實現。- 將
CalculatorServant實例注冊到POA（可移植對象適配器）中，并獲取其對象引用。- 使用命名服務將對象引用綁定到
CalculatorService名稱下。- 調用
orb.run()方法，使服務器進入等待狀態，等待客戶端的請求。
CalculatorClient.java：
- 初始化
ORB。- 通過命名服務查找名為
CalculatorService的對象引用。- 調用
add方法進行加法運算，并輸出結果。
2. 軟件架構風格
軟件體系結構風格是描述某一特定應用領域中系統組織方式的慣用模式。架構風格定義一個系統家族，即一個架構定義、一個詞匯表和一組約束。詞匯表中包含一些構件和連接件類型，而這組約束指出系統是如何將這些構件和連接件組合起來的。
架構風格反映了領域中眾多系統所共有的結構和語義特性，并指導如何將個模塊和子系統有效地組織成一個完整的系統。對軟件架構風格的研究和實踐促進對設計的重用，一些經過實踐證實的解決方案也可以可靠地用于解決新的問題。
架構設計的一個核心問題是能否達到架構級的軟件復用。
架構風格定義了用于描述系統的術語表和一組指導構建系統的規則。
五大類架構風格
- 數據流風格:面向數據流，按照一定的順序從前向后執行程序，代表的風格有 批處理序列、管道-過濾器。
- 調用/返回風格:構件之間存在互相調用的關系，一般是顯式的調用，代表的風格有 主程序/子程序、面向對象、層次結構。
- 獨立構件風格:構件之間是互相獨立的，不存在顯式的調用關系，而是通過某個事件觸發、異步的方式來執行，代表的風格有 進程通信、事件驅動系統(隱式調用)。
- 虛擬機風格:自定義了一套規則供使用者使用，使用者基于這個規則來開發構件，能夠跨平臺適配，代表的風格有 解釋器、基于規則的系統。
- 倉庫風格:以數據為中心，所有的操作都是圍繞建立的數據中心進行的，代表的風格有 數據庫系統、超文本系統、黑板系統。
數據流風格
批處理序列:構件為一系列固定順序的計算單元，構件之間只通過數據傳遞交互。每個處理步驟是一個獨立的程序，每一步必須在其前一步結束后才能開始，數據必須是完整的，以整體的方式傳遞。
管道-過濾器:每個構件都有一組輸入和輸出，構件讀取輸入的數據流，經過內部處理，產生輸出數據流。前一個構件的輸出作為后一個構件的輸入，前后數據流關聯。過濾器就是構件，連接件就是管道。
早期編譯器就是采用的這種架構，要一步一步處理的，均可考慮此架構風格。
二者區別在于：批處理前后構件不一定有關聯，并且是作為整體傳遞，即必須前一個執行完才能執行下一個。管道-過濾器是前一個輸出作為后一個輸入，前面執行到部分可以開始下一個的執行。
調用/返回風格
主程序/子程序:單線程控制。把問題劃分為若干個處理步驟，構件即為主程序和子程序，子程序通常可合成為模塊。過程調用作為交互機制，充當連接件的角色。
面向對象:構件是對象，對象是抽象數據類型的實例。連接件即是對象間交互的方式，對象是通過函數和過程的調用來交互的。
層次結構:構件組成一個層次結構，連接件通過決定層間如何交互的協議來定義。每層為上一層提供服務，使用下一層的服務，只能見到與自己鄰接的層。修改某一層，最多影響其相鄰的兩層(通常只能影響上層)。
層次結構優點:
- 支持基于可增加抽象層的設計，允許將一個復雜問題分解成一個增量步驟序列的實現。
- 不同的層次處于不同的抽象級別，越靠近底層，抽象級別越高。
- 由于每一層最多只影響兩層，同時只要給相鄰層提供相同的接口，允許每層用不同的方法實現，同樣為軟件復用提供了強大的支持。
缺點:
- 并不是每個系統都可以很容易的劃分為分層的模式。
- 很難找到一個合適的、正確的層次抽象方法。
獨立構件風格
進程通信:構件是獨立的進程，連接件是消息傳遞。構件通常是命名過程消息傳遞的方式可以是點對點、異步或同步方式，以及遠程過程(方法)調用等。
事件驅動系統(隱式調用):構件不直接調用一個過程，而是觸發或廣播一個或多個事件。構件中的過程在一個或多個事件中注冊，當某個事件被觸發時，系統自動調用在這個事件中注冊的所有過程。一個事件的觸發就導致了另一個模塊中的過程調用。這種風格中的構件是匿名的過程，它們之間交互的連接件往往是以過程之間的隱式調用來實現的。
主要優點是為軟件復用提供了強大的支持，為構件的維護和演化帶來了方便缺點是構件放棄了對系統計算的控制。
虛擬機風格
解釋器:通常包括一個完成解釋工作的解釋引擎、一個包含將被解釋的代碼的存儲區、一個記錄解釋引擎當前工作狀態的數據結構，以及一個記錄源代碼被解釋執行的進度的數據結構。具有解釋器風格的軟件中含有一個虛擬機，可以仿真硬件的執行過程和一些關鍵應用，缺點是執行效率低。
基于規則的系統:包括規則集、規則解釋器、規則/數據選擇器和工作內存，一般用在人工智能領域和DSS中。
倉庫(數據共享)風格
數據庫系統:構件主要有兩大類，一類是中央共享數據源，保存當前系統的數據狀態;另一類是多個獨立處理單元，處理單元對數據元素進行操作。
黑板系統:包括知識源、黑板和控制三部分。知識源包括若干獨立計算的不同單元，提供解決問題的知識。知識源響應黑板的變化，也只修改黑板;黑板是一個全局數據庫，包含問題域解空間的全部狀態，是知識源相互作用的唯一媒介;知識源響應是通過黑板狀態的變化來控制的。黑板系統通常應用在對于解決問題沒有確定性算法的軟件中(信號處理、問題規劃和編譯器優化等)。
超文本系統:構件以網狀鏈接方式相互連接，用戶可以在構件之間進行按照人類的聯想思維方式任意跳轉到相關構件。是一種非線性的網狀信息組織方法它以節點為基本單位，鏈作為節點之間的聯想式關聯。通常應用在互聯網領域。
現代編譯器的集成開發環境一般采用數據倉庫(即以數據為中心的架構風格)架構風格進行開發，其中心數據就是程序的語法樹。
閉環控制
當軟件被用來操作一個物理系統時，軟件與硬件之間可以粗略的表示為一個反饋循環，這個反饋循環通過接受一定的輸入，確定一系列的輸出，最終使環境達到一個新的狀態，適合于嵌入式系統，涉及連續的動作與狀態。
C2體系結構風格
C2體系結構風格可以概括為:通過連接件綁定在一起的按照一組規則運作的并行構件網絡。C2風格中的系統組織規則如下:
- 系統中的構件和連接件都有一個頂部和一個底部；
- 構件的頂部應連接到某連接件的底部，構件的底部則應連接到某連接件的頂部，而構件與構件之間的直接連接是不允許的;
- 一個連接件可以和任意數目的其它構件和連接件連接;
- 當兩個連接件進行直接連接時，必須由其中一個的底部到另一個的頂部。
總結
| 架構風格名 | 關鍵字及實例 | 簡介 |
|---|---|---|
| 數據流-批處理 | 傳統編譯器，每個階段產生的結果作為下一個階段的輸入，區別在于整體。 | 一個接一個，以整體為單位。 |
| 數據流-管道-過濾器 | 一個接一個，前一個輸出是后一個輸入。 | |
| 調用/返回-主程序/子程序 | 顯示調用，主程序直接調用子程序。 | |
| 用/返回-面向對象 | 對象是構件，通過對象調用封裝的方法和屬性。 | |
| 調用/返回-層次結構 | 分層，每層最多影響其上下兩層，有調用關系。 | |
| 獨立構件-進程通信 | 進程間獨立的消息傳遞，同步異步。 | |
| 獨立構件-事件驅動（隱式調用） | 事件觸發推動動作，如程序語言的語法高亮、語法錯誤提示 | 不直接調用，通過事件驅動 |
| 虛擬機-解釋器 | 自定義流程，按流程執行，規則隨時改變，靈活定義，業務靈活組合機器人。 | 解釋自定義的規則，解釋引擎、存儲區、數據結構。 |
| 虛擬機-規則系統 | 規則集、規則解釋器、選擇器和工作內存，用于DSS和人工智能、專家系統。 | |
| 倉庫-數據庫 | 現代編譯器的集成開發環境IDE，以數據為中心。又稱為數據共享風格。 | 中央共享數據源，獨立處理單元。 |
| 倉庫-超文本 | 網狀鏈接，多用于互聯網。 | |
| 倉庫-黑板 | 語音識別、知識推理等問題復雜、解空間很大、求解過程不確定的這一類軟件系統，黑板、知識源、控制。 | |
| 閉環-過程控制 | 汽車巡航定速，空調溫度調教，設定參數，并不斷調整。 | 發出控制命令并接受反饋，循環往復達到平衡。 |
| C2風格 | 構件和連接件、頂部和底部 | 通過連接件綁定在一起按照一組規則運作的并行構件網絡 |
兩層C/S架構
兩層C/S架構:客戶端和服務器都有處理功能，現在已經不常用，原因有:開發成本較高、客戶端程序設計復雜、信息內容和形式單一、用戶界面風格不一、軟件移植困難、軟件維護和升級困難、新技術不能輕易應用、安全性問題、服務器端壓力大難以復用。
三層C/S架構
三層C/S架構:將處理功能獨立出來，表示層和數據層都變得簡單。表示層在客戶機上，功能層在應用服務器上，數據層在數據庫服務器上。即將兩層C/S架構中的數據從服務器中獨立出來了。其優點下面四點:
- 各層在邏輯上保持相對獨立，整個系統的邏輯結構更為清晰，能提高系統和軟件的可維護性和可擴展性;
- 允許靈活有效的選用相應的平臺和硬件系統，具有良好的可升級性和開放性;
- 各層可以并行開發，各層也可以選擇各自最適合的開發語言；
- 功能層有效的隔離表示層與數據層，為嚴格的安全管理奠定了堅實的基礎，整個系統的管理層次也更加合理和可控制。
三層C/S架構設計的關鍵在于各層之間的通信效率，要慎重考慮三層間的通信方法、通信頻度和數據量，否則即使分配給各層的硬件能力很強，性能也不高。
三層B/S架構
是三層C/S架構的變種，將客戶端變為用戶客戶端上的瀏覽器，將應用服務器變為網絡上的WEB服務器，又稱為0客戶端架構，雖然不用開發客戶端，但有很多缺點:
- B/S架構缺乏對動態頁面的支持能力，沒有集成有效的數據庫處理功能；
- 安全性難以控制;
- 在數據查詢等響應速度上，要遠遠低于C/S架構；
- 數據提交一般以頁面為單位，數據的動態交互性不強，不利于OLTP應用。
混合架構風格
內外有別模型：企業內部使用C/S，外部人員訪問使用B/S。
查改有別模型：采用B/S查詢，采用C/S修改。
混合架構實現困難，且成本高。
富互聯網應用RIA
彌補三層B/S架構存在的問題，RIA是一種用戶接口，比用HTML實現的接口更加健壯，且有可視化內容，本質還是網站模式，其優點如下：
- RIA結合了C/S架構反應速度快、交互性強的優點與B/S架構傳播范圍廣及容易傳播的特性;
- RIA簡化并改進了B/S架構的用戶交互；
- 數據能夠被緩存在客戶端，從而可以實現一個比基于HTML的響應速度更快且數據往返于服務器的次數更少的用戶界面。
本質還是0客戶端，借助于高速網速實現必要插件在本地的快速緩存，增強頁面對動態頁面的支持能力，典型的如小程序。
MVC架構
- 控制器(Controller):是應用程序中處理用戶交互的部分。通常控制器負責從視圖讀取數據，控制用戶輸入，并向模型發送數據。
- 模型(Model):是應用程序中用于處理應用程序數據邏輯的部分。通常模型對象負責在數據庫中存取數據。模型表示業務數據和業務邏輯。
- 視圖(View):是應用程序中處理數據顯示的部分。通常視圖是依據模型數據創建的。是用戶看到并與之交互的界面。視圖向用戶顯示相關的數據，并能接收用戶的輸入數據，但是它并不進行任何實際的業務處理:
MVP架構
MVP:MVP是把MVC中的Controller換成了Presenter(呈現)，目的就是為了完全切斷View跟Model之間的聯系,由Presenter充當橋梁，做到View-Model之間通信的完全隔離。
MVP特點:
- M、V、P之間雙向通信。
- View與 Model不通信，都通過 Presenter傳遞。Presenter完全把Model和View進行了分離，主要的程序邏輯在Presenter里實現。
- View 非常薄，不部署任何業務邏輯，稱為”被動視圖”(Passive View)，即沒有任何主動性，而 Presenter非常厚，所有邏輯都部署在那里。
- Presenter與具體的View是沒有直接關聯的，而是通過定義好的接口進行交互，從而使得在變更View時候可以保持Presenter的不變，這樣就可以重用。
MVVM架構
MVVM:MVVM模式和MVC模式類似，主要目的是分離視圖(View)和模型(Model)，有幾大優點:
- 低耦合，視圖 (View)可以獨立于Model變化和修改，一ViewModel可以綁定到不同的”View"上，當View變化的時候Model可以不變，當Model變化的時候View也可以不變。
- 可重用性，可以把一些視圖邏輯放在一個viewModel里面讓很多view重用這段視圖邏輯。
- 獨立開發，開發人員可以專注于業務邏輯和數據的開發(ViewModel)，設計人員可以專注于頁面設計。
- 可測試，界面向來是比較難于測試的，而現在測試可以針對ViewModel來寫。
面向服務的架構風格（SOA）
SOA是一種粗粒度、松耦合服務架構，服務之間通過簡單、精確定義接口進行通信，不涉及底層編程接口和通信模型。
在SOA中，服務是一種為了滿足某項業務需求的操作、規則等的邏輯組合，它包含一系列有序活動的交互，為實現用戶目標提供支持。
SOA并不僅僅是一種開發方法，還具有管理上的優點，管理員可直接管理開發人員所構建的相同服務。多個服務通過企業服務總線提出服務請求，由應用管理來進行處理，如下：
實施SOA的關鍵目標是實現企業IT資產重用的最大化，在實施SOA過程中要牢記以下特征:可從企業外部訪問、隨時可用(服務請求能被及時響應)、粗粒度接口(粗粒度提供一項特定的業務功能，而細粒度服務代表了技術構件方法)、服務分級、松散耦合(服務提供者和服務使用者分離)、可重用的服務及服務接口設計管理、標準化的接口(WSDL、SOAP、XML是核心)、支持各種消息模式、精確定義的服務接口。
從基于對象到基于構件再到基于服務，架構越來越松散耦合，粒度越來越粗接口越來越標準。
基于服務的構件與傳統構件的區別有四點:
- 服務構件粗粒度，傳統構件細粒度居多；
- 服務構件的接口是標準的，主要是WSDL接口，而傳統構件常以具體API形式出現；
- 服務構件的實現與語言是無關的，而傳統構件常綁定某種特定的語言；
- 服務構件可以通過構件容器提供QoS的服務，而傳統構件完全由程序代碼直接控制。
SOA中應用的關鍵技術如下表。
| 功能 | 協議 |
|---|---|
| 發現服務 | UDDI、DISCO |
| 描述服務 | WSDL、XML Schema |
| 消息格式層 | SOAP、RESP |
| 編碼格式層 | XML（DOM, SAX） |
| 傳輸協議層 | HTTP、TCP/IP、SMTP等 |
UDDI:是一套基于WEB的、分布式的、為WebService提供的、信息注冊中心的實現標準規范，同時也包含一組使企業能將自身提供的WebService注冊，以使別的企業能夠發現的訪問協議的實現標準，用于WEB服務注冊統一描述、發現及集成。
WSDL(Web Service描述語言):將Web服務描述定義為一組服務訪問點，客戶端可以通過這些服務訪問點對包含面向文檔信息或面向過程調用的服務進行訪問(類似遠程調用)，用于描述服務。
SOAP (簡單對象訪問協議):是用于交換XML編碼信息的輕量級協議用于傳遞信息。
XML(可擴展標記語言):是Webservice平臺中表示數據的基本格式，用于數據交換。
WEB Service
服務提供者、服務注冊中心(中介，提供交易平臺，可有可無)服務請求者。服務提供者將服務描述發布到服務注冊中心，供服務請求者查找，查找到后，服務請求者將綁定查找結果。如圖：
服務注冊表
- 服務注冊:應用開發者(服務提供者)在注冊表中公布服務的功能。
- 服務位置:服務使用者(服務應用開發者)，幫助他們查詢注冊服務，尋找符合自身要求的服務。
- 服務綁定:服務使用者利用檢索到的服務接口來編寫代碼所編寫的代碼將與注冊的服務綁定，調用注冊的服務，以及與它們實現互動。
企業服務總線ESB
企業服務總線ESB:簡單來說是一根管道用來連接各個服務節點。ESB的存在是為了集成基于不同協議的不同服務，ESB 做了消息的轉化、解釋以及路由的工作，以此來讓不同的服務互聯互通。
包括:客戶端(服務請求者)、基礎架構服務(中間件)、核心集成服務(提供服務)。
ESB特點:
- SOA的一種實現方式，ESB在面向服務的架構中起到的是總線作用，將各種服務進行連接與整合;
- 描述服務的元數據和服務注冊管理；
- 在服務請求者和提供者之間傳遞數據，以及對這些數據進行轉換的能力，并支持由實踐中總結出來的一些模式如同步模式、異步模式等;
- 發現、路由、匹配和選擇的能力，以支持服務之間的動態交互，解耦服務請求者和服務提供者。高級一些的能力，包括對安全的支持、服務質量保證、可管理性和負載平衡等。
ESB的主要功能：
- 服務位置透明性；
- 傳輸協議轉換；
- 消息格式轉換；
- 消息路由；
- 消息增強；
- 安全性；
- 監控與管理。
3. 軟件架構復用
軟件產品線是指一組軟件密集型系統，它們共享一個公共的、可管理的特性集，滿足某個特定市場或任務的具體需要，是以規定的方式用公共的核心資產集成開發出來的。即圍繞核心資產庫進行管理復用、集成新的系統。
軟件架構復用的類型包括機會復用和系統復用。機會復用是指開發過程中，只要發現有可復用的資產，就對其進行復用。系統復用是指在開發之前，就要進行規劃，以決定哪些需要復用。
可復用的資產包括:需求、架構設計、元素、建模與分析、測試、項目規劃、過程方法和工具、人員、樣本系統、缺陷消除。
復用的基本過程主要包括3個階段:首先構造/獲取可復用的軟件資產，其次管理這些資產(構件庫)，最后針對特定的需求，從這些資產中選擇可復用的部分，以開發滿足需求的應用系統。
4. 特定領域軟件架構（DSSA）
DSSA就是專用于一類特定類型的任務(領域)的、在整個領域中能有效地使用的、為成功構造應用系統限定了標準的組合結構的軟件構件的集合。
DSSA就是一個特定的問題領域中支持一組應用的領域模型、參考需求、參考架構等組成的開發基礎，其目標就是支持在一個特定領域中多個應用的生成。
垂直域:在一個特定領域中的通用的軟件架構，是一個完整的架構。
水平域:在多個不同的特定領域之間的相同的部分的小工具(如購物和教育都有收費系統，收費系統即是水平域)。
DSSA的三個基本活動
- 領域分析:這個階段的主要目標是獲得領域模型(領域需求)。識別信息源，即整個領域工程過程中信息的來源，可能的信息源包括現存系統、技術文獻問題域和系統開發的專家、用戶調查和市場分析、領域演化的歷史記錄等，在此基礎上就可以分析領域中系統的需求，確定哪些需求是領域中的系統廣泛共享的，從而建立領域模型。
- 領域設計:這個階段的目標是獲得DSSA。DSSA描述在領域模型中表示的需求的解決方案，它不是單個系統的表示，而是能夠適應領域中多個系統的需求的一個高層次的設計。建立了領域模型之后，就可以派生出滿足這些被建模的領域需求DSSA。
- 領域實現:這個階段的主要目標是依據領域模型和DSSA開發和組織可重用信息。這些可重用信息可能是從現有系統中提取得到，也可能需要通過新的開發得到。
參與DSSA的四種角色人員
- 領域專家:包括該領域中系統的有經驗的用戶、從事該領域中系統的需求分析設計、實現以及項目管理的有經驗的軟件工程師等。提供關于領域中系統的需求規約和實現的知識，幫助組織規范的、一致的領域字典，幫助選擇樣本系統作為領域工程的依據，復審領域模型、DSSA等領域工程產品，等等。
- 領域分析人員:由具有知識工程背景的有經驗的系統分析員來擔任。控制整個領域分析過程，進行知識獲取，將獲取的知識組織到領域模型中。
- 領域設計人員:由有經驗的軟件設計人員來擔任。根據領域模型和現有系統開發出DSSA，并對DSSA的準確性和一致性進行驗證。
- 領域實現人員:由有經驗的程序設計人員來擔任。根據領域模型和DSSA，開發構件。
建立DSSA的過程
- 定義領域范圍:領域中的應用要滿足用戶一系列的需求。
- 定義領域特定的元素:建立領域的字典，歸納領域中的術語，，識別出領域中相同和不相同的元素。
- 定義領域特定的設計和實現需求的約束:識別領域中的所有約束，這些約束對領域的設計和實現會造成什么后果。
- 定義領域模型和架構:產生一般的架構，并描述其構件說明。
- 產生、搜集可復用的產品單元:為DSSA增加復用構件，使可用于新的系統。
以上過程是并發的、遞歸的、反復的、螺旋型的。
三層次模型
領域開發環境:領域架構師決定核心架構，產出參考結構、參考需求、架構、領域模型、開發工具。
領域特定的應用開發環境:應用工程師根據具體環境來將核心架構實例化。
應用執行環境:操作員實現實例化后的架構。
5. 基于架構的軟件開發（ABSD）
ABSD方法是架構驅動，強調由業務、質量和功能需求的組合驅動架構設計。它強調采用視角和視圖來描述軟件架構，采用用例和質量屬性場景來描述需求。進一步來說，用例描述的是功能需求，質量屬性場景描述的是質量需求(或側重于非功能需求)。
使用ABSD方法，設計活動可以從項目總體功能框架明確就開始，這意味著需求獲取和分析還沒有完成，就開始了軟件設計。
ABSD方法有三個基礎。第一個基礎是功能的分解，使用已有的基于模塊的內聚和耦合技術;第二個基礎是通過選擇架構風格來實現質量和業務需求;第三個基礎是軟件模板的使用，軟件模板利用了一些軟件系統的結構。
ABSD方法是遞歸的，且迭代的每一個步驟都是清晰定義的。因此，不管設計是否完成，架構總是清晰的，有助于降低架構設計的隨意性。
基于架構的軟件開發過程可分為下列6步：
- 架構需求:主要來自系統的質量目標、系統的商業目標、系統開發人員的商業目標。重在掌握標識構件的三步，如下左圖。
- 架構設計:將需求階段的標識構件映射成構件，進行分析，如下右圖。
- 架構(體系結構)文檔化:主要產出兩種文檔，即架構(體系結構)規格說明，測試架構(體系結構)需求的質量設計說明書。文檔是至關重要的，是所有人員通信的手段，關系開發的成敗。
- 架構復審:由外部人員(獨立于開發組織之外的人，如用戶代表和領域專家等)參加的復審，復審架構是否滿足需求，質量問題，構件劃分合理性等。若復審不過，則返回架構設計階段進行重新設計、文檔化，再復審。
- 架構實現:用實體來顯示出架構。實現構件，構件組裝成系統，如下左圖。
- 架構演化:對架構進行改變，按需求增刪構件，使架構可復用，如下右圖。
6. 軟件系統的質量屬性
可以將軟件系統的質量屬性分為開發期質量屬性和運行期質量屬性2個部分。
- 開發期質量屬性主要指在軟件開發階段所關注的質量屬性，主要包含6個方面。
- 易理解性:指設計被開發人員理解的難易程度。
- 可擴展性:軟件因適應新需求或需求變化而增加新功能的能力，也稱為靈活性。
- 可重用性:指重用軟件系統或某一部分的難易程度。
- 可測試性:對軟件測試以證明其滿足需求規范的難易程度。
- 可維護性:當需要修改缺陷、增加功能、提高質量屬性時，識別修改點并實施修改的難易程度。
- 可移植性:將軟件系統從一個運行環境轉移到另一個不同的運行環境的難易程度。
- 運行期質量屬性主要指在軟件運行階段所關注的質量屬性，主要包含7個方面。
- 性能:性能是指軟件系統及時提供相應服務的能力，如速度、吞吐量和容量等的要求。
- 安全性:指軟件系統同時兼顧向合法用戶提供服務，以及阻止非授權使用的能力。
- 可伸縮性:指當用戶數和數據量增加時，軟件系統維持高服務質量的能力。例如，通過增加服務器來提高能力。
- 互操作性:指本軟件系統與其他系統交換數據和相互調用服務的難易程度。
- 可靠性:軟件系統在一定的時間內持續無故障運行的能力。
- 可用性:指系統在一定時間內正常工作的時間所占的比例。可用性會受到系統錯誤，惡意攻擊高負載等問題的影響。
- 魯棒性:是指軟件系統在非正常情況(如用戶進行了非法操作、相關的軟硬件系統發生了故障等)下仍能夠正常運行的能力，也稱健壯性或容錯性。
質量屬性場景
質量屬性場景是一種面向特定質量屬性的需求。它由 6 部分組成:
- 刺激源(Source):這是某個生成該刺激的實體(人、計算機系統或者任何其他刺激器)
- 刺激(Stimulus):該刺激是當刺激到達系統時需要考慮的條件。
- 環境(Environment):該刺激在某些條件內發生。當激勵發生時，系統可能處于過載、運行或者其他情況。
- 制品(Artifact):某個制品被激勵。這可能是整個系統，也可能是系統的一部分。
- 響應(Response):該響應是在激勵到達后所采取的行動。
- 響應度量(Measurement):當響應發生時，應當能夠以某種方式對其進行度量，以對需求進行測試
可修改性質量屬性場景描述實例:
| 場景要素 | 可能的情況 |
|---|---|
| 剌激源 | 最終用戶、開發人員、系統管理員 |
| 刺激 | 希望增加、刪除、修改、改變功能、質量屬性、容量等 |
| 環境 | 系統設計時、編譯時、構建時、運行時 |
| 制品 | 系統用戶界面、平臺、環境或與目標系統交互的系統 |
| 響應 | 查找架構中需要修改的位置，進行修改且不會影響其他功能，對所做的修改進行測試，部署所做的修改 |
| 響應度量 | 根據所影響元素的數量度量的成本、努力、資金;該修改對其他功能或質量屬性所造成影響的程度 |
7. 軟件架構評估
質量屬性
- 性能:指系統的響應能力，即要經過多長時間才能對某個事件做出響應，或者在某段時間內系統所能處理的事件的個數。如響應時間、吞吐量。
設計策略:優先級隊列、增加計算資源、減少計算開銷、引入并發機制、采用資源調度等。 - 可靠性:是軟件系統在應用或系統錯誤面前，在意外或錯誤使用的情況下維持軟件系統的功能特性的基本能力。如MTTF、MTBF、MTTR、容錯性（故障時確保正常行為）、健壯性（錯誤輸入時按預定義方式終止）。
設計策略:心跳、Ping/Echo、冗余、選舉。 - 可用性:是系統能夠正常運行的時間比例，經常用兩次故障之間的時間長度或在出現故障時系統能夠恢復正常的速度來表示。如故障間隔時間。
設計策略:心跳、Ping/Echo、冗余、選舉。 - 安全性:是指系統在向合法用戶提供服務的同時能夠阻止非授權用戶使用的企圖或拒絕服務的能力。如保密性、完整性、不可抵賴性、可控性。
設計策略:入侵檢測、用戶認證、用戶授權、追蹤審計等。 - 可修改性:指能夠快速的以較高的性能價格比對系統進行變更的能力。通常以某些具體的變更為基準，通過考察這些變更的代價衡量。
設計策略:接口-實現分離、抽象、信息隱藏。 - 功能性:是系統所能完成所期望的工作的能力。一項任務的完成需要系統中許多或大多數構件的相互協作。
- 可變性:指體系結構經擴充或變更而成為新體系結構的能力。這種新體系結構應該符合預先定義的規則，在某些具體方面不同于原有的體系結構。當要將某個體系結構作為一系列相關產品的基礎時，可變性是很重要的。
- 互操作性:作為系統組成部分的軟件不是獨立存在的，經常與其他系統或自身環境相互作用。為了支持互操作性，軟件體系結構必須為外部可視的功能特性和數據結構提供精心設計的軟件入口。程序和用其他編程語言編寫的軟件系統的交互作用就是互操作性的問題，也影響應用的軟件體系結構。
【記憶口訣】
開發：重用李(理)闊(擴)，測位(維)移簡。
運行：互靠永(用)安，伸縮棒性。
評估：互靠永(用)安，改功變性。開發期質量屬性：可重用性、易理解性、可擴展性、可測試性、可維護性、可移植性
運行期質量屬性：互操作性、可靠性、可用性、安全性、可伸縮性、魯棒性、性能
架構評估質量屬性：互操作性、可靠性、可用性、安全性、可修改性、功能性、可變性、性能
軟件架構評估的相關概念
敏感點:是指為了實現某種特定的質量屬性，一個或多個構件所具有的特性。
權衡點:是影響多個質量屬性的特性，是多個質量屬性的敏感點。
風險點與非風險點不是以標準專業術語形式出現的，只是一個常規概念，即可能引起風險的因素，可稱為風險點。某個做法如果有隱患，有可能導致一些問題，則為風險點;而如果某件事是可行的可接受的，則為非風險點。
軟件架構評估在架構設計之后，系統設計之前，因此與設計、實現、測試都沒有關系。評估的目的是為了評估所采用的架構是否能解決軟件系統需求，但不是單純的確定是否滿足需求。
三種常用的評估方式
基于調查問卷(檢查表)的方式:類似于需求獲取中的問卷調查方式，只不過是架構方面的問卷，要求評估人員對領域熟悉。
基于度量的方式:制定一些定量指標來度量架構，如代碼行數等。要制定質量屬性和度量結果之間的映射，要求評估人員對架構熟悉。
基于場景的方式:主要方法。首先要確定應用領域的功能和軟件架構的結構之間的映射，然后要設計用于體現待評估質量屬性的場景(即4+1視圖中的場景)，最后分析軟件架構對場景的支持程度。要求評估人員即對領域熟悉，也對架構熟悉。從三個方面對場景進行設計:刺激(事件);環境(事件發生的環境);響應(架構響應刺激的過程)
| 評估方式 | 調查問卷或檢查表 | 場景 | 度量 | |
|---|---|---|---|---|
| 調查問卷 | 檢查表 | |||
| 通用性 | 通用 | 特定領域 | 特定系統 | 通用或特定領域 |
| 評估者對架構的了解程度 | 粗略了解 | 無限制 | 中等了解 | 精確了解 |
| 實施階段 | 早 | 中 | 中 | 中 |
| 客觀性 | 主觀 | 主觀 | 較主觀 | 較客觀 |
基于場景的架構分析方法SAAM
SAAM是一種非功能質量屬性的架構分析方法，是最早形成文檔并得到廣泛應用的軟件架構分析方法
- 特定目標。SAAM的目標是對描述應用程序屬性的文檔，驗證基本的架構假設和原則。
- 質量屬性。這一方法的基本特點是把任何形式的質量屬性都具體化為場景，但可修改性是SAAM分析的主要質量屬性。
- 架構描述。SAAM 用于架構的最后版本，但早于詳細設計。架構的描述形式應當被所有參與者理解。
- 功能、結構和分配被定義為描述架構的3個主要方面。
- 方法活動。SAAM的主要輸入是問題描述、需求聲明和架構描述。下圖描繪了SAAM分析活動的相關輸入及評估過程。包括5個步驟，即場景開發、架構描述、單個場景評估、場景交互和總體評估。
架構權衡分析法ATAM
架構權衡分析法ATAM，讓架構師明確如何權衡多個質量目標，參與者有評估小組、項目決策者和其他項目相關人。
ATAM被分為四個主要的活動領域分別是場景和需求收集、體系結構視圖和場景實現、屬性模型構造和分析折中。整個評估過程強調以屬性作為架構評估的核心概念。主要針對性能可用性、安全性和可修改性，在系統開發之前，對這些質量屬性進行評價和折中。
在ATAM中，頭腦風暴的三種場景為：
- 用例場景：表示系統在典型工作負載或使用情況下的行為
- 增長場景：描述系統隨著需求變化或規模擴展的能力
- 探索性場景：表示非典型或異常使用情況下的表現，強調魯棒性和邊界條件
成本效益分析法CBAM
成本效益分析法CBAM，用來對架構建立的成本來進行設計和建模，讓決策者根據投資收益率來選擇合適的架構，可以看做對ATAM的補充，在ATAM確定質量合理的基礎上，再對效益進行分析。有下列步驟:
- 整理場景(確定場景，并確定優先級，選擇三分之一優先級最高的場景進行分析);
- 對場景進行細化(對每個場景詳細分析，確定最好、最壞的情況);
- 確定場景的優先級(項目干系人對場景投票，根據投票結果確定優先級)；
- 分配效用(對場景響應級別確定效用表，建立策略、場景、應級別的表格);
- 形成“策略-場景-響應級別的對應關系”；
- 確定期望的質量屬性響應級別的效用(根據效用表確定所對應的具體場景的效用表)；
- 計算各架構策略的總收益；
- 根據受成本限制影響的投資報酬率選擇架構策略(估算成本，用上一步的收益減去成本，得出收益，并選擇收益最高的架構策略)。
其他評估方法(僅了解)
- SAEM方法。軟件架構評估與演進方法（Software Architecture Evaluation and Evolution Method）將軟件架構看作一個最終產品以及設計過程中的一個中間產品，從外部質量屬性和內部質量屬性兩個角度來闡述它的評估模型，旨在為軟件架構的質量評估創建一個基礎框架。
外部屬性指用戶定義的質量屬性，而內部屬性指開發者決定的質量屬性。該軟件架構評估模型包含以下幾個流程。 - 對待評估的質量屬性進行規約建模。
- 為外部和內部的質量屬性創建度量準則，先從評估目的(如軟件架構比較、最終產品的質量預測)，評估角度(如開發者、用戶、維護者)，評估環境(架構作為最終產品或設計中間產品)出發來定義架構評估的目標，再根據目標相關的屬性來提出問題，然后回答每個問題并提出相應的度量準則。
- 評估質量屬性，包括數據收集、度量和結果分析3個活動。
- SAABNet方法。SAABNet 方法即軟件架構評估信念網絡（Software Architecture Assessment Belief Network）方法，是一種用來表達和使用定性知識以輔助架構的定性評估。該方法來源于人工智能允許不確定，不完整知識的推理。該方法使用貝葉斯信念網絡(Bavesian Belief Networks，BBN)來表示和使用開發過程中的知識，包含定性和定量的描述，其中定性的描述是所有結點的圖，定量的描述是每個結點狀態相關的條件概率。其中的變量可分為3 類，即架構質量屬性變量(如可維護性、靈活性等)、質量屬性的度量準則變量(如容錯性、響應性等)和架構特征變量(如繼承深度、編程語言等)，高層抽象的質量屬性變量分解為低層抽象的度量準則變量，度量準則變量則分解為更低層抽象的架構特征變量。
- SACMM方法。軟件架構修改度量方法(Software Architecture Change Measurement Method, SACMM)是一種軟件架構修改的度量方法。
- SASAM方法。軟件架構靜態分析方法(static Analysis of software Architecture mode，SASAM)通過對預期架構(架構設計階段的相關描述材料)和實際架構(源代碼中執行的架構)進行映射和比較來靜態地評估軟件架構。
- ALRRA方法。軟件架構可靠性風險評估方法(Architecture-based Reliability Risk Assessment，ALRRA)是一種軟件架構可靠性風險評估方法，該方法使用動態復雜度準則和動態耦合度準則來定義組件和連接件的復雜性因素，其中，動態復雜度準則在某個場景的執行中分析組件的動態行為來度量組件的復雜性，動態耦合度準則在某個場景的執行中分析連接件的消息傳遞協議來度量連接件的復雜性。利用失效模式和影響分析(FMEA)技術。
- AHP(層次分析法)方法。層次分析法（Analytical Hierarchy Process，AHP）是對定性問題進行定量分析的一種簡便、靈活而又實用的多準則決策方法。AHP方法的特點是把復雜問題中的各種因素通過劃分為相聯系的有序層次使之條理化，并在一般情況下通過兩兩對比，根據一定客觀現實的主觀判斷結構，把專家意見和分析者的客觀判斷結果直接、有效地結合起來，將一定層次上元素的某些重要性進行定量描述，之后利用數學方法計算反映每一層次元素的相對重要性次序的權值，并最后通過所有層次之間的總排序計算所有元素的相對權重及對權重進行排序。
- COSMIC+UML方法。基于度量模型來評估軟件架構可維護性的方法。針對不同表達方式的軟件架構，采用統一的軟件度量COSMIC方法來進行度量和評估。該方法主要是為了輔助分析軟件架構的演化方案是否可行，并在開源軟件DCMMS的軟件架構UML組件圖上得以驗證。
8. 中間件技術
中間件:在一個分布式系統環境中處于操作系統和應用程序之間的軟件，可以在不同的技術之間共享資源，將不同的操作系統、數據庫、異構的網絡環境以及若干應用結合成一個有機的協同工作整體。
中間件位于客戶機/服務器的操作系統之上，管理計算機資源和網絡通信，有如下特點
- 中間件是一類軟件，而非一種軟件;
- 中間件不僅僅實現互連，還要實現應用之間的互操作;
- 中間件是基于分布式處理的軟件，最突出的特點是其網絡通信功能。
中間件的任務是使應用程序開發變得更容易，通過提供統一的程序抽象，隱藏異構系統和分布式系統下低級別編程的復雜度。
主要的中間件有五類:
- 數據庫訪問中間件:通過一個抽象層訪問數據庫，從而允許使用相同或相似的代碼訪問不同的數據庫資源。典型的技術如Windows平臺的ODBC和Java平臺的JDBC等。
- 遠程過程調用(RPC):是一種廣泛使用的分布式應用程序處理方法。一個應用程序使用RPC來“遠程”執行一個位于不同地址空間內的過程，從效果上看和執行本地調用相同。
- 面向消息中間件(MOM):利用高效可靠的消息傳遞機制進行平臺無關的數據交流，并可基于數據通信進行分布系統的集成。通過提供消息傳遞和消息排隊模型，可在分布環境下擴展進程間的通信，并支持多種通信協議、語言、應用程序、硬件和軟件平臺。典型的產品如IBM的MaSeries。
- 分布式對象中間件:隨著對象技術與分布式計算技術的發展，兩者相互結合形成了分布式對象技術，并發展成為當今軟件技術的主流方向。典型的產品如OMG的CORBA、Sun的RMI/EJB、Microsoft的DCOM等。
- 事務中間件:也稱事務處理監控器(TPM)最早出現在大型機上。事務處理監控程序位于客戶和服務器之間，完成事務管理與協調、負載平衡、失效恢復等任務，提高系統的整體性能。
9. 典型應用架構
J2EE核心技術
J2EE 平臺采用了多層分布式應用程序模型，實現不同邏輯功能的應用程序被封裝到不同的構件中，處于不同層次的構件被分別部署到不同的機器中。
四層結構:
- 客戶層組件:J2EE應用程序可以是基于web方式的也可以是基于傳統方式的靜態的HTML(標準通用標記語言下的一個應用)頁面和Applets是客戶層組件。
- Web層組件:J2EEweb層組件可以是JSP 頁面或Servlet。
- 業務層組件:業務層代碼的邏輯用來滿足特定領域的業務邏輯處理。
- 信息系統層:企業信息系統層處理企業信息系統軟件包括企業基礎建設系統例如企業資源計劃(ERP)，大型機事務處理，數據庫系統，和其它的遺留信息系統.例如，J2EE應用組件可能為了數據庫連接需要訪問企業信息系統。
)