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，此架构也可以在未来进行扩展。

现在我的担忧/问题是：

• 由于Cast Iron是一个业务流程工具，我应该将哪一个用于业务流程？是Cast Iron还是ESB？
• Cast Iron只能与JMS / IBM MQ通信，无法与Microsoft Messsage Queue通信。那么，我们应该使用基于Java的ESB，如Mule（使用Active MQ）还是Service Mix？
• 基于.NET的ESB（Microsoft Biztalk和NServiceBus除外）有哪些选择，哪些是可靠且使用最广泛的？
• 批量数据移动的最佳做法是什么？通常，这可以通过SSIS完成。在我们的案例中，我们可能需要定期将批量数据移至云端。
• 从.NET应用程序向基于JMS的消息存储库发布消息的最佳方法是什么？

我知道我在这里问了很多问题，可能有也可能没有直接答案。我很高兴听到大师们的意见。

Answer 1

1）这取决于。 Cast Iron适用于快速开/关premiss集成/编排。有关外部/ 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没有通用的解决方案 - ＆gt; .NET连接。如果没有桥接在JVM上运行的组件，它就无法工作。但是，大多数JMS实现为.NET客户端提供了类似但非标准的API。无论是WebSphere MQ（XMS）还是ActiveMQ（NMS），这都适用于大多数其他供应商。

Answer 2

我还认为，通过为您的架构引入ESB将导致可扩展和可扩展的系统。 如果您对基于Java的ESB感兴趣，WSO2 ESB [1]（WSO2 ESB基于OSGI的WSO2 Carbon平台及其100％免费和开源）是一个不错的选择。但是，WSO2不仅仅是一个ESB，而且提供了一个完整的SOA平台（也可以作为云中的PaaS）。

由于使用ESB时获得的优势，您可以将其用作业务流程组件。

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