EJB2.0系統中什么時候需要使用messaging或者RMI/IIOP

小編給大家分享一下EJB2.0系統中什么時候需要使用messaging或者RMI/IIOP，希望大家閱讀完這篇文章之后都有所收獲，下面讓我們一起去探討吧！

EJB2.0系統中什么時候使用messaging或者Rmi/IIOP

以下幾條是messaging的優勢，和你需要去使用它的原因:
1.數據庫性能。如果你去完成一個關系型數據庫工作，如
對一個數據庫持久化一個定單,使用messaging更有優勢。
傳送一個消息到一個二級消息隊列去被晚些時候處理減輕了
在高峰時刻的主數據庫壓力。在早上負荷較低的早上，當
通信量比較小時，你能在消息隊列中取出并處理那個消息
，并把定單插入到數據庫中。注意這只是在用戶無論他的操
作成功與否都不需要馬上的回答時起作用，如檢測他的信用卡。

2.快速反應。一個客戶可能不想去被阻塞并去等待一個不存在的
反映。對于返回void值的方法，只可能什么都不返回或返回一個
異常。如果客戶沒有預料會收到一個異常，為什么非得要會被阻
塞得到一個反應？messaging允許客戶去處理其他事情，當他被
阻塞得到一個方法的返回。

3.平滑的負載平衡。message-driven beans比session和entity
bean更加平滑的分布負載。用session和entity bean,一個負載
平衡算法聰明的猜出哪一個服務器負載更小。用messaging，負載
最小的服務器自己請求message來得到那個message。

4.請求優先。異步服務器能排隊列，設置優先級，并用與meaasge
到達系統不同的順序來處理它們。有一些消息系統允許消息按照
商業規則來被設置優先級來被排序。舉個例子，在一個軍用坦克
中，如果所有的對系統的請求都被發送到集中分發隊列來異步，
那么開炮的命令被排在100個通信消息之后可能帶來災難。在軍用
系統中，在通信消息前先處理開火控制和安全消息將更有優勢。
一個設置了優先級的隊列允許在隊列中的消息重排來計算坦克中
開火控制的緊急性。

5.快速的集合分離的系統。許多已有系統是建立在面向消息的中
間件之上的，并能夠很容易的用messaging來和你的J2EE系統交互。
messaging為商業處理和必須互相通信的分布式節點系統提供一個
快速開發環境。

6.松耦合系統。messaging可以使應用程序之間松散耦合。應用程序
在他們被編譯時無需知道對方。這使你有“動態發現”的應用程序
，可能在快速變化、面向服務的商業環境下有用。

7.并行處理。messaging是一個在EJB發布中使用偽線程的的方法。
你能啟動一系列消息并繼續處理，和分布式的啟動許多線程一樣。

8.可靠性。messaging被使用即使服務器當掉。系統級的錯誤(如
數據庫當掉了)通常不會影響操作的成功，因為消息仍在隊列中
直到系統級的錯誤被解決。

9.多對多通信。如果你有許多團體一起互相通信，messaging是
合適的，因為它使許多生產者和消費者互相協作，而RMI/IIOP
是單源單目的的請求模型。

以下是你不應使用messaging的情況:
1.當你不確定操作是否成功。RMI/IIOP系統能拋出異常，而
message-driven bean不行。

2.當你需要返回結果。RMI/IIOP系統能馬上返回結果，因為
請求是被立即執行的。相反，你能最終通過messaging返回結果，
不過這很讓人郁悶：你需要發送分隔的返回消息，并用初始
的客戶端來監聽它們。

3.當你的操作是一個更大的一個事務的一部分。當你向目的地
發送一個消息，接收到的message-driven bean不能處理其他的
消息直到一個將來的事務。這對你需要這個操作是一個單獨的，
原子的，要處理其他操作的一個事務的一部分來說是不合適的。
舉個例子，當你操作一個銀行帳戶傳送，這時候使用RMI/IIOP
來向一個銀行帳戶存錢是個壞主意，用messaging來取錢也一樣，
因為取錢可能失敗。

4.當你需要把客戶的安全ID傳給服務器。因為messaging不把
客戶的安全ID傳給接收的message-driven bean,你不能容易的
保證你的商業操作的安全性。

5.當你關心請求性能。messaging天生的比RMI/IIOP慢，因為
有一個在發送者和接收者之間的中介人(JMS)。

6.當你需要一個強類型，OO的系統。你通過使用messaging api
如JMS來發送消息。這是一個平滑的API而且不是面相對象的。
當你想要完成不同操作，服務器需要crack打開的消息，或
把它濾掉。與之相比，RMI/IIOP讓你基于你想操作的商業操作
來調用不同的商業方法。這個更直覺；也更容易做編譯時的
語意檢查。

7.當你需要更緊密，更直接的系統。同步發布比messaging
更直接。你有巨大的自由什么時候發送數據類型，和你需要寫
的和messaging比較最少的代碼量。調試也更直接。當使用
完全同步的服務，每個客戶端控制線程有一個單獨的能被跟
蹤的從客戶端到服務器的路徑，相反亦然。當系統有bug時，
需要跟蹤它們的努力也是最小的。

看完了這篇文章，相信你對“EJB2.0系統中什么時候需要使用messaging或者RMI/IIOP”有了一定的了解，如果想了解更多相關知識，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！