ОО Дизайн для методологии коммуникации, которая изменится - PullRequest
1 голос
/ 13 мая 2010

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

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

Я ожидаю, что сам веб-сервис абстрагирует детали изменения методологии связи между веб-приложением и внешним API. Моя главная задача - как спроектировать внутреннюю часть веб-сервиса. Каковы некоторые предписанные способы использования ОО-дизайна для создания соответствующего уровня абстракции, чтобы изменение метода коммуникации можно было обрабатывать аккуратно? Есть ли рекомендуемый шаблон дизайна?

Ответы [ 3 ]

1 голос
/ 13 мая 2010

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

Если в веб-сервисе есть методы doX и doY, например, ни один из вызывающих doX и doY не должен заботиться о том, что происходит внутри. Поэтому, пока вы поддерживаете API между клиентами веб-службы и веб-службы, вы должны быть установлены.

0 голосов
/ 13 мая 2010

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

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

Как посредник, вы должны быть настроены так, чтобы ваши конечные пользователи ничего не знали о исходном API.

0 голосов
/ 13 мая 2010

Я часто сталкивался с подобной проблемой, когда у меня был бы новый фасад (обычно класс Java), а затем какое-то новое «промежуточное программное обеспечение», которое в конечном итоге связывалось бы со службами, расположенными в другом месте.

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

Мое обычное решение - определить понятие пакета данных с его подтипами, содержащими конкретные формы данных (например, конкретные ответы, конкретные запросы) и т. Д. Важно то, что все пакеты должны быть в некоторой форме сериализуемыми ( У Java есть понятие для этого, я не уверен насчет C ++).

У меня тогда есть агент и поставщик. Агент принимает запросы программного домена, создает пакеты. Он перемещает их в тупик, который отвечает только за общение. Удаленная заглушка принимает пакет и передает его провайдеру. Поставщик переводит его обратно в объект домена, который он затем предоставляет фактическим услугам. Он принимает ответ, отправляет его обратно агенту через заглушку и т. Д.

Преимущество этого подхода состоит в том, что я создаю несколько слоев абстракции. Агент / провайдер ориентирован на уровень домена и его трансляцию в пакеты и обратно. Пара скелет-заглушка отвечает за маршаллинг и отправку пакетов туда и обратно. Поменяв местами мою пару скелет-заглушка с подтипами, я могу заставить одну и ту же программу взаимодействовать по-разному (например, встроенную в одну и ту же JVM, через что-то вроде JMS, напрямую через сокеты и т. Д.)

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...