IBM Cast Iron 和 ESB
我正在尝试为我的公司定义集成架构路线图，并且正在寻找有关我的方法的一些指导。
我们的大多数应用程序 (90-95%) 都基于 .NET 和 Microsoft SQL Server 2008。我们在 Salesforce 中拥有销售云，并计划在未来几年将更多应用程序迁移到 Salesforce（到 Force.com 平台）。我们购买了 IBM Cast Iron，用于将我们的本地应用程序与 Salesforce 集成，并可能集成到我们的本地应用程序中。现在，在分析了现有应用程序和现有集成（临时 - SQL 作业、Windows 服务等）之后，我觉得我们需要一个 ESB，因为我意识到我们有多种方式与应用程序对话（ FTP、Web 服务、CSV/Excel、SQL）。尽管 Cast Iron 可以采用任何类型的格式并且可以进行 Web 服务、FTP 等通信...，但我担心将 Cast Iron 定位为核心集成平台，因为这将成为代理架构（类似于 Hub and Spoke）遵循传统的 EAI 方法，随着编排的增加，该方法可能会出现单点故障和性能问题。
通过引入 ESB，我认为我将至少获得以下好处：
- 可扩展性
- 可靠性
- 高性能
附图反映了此场景的简化版本。该架构将来还可以通过在 ESB 上提供 SOA 来扩展。
现在我的担忧/问题是：
- 既然 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 的消息存储发布消息的最佳方式是什么？
我知道我在这里问了很多问题，可能有也可能没有直接答案。我很高兴听到大师们的观点。
I'm trying to define the integration architecture roadmap for my company and I'm looking for some guidance on my approach.
Most (90-95%) of our applications are based on .NET with Microsoft SQL Server 2008. We have sales cloud in Salesforce and planning to migrate more applications (to Force.com platform) Salesforce in the coming years. We bought IBM Cast Iron for integrating our on-premise applications with Salesforce and possibly within our on-premise applications. Now after analyzing the existing applications and the existing integration (ad-hoc - SQL jobs, windows services,...), I felt that we needed an ESB as I realized that we have multiple ways that we use to talk with the applications (FTP, Web Services, CSV/Excel, SQL). Though Cast Iron can take any type of formats and can talk Web Services, FTP, etc..., I'm concerned about positioning the Cast Iron as the core integration platform as this will become a broker architecture (similar to Hub and Spoke) that follows traditional EAI approach which may suffer from single point of failure and performance issues as the orchestrations increase.
By introducing ESB, I think I'll achieve at least the following benefits:
- Scalability
- Reliability
- High performance
The attached diagram reflects a simplified version of this scenario. This architecture can also be expanded in future by providing SOA over the ESB.
Now my concerns/questions are:
- Since Cast Iron is an orchestration tool, which one should I use for orchestrations? Is it Cast Iron or the ESB?
- Cast Iron can only talk to JMS/IBM MQ and cannot talk to Microsoft Messsage Queue. So, should we go with java based ESB like Mule (with Active MQ) or Service Mix?
- What are my options for .NET based ESB (other than Microsoft Biztalk and NServiceBus), which is reliable and most widely used?
- What's the best practice on bulk data movement? Usually, this can be done through SSIS. In our case, we may have to move bulk data to cloud on periodical basis.
- What's the best way to publish messages to JMS based message store from .NET applications?
I know I have asked many questions here and may or may not have direct answers. I would be glad to hear the views from the gurus.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
1）这要看情况。铸铁非常适合快速的内部/外部集成/编排。有关外部/SaaS 服务的编排很自然地可以在 CI 中进行编排。没有明确的答案，“这取决于”。
2-3) 由于您已经拥有 WebSphere 组件，因此我尝试与 .NET 和消息传递 (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)，这也适用于大多数其他供应商。
1) It depends. Cast Iron is good for rapid on/off premiss integrations/orchestrations. Orchestrations concerning external/SaaS services would be natural to orchestrate in CI. There is no clear answer, "it depends".
2-3) Since you have WebSphere components already, a good solution I tried integrating with .NET and Messaging (IBM WebSphere MQ) is WebSphere Message Broker 8. It has built in support to run embedded .NET code. For instance, you could fire up Visual Studio and then import a service reference, and just invoke it straight away, while still having a full scale (java compatible) ESB. The express edition is a bit cheaper, but somewhat limited. Using the underlying WebSphere MQ would give you .NET client support and very good integration with Cast Iron. You also mention ServiceMix, which essentially is an OSGi container around ActiveMQ and Camel. It's a powerful open source ESB. Mule ESB CE + ActiveMQ would be rather similar, it's not really a deal breaker which of those you choose. ActiveMQ have support for .NET clients as well and is often underestimated as enterprise JMS broker.
4) Bulk data. My experience is that this is a very complex topic that there is no best answer to in all scenarios.
5) There is no generic solution for JMS -> .NET connectivity. It does not work, without bridging components running on JVM. However, most JMS implementations offer similar, but non standard, APIs for .NET clients. Both WebSphere MQ (XMS) and ActiveMQ (NMS), this goes for most other vendors as well.