SOA: объединение данных по нескольким службам

Ответ 1

Я провел некоторое исследование и нашел для него 2 разных решения.

1- Службы могут кэшировать данные других Служб локально. Но для этого требуется механизм pub/sub, поэтому любые изменения в источнике данных должны публиковаться, чтобы подписываемые службы могли обновлять свой локальный кеш. Это дорого стоит реализовать, но является самым быстрым решением, поскольку служба имеет требуемые данные локально. Это также увеличивает доступность Сервиса, не позволяя ему зависеть от данных других Услуг. Другими словами, если другая Служба недоступна, она все еще может выполнять свою работу по своим данным кеша.

2- Альтернативно, служба может запрашивать "список" объектов из другой Службы, предоставляя список идентификаторов. Это предотвращает отдельный вызов, который должен быть сделан целевой службе, чтобы получить информацию о заданном объекте. Это проще реализовать, но с точки зрения производительности, не так быстро, как решение 1. Также, если целевая служба недоступна, служба-источник не может выполнять свою работу.

Надеюсь, это поможет другим, кто столкнулся с этой проблемой.

Мош

Ответ 2

Интеграция БД (на самом деле это то, о чем вы говорите, когда две службы используют таблицу в БД) ошибочна на стольких уровнях! Он полностью нарушает некоторые основные принципы разработки программного обеспечения.

свободная муфта, инкапсуляция разделение проблем

Служба должна быть (чтобы получить это имя) полностью независимой, а именно:

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

Две службы, которые обмениваются данными на уровне БД, не могут гарантировать какой-либо из них.

Тот факт, что вы "контролируете" обе службы, совершенно неактуальен. Сегодня вы контролируете... завтра вы, возможно, захотите передать на аутсорсинг или заменить одну из услуг. Это должно быть так же просто, как обеспечить правильные интерфейсы.

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

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

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

Ответ 3

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

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

Недостатком является дополнительная сложность и накладные расходы на обслуживание.

Ответ 4

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

Ответ 5

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

Ответ 6

Несчастливо видеть, что вся эта дискуссия ухудшается в квесте операторов "Я могу использовать базу данных или нет в SOA", что совершенно не имеет отношения к делу и не отвечает на исходный вопрос вообще.

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

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

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