полностью отделенная ОО система?

Question

Чтобы сделать ОО-систему максимально разобщенной, я думаю о следующем подходе:

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

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

3) когда объект A хочет вызвать метод для объекта B, он обнаруживает уникальную идентичность целевого объекта через # 1 выше и публикует сообщение в службе сообщений для объекта B

4) службы сообщений вызывают обратный вызов B, чтобы передать ему сообщение

5) B обрабатывает запрос и отправляет ответ для A на службу сообщений

6) Обратный вызов A вызывается, и он получает ответ.

Я чувствую, что эта система настолько отсоединена, насколько это практически возможно, но у нее есть следующие проблемы:

1) связь обычно асинхронная

2) следовательно, это не в реальном времени

3) система в целом менее эффективна.

Существуют ли какие-либо другие практические проблемы, в которых этот дизайн явно не применим? Что вы думаете об этом дизайне в целом?

Answer 1

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

Лично я считаю, что лучше всего определить некоторые ключевые допущения, которые могут усилить сцепление, но повысить эффективность.

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

Answer 2

Книги

Корпоративные интеграционные шаблоны

Похоже, он говорит об использовании промежуточного программного обеспечения, ориентированного на сообщения

Вот некоторые моменты, которые следует учитывать

Безопасность

Что помешает другой мошеннической службе зарегистрироваться в качестве ключевого компонента в вашей системе.Вам понадобится способ подтвердить и подтвердить, что услуги - это то, кем они себя называют.Это можно сделать через систему PKI.Существуют сценарии, которые вам могут не понадобиться, если ваша система полностью размещена в вашей интрасети.Если это так, то социальная инженерия и мошеннические сотрудники будут вашей самой большой угрозой.

Контракт

Какой контракт будут заключены с вашими клиентами на услуги?Будут ли все сообщения сериализованы как XML и отправлены как TextMessage?Если вы используете чисто байтовое сообщение, вам нужно быть осторожным с порядком байтов, если ваши службы должны работать на нескольких платформах.

Синхронизация

Большинство разработчиков нев состоянии правильно понимать и использовать асинхронные сообщения.Там, где это возможно, в ваших интересах было бы создать способ вызывать «синхронные» сообщения.Я делал это в прошлом, создав метод sendMessageAndWait () с тайм-аутом и возвращаемым объектом.В методе вы можете создать временный идентификатор темы для получения ответа, зарегистрировать прослушиватель для него, а затем использовать блокировки, чтобы дождаться возвращения сообщения по вашей временной теме.

Нежелательные сообщения

Что произойдет, если вы захотите разрешить вашим службам отправлять нежелательные сообщения вашим клиентам?Критическое событие произошло в Сервисе A, и оно должно уведомить ваших клиентов или, возможно, службу Watch Dog.Разрешите вашей схеме зарегистрировать общий канал связи для служб, чтобы общаться с клиентами без клиентов, инициирующих диалог.

Failover

Что произойдет, если критическая служба обрабатывает вашукредитные карты выходят из строя?Вам потребуется внедрить службу Failover and Watch Dog, чтобы гарантировать, что ваша ключевая инфраструктура всегда работает.Вы можете зарегистрировать список служб в своем реестре, после чего ваш реестр может выдать первичную услугу, воспользовавшись вторичной услугой, если ваша первичная прекратит связь.Или, если ваше промежуточное ПО, ориентированное на сообщения, может обрабатывать сообщения Round Robin, вы можете зарегистрировать все службы на одну и ту же тему.Подумайте, как создать способ узнать, когда служба умерла.Поскольку большинство сообщений являются асинхронными, будет трудно определить, когда служба перешла в автономный режим.Это можно сделать с помощью Heartbeat и Watch Dog.

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

Самый большой совет, который я могу дать, - это создать инструментарий для других ваших разработчиков, чтобы они этого не делали.Нужно подумать о том, как зарегистрировать сервис, реализовать отказоустойчивость или ответить на сообщения от клиента.Это те вещи, которые убьют вашу систему, и другие скажут, что она слишком сложна.Безболезненно для них позволит вашей системе работать так, как вам нужно, с гибкостью и развязкой, не обременяя ваших разработчиков пониманием шаблонов корпоративного дизайна.

Это не Ivory Tower Architect / Architecture.Было бы, если бы он сказал: «Вот как это будет сделано, теперь иди и сделай это, и не беспокойте меня об этом, потому что я знаю, что я прав».Если вы действительно хотите сослаться на Anti-Pattern, возможно, это может быть Kitchen Sink.Нет, теперь, когда я думаю об этом, это не Kitchen Sink.

Если вы можете найти его, пожалуйста, оставьте его как комментарий. Анти-паттерны

Answer 3

Какая самая простая вещь, которая могла бы сработать? Выполняйте модульное преобразование в подпрограммы разумного размера, но избегайте интерфейсов, служб, сообщений и всего этого, если только у вас не будет нескольких реализаций или нескольких аппаратных ресурсов для разделения работы.

Сделайте это просто, а затем проведите рефакторинг тех частей, которые оказались важными.