Стиль SOA — совместное использование данных

Я рассматриваю архитектуру SOA для набора серверов для поддержки бизнеса, для которого я консультирую, ранее мы использовали интеграцию с базой данных, где каждое приложение выбирало то, что ему нужно, из общей базы данных MS SQL и работало с ней и т. д. У нас были различные приложений, интегрированных с базой данных монстров, включая доступ к Java, .net и Microsoft, была ссылочная целостность, поскольку все было тесно связано.

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

Возьмем Product Service, который находится поверх базы данных Product, ежемесячно предоставляемой оптовым продавцом. Мы строим модель предметной области и размещаем ее в базе данных с помощью Hibernate или чего-то еще, с точки зрения внедрения. Продукт — это большой граф объектов с учетом информации, предоставленной оптовым продавцом о продукте.

Теперь предположим, что служба обзора, служба ценообразования, служба доставки и служба запасов подпишутся на ProductUpdated, ProductAdded, ProductDeleted. Проблема в том, что каждому сервису нужна только часть или несколько частей информации о Товаре. Для доставки могут потребоваться только размеры и вес. Для ценообразования может потребоваться только идентификатор продукта, оптовая стоимость, скидка за объем и цена, действующая на сегодняшний день. Для обзора может потребоваться идентификатор продукта, название продукта, производитель.

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

Или, когда я пишу это, я думаю, может быть:

Product Service Публикует сообщение ProductAdded (не содержит сведений о продукте, только идентификатор продукта и, возможно, отметку времени)

Служба ценообразования подписывается на ProductAdded и публикует сообщение RequestPricingForProduct.

Служба продукта публикует сообщение ResultForPricingForProduct

Хм... кажется, немного лучше... но мне кажется, что я строю контракт на обслуживание продукта, основываясь на том, какие другие услуги я могу определить и что им понадобится, возможно, в будущем XYZ Service потребует чего-то другого. Я собираюсь остановиться на этом, так как я думаю, что становится яснее, где я запутался ... возможно, вышеизложенное сработает, потому что я должен показать способ вернуть все, что должно быть общедоступным, хммм правильно.

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


soa
person Community    schedule 08.06.2009    source источник

Ответы (2)


arrow_upward
5
arrow_downward

Я действительно думаю, что решение этой проблемы состоит в том, чтобы НЕ делиться данными. SOA означает, что данные принадлежат службе — это технический орган по этим данным. Я предлагаю прочитать несколько статей Пэта Хелланда, таких как Данные внутри, данные на Снаружи.

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

Не обязательно должен быть один «Продукт». Каждый сервис может иметь разное представление о продукте в своем сервисе. Для службы ценообразования у вас есть productId и цена. Для службы обзора — productId и обзор. И так далее.

Людей начинает смущать то, как отображать эти данные в пользовательском интерфейсе, если они получены из всех этих разрозненных сервисов. Как вы можете показать список отзывов о продукте, который имеет название продукта из ProductService и текст отзыва из ReviewService?

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

person Dan    schedule 06.06.2013

arrow_upward
3
arrow_downward

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

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

Пример того, как настроить свой сервисный уровень таким образом, см. в шаблоне «Сервисный интерфейс». На стороне клиента службы существует противоположный шаблон, который называется «Сервисный шлюз».

В Руководстве по архитектуре приложений 2.0 есть целая глава, посвященная типам принимаемых вами решений (http://msdn.microsoft.com/en-us/library/ms998421.aspx). Я бы скачал всю инструкцию.

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

При проектировании интерфейса службы учитывайте следующие рекомендации: Рассмотрите возможность использования крупномодульного интерфейса для пакетных запросов и минимизации количества вызовов по сети. Спроектируйте интерфейс службы таким образом, чтобы изменения в бизнес-логике не влияли на интерфейс. Не реализуйте бизнес-правила в интерфейсе службы. Рассмотрите возможность использования стандартных форматов параметров, чтобы обеспечить максимальную совместимость с различными типами клиентов. Не делайте предположений в дизайне интерфейса о том, как клиенты будут использовать сервис. Не используйте наследование объектов для реализации управления версиями интерфейса службы.

person Loren Paulsen    schedule 10.06.2009