SOA Style - обмен данными

Question

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

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

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

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

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

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

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

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

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

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

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

В Руководстве по архитектуре приложений 2.0 есть целая глава, посвященная типам принимаемых вами решений (http://apparchguide.codeplex.com/Wiki/View.aspx?title=Chapter%2013%20-%20Service%20Layer%20Guidelines). Я бы скачал полное руководство.

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

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