我们有一个遗留系统，可以生成每个包含数百条消息（金融交易）的文件。我们需要将这些消息转换为另一种格式，并将它们（单独）提交给目标系统。问题是： ESB是否应该接受这些文件直接处理，或者遗留系统和ESB之间是否应该有适配器应用程序将接收到的文件拆分成单独的消息并让ESB单独处理消息（而不是处理整个文件）？
在第一个解决方案中，我们预计会有两个ESB流。第一个将文件转换为新格式，将其拆分为消息，并将这些消息存储到临时位置。转换需要整体处理文件，因为该文件包含转换单个消息所需的一些常用部分。 第二个流将采用单个转换后的消息（每个都在一个单独的DB事务中），将它们传递给目标系统，并等待其答案（同步或异步）。
第二个解决方案将由外部应用程序替换第一个流程，该外部应用程序将转换文件，将其拆分为单独的转换消息，并将它们存储在临时位置（本地文件系统）中。第二个流程将保留在ESB中。
在我们看来，第一种解决方案的缺点在于ESB必须处理大量文件（在第一个流程中），这通常被认为是反模式。另一方面，ESB将直接调整到遗留系统的接口，这是ESB的目的之一。
在第二个解决方案中，适配器应用程序将包含转换逻辑，这应该是ESB的另一个目的和职责。
针对这种情况（模式）通常建议的解决方案是什么？你能提供一些比我找到的这两个链接更具描述性的参考文献吗？
https://www.ibm.com/developerworks/wikis/display/esbpatterns/File+Processing
修改 另一个参考： http://www.ibm.com/developerworks/webservices/library/ws-largemessaging/
答案 0 :(得分：0)
请记住，SOA中有3种消息类型：命令，事件，文档
'Document'位用于数据块。它可能更适合“真实”的文档类型，如“订单”或“发票”等，但没有什么能阻止你使用'TransactionBatch'。
话虽如此，它是一种相当未使用的消息类型，因为没有多少服务总线实际实现它周围的任何东西，因为：
所以我在你的场景中会做的是有一个处理文件的端点。所以像ProcessTransactionFileCommand这样的东西发送到处理端点，在其中你只有对实际文件的引用（存储在文件系统的某个地方，甚至是要从中下载的URL）。该处理端点可以处理文件并将单个消息（在事务内的所有消息）发送到集成端点，该集成端点将消息发送到外部系统。您可以SendTransactionCommand来做到这一点。
通过这种方式，您的系统非常灵活，因为集成端点可以从解决方案的某些部分接收单独的集成命令，而处理端点可以处理批处理并将其拆分为单独的集成命令。
如果你在.NET领域，你可能想看看我的FOSS服务总线项目：http://shuttle.codeplex.com/
但任何服务总线都可以解决问题（MassTransit，NServiceBus等）
答案 1 :(得分：0)
你可以使用ESB作为第一种情况，我不认为它会是一种反模式。 ESB的目的还在于将遗留应用程序与其他应用程序集成在一起，这些应用程序将文件作为用例输出。
您可以尝试Mule ESB。它允许您使用流（通过文件传输）使用文件，使用名为DataMapper的GUI将文件内容映射到所需的输出，最后将这些消息放入VM队列，该队列可以是ESB中的持久队列。此队列是事务性的，因此您可以保证从一个文件创建的所有消息都放在VM队列中，或者不放在VM队列中。 然后，您可以从另一个流（实际上在ESB中处理的流被称为mule中的流）读取每个消息并处理它们。
HTH，Pablo。