У меня есть приложения, которые необходимы для прослушивания сообщений ADT и ORU. Эти типы сообщений могут быть получены по одному каналу и подвергнуты соответствующей постобработке. В качестве альтернативы они могут быть получены в отдельных очередях и обработаны отдельно. Я использую Camel/mina для каналов MLLP. Каков традиционный подход к этому типу приложений? Я пытался рассмотреть преимущества и недостатки обоих подходов. Думаю, если бы они были отдельными, я мог бы запускать отдельные приложения, сохраняющие данные в общем хранилище данных. Это может упростить разработку и стать более подходом к SOA, но это единственное преимущество, о котором я могу думать.
Прием сообщений ADT и ORU по одному каналу или по двум
Ответы (2)
По моему опыту, большинство пользователей предпочитают разделять разные типы сообщений и разных отправителей, т. е. один канал для каждого типа сообщения и комбинации отправитель/получатель. Его преимущество заключается в том, что ошибка одного типа не может повлиять на передачу сообщения другого типа и другого отправителя/получателя. Также легче проводить отладку в случае сбоя или ошибочного сообщения.
Недостатком является то, что вы должны контролировать больше каналов. Конечно, вы должны учитывать и другие вещи. Что, если, например. Ваша учетная система молча отбрасывает учетные сообщения для пациентов, она не знает, как прекратилась передача ADT-сообщений?
вы можете создать один общий канал для получения сообщений ADT и ORU, а затем создать два отдельных канала для ADT и ORU. Добавьте фильтры к каждому из этих двух каналов, чтобы сообщения ADT
направлялись в канал ADT, а сообщения ORU — в канал ORU.