Архитектура в стиле SOA в ColdFusion?

Question

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

Я новичок в SOA.Означает ли это ... отдельные экземпляры CF, и они общаются друг с другом через удаленные вызовы веб-сервисов?Как можно справиться с такими вещами, как ... обработка ошибок и перебои в работе сервера?Будет ли ESB полезен для архитектуры, если каждая его часть находится в ColdFusion?

Как насчет уровня DB?Должны ли они иметь одну огромную базу данных или сами хранить вещи по-своему?

Спасибо

Answer 1

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

Так что, если вы хотите получить плюсы и не особенно беспокоиться о минусах, начните с чтения некоторых применимых книг на эту тему:

• Шаблоны архитектуры корпоративных приложений Мартина Фаулера - в частности, обратите внимание на шаблон Service Layer
• Дизайн, управляемый доменом, быстро сжатая версия гораздо более длинной (ненужно IMO) той же книгиимя минус «быстро», что поможет вам подумать о том, как определить сервисы и иерархию объектов под каждым из них.

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

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

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

Answer 2

Я слышал, что термин SOA использовался для описания множества различных настроек, поэтому я не уверен, что есть «правильный» ответ, но основная концепция - это сервисный уровень.Большим преимуществом является то, что ответ на ваш последний вопрос о слое DB - все вышеперечисленное.Как только логика управления хранением / постоянством изолирована на уровне обслуживания, и приложения просто обращаются к этому уровню, становится намного проще перемещать определенные данные на другие серверы или объединять их в один, когда это необходимо.Вы можете даже получить некоторые услуги, просто позвонив другим службам, которые часто называют фасадом службы .

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

Что касается обработки ошибок, если все ваши приложения и сервисы написаны на CF, у вас будет логирование и обработка ошибок на обоих (или всех) уровнях.Очевидно, что отключение сервера на служебном сервере будет довольно серьезным, поскольку это повлияет на все, что выше него.Мы используем монитор на том, который отправляет электронные письма в службу поддержки, если что-то истекает или начинает идти на юг.В клиентских приложениях ключ, который я нашел, - это установление разумного времени ожидания для вызовов веб-службы.Я никогда не видел, чтобы использовался ESB, но я предполагаю, что он даст вам еще один уровень абстракции для управления реальными вызовами.Это может помочь с таймаутами и тому подобным, но я не могу точно сказать.