J2EE交易框架

2019-11-18 16:21:23

字體：大中小

來源：轉載

供稿：網友

J2EE交易框架：構建框架by Dibyendu Baksi
04/26/2001
緒論
        廉價的計算能力和不斷增加的網絡帶寬促進了以組件為基礎的分布式計算程序的發展。以組件為基礎的分布式程序是一個服務架構。它由物理上獨立的計算機上的不同的應用組件構成。對用戶來說，它們就像是運行在一臺機器上的單一應用程序。有幾個因素促進了分布式系統的應用，而不是傳統的集中式系統。
·        分布式應用：一些任務本身就是分布的。這個特性決定需要多個agent合作工作。在這種情況下，定位和獲取有效的和最需要的計算能力及數據具有優先權。
·        可靠性：因為系統的共享、合作和分布的特性，系統中不存在一個單個的失敗點。使用新的容錯、恢復和分布同步技術，更好的可靠性可以得到滿足。
·        可擴展性：對應用的需求日益繁多，正確的設計系統，就可以通過增加新的服務和硬件來處理更多的負載。
·        性能：由于處理涉及到更多的應用范圍，這些難題從本質上講越來越復雜。為了解決日益復雜的問題，我們需要更快的計算機，這些計算機在可以接受的價格下具有更高的計算能力。
·        經濟性：獲取相同等級的計算能力，使用分布在多臺機器的系統其費用可以更低一些
        對于用戶來說，通過網絡互連的異構計算機上的異構應用系統就像是在單臺物理機器上的標準的應用系統。要達到這樣的透明度，分布是系統需要在如下方面做到透明。
·        數據定位：對于系統用戶來說，他們不需要知道數據位于網絡中的哪一個地方
·        失敗：對系統用戶來說，他們不需要關注數據的一致性
·        復制：系統用戶不需要知道數據是如何被復制的
·        分布：系統用戶不需要知道計算能力和數據如何通過系統被分布的
        分布式系統允許用戶透明的保存、存取和操作來至多個計算機的數據，能在系統發生故障的時候維持數據的完整性。對分布式數據和交易的管理分成本地和全局兩個級別。本地數據管理者或資源管理者能夠訪問和操作本地數據和資源。資源管理者提供了數據的透明定位，數據模型和數據庫的安全與授權控制。本地的交易管理器負責處理計算系統交易的初始化、監控和終止。分布式交易系統將網絡中相關的交易視為單一交易從而擴展了本地交易系統的范圍。
交易是一組語句的集合表示一個工作單元，他們必須作為一個單元被執行。交易是位于資源上的操作的一個序列比如讀、寫或是更新。這些操作序列將系統由一個穩定態轉化為新的穩定態。為了真實的反映系統中的實體，一個交易應該具有下面的特性：
·        原子性：這個特性指全部都做或是全部都不做。操作序列或者是成功或者是失敗。一個交易應該被認為是一個單一的操作單元。完成的交易應該被提交，沒有完成的交易應該被回滾或是恢復為它的開始狀態。絕不可能只有部分工作被提交。
·        一致性：一個交易反映了資源之間的一種連續性。一致性關心的是正確反映資源狀態的事實。一致性的例子有數據庫的完成性、表格中主鍵的唯一性等。
·        獨立性：一個交易在它提交前不應該將自己的結果暴露給其它并發的交易。獨立性確保不會去訪問正被更新的數據。獨立性的另一個名字是序列化。
·        持久性：一個完成的交易的結果應該被保存下來，不能因為系統錯誤而從數據庫中清除掉。資源管理者應該確保系統失敗的時候交易的結果不會被改變。

