Перестроить N-уровневое приложение в сервис-ориентированную архитектуру (SOA)?

Question

Учитывая обычные характеристики n-уровневого приложения со слоями, такими как: презентация, бизнес, доступ к данным; как это обычно перестраивается для создания сервис-ориентированной архитектуры ( SOA )?

Требуется обзор высокого уровня от программистов, имеющих опыт в этом упражнении.

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

Answer 1

SOA и n-уровень - это несколько разные понятия. n-ярус - это, как правило, архитектура приложения для создания автономного приложения (которое может иметь определенные интерфейсы с другими приложениями и т. д.).

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

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

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

Answer 2

Насколько я понимаю, SOA-подход - это то, что вы бы использовали, чтобы системы могли общаться друг с другом (в отличие от отправки данных между уровнями); с той вариацией, что вы можете создавать приложения, которые состоят только из некоторых традиционных слоев и полагаются на существующие сервисы для данных.

Я также думаю, что S в SOA относится к бизнес-сервисам (что-то на уровне бизнеса), а не к веб-сервисам (что-то на технологическом уровне).

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

Какой обзор вам нужен, технический? Или что-то еще?

Обзор высокого уровня: найдите того, кто понимает данные и услуги, которые вы предлагаете (или хотите предложить), выясните, как их поделить - иди к простоте: http://www.objectwatch.com/whitepapers/ITComplexityWhitePaper.pdf