SOA: Желательно ли реализовать сервис вместо простого написания кода, готового к сервису, когда внешний доступ не требуется?

Question

Я работаю над первоначальной архитектурой для решения, для которого предыдущий консультант рекомендовал подход SOA. Из чтения книги (книг) Erl и применения предыдущей работы со службами (и хороших шаблонов проектирования в целом), я вижу преимущества такого подхода. Однако у этой конкретной группы в настоящее время нет традиционных потребностей для реализации веб-сервисов - нет внешних потребителей и нет интеграции с другими приложениями.

Что мне интересно, так это то, есть ли какие-то преимущества в использовании веб-сервисов, строго придерживаясь SOA, которые мы не могли получить от простой реализации объектов, которые «готовы к обслуживанию»?

Чтобы объяснить, пример. Допустим, вы реализуете сущность «Персона» как сервис. Вы должны реализовать: 1. Бизнес-объект / логика 2. Переводчик в сервисную структуру данных 3. Переводчик из сервисной структуры данных 4. WSDL 5. Сервисная структура данных (XML / JSON / и т. Д.) 6. Утверждения

Теперь, с другой стороны, если вы не пользуетесь сервисом, вам нужно только реализовать # 1 и убедиться, что другой код обращается к нему через свободную ссылку (используя внедрение зависимостей или оболочку и т. Д.). ). Затем, если позже станет очевидно, что служба нужна, вы можете просто указать ссылку вместо нее на указанную выше логику # 2 / # 3 в объекте-оболочке (чтобы все объекты вызывающей стороны не нуждались в обновлении), и реализовать такое же количество объекты без штрафа в зависимости от объема разработки, которую вы должны выполнить - не нужно создавать никаких дополнительных объектов или кода, в отличие от выполнения всего этого заранее.

Таким образом, если объем работы, который должен быть выполнен, является одинаковым, независимо от того, был ли сервис реализован изначально или по мере необходимости, и в настоящее время нет необходимости во внешнем доступе через сервис, есть ли основания для его первоначального внедрения? как сервис просто придерживаться SOA?

Answer 1

Вообще говоря, вам лучше подождать.

Вы можете спроектировать и внедрить веб-сервис, представляющий собой просто технический фасад, который демонстрирует базовую функциональность - вопрос в том, что вы просто сделаете прямойодно «отражение» этой базовой функциональности?Если да - вы проектировали эту базовую вещь таким образом, чтобы она подходила для внешних абонентов?Имеет ли смысл API, предоставляет ли он членов, которые должны быть частными и т. Д.

Еще один фактор, который следует учитывать, - вы действительно знаете, чего хотят или нуждаются абоненты службы?Риск, с которым вы сталкиваетесь при создании службы, заключается в том, что (как вы, по сути, только предполагаете) вам может потребоваться переписать ее, когда появятся первые клиенты / абоненты.Это может привести к выполнению всех видов работ, включая тестовые случаи, обратную совместимость, если накопители перейдут на более низкие уровни, и т. Д.

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

Answer 2

Как я уже говорил, это зависит от ваших требований.Если это монолитное приложение, и вы уверены, что никогда не интегрируете это приложение и не будете повторно использовать шину.Доступ к логике / данным для двухуровневого приложения (UI / DB) достаточно хорош.
Тем не менее, это архитектурное решение и, как и большинство архитектурных решений, его изменение стоит дорого.Конечно, вы все еще можете учесть модель веб-сервиса позже, но это не так просто, как вы могли подумать.Рефакторинг существующего приложения для добавления сервисного уровня обычно является сложной задачей даже при использовании хорошего дизайна на основе интерфейсов.Пример вещей, которые могут пойти не так: структура данных, которую нельзя сериализовать, циклические ссылки в свойствах, перегрузка конструктора, зависимости от некоторых внутренних поведений…

Answer 3

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

Для приложений Entreprise требуется множество взаимодействующих друг с другом компонентов и множество разработчиков, работающих над этим.В этом типе сценариев использование архитектуры типов SOA - путь.Основной причиной принятия SOA является уменьшение зависимостей.Корпоративные приложения обычно зависят от множества внешних компонентов (логики или данных), и вы не хотите интегрировать эти компоненты путем совместного использования сборок.
Представьте, что вы используете общий компонент, который реализует некоторые конкретные вычисления, если бы вы развернули этот компонент ввсе зависимые приложения?Что произойдет, если вы захотите изменить логику вычислений?Не могли бы вы попросить все команды обновить свои ссылки, перекомпилировать и повторно развернуть их приложение?
Я недавно разместил в своем блоге историю, в которой бывший Архитектор также решил не использовать веб-сервисы и подумал, что совместное использование сборок - это хорошо.Результатом стал хаос.Подробнее здесь .