Как реализовать слабую связь с архитектурой SOA
Я проводил большое исследование в последнее время о SOA и ESB's и т.д.
Я работаю над перепроектированием некоторых унаследованных систем на работе теперь и хотел бы создать его с большим количеством архитектуры SOA, чем это в настоящее время имеет. Мы используем эти сервисы приблизительно в 5 из наших веб-сайтов и одной из самых больших проблем, которые мы имеем прямо сейчас с нашей унаследованной системой, то, что почти все время, когда мы делаем исправления ошибок или обновления, мы должны повторно развернуть наши 5 веб-сайтов, которые могут быть довольно трудоемким процессом.
Моя цель состоит в том, чтобы сделать интерфейсы между сервисами слабо связанными так, чтобы изменения могли быть внесены, не имея необходимость повторно развертывать все зависимые сервисы и веб-сайты.
Мне нужна способность расширить уже существующий сервисный интерфейс, не повреждаясь или обновляя любую из его зависимостей. Какой-либо из Вас встретился с этой проблемой прежде? Как Вы решали его?
4 ответа
Я предлагаю взглянуть на другой стиль услуг, чем, возможно, вы делали до сих пор. Рассмотрим службы, которые взаимодействуют друг с другом с помощью событий, а не запросов / ответов. Я много лет использую этот подход с клиентами в различных сферах и с большим успехом. Я довольно много писал на эти темы за последние 4 года. Вот одно место, с которого можно начать:
http://www.udidahan.com/2006/08/28/podcast-business-and-autonomous-components-in-soa/
Надеюсь, это поможет.
То, что вы спрашиваете, непростая тема. Есть много способов сделать вашу сервис-ориентированную архитектуру слабосвязанной.
Я предлагаю ознакомиться с серией книг Томаса Эрла SOA . Он все довольно четко и подробно объясняет.
Есть несколько общих практик для достижения свободной связи для сервисов.
Используйте стиль веб-сервисов doc/literal, думайте в данных (формат проводов) вместо RPC, избегайте привязки данных на основе схем.
Строго придерживайтесь контракта при отправке данных, но сохраняйте несколько предположений при обработке входящих данных, xpath - хороший инструмент для этого (loose in, tight out)
Используйте ESB и избегайте любого прямого взаимодействия между сервисами.
Есть несколько подходов, которые вы можете предпринять. Наша архитектура SOA включает в себя XML-сообщения, отправляемые службам и от них. Один из способов достичь того, что вы описываете, - это избегать использования библиотеки привязки данных к нашей схеме XML и использовать общий анализатор XML для получения только тех узлов данных, которые вы хотите игнорировать, игнорируя те, которые вам не интересны. Таким образом, служба может добавить дополнительные новые узлы к сообщению, не нарушая тех, кто в настоящее время его использует. Обычно мы делаем это только тогда, когда нам нужен только один или два фрагмента информации из более крупной структуры схемы.
В качестве альтернативы мы используем другое (предпочтительное) решение - управление версиями. Версия службы придерживается определенной схемы / интерфейса. Когда схема изменяется (например, интерфейс расширяется или изменяется), мы создаем новую версию сервиса. В любой момент у нас может быть 2 или 3 версии одновременно. Со временем мы отказываемся от рекомендаций, а затем удаляем старые версии, а в конечном итоге переносим зависимый код на более новые версии. Таким образом, те, кто зависит от службы, могут продолжать использовать существующую версию службы, в то время как некоторая конкретная зависимость может «обновиться» до новой версии. Какие версии службы вызываются, определяется в файле конфигурации для зависимого кода. Обратите внимание, что версионируется не только схема, но и весь базовый код реализации.
Надеюсь, это поможет.