交易處理的基本原理
為了反映實體的真實狀態，每一個交易都應該具有上述四種特性。集中式計算環境的應用組件和資源被定位到一臺單個的機器上，交易管理僅僅包括一個運行在單一機器上的本地的數據管理者。與此不同，分布式計算環境中所有的資源被分布在多個系統中。在這種情況下，交易管理包括兩個級別本地和全局。一個本地交易包括單個本地資源管理中的活動。一個分布式或是全局的交易在多個系統中被執行。它執行需要全局交易管理系統和所以涉及到的系統的本地數據管理者協同工作。資源管理者和交易管理者，也是作為交易處理監控者是一個交易系統的兩個主要的元素。在一個集中式系統中，交易處理監視器和資源管理者被集成到DBMS服務總。為了支持以組件為基礎的分布式系統更高級的特性，將TP監視器從資源管理者中分離出來是必要的。

交易管理分類
交易性企業系統的最通常的結構如下：
·        小模式TP：這種結構不需要任何獨立的交易管理中間件。每一個SQL語句都被認為是一個單獨的交易
·        這種方式使用數據庫的存儲過程來處理更新。由于多數的RDBMS提供商提供一些集成的TP工具，每一個交易都被定義為一個存儲過程。這種方式帶有一個復制服務器。主服務器數據通過存儲過程來更新，第二份數據通過使用復制服務器來被復制。
·        大模式TP：這種方式被用于企業級別的交易系統。它需要對原有系統提供一個接口。它使用一個分布式的交易管理器來處理交易更新。它分為兩個子類，一種，使用一個獨立的交易管理器，例如CICS，Encina，Tuxedo或是TopEnd.第二種，TP監視器被放入到應用服務器中像Websphere或iplanet應用服務器或是微軟的交易服務器。

有兩種方式用來說明交易。
·        計劃式：在計劃式交易規范中，一組或是一個操作序列被定義成一個交易。最通常的方式是標記那些執行交易處理操作的線程。交易可以通過取消標記被掛起。通過明確的復制交易上下文（叢掛起點到重新啟動點）稍后重新啟動交易。提交請求指揮所有參與的資源管理器永久記錄交易操作產生的影響。回滾請求讓資源管理器撤銷交易操作的影響。
·        宣稱式：以組件為基礎的交易處理系統，像基于EJB的應用服務器和微軟的交易服務器的COM，支持declarative交易規范。這種方式，在配置的時候，組件被標記為一個交易。這有兩方面的含義。首先，交易的職責從應用程序轉移到組件的宿主容器。第二，交易的有效時間從應用程序的構建延后到了組建配置的時候。

交易繁殖(PRopagation)
        一個全局或是分布式交易由一些子交易組成，它被作為一個單一的可重獲取的原子單元。全局交易管理器的責任是通過調整不同的資源管理器來訪問在不同系統中的數據從而管理分布式交易。由于在一個交易中有多個應用組件和資源參與，所以交易管理器應該在交易發生的時候建立和記錄下交易的狀態。這個功能可以通過使用交易上下文來取得。交易上下文是資源上的交易操作和調用這些操作的組件間的一個紐帶。在交易發生過程中，所有參與交易的線程共享相同的交易上下文。在一個交易過程中，交易上下文的范圍邏輯上包裹了所有執行在交易資源上的操作。交易管理器需要分析交易請求并將交易分解成多個子交易，復制交易上下文，并將他們發送給相關聯的資源管理者。在資源管理者的控制下，交易上下文通常來說是透明存在的。

資源管理器依靠稱之為資源服役這一過程來通知交易管理器自己加入了交易。交易管理器保持了交易中加入的所有的資源的軌跡，通過兩段式提交和恢復協議調整資源管理者的交易工作表現。在交易的最后，無論是提交還是回滾，所有被使用的資源都要被刪除掉。交易管理者必須要監控交易的執行決定提交還是回滾交易的變化以確保交易的原子性。

