EJB2.0系統(tǒng)中什么時(shí)候需要使用messaging或者RMI/IIOP

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

EJB2.0系統(tǒng)中什么時(shí)候使用messaging或者Rmi/IIOP

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

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

3.平滑的負(fù)載平衡。message-driven beans比session和entity
bean更加平滑的分布負(fù)載。用session和entity bean,一個(gè)負(fù)載
平衡算法聰明的猜出哪一個(gè)服務(wù)器負(fù)載更小。用messaging，負(fù)載
最小的服務(wù)器自己請(qǐng)求message來(lái)得到那個(gè)message。

4.請(qǐng)求優(yōu)先。異步服務(wù)器能排隊(duì)列，設(shè)置優(yōu)先級(jí)，并用與meaasge
到達(dá)系統(tǒng)不同的順序來(lái)處理它們。有一些消息系統(tǒng)允許消息按照
商業(yè)規(guī)則來(lái)被設(shè)置優(yōu)先級(jí)來(lái)被排序。舉個(gè)例子，在一個(gè)軍用坦克
中，如果所有的對(duì)系統(tǒng)的請(qǐng)求都被發(fā)送到集中分發(fā)隊(duì)列來(lái)異步，
那么開炮的命令被排在100個(gè)通信消息之后可能帶來(lái)災(zāi)難。在軍用
系統(tǒng)中，在通信消息前先處理開火控制和安全消息將更有優(yōu)勢(shì)。
一個(gè)設(shè)置了優(yōu)先級(jí)的隊(duì)列允許在隊(duì)列中的消息重排來(lái)計(jì)算坦克中
開火控制的緊急性。

5.快速的集合分離的系統(tǒng)。許多已有系統(tǒng)是建立在面向消息的中
間件之上的，并能夠很容易的用messaging來(lái)和你的J2EE系統(tǒng)交互。
messaging為商業(yè)處理和必須互相通信的分布式節(jié)點(diǎn)系統(tǒng)提供一個(gè)
快速開發(fā)環(huán)境。

6.松耦合系統(tǒng)。messaging可以使應(yīng)用程序之間松散耦合。應(yīng)用程序
在他們被編譯時(shí)無(wú)需知道對(duì)方。這使你有“動(dòng)態(tài)發(fā)現(xiàn)”的應(yīng)用程序
，可能在快速變化、面向服務(wù)的商業(yè)環(huán)境下有用。

7.并行處理。messaging是一個(gè)在EJB發(fā)布中使用偽線程的的方法。
你能啟動(dòng)一系列消息并繼續(xù)處理，和分布式的啟動(dòng)許多線程一樣。

8.可靠性。messaging被使用即使服務(wù)器當(dāng)?shù)?。系統(tǒng)級(jí)的錯(cuò)誤(如
數(shù)據(jù)庫(kù)當(dāng)?shù)袅?通常不會(huì)影響操作的成功，因?yàn)橄⑷栽陉?duì)列中
直到系統(tǒng)級(jí)的錯(cuò)誤被解決。

9.多對(duì)多通信。如果你有許多團(tuán)體一起互相通信，messaging是
合適的，因?yàn)樗乖S多生產(chǎn)者和消費(fèi)者互相協(xié)作，而RMI/IIOP
是單源單目的的請(qǐng)求模型。

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

2.當(dāng)你需要返回結(jié)果。RMI/IIOP系統(tǒng)能馬上返回結(jié)果，因?yàn)?br/>請(qǐng)求是被立即執(zhí)行的。相反，你能最終通過(guò)messaging返回結(jié)果，
不過(guò)這很讓人郁悶：你需要發(fā)送分隔的返回消息，并用初始
的客戶端來(lái)監(jiān)聽它們。

3.當(dāng)你的操作是一個(gè)更大的一個(gè)事務(wù)的一部分。當(dāng)你向目的地
發(fā)送一個(gè)消息，接收到的message-driven bean不能處理其他的
消息直到一個(gè)將來(lái)的事務(wù)。這對(duì)你需要這個(gè)操作是一個(gè)單獨(dú)的，
原子的，要處理其他操作的一個(gè)事務(wù)的一部分來(lái)說(shuō)是不合適的。
舉個(gè)例子，當(dāng)你操作一個(gè)銀行帳戶傳送，這時(shí)候使用RMI/IIOP
來(lái)向一個(gè)銀行帳戶存錢是個(gè)壞主意，用messaging來(lái)取錢也一樣，
因?yàn)槿″X可能失敗。

4.當(dāng)你需要把客戶的安全I(xiàn)D傳給服務(wù)器。因?yàn)閙essaging不把
客戶的安全I(xiàn)D傳給接收的message-driven bean,你不能容易的
保證你的商業(yè)操作的安全性。

5.當(dāng)你關(guān)心請(qǐng)求性能。messaging天生的比RMI/IIOP慢，因?yàn)?br/>有一個(gè)在發(fā)送者和接收者之間的中介人(JMS)。

6.當(dāng)你需要一個(gè)強(qiáng)類型，OO的系統(tǒng)。你通過(guò)使用messaging api
如JMS來(lái)發(fā)送消息。這是一個(gè)平滑的API而且不是面相對(duì)象的。
當(dāng)你想要完成不同操作，服務(wù)器需要crack打開的消息，或
把它濾掉。與之相比，RMI/IIOP讓你基于你想操作的商業(yè)操作
來(lái)調(diào)用不同的商業(yè)方法。這個(gè)更直覺；也更容易做編譯時(shí)的
語(yǔ)意檢查。

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

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