IBM Cast Iron和ESB

Question

我正在嘗試爲我的公司定義集成架構路線圖，並且正在尋找一些關於我的方法的指導。

我們的應用程序大多數（90-95％）都基於.NET和Microsoft SQL Server 2008.我們在Salesforce中銷售雲，並計劃在未來幾年將更多應用程序遷移到Force.com平臺Salesforce。我們購買了IBM Cast Iron，以將我們的內部部署應用程序與Salesforce集成，並可能在我們的內部部署應用程序中集成。現在，在分析了現有的應用程序和現有的集成（ad-hoc-SQL作業，windows服務......）之後，我覺得我們需要一個ESB，因爲我意識到我們有多種方式來與應用程序進行對話FTP，Web服務，CSV/Excel，SQL）。儘管Cast Iron可以採用任何格式並可以與Web服務，FTP等進行對話，但我擔心Cast Iron將成爲核心集成平臺，因爲這將成爲代理體系結構（類似於Hub和Spoke）它遵循傳統的EAI方法，隨着業務流程的增加，可能會遭遇單點故障和性能問題。

通過引入ESB，我想我會達到至少以下好處：

• 可擴展性
• 可靠性
• 高性能

所附的圖反映的簡化版本這種情況。未來，通過在ESB上提供SOA，此架構也可以進行擴展。

現在我的顧慮/問題是：

• 由於鑄鐵是一種協調工具，我應該使用業務流程哪一個？它是鑄鐵還是ESB？
• Cast Iron只能與JMS/IBM MQ通話，無法與Microsoft Messsage隊列通信。那麼，我們應該使用基於Java的ESB，如Mule（使用Active MQ）還是Service Mix？
• 對於基於.NET的ESB（Microsoft Biztalk和NServiceBus除外），我可以選擇哪種方法，這是可靠和最廣泛使用的方法？
• 大容量數據移動的最佳做法是什麼？通常，這可以通過SSIS完成。在我們的情況下，我們可能必須定期將批量數據移動到雲端。
• 從.NET應用程序向基於JMS的消息存儲發佈消息的最佳方式是什麼？

我知道我在這裏問過很多問題，可能有也可能沒有直接的答案。我很樂意聽到大師的意見。

Answer 1

我也認爲，通過爲您的架構引入ESB將導致可擴展和可擴展的系統。 如果您對基於Java的ESB感興趣，WSO2 ESB [1]（WSO2 ESB基於基於OSGI的WSO2 Carbon平臺及其100％免費和開放源代碼）是一個不錯的選擇。但是，WSO2不僅僅是一個ESB，而是提供了一個完整的SOA平臺（也可以在雲中用作PaaS））。

由於您在使用ESB時獲得的優勢，因此可以將其用作業務流程組件。

[1] http://wso2.com/products/

Answer 2

1）這取決於。鑄鐵適用於快速開/關預設集成/編排。有關外部/ SaaS服務的協調在CI中是很自然的。沒有明確的答案，「這取決於」。 2-3）由於您已經有了WebSphere組件，我嘗試將.NET和Messaging（IBM WebSphere MQ）集成到一個很好的解決方案中，就是WebSphere Message Broker 8.它已經構建支持運行嵌入式.NET代碼。例如，你可以啓動Visual Studio，然後導入一個服務引用，並直接調用它，同時仍然具有全尺寸（兼容Java）的ESB。快遞版有點便宜，但有一點限制。使用底層WebSphere MQ將爲您提供.NET客戶端支持，並與Cast Iron進行非常好的集成。你還提到了ServiceMix，它本質上是一個圍繞ActiveMQ和Camel的OSGi容器。它是一個功能強大的開源ESB。 Mule ESB CE + ActiveMQ將會非常相似，它並不是真正意義上的選擇。 ActiveMQ也支持.NET客戶端，並且經常被低估爲企業JMS代理。

4）批量數據。我的經驗是，這是一個非常複雜的話題，在所有情況下都沒有最好的答案。

5）JMS沒有通用的解決方案 - > .NET連接。它不起作用，不會橋接運行在JVM上的組件。但是，大多數JMS實現爲.NET客戶端提供了類似但非標準的API。 WebSphere MQ（XMS）和ActiveMQ（NMS）都適用於大多數其他供應商。