Зачем выполнять преобразования в промежуточном программном обеспечении?

Question

Удаленная система отправляет сообщение через промежуточное ПО (MQ) в мое приложение.

В промежуточном программном обеспечении к этому сообщению применяется преобразование (с использованием xslt). Он просто переформатирован и нет никакого обогащения или подтверждения. Моя система является единственным потребителем этого преобразованного сообщения, а xslt поддерживается моей командой.

Оригинальный автор всего этого давно ушел, и мне интересно, почему он думал, что было бы неплохо сделать трансформацию промежуточного программного обеспечения, а не в моем приложении. Я не вижу значения в переносе этого на промежуточное ПО, он делает его менее видимым и менее простым в обслуживании.

Также я бы подумал, что xslt будет поддерживаться производителем сообщений, а не потребителем.

Есть ли какие-либо рекомендации для такого рода архитектуры? Он сделал правильные вещи здесь?

Answer 1

Плохая идея изменить тело сообщения в промежуточном программном обеспечении. Это отрицательно сказывается на ремонтопригодности и производительности.

Единственная причина этого - попытаться соединить две несовместимые конечные точки без их модификации. Для этого потребуется преобразование исходного содержимого, которое должно быть понято конечной точкой назначения.

Мотивация делегировать промежуточное программное обеспечение для выполнения преобразований может быть политическим (конечные точки поддерживаются разными командами, руководство не хочет касаться кода конечной точки и т. Д.).

Answer 2

С архитектурной точки зрения, это хорошая идея предоставить потребителям сообщения или контент, который находится в человеко читаемом формате, например. xslt, если не будет значительного увеличения производительности при использовании двоичного формата.

В случае с человеком, пригодным для чтения, просто нужно посмотреть сообщение, чтобы убедиться, что оно правильно. В двоичном случае нужно было бы разработать утилиту для преобразования двоичного сообщения в удобочитаемую форму. Различные исполнители такой утилиты могут не всегда интерпретировать двоичную форму по назначению, и она может превратиться в упражнение, указывающее на то, кто или что правильно.

Кроме того, если вы смотрите на то, что находится в очереди, легче понять это, если сообщения находятся в человеко читаемом формате.

Не больно начинать с общедоступного формата и получать первое приложение. Затем профилируйте приложение и посмотрите, являются ли основные рисунки значительными источниками задержки на большой картинке. Если да, перейдите в двоичный формат.

Было бы предпочтительнее, чтобы исходный поставщик сообщений предоставлял сообщения в формате xslt, но у них должны были быть веские причины делать то, что они делали, когда они это делали. Например, потенциально другие потребители, xslt не существовало тогда, ограничения ресурсов и т. Д.

Answer 3

Если вы пытаетесь создать архитектуру приложения, где необходимо обслуживать данные для разных пользователей в разных форматах и, возможно, получать данные в различные форматы (думаю, отчеты о погоде или спортивные новости), а затем создать концентратор, способный делать преобразования между многими различными форматами, имеет отличный смысл. (Назовите ли вы, что «промежуточное ПО» зависит от вас.) Возможно, ваш предшественник имел такую ​​архитектуру, но он никогда не становился большим или сложным, чтобы оправдать дизайн.

Answer 4

Читайте о шаблоне проектирования adaptor и вы поймете намерение текущей архитектуры системы.