0

我们有一个遗留系统，它生成的文件每个都包含数百条消息（金融交易）。我们需要将这些消息转换为另一种格式并（单独）将它们提交到目标系统。问题是：ESB 是否应该直接接受这些文件进行处理，或者是否应该在遗留系统和 ESB 之间存在一个适配器应用程序，它将接收到的文件拆分为单独的消息并让 ESB 单独处理消息（而不是处理整个文件)?

在第一个解决方案中，我们期望两个 ESB 流。第一个将文件转换为新格式，将其拆分为消息，并将这些消息存储到临时位置。转换需要将文件作为一个整体进行处理，因为该文件包含转换单个消息所需的一些公共部分。第二个流程将获取单独的转换消息（每个都在一个单独的 DB 事务中），将它们传递给目标系统，并等待它的答案（同步或异步）。

第二种解决方案将用一个外部应用程序替换第一个流，该应用程序将转换文件，将其拆分为单独的转换消息，并将它们存储在临时位置（本地文件系统）。第二个流将保留在 ESB 中。

在我们看来，第一种解决方案的缺点在于 ESB 必须处理大文件（在第一个流程中），这通常被认为是一种反模式。另一方面，ESB 会直接适应遗留系统的接口，这是 ESB 的目的之一。

在第二种解决方案中，适配器应用程序将包含转换逻辑，这应该是 ESB 的另一个目的和职责。

对于这种情况（模式），通常建议的解决方案是什么？您能否提供一些比我找到的这两个链接更具描述性的参考资料？

http://publib.boulder.ibm.com/infocenter/esbsoa/wesbv7r5/index.jsp?topic=%2Fcom.ibm.websphere.wesb.programming.doc%2Ftopics%2Fesbprog_patterns.html

https://www.ibm.com/developerworks/wikis/display/esbpatterns/File+Processing

编辑 另一个参考： http ://www.ibm.com/developerworks/webservices/library/ws-largemessaging/

4

2 回答 2

0

请记住，SOA 中有 3 种消息类型：命令、事件、文档

该“文档”位用于数据块。它可能更适合“订单”或“发票”等“真实”文档类型，但没有什么能阻止您使用“TransactionBatch”。

话虽如此，它是一种相当未使用的消息类型，因为实际上并没有多少服务总线围绕它实现任何东西，因为：

  • 你真的不需要它
  • 许多消息队列技术对消息大小有限制（低至 4kb），因此难以传输任何大消息（需要分块发送）

所以我在你的场景中要做的是有一个处理文件的端点。因此，类似于ProcessTransactionFileCommand发送到处理端点的内容，在其中您只有对实际文件的引用（存储在文件系统中的某处，甚至是要从中下载的 url）。该处理端点可以处理文件并将单个消息（全部在事务中）发送到将消息发送到外部系统的集成端点。你可以SendTransactionCommand这样做。

通过这种方式，您的系统非常灵活，因为集成端点可以从解决方案的某些部分接收单独的集成命令，而处理端点可以处理批处理并将它们拆分为单独的集成命令。

如果您在 .NET 领域，您可能想查看我的 FOSS 服务总线项目：http ://shuttle.codeplex.com/

但是任何服务总线都可以解决问题（MassTransit、NServiceBus 等）

于 2012-10-30T04:35:38.910 回答
0

对于第一种情况，您可以使用 ESB，我认为这不是反模式。ESB 的目的还在于将遗留应用程序与其他应用程序集成，这些应用程序在您的用例中创建文件作为输出。

你可以试试骡 ESB。它将允许您使用流式传输（通过文件传输）使用文件，使用称为 DataMapper 的 GUI 将文件的内容映射到所需的输出，最后将这些消息放入 VM 队列中，该队列可以是 ESB 中的持久队列. 此队列是事务性的，因此您可以保证从一个文件创建的所有消息都放在 VM 队列上，或者一个都不放在。然后，您可以从另一个流（实际上在 ESB 中处理的流称为 mule 中的流）读取这些消息中的每一个并处理它们。

HTH，巴勃罗。

于 2013-05-17T17:59:33.180 回答