場景：我有一個CRM系統和我的應用程序。當在CRM系統中創建新訂單時，myApp應該做一些事情（爲訂單創建一個項目房間），並將一些東西（項目房間地址）寫回CRM系統。所以，也許這是一個我應該去SOA的情況？
因此，我可以使用點對點集成輕鬆實現這一點，myApp託管的服務在完成時會調用CRM中的服務。
問題是：我應該爲增加一些服務總線（額外的代碼，額外的維護）做額外的工作嗎？或者這不是合適的情況？該公司今天沒有服務總線，也沒有整合策略。
如果上述問題的'是'（我有點期待）那麼我應該估計什麼時候包括nServiceBus或rhino-service-bus（（從來沒有嘗試過） ），進入範圍是什麼？你有沒有其他ESB的任何recommandations，或案例研究中，我能讀懂？
感謝所有幫助
問候
Larsi
的問題是，是否不是它是其他系統的商業事件ems可能會關心。如果我以新客戶爲例，營銷系統可能會向他們發送一封電子郵件，然後訂購系統開始處理訂單。
如果這是你可以看到發生的事情，那麼我會使用nservicebus推送pub/sub模型（http://www.eaipatterns.com/ObserverJmsExample.html）。你所要做的就是建立一個處理程序，爲每一個關心的應用程序傾聽一條新的客戶信息，然後用這種方法做你的事情。
另外....你在做什麼是轉向SOA，但你需要更多的東西成爲SOA。 SOA是架構哲學。我們正在討論的pub/sub更多的是使用MoM。
如果您正在考慮轉向SOA架構，在做出溝通決策之前首先要考慮的是您的服務邊界。如果您的應用擁有特定業務功能的實現，這意味着它指定了業務邏輯並且是該功能的權威數據源，那麼它應該是它自己的服務。但是，如果您的應用只是向CRM系統提供幫助功能，那麼在SOA方面，您的應用和CRM都將成爲同一服務的一部分。
開始通過閱讀這篇較短後：http://fafach.wordpress.com/2011/04/20/soa-what-is-a-service/
然後看看這個優秀的介紹SOA視頻：http://www.nservicebus.com/ArchitecturalPrinciples.aspx
你應該到SOA
的主要方面一個區別是有服務，這是主要是設計問題。簡而言之這意味着該服務應該是一種商品，併爲您規劃特定的客戶端不定製..
第二個方面是基礎設施 - 其中可能包括和ESB
如果你有一個單一服務或少量服務，您可以使用簡單的Web服務（無需ESB或其他基礎架構），並且仍然可以獲得SOA的所有好處。 當項目增長時，添加ESB不會比現在添加更難。
另一方面，如果您有難以修改的現有客戶端，那麼在添加更多客戶端時重新設計服務的接口是一個艱難的過程