Как реализовать слабую связь с архитектурой SOA - PullRequest
8 голосов
/ 23 марта 2010

В последнее время я много исследовал SOA, ESB и т. Д.

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

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

Мне нужна возможность расширить уже существующий сервисный интерфейс, не нарушая и не обновляя его зависимости. Кто-нибудь из вас сталкивался с этой проблемой раньше? Как ты это решил?

Ответы [ 5 ]

3 голосов
/ 24 марта 2010

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

http://www.udidahan.com/2006/08/28/podcast-business-and-autonomous-components-in-soa/

Надеюсь, это поможет.

2 голосов
/ 24 марта 2010

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

В качестве альтернативы, другое (предпочтительное) решение, которое мы используем, - управление версиями. Версия сервиса придерживается определенной схемы / интерфейса. Когда схема изменяется (например, интерфейс расширяется или модифицируется), мы создаем новую версию сервиса. В любое время у нас может быть 2 или 3 версии на ходу в любое время. Со временем мы устареваем, а затем удаляем более старые версии, а затем переносим зависимый код в более новые версии. Таким образом, зависимые от службы могут продолжать использовать существующую версию службы, в то время как некоторые конкретные зависимости могут «обновиться» до новой версии. Какие версии службы вызываются, определяются в файле конфигурации для зависимого кода. Обратите внимание, что не только схема становится версионной, но и весь базовый код реализации.

Надеюсь, это поможет.

0 голосов
/ 18 августа 2014

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

  • Местоположение вызываемой системы (ее физический адрес): Есть ли у вас приложение использует прямые URL-адреса для доступа к системам или является приложение отделено через уровень абстракции, который отвечает для поддержания связей между системами? Реестр услуг и парадигма группы услуг, используемая в SAP NetWeaver CE, хороша примеры того, как может выглядеть такая абстракция. Используя Enterprise Service Bus (ESB) является еще одним примером. Дело в том, что приложение не должно жестко кодировать физический адрес называется системой для того, чтобы действительно считаться слабосвязанной.

  • Количество получателей: Указывает ли приложение, какие системы получатели сервисного вызова? Слабосвязанный композит не будет указать конкретные системы, но оставит доставку своей сообщения на уровень реализации контракта на обслуживание. Плотно связанное приложение будет явно вызывать принимающие системы в порядок; слабосвязанное приложение просто звонит сервисный интерфейс и позволяет реализацию контракта на обслуживание слой, чтобы заботиться о деталях доставки сообщений справа системы.

  • Наличие систем: Требует ли ваше приложение, чтобы все системы, которые вы подключаете, чтобы все время работать? Очевидно, это очень сложное требование, особенно если вы хотите подключиться к внешним системам, которые не находятся под вашим контролем. Если ответ заключается в том, что все системы должны работать все время, приложение тесно связано в этом отношении.

  • Формат данных: Использует ли приложение повторно форматы данных, предоставленные бэкэнд-системы или вы используете каноническую систему типов данных который не зависит от систем типов, используемых в вызываемых Приложения? Если вы повторно используете типы данных серверной части систем, вам, вероятно, придется бороться с преобразованиями типов данных в ваше приложение, и это не очень слабосвязанный подход.

  • Время ответа: Требует ли приложение, чтобы вызываемые системы отвечали в течение определенного периода времени или это приемлемо для приложения к получить ответ минут, часов или даже дней спустя?

0 голосов
/ 25 марта 2010

Есть несколько общих правил для достижения слабой связи для услуг.

  1. Использование веб-сервисов в стиле doc / literal, вместо данных RPC используйте данные (проводной формат), избегайте привязки данных на основе схемы.

  2. При отправке данных строго соблюдайте условия контракта, но при обработке входящих данных придерживайтесь нескольких предположений, xpath - хороший инструмент для этого (свободный, сжатый)

  3. Используйте ESB и избегайте прямой связи между службами.

0 голосов
/ 23 марта 2010

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

Предлагаю ознакомиться с серией книг SOA Томаса Эрла . Все объясняется довольно четко и подробно.

...