Надеюсь, начинающим изучать subj будет полезно.
http://ekrs.blogspot.com/2007/11/just-one-...oa-and-bpm.html

Спасибо! Интересная статья!

кстати, принимаются предложения по поводу продолжения этого цикла.
может, кого-то интересуют какие-либо более детальные аспекты?

Хм. Статья на самом деле интересная. Хотя признаюсь честно, многое еще не до понял, не догнал.  В силу того, что ранее и в текущий момент времени являюсь в первую очередь чистым кодером. Вот только очень скоро сменю место работы, и на новом месте как раз придется заниматся:

"Компания рано или поздно вставала перед фактом: в её IT-среде наблюдается зоопарк различных систем, от корпоративных ERP до мини-утилиток. Все это написано разными людьми в разное время, при этом интеграция этих систем реализована по принципу "одна с несколькими", а интерфейсы этих систем и механизм их взаимодействия крайне плохо документирован. В дальнейшем так и будем называть эту сложившуюся ситуацию зоопарком систем."

только вот не хотелось бы еще более усложнять эту запарку, хотя в первое время все будет сводится к этому.

Но это к предисловию.

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



Как правило вопросов больше чем ответов. Но начну с самого главного, после прочтения пары статей, все же есть приличная каша в голове. Хотелось бы почитать про все это на уровне простой арифметики. Небольшое чтиво, на уровне тривиальных примеров и т.п., чтоб можно было формулировать настоящие вопросы 

Столкнутся с зоопарком может только та фирма которая работает децентрализированно.
Т.е. каждый отдел ваяет что-то своё, и о наработках соседей не знает.
Что бы устранить подобное проводятся встречи,  и руководсво железной рукой продвигает перспективную платформу как внутрифирменный стандарт.
С момента Х все разработки делаются только по стандарту, а старые потихоньку перетягиваются на новую платформу.
Мы создали масштабируемую платформу, написали движок, ряд классов для решения общих задач, сейчас создаём DSL.
Каждый манагер получил диск, и лицензию на одного пользователя , всё что он делает начиная с момента Х он ОБЯЗАН делать только на этой платформе.
Тоже самое с документооборотом, раньше  документы были где угодно, только не в том месте где они нужны; одно решение руководства, поставлен шарепоинт - и, о чудо, всё на месте . всё в порядке.



Это сообщение отредактировал(а) Zlatogorov - 25.1.2008, 17:03

В некоторых случаях бывает выгоднее просто сливать уже готовую отчетность с разных источников, чем пересаживать на новый софт всех и вся. Это очень сложно и иногда бессмысленно. Особенно для какой-нибудь холдинговой компании, которая владее производством мыла, шин и телевизоров. Бизнес абсолютно разный, отчетность и учет тоже. Именно в таких ситуациях удобно "обернуть" уже готовые IT-структуры в сервисы и подключить их к какой-нибудь ESB.

Я думаю, что SOA еще не заняла свою нишу. Ситуация напоминает старт JAVA - когда все говорили об апплетах, а в итоге на JAVA пишутся мощные Enterprise-приложения.

Тоже самое наблюдается и сейчас - есть идея и даже готовые инструменты, но вот ниша пока для них непонятна для большинства. Посмотрим, что будет дальше.

Любая фирма с числом сотрудников > 10 000 человек работает децентрализованно, да и большинство более мелких контор - тоже. И перевести всё и вся, включая разбухшие биллинговые хранилища и системы анализа-обработки в приемлимые сроки просто нереально.

Это сообщение отредактировал(а) batigoal - 27.1.2008, 00:45

batigoal, понятно, что на новую платформу всех на одну ночь не пересадишь. Просто всё новое что создаётся делается на ней, а старое усилиями создателей платформы конвертируется (инициатива наказуема).  У нас примерно 30 тыс. сотрудников по всему миру. Манагерский состав - несколько тысяч,  приказом руководства каждый манагер получил копию платформы , до июня каждый обязан пройти обучение. А системы анализа были отдельно созданы ещё давно, каждый сотрудник при поступлении получает 2 курса продолжительностью 2 недели каждый.
Так что в system definition никаких разногласий не бывает.

SOA и веб-сервисы

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

Добавлено через 12 минут и 23 секунды
Мой вопрос остается открытым, но в целом хотел бы выложить ссылку, хотя там вроде есть и тривиальный пример на уровне HelloWorld, (пока все просмотреть не успел). Русскоязычный источник. По мере прочтения, лично у меня каша начинает перевариватся 

SOA и WEB-сервисы

Вот кстати, тоже на мой взгляд очень не плохая статья, небольшая, но вот после этого предложения, приходит еще большее осмысление СОА



Сервис-ориентировання архитектура

Можно наверн и мою  темку переложить в этот раздел

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

Через некоторое время создатели платформы попытаются создать некий интеграционный слой, который сравнитено удобно можно интегрировать с окружающими системами. И получат, фактически, свой ESB. Если не ошибаюсь, ESB возникло примерно из таких-же условий. А то, что работает с шиной - назовут Сервисами. Вот тебе и СОА