caballeroавтора где смотрели? я этим 10 лет занимаюсь, поэтому "встречал" конечно же
ну если иметь ввиду самописки то там можно встретить что угодно.
что значит "самописки"?
действительно системы написаны самостоятельно разработчиками. Это самописки? Что такое "не самописка"? Написанная роботом?

caballeroавторкакое-то полное непонимание архитектуры
непонимание вашего личного понимания которое вы не в состоянии внятно изложить.

речь шла о том что бизнес-логика на SQL - вчерашний день. SOA оно или нет - сути дела не меняет.
меняет в корне, потому что на каком языке написать код сервиса зависит от того что более адекватно для решения задачи, которую этот сервис решает.
то что часть сервис подписи реализован на языке T-SQL, к примеру, а сервис проверки подписи на высокоуровневом (как на картинке, например) говорит только о том, что внутренности "черного ящика" могут быть реализованы на том, что удовлетворяет критериям. Конечно, если не выполнена нормальная архитектурная декомпозиция и бизнес-логика представляет из себя "мешанину", то возникает множество вопросов, потому что на SQL нелогично, к примеру, отправлять электронную почту или обмениваться сообщениями. Поэтому сразу же возникает "привет из 70-х годов" :)

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

caballeroавторменяет в корне, потому что на каком языке написать код сервиса зависит от того что более адекватно для решения задачи, которую этот сервис решает.
в таком случае любая программа - SOA.

у меня есть функция реализующая подпись. Я назову ее сервисом.
у меня есть выборка с БД. я тоже назову ее сервисом.
я могу эти функции, обращения к Бд и прочее комбинировать? могу. вот и SOA.
у вас есть то, что можно использовать как реализацию сервиса. А само ядро есть? Т.е. сама система?

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

в таком случае любая программа - SOA.

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

древнюю статью нашел


caballeroу меня есть функция реализующая подпись. Я назову ее сервисом.
у меня есть выборка с БД. я тоже назову ее сервисом.
я могу эти функции, обращения к Бд и прочее комбинировать? могу. вот и SOA.
чтобы долго не печатать, прочитайте ее. Но смысл таков: оформите то, что вы перечислили в форме компотентов со стандартными интерфейсами, обеспечьте доступ к этим компонентам хотя бы в форме URL и будет вам ваша реализация SOA

caballeroавторНо смысл таков: оформите то, что вы перечислили в форме компотентов со стандартными интерфейсами, обеспечьте доступ к этим компонентам хотя бы в форме URL и будет вам ваша реализация SOA
отож
посему не надо рассказывать о SOA на хранимых процедурах.

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

p.s. можете вкратце привести ваше видение того, как j2ee выполняет простое действие обновления одного поля в таблице БД по заданному условию?

на эту тему на AskTom была дискуссия давно, что лучше j2EE или хранимые процедуры на PL/SQL для бизнес-логики, здесь
там много текста, почитайте. Но нить всего:
It is a religous war though, they cannot be won by reason or objectivity.

неплохо он здесь отразил то, что многие путают логику приложения и бизнес-логику.

AskTomapplication logic -- i agree.

BUSINESS LOGIC -- that, well, no, i agree to disagree. unless your business is J2EE and that
alone. business rules = data rules = close to data. a business rule could be "you can only be in
EMP if there exists a record in DEPT". would you argue that should be enforced outside?

application logic = something outside of the database.

я тоже с ним согласен

caballeroкак вы к примеру будет обеспечивать транзакции между вызовами сервисов?
что это такое?

caballeroА если перестать кидать умняки и вернутся к собственно теме - лично я согласен с мнением что в компьютерную эпоху двойная запись, баланс (не говоря уже про кореспонденцию счетов и остальное что от лукавого) не имеют никакого смысла
потому как компьютер не ошибается. И все счета можно спокойно вести как ведутся забалансовые счета.
"Я слышу речь не мальчика, но мужа" Можете объяснить в чем глубокий смысл этого компетентного мнения и как это связано с ошибками компьютера?