4

我正在尝试为我的公司定义集成架构路线图，并且正在寻找有关我的方法的一些指导。

我们的大多数 (90-95%) 应用程序都基于带有 Microsoft SQL Server 2008 的 .NET。我们在 Salesforce 中拥有销售云，并计划在未来几年迁移更多应用程序（到 Force.com 平台）Salesforce。我们购买 IBM Cast Iron 是为了将我们的本地应用程序与 Salesforce 以及可能在我们的本地应用程序中集成。现在，在分析了现有应用程序和现有集成（即席 - SQL 作业、Windows 服务......）之后，我觉得我们需要一个 ESB，因为我意识到我们有多种方式可以用来与应用程序通信（ FTP、Web 服务、CSV/Excel、SQL）。虽然 Cast Iron 可以采用任何类型的格式，并且可以使用 Web 服务、FTP 等...，但我

通过引入 ESB，我想我至少会获得以下好处：

  • 可扩展性
  • 可靠性
  • 高性能

所附图表反映了此方案的简化版本。将来还可以通过在 ESB 上提供 SOA 来扩展此架构。

在此处输入图像描述

现在我的担忧/问题是：

  • 由于 Cast Iron 是一种编排工具，我应该使用哪个进行编排？是铸铁还是 ESB？
  • Cast Iron 只能与 JMS/IBM MQ 对话，而不能与 Microsoft 消息队列对话。那么，我们应该使用基于 Java 的 ESB，比如 Mule（使用 Active MQ）还是 Service Mix？
  • 对于可靠且使用最广泛的基于 .NET 的 ESB（Microsoft Biztalk 和 NServiceBus 除外），我有哪些选择？
  • 批量数据移动的最佳实践是什么？通常，这可以通过 SSIS 完成。在我们的案例中，我们可能必须定期将批量数据移动到云中。
  • 将消息从 .NET 应用程序发布到基于 JMS 的消息存储的最佳方式是什么？

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

4

1 回答 1

3

1）这取决于。Cast Iron 有利于快速开/关前提集成/编排。与外部/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 支持 .

4) 批量数据。我的经验是，这是一个非常复杂的话题，在所有情况下都没有最佳答案。

5) JMS -> .NET 连接没有通用解决方案。如果没有桥接在 JVM 上运行的组件，它就不起作用。但是，大多数 JMS 实现都为 .NET 客户端提供了类似但非标准的 API。WebSphere MQ (XMS) 和 ActiveMQ (NMS) 都适用于大多数其他供应商。

于 2012-09-08T18:36:39.413 回答