caballeroiscrafmможно не делать сложных ХП. Сложную ХП можно представить в виде простых сервисов. Просто для этого кардинально другие подходы нужно применять при проектировании приложений.
Сервера приложений и есть другой подход
сервер приложений - это tier, а не layer.

caballeroiscrafmпропущено...

я скажу, что SOA систему на порядок легче сопровождать.
и как из SOA следует бизнес логика на SQL?

следует очень просто: сервис реализован в виде ХП.

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

путаница "tiev vs layer" - очень распространенное явление. Также как и непонимание сути SOA

ДжекНепотрошительiscrafmне совсем понятно что означает "у вас". Я не говорю конкретно по какую-то свою систему, я говорю про сам подход. Если говорить о поднятом вами примере, то сервисом будет не "Payroll", а будут сервисы:
- "сформировать ведомость начислений по сотруднику/подразделению за указанный период"
- "получить ведомость"
- "закрыть ведомость"
- и т.д

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

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

caballeroавтор Один вопрос "и как из SOA следует бизнес логика на SQL" просто выносит моск

человек на утверждение что логика на SQL - чушь возразил что SOA легче сопровождать. вполне логично спроcить какая тут связь.
связь простая: сервис - "черный ящик". Обращение к нему стандартизовано. Внутри этого "ящика" может быть что угодно, что позволяет выполнить возложенную на него задачу, в том числе и ХП

ДжекНепотрошительКоллеги, у меня такое впечатление, что вы только что из космоса прилетели. Я начал рассказывать вам о том, что реализовывать сложную бизнес-логику на ХП менее эффективно, чем на языках высокого уровня , а вы мне кинулись в ответ доказывать о преимуществах SOA. Спасибо, не надо, я их и без вас знаю.
вам просто показывается, что ваше утверждение не верно. Судя по утверждениям - не знаете, поэтому я вам и рассказываю, что все зависит от того, каким образом вы эту самую бизнес-логику, реализуете.

ДжекНепотрошительМСУЭто не так, сервис - это шлюз (поставщик данных). Каких данных - другой вопрос. Зависит от того, как архитектор разнесёт ответственность. Бизнес сущность тут вообще не в тему упомянута.

Это следующий уровень абстракции. Но в правильно спроектированных системах не должно быть абстрактных "каких-то данных". Данные должны соответствовать бизнес-сущностям. Без этого смысл SOA вообще теряется.
смысл SOA совершенно в другом

нарисовал, наспех правда, абстракцию на тему "как развиваются SOA системы". Любой из кубиков можно заменить в любой время, если изменились потребности. Как в серверной стойке...
Если это вызывает какие-то проблемы, то скорее всего нарушены главные принципы SOA.
А что внутри блока? какая разница, если выполняемая им работа соответствует определенным для этого критериям.
Как это относится к обсуждаемому вопросу? Самым прямым образом. Бизнес-логику можно спроектировать и реализовать в виде огромной неделимой "простыни" и под легким сопровождением и легким внесением изменений понимать не более чем возможность инструмента для разработки отслеживать связи, а можно разложить на слабосвязанные сервисы. В этом случае, абстрактно "update ... where..." в ХП будет выполняться сервером СУБД значительно адекватней, чем надстройкой над ним

картинка не приклеилась

caballeroавторследует очень просто: сервис реализован в виде ХП.
привет из семидесятых
какое-то полное непонимание архитектуры. Ладно, убеждать не буду.

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