兩段式提交
交易管理者和所有交易有關的資源中的兩段式提交協議確保了資源管理者或是提交或是放棄交易。如下圖所示，當應用程序發送交易提交請求的時候，交易管理者發送PREPARE_TO_COMMIT請求給所有被調用的資源管理者。所有的資源管理者順次發送一個應答表明自己是否做好提交的準備。僅僅當所有的資源管理者都準備好提交，交易管理者發送一個提交請求COMMIT給所有的資源管理者。或者，交易管理者發送一個回滾請求(ABORT)給資源管理者，交易被回滾。
        雖然2PC保證了交易的自治，但必需的處理負載太重，經常產生更新沖突，特別是存在重復數據的時候。數據復制是減少沖突的一個方式，僅僅在基于交易的更新繁殖不是必需的時候有用。多數分布式系統平行的采用這兩種方式相應匹配應用程序的需求。

        在兩段式提交(2PC)和復制服務器方法間是品衡的。兩者基本不同之處在于交易級上的一個操作和另一個操作是周期性的更新。指導方針是1）盡可能小的保持數據復制2）如果數據作為一個交易需要同步，拷貝數量少并使用2PC，3）4）如果網絡和節點不可靠，使用復制服務器。
同步控制是另一個至關重要的功能。它允許多個用戶同時訪問數據，增加了系統的吞吐量和執行。在取得同一個邏輯結果的時候，系統允許交易同步進行好像他們是連續地執行的。合作控制同意多個交易同時讀和更新數據，它包括交易調度和交易執行期所需資源的管理。大多數交易的串行化都是依靠鎖機制，比如兩段式鎖方法，時間磋方法。兩段式鎖算法是最通常的應用在分布式交易系統中的技術可以取得同步更新和合作控制。通常，供應商結合合作控制技術比如2PL，一致性控制技術如2PC，超時控制為了解決死鎖，結合成一個單一的實現為全局分布式交易管理。

隊列式交易處理
        直接交易過程是同步的，起初交易創建者被阻塞直到交易管理器開始運行為止。不幸的是，交易的客戶端或是服務端通信有時候會失敗。有時候，有些交易的請求等級有很高，需要優先處理。這種同步交易處理模式無法很好的處理這些情況。這導致了使用隊列的異步交易處理模式的發展。隊列是一種交易資源，隊列上的操作包括入隊和出隊。在J2EE平臺定義了兩種機制處理隊列。一種是使用原生JMS API，另一種是利用消息Bean，它被定義在EJB2.0中。
交易中的JMS API
應用組件的開發者不應該在單一交易里使用JMS請求-應答范例。直到交易被提交，一個JMS消息不會被投遞給它的最終目標，在同一個交易里應答的接受決不會發生。因為一個容器管理著一個代表bean的JMS會話的交易。createQueuesession(boolen transacted, int acknowledgeMode)和createTopsession（booleantransacted, int acknowledgeMode）方法的參數被忽略。我們建議組件開發者指定一個被處理過的會話提供0作為acknowledgement的值。記住JMS的acknowledge()方法無論是在一個交易里還是在一個沒有指明的交易上下文都不該使用，這一點很重要。在一個未確定的交易上下文消息的確認是通過帶有JMS AUTO_ACKNOWLEDGE符號的容器來處理的。

message-driven beans
消息驅動beans
        一個消息驅動bean是一個異步消息的消費者，當一個JMS消息到達時由容器來調用。從客戶的角度看，消息驅動bean是一個JMS消息的消費者它在服務器端完成了一些業務邏輯。客戶經由JMS通過發送消息給JMS目標（隊列或是主題）來訪問消息驅動bean，因為消息驅動bean類是一個消息監聽者。消息驅動bean沒有home和remote接口，它是無狀態的。它們像無狀態的session bean：當他們沒有包括在服務一個客戶端的消息中，所有的bean實例都是一樣的。一個消息驅動bean實例由容器創建作為消費者處理消息過程。容器控制它的生命期。然而，實例消息驅動bean的實例的實例變量可以通過客戶端的消息操作維持自己的狀態。
        這種情況包括一個開放的數據庫連接和一個對EJB對象的引用。消息驅動的bean模式正發展成為一個企業bean，它被異步調用來處理接受的JMS消息。對它的開發工作如同其他的JMS消息監聽器一樣簡單。依靠容器提供的消息驅動bean實例池，它也可以同時處理一串消息。
