OO Дизайн для коммуникационной методологии, которая изменится

Question

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

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

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

Answer 1

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

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

Answer 2

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

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

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

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

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

Answer 3

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

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

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