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

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

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

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


architecture rebuild n-tier-architecture soa
person John K    schedule 27.02.2010    source источник
comment
Мне нравятся новые модные слова, потому что SOA было недостаточно круто.   -  person Woot4Moo    schedule 28.02.2010
comment
Я думаю, что Woot4Moo намекает, что вы путаете SaaS (модель лицензирования) с SOA (своего рода программной архитектурой).   -  person molf    schedule 28.02.2010
comment
@molf действительно мой друг, но я также слышал, что люди используют SaaS в качестве замены SOA   -  person Woot4Moo    schedule 28.02.2010
comment
По крайней мере, вы не слышали об этом сначала от меня! В вопрос внесены соответствующие изменения. Спасибо.   -  person John K    schedule 28.02.2010
comment
... серия горизонтальных модулей, каждый из которых инкапсулирует свой собственный n-уровневый мини-стек. Думаю, это тот ответ, который вы ищете.   -  person Travis Gockel    schedule 02.03.2010

Ответы (2)


arrow_upward
4
arrow_downward

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

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

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

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

person Kris C    schedule 02.03.2010
comment
Хорошее объяснение. Я бы добавил, что эти концепции не исключают друг друга, поэтому у вас может быть сервис, который соединяется с n-уровневой системой. - person Travis Gockel; 02.03.2010
comment
Хорошая точка зрения. Я обдумываю некоторые изменения, которые лучше отвечают на исходный вопрос, например, как лучше всего реинтегрировать существующие n-уровневые приложения для формирования SOA, поэтому я постараюсь включить эти комментарии - person Kris C; 02.03.2010

arrow_upward
1
arrow_downward

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

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

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

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

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

person Adrian K    schedule 01.03.2010