標準
        分布式TP環境的透明目標要求交易管理者和帶有資源管理者的TMs之間應該具有協同工作的能力。目前，有兩個開放標準，即X/Open DTP模式和ISO TP模式。對一個開放環境中來至不同提供者的交易管理者可以通過ISO TP協議互相通信。ISO TP并沒有太多的追隨者。另一個方面，X/Open分布式交易處理模式是由一個開放組織提出的標準。目前多數商業化的交易處理和關系數據庫解決方案提供商都遵循這個標準。這個模式主要原理：
·        應用組件實現了交易操作
·        資源管理器來控制資源
·        交易管理者和資源管理者協同處理一個全局交易
下面是這個模式特別被提及的主要方面
·        TX接口：這個接口位于請求和交易管理者之間由交易管理者實現。它通過將應用程序組件和交易操作綁定的方式來提供交易的劃分服務。
·        XA接口：這個接口位于資源管理者和交易管理者之間。當交易管理者（或TP監視器）和RDBMS或是EIS的資源管理器都支持XA接口時，他們能夠被組織在一起被處理。這是標準中最重要的借口已經被業界所接受
Figure 3. X/Open DTP standard
X/Open DTP模式在工業界已廣泛的使用。商業化的交易管理軟件像TXSeries/Encina， Tuxedo，TopEnd和AT&T GIS都支持TX接口。大多數的商業化數據庫如Oracle，Sybase，Informix和微軟的SQL Server和消息中間件產品如IBM的MQSeries和微軟的MSMQ Server都實現了XA接口。
Some J2EE configurations

一些j2ee結構
        J2EE是一個基于架構的框架。對交易的支持是J2EE架構的主要方面。組件提供者能夠利用java交易API(JTA)在組件代碼中提供交易邊界。另一方面，隨著支持企業beans的交易規范的公布，交易能夠由容器自動的開始和完成。J2EE服務器在低層實現了交易管理者和支持JDBC API的數據庫系統的通信協議，包括交易上下文的復制機制和可選的分布式兩段式提交。J2EE平臺目前支持扁平式交易，這種交易中不能嵌套交易。存在這種可能性，一個交易請求使用serverlets和jsp頁面在一個交易中訪問多種EJB。每一個組件允許獲得一個或多個連接以訪問一個或多個資源管理器
Figure 4. Recommended J2EE configurations.
需要強調的是雖然對一個特定的應用可能有多個解決方案供選擇。不同，在所有可能的配置方案中，我們強烈推薦以下幾種
·        Case I: Stand-alone Client <-> EJB Container <-> RDBMS/EIS Resources
這種結構是從兩層客戶服務器模式中變化而來。一般來說，存在一個利用Swing寫成的胖客戶端,它直接和EJB中的商業邏輯通信。這個EJB位于應用服務器中的某個EJB容器中。
·        Case II: Browser <-> Web Container <-> RDBMS/EIS Resources
這種配置在一個小規模的web應用程序中很普遍。支持的用戶數相對較少，對于一個組織中的內部企業互聯網系統來說很適用
·        Case III: Browser <-> Web Container <-> EJB Container <-> RDBMS/EIS Resources
對于一個有大量用戶需要良好性能的系統來說，這個結構是一個值得推薦的完整的架構，這種應用具有魯棒性和可伸縮性。
Dibyendu Baksi 是sun公司的一個J2ee交易系統和框架的設計者和開發者進入討論組討論。

（出處：http://m.survivalescaperooms.com）

上一篇：J2EE中的異常管理及錯誤跟蹤

下一篇：j2ee設計模式：CMP到BMP模式（一）