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

Question

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

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

所有这一切的原作者早就走了，我想知道为什么他认为在中间件而不是我的应用程序中进行转换是个好主意。我看不到将其移至中间件的价值，它使其不那么明显并且不那么易于维护。

另外我会认为 xslt 将由消息生产者而不是消费者维护。

这种架构有什么指导方针吗？他在这里做对了吗？

Answer 1

在中间件中修改消息体是个坏主意。这会对可维护性和性能产生负面影响。

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

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

Answer 2

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

Answer 3

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

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

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

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

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

Answer 4

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