为什么要在中间件中执行转换？

Question

远程系统通过中间件（MQ）向我的应用程序发送消息。

在中间件中，转换（使用xslt）应用于此消息。它只是重新格式化，没有丰富也没有验证。我的系统是此转换消息的唯一消费者，xslt由我的团队维护。

所有这一切的原作者早已不复存在，我想知道为什么他认为在中间件而不是在我的应用程序中进行转换是个好主意。我无法看到将其转移到中间件的价值，它使其不那么明显，维护起来也不那么简单。

此外，我认为xslt将由消息生成者而不是消费者维护。

这种架构是否有任何指导方针？他在这里做了正确的事吗？

Answer 1

修改中间件中的邮件正文是个坏主意。这会对可维护性和性能产生负面影响。

这样做的唯一原因是尝试连接两个不兼容的端点而不修改它们。这将要求目标端点理解源内容的转换。

委托中间件执行转换的动机可能是政治性的（端点由不同的团队维护，管理层不愿意触及端点代码等）。

Answer 2

如果您正在尝试创建一个应用程序架构，其中需要以不同格式向不同用户提供数据，并且可能以不同格式接收数据（想想天气报告或体育新闻），那么创建一个能够在许多不同格式之间进行转换非常有意义。 （你是否称之为“中间件”取决于你。）也许你的前任考虑过这种架构，但它从来没有变得足够大或复杂到足以证明设计的合理性。

Answer 3

从架构的角度来看，为消费者提供人类可读格式的消息或内容是个好主意，例如： xslt，除非使用二进制格式有显着的性能提升。

在人类可读格式的情况下，只需要查看消息以验证它是否正确。在二进制的情况下，人们必须开发一个实用程序来将二进制消息转换为人类可读的形式。这种实用程序的不同实现者可能并不总是按照预期解释二进制形式，并且它可以变成关于谁或什么是正确的指责练习。

此外，如果一个人正在查看队列中的内容，如果消息采用人类可读的格式，则更容易理解它。

以人类可读的格式开始并让应用程序首先运行并没有什么坏处。然后对应用程序进行概要分析，看看转换例程是否是重要的延迟来源。如果是，则转到二进制格式。

最好让原始的消息生成器以xslt格式提供消息，但是他们必须有充分的理由去做他们做的时候做的事情。例如，可能是其他消费者，xslt当时不存在，资源限制等等。

Answer 4

了解 adaptor 设计模式，您将了解当前系统架构的意图。