Source: http://www.itblogs.ru/blogs/borkus/archive/2007/07/09/18921.aspx
Прочитал недавно очередной прогноз, касающийся SOA. В общем, все как обычно, но несколько положений заинтересовало. В частности, в нем говорится, что в ближайшее время вендоры перестанут пиарить аббревиатуру SOA, а переключатся на рекламу EDA. Так как подобное вполне возможно (нужна новая «серебрянная пуля»), то можно поговорить немного об этом «новом прорыве» и о некоторых других.
EDA расшифровывается как Event Driven Architecture, т.е. архитектура, построенная на обработке событий. События рождаются в одних системах, попадают на шину доставки и потребляются другими системами. Получается, что EDA -- это наследница технологий MOM (Message Oriented Middleware). Собственно, и программное обеспечение, через которое распространяются события EDA -- это, как правило, шина на базе JMS (Java Messaging Service), т.е. самый что ни на есть MOM.
Есть в EDA, правда, и некоторые добавочные вещи, например, повсеместность событий (сервисы могут генерировать события), возможность по событию инициировать вызов сервиса (т.е. синхронной коммуникации) или запуск делового процесса, возможность мониторинга событий (в том числе через агрегаторы типа dashboards), средства интеллектуальной корреляции событий (Complex Event Processing (CEP).
Например, BPM-система TIBCO iProcess Suite может автоматически генерировать события по завершению каждого шага делового процесса. Другие инструменты TIBCO могут находить соответствия в цепочках событий, и, например, создавать новое событие, которое запускает деловой процесс. (Аналогичные возможность есть в ПО Oracle и других.). И все же сказать, что EDA -- вещь абсолютно новая, сложно.
Для привязки вызовов сервисов к событиям одной MOM уже мало, нужны средства ESB (Enterprise Services Bus). Продукты ESB (Enterprise Service Bus) и дополнительные к ним модули основных производителей -- BEA, Fiorano, IBM, Oracle, Sonic, TIBCO -- поддерживает EDA «из коробки». Но среди вендоров пока нет терминологического согласия на тему, является ли EDA частью SOA или нет. Например, TIBCO считает, что является, а Oracle, что это уже «больше, чем SOA».
Есть еще один набирающий популярность термин/набор стандартов -- SCA (Service Component Architecture, архитектура служебных/сервисных компонент). Суть здесь состоит в создании сборок сервисов, описания интерфейсов которых отделены от инфраструктурной составляющей.
В системе выделяются компоненты, решающие какие-либо бизнес задачи, и для каждой из них задается интерфейс внешнего доступа в виде группы сервисов. Изменить данные в компоненте можно только через эти сервисы. Сами сервисы и компоненты описываются терминах именно бизнеса, а не технологий. Иначе говоря, если в SOA (по мнению некоторых) может фигурировать "сервис обновления таблицы БД", то в рамках SCA может быть исключительно сервис «обновить данные о клиенте» в объекте «клиент».
Существенно, что такую компоненту/интерфейс потом можно при помощи деклараций привязывать к конкретному технологии -- Java, COBOL, PHP, XML-языки (BPEL) и т.п. В ходе жизненного цикла, можно менять технологический слой компоненты, не трогая интерфейс. SCA индифферентна к тому используются ли синхронные или асинхронные вызовы, а обращающиеся к компоненте системы в технологическом плане могут быть оформлены весьма различно.
Подобная «высокоуровневая» объектная ориентированность позволяет разработчику компоненты инкапсулировать в ее описании все зависимости данного сервиса от других сервисов. В итоге упрощается применение в сервисам политик доступа, политик доставки, обеспечение транзакционности -- они задаются декларативно на уровне SCA, а не в рамках программного кода. Также управлять жизненным циклом компонент проще, чем жизненным циклом «кучи» сервисов. В общем, новое есть. Некоторые называют все это «SOA NextGeneration/2.0», хотя, наверное, это чересчур оптимистично.
PS. Замечу, что SCA также опирается на технологию SDO (Service Data Objects, служебные объекты данных) для передачи параметров и возвращаемых значений. Это инструмент для универсального описания объектов данных (в терминах графов) и интерфейсы для манипулирования ими.
PPS. В настоящее время SCA поддерживают продукты BEA, IBM, Oracle, TIBCO и несколько более мелких вендоров. Работы по SCA ведутся в рамках проекта «открытая SOA» (www.osoa.org)
//Влад Боркус, www.konnasi.ru
Published 9 июля 2007 г. 16:08 by Vlad Borkus Edit
Filed under: SOA
Alexander Kupriyanov said:Производители ИТ идеологий верхнего порядка все более напоминают модные дома Haute couture.июля 9, 2007 17:09
nvoynov said:
Названия новые, но все это оркестрация веб сервисов ... не как стандарт описания но как типовая функциональность тех же BPM- продуктов. И, кстати, к цитате ниже прекрасно подходим BPMN (уже стандарт OMG).
".. некоторые добавочные вещи, например, повсеместность событий , возможность по событию инициировать вызов сервиса (т.е. синхронной коммуникации) или запуск делового процесса, возможность мониторинга событий (в том числе через агрегаторы типа dashboards), средства интеллектуальной корреляции ..."
В целях демонстрации можно порекомендовать intalio.org (компания выпускает Intalio|BPMS, автор первых стандартов по языкам выполнения бизнес-процессов, BPMN нотации) - просто посмотрите демонстрационные примеры процессов
июля 9, 2007 18:20
kolesov said:
Я совсем не претендую на роль первооткрывателя, но помнится, что еще в конце прошлого года по поводу СОА отметил, что ИТ-термины и "актуальные" ИТ-темы должны обновляться с периодиченостью в 2-3 года. И там же было сказано, что 2007 -- это время смены для СОА :-) Так что самое время менять слова.
Кстати, кто-то неделю назд спрашивал о графике "жизненого цикла" Гантнера. Вот он -- ftp://visual.2000.ru/http/kolesov/pcweek/2007/slidesoa.JPG (это из презентации Владимира Андреева, которые ее сделал 25 мая на DOCFLOW). Так что СОА скоро пройдет минимум и начнет период "реального" освоения.
Да..., Гартнер уже придумал новый сегмент рынка, вместо СОА -- "application platform". Работают ребята и нам -- консультантам и примкнывшим к ним журналистам -- дают обновлить свой гардеробчик :-)
июля 9, 2007 20:17
kolesov said:
Извините, дал неверную ссылку на слайд. Вот правильная:
http://visual.2000.ru/kolesov/pcweek/2007/slidesoa.JPG
июля 9, 2007 20:20
Vlad Borkus said:
2 nvoynov
О том, в общем-то и речь.
Хотя есть некоторые тонкости, например, события могут быть и вне конкретного процесса BPM и вообще вне системы BPM. Их поток как-то можно коррелировать, с полезными результатами. CEP и внешние dashboards -- как раз про это.
SCA, как понимаю, имеет несколько практических задач 1) унификацию описаний сервисных сборок между продуктами (т.е. стандартизация самих продуктов) и привязки их к слою реализации 2) улучшение структуризации "куч сервисов", их управлемости 3) технические задачи (в частности упрощение, стандартизация транзакционности). Есть, конечно, и цель упрощения BPM-оркестровки. Но компоненты -- это больше метод объединения сервисов и описания некоторых их свойств в один развертываемый пакет.
По нотациям... их изобрели много, BPMN пока только одна из них. Хотя она действительно толковая. Но по ней можно сразу смотреть первоисточник www.bpmn.org. Вполне внятная документация.
[Intalio вызывает уважение (я думаю, мы говорим все же о intalio.com), вендор с хорошими идеями, open source, мне нравится их блог, но пока вендор очень маленький..]
июля 9, 2007 20:44
feygin said:
SCA (как, кстати, и JMS) представляет из себя API, позиционирующийся как нейтральный по отношению к языку и платформе. Предпочтения в пользу Java, тем не менее, очевидны. В этом смысле это своеобразный ответ Windows Communication Foundation, пока весьма ущербный.
Кстати SCA уже в OASIS: http://www.oasis-opencsa.org/.
июля 10, 2007 15:51
Vlad Borkus said:
2 feygin
SDO -- это да, много элементов API, а SCA выглядит больше как очередной XML-язык для описания/группировки свойств + все же некая модель программирования. Скорее SCA ближе к _конфигурационным_ мета-файлам из EJB + визуальные представления. Задача в каком-то смысле обратная API -- запрятать программиста подальше от бизнеса (собственно они даже заявляют "no technical APIs like JMS" :)) ). Аннотации -- не в счет, это не API.
Склонность SCA к Java -- это точно. Видимо потому, что Microsoft это все проигнорировал.
Хорошая презентация на тему: http://www.osoa.org/download/attachments/250/SCA_OASIS_Tutor…
июля 10, 2007 17:20
feygin said:
Да, я действительно про SDO думал, а не про SCA. SCA я бы описал как мета-модель deployment'а + соответствующий межплатформенный язык описания этой самой модели.
Кстати, я смотрел как-то Apache Tuscany; кажется тогда была версия 0.6. Понятно, что по такой ранней реализации трудно судить о конечном продукте, но мне далеко не все понравилось в самой модели. Жаль, что тогда не записал свои мысли. Думаю, что тем, кто попробовал WCF, SCA придется не по вкусу.
июля 10, 2007 17:55
sdng said:
Хотел бы не согласиться с утверждением, что в SCA сервисы описываются исключительно в терминах бизнеса - как опишем так и будет :)
июля 10, 2007 19:24
Vlad Borkus said:
2 sdng
Согласен. Но с точки зрения текукщих спецификаций. Отдельно разработчики (вендоры) все же высказывались про глубинную идеологию/про то, как они считают эта штука должна применяться. Так сказать, путеводная звезда, еще не достигнутая сверхзадача. :))))
июля 10, 2007 22:29
Прочитал недавно очередной прогноз, касающийся SOA. В общем, все как обычно, но несколько положений заинтересовало. В частности, в нем говорится, что в ближайшее время вендоры перестанут пиарить аббревиатуру SOA, а переключатся на рекламу EDA. Так как подобное вполне возможно (нужна новая «серебрянная пуля»), то можно поговорить немного об этом «новом прорыве» и о некоторых других.
EDA расшифровывается как Event Driven Architecture, т.е. архитектура, построенная на обработке событий. События рождаются в одних системах, попадают на шину доставки и потребляются другими системами. Получается, что EDA -- это наследница технологий MOM (Message Oriented Middleware). Собственно, и программное обеспечение, через которое распространяются события EDA -- это, как правило, шина на базе JMS (Java Messaging Service), т.е. самый что ни на есть MOM.
Есть в EDA, правда, и некоторые добавочные вещи, например, повсеместность событий (сервисы могут генерировать события), возможность по событию инициировать вызов сервиса (т.е. синхронной коммуникации) или запуск делового процесса, возможность мониторинга событий (в том числе через агрегаторы типа dashboards), средства интеллектуальной корреляции событий (Complex Event Processing (CEP).
Например, BPM-система TIBCO iProcess Suite может автоматически генерировать события по завершению каждого шага делового процесса. Другие инструменты TIBCO могут находить соответствия в цепочках событий, и, например, создавать новое событие, которое запускает деловой процесс. (Аналогичные возможность есть в ПО Oracle и других.). И все же сказать, что EDA -- вещь абсолютно новая, сложно.
Для привязки вызовов сервисов к событиям одной MOM уже мало, нужны средства ESB (Enterprise Services Bus). Продукты ESB (Enterprise Service Bus) и дополнительные к ним модули основных производителей -- BEA, Fiorano, IBM, Oracle, Sonic, TIBCO -- поддерживает EDA «из коробки». Но среди вендоров пока нет терминологического согласия на тему, является ли EDA частью SOA или нет. Например, TIBCO считает, что является, а Oracle, что это уже «больше, чем SOA».
Есть еще один набирающий популярность термин/набор стандартов -- SCA (Service Component Architecture, архитектура служебных/сервисных компонент). Суть здесь состоит в создании сборок сервисов, описания интерфейсов которых отделены от инфраструктурной составляющей.
В системе выделяются компоненты, решающие какие-либо бизнес задачи, и для каждой из них задается интерфейс внешнего доступа в виде группы сервисов. Изменить данные в компоненте можно только через эти сервисы. Сами сервисы и компоненты описываются терминах именно бизнеса, а не технологий. Иначе говоря, если в SOA (по мнению некоторых) может фигурировать "сервис обновления таблицы БД", то в рамках SCA может быть исключительно сервис «обновить данные о клиенте» в объекте «клиент».
Существенно, что такую компоненту/интерфейс потом можно при помощи деклараций привязывать к конкретному технологии -- Java, COBOL, PHP, XML-языки (BPEL) и т.п. В ходе жизненного цикла, можно менять технологический слой компоненты, не трогая интерфейс. SCA индифферентна к тому используются ли синхронные или асинхронные вызовы, а обращающиеся к компоненте системы в технологическом плане могут быть оформлены весьма различно.
Подобная «высокоуровневая» объектная ориентированность позволяет разработчику компоненты инкапсулировать в ее описании все зависимости данного сервиса от других сервисов. В итоге упрощается применение в сервисам политик доступа, политик доставки, обеспечение транзакционности -- они задаются декларативно на уровне SCA, а не в рамках программного кода. Также управлять жизненным циклом компонент проще, чем жизненным циклом «кучи» сервисов. В общем, новое есть. Некоторые называют все это «SOA NextGeneration/2.0», хотя, наверное, это чересчур оптимистично.
PS. Замечу, что SCA также опирается на технологию SDO (Service Data Objects, служебные объекты данных) для передачи параметров и возвращаемых значений. Это инструмент для универсального описания объектов данных (в терминах графов) и интерфейсы для манипулирования ими.
PPS. В настоящее время SCA поддерживают продукты BEA, IBM, Oracle, TIBCO и несколько более мелких вендоров. Работы по SCA ведутся в рамках проекта «открытая SOA» (www.osoa.org)
//Влад Боркус, www.konnasi.ru
Published 9 июля 2007 г. 16:08 by Vlad Borkus Edit
Filed under: SOA
Comments
Alexander Kupriyanov said:Производители ИТ идеологий верхнего порядка все более напоминают модные дома Haute couture.июля 9, 2007 17:09
nvoynov said:
Названия новые, но все это оркестрация веб сервисов ... не как стандарт описания но как типовая функциональность тех же BPM- продуктов. И, кстати, к цитате ниже прекрасно подходим BPMN (уже стандарт OMG).
".. некоторые добавочные вещи, например, повсеместность событий , возможность по событию инициировать вызов сервиса (т.е. синхронной коммуникации) или запуск делового процесса, возможность мониторинга событий (в том числе через агрегаторы типа dashboards), средства интеллектуальной корреляции ..."
В целях демонстрации можно порекомендовать intalio.org (компания выпускает Intalio|BPMS, автор первых стандартов по языкам выполнения бизнес-процессов, BPMN нотации) - просто посмотрите демонстрационные примеры процессов
июля 9, 2007 18:20
kolesov said:
Я совсем не претендую на роль первооткрывателя, но помнится, что еще в конце прошлого года по поводу СОА отметил, что ИТ-термины и "актуальные" ИТ-темы должны обновляться с периодиченостью в 2-3 года. И там же было сказано, что 2007 -- это время смены для СОА :-) Так что самое время менять слова.
Кстати, кто-то неделю назд спрашивал о графике "жизненого цикла" Гантнера. Вот он -- ftp://visual.2000.ru/http/kolesov/pcweek/2007/slidesoa.JPG (это из презентации Владимира Андреева, которые ее сделал 25 мая на DOCFLOW). Так что СОА скоро пройдет минимум и начнет период "реального" освоения.
Да..., Гартнер уже придумал новый сегмент рынка, вместо СОА -- "application platform". Работают ребята и нам -- консультантам и примкнывшим к ним журналистам -- дают обновлить свой гардеробчик :-)
июля 9, 2007 20:17
kolesov said:
Извините, дал неверную ссылку на слайд. Вот правильная:
http://visual.2000.ru/kolesov/pcweek/2007/slidesoa.JPG
июля 9, 2007 20:20
Vlad Borkus said:
2 nvoynov
О том, в общем-то и речь.
Хотя есть некоторые тонкости, например, события могут быть и вне конкретного процесса BPM и вообще вне системы BPM. Их поток как-то можно коррелировать, с полезными результатами. CEP и внешние dashboards -- как раз про это.
SCA, как понимаю, имеет несколько практических задач 1) унификацию описаний сервисных сборок между продуктами (т.е. стандартизация самих продуктов) и привязки их к слою реализации 2) улучшение структуризации "куч сервисов", их управлемости 3) технические задачи (в частности упрощение, стандартизация транзакционности). Есть, конечно, и цель упрощения BPM-оркестровки. Но компоненты -- это больше метод объединения сервисов и описания некоторых их свойств в один развертываемый пакет.
По нотациям... их изобрели много, BPMN пока только одна из них. Хотя она действительно толковая. Но по ней можно сразу смотреть первоисточник www.bpmn.org. Вполне внятная документация.
[Intalio вызывает уважение (я думаю, мы говорим все же о intalio.com), вендор с хорошими идеями, open source, мне нравится их блог, но пока вендор очень маленький..]
июля 9, 2007 20:44
feygin said:
SCA (как, кстати, и JMS) представляет из себя API, позиционирующийся как нейтральный по отношению к языку и платформе. Предпочтения в пользу Java, тем не менее, очевидны. В этом смысле это своеобразный ответ Windows Communication Foundation, пока весьма ущербный.
Кстати SCA уже в OASIS: http://www.oasis-opencsa.org/.
июля 10, 2007 15:51
Vlad Borkus said:
2 feygin
SDO -- это да, много элементов API, а SCA выглядит больше как очередной XML-язык для описания/группировки свойств + все же некая модель программирования. Скорее SCA ближе к _конфигурационным_ мета-файлам из EJB + визуальные представления. Задача в каком-то смысле обратная API -- запрятать программиста подальше от бизнеса (собственно они даже заявляют "no technical APIs like JMS" :)) ). Аннотации -- не в счет, это не API.
Склонность SCA к Java -- это точно. Видимо потому, что Microsoft это все проигнорировал.
Хорошая презентация на тему: http://www.osoa.org/download/attachments/250/SCA_OASIS_Tutor…
июля 10, 2007 17:20
feygin said:
Да, я действительно про SDO думал, а не про SCA. SCA я бы описал как мета-модель deployment'а + соответствующий межплатформенный язык описания этой самой модели.
Кстати, я смотрел как-то Apache Tuscany; кажется тогда была версия 0.6. Понятно, что по такой ранней реализации трудно судить о конечном продукте, но мне далеко не все понравилось в самой модели. Жаль, что тогда не записал свои мысли. Думаю, что тем, кто попробовал WCF, SCA придется не по вкусу.
июля 10, 2007 17:55
sdng said:
Хотел бы не согласиться с утверждением, что в SCA сервисы описываются исключительно в терминах бизнеса - как опишем так и будет :)
июля 10, 2007 19:24
Vlad Borkus said:
2 sdng
Согласен. Но с точки зрения текукщих спецификаций. Отдельно разработчики (вендоры) все же высказывались про глубинную идеологию/про то, как они считают эта штука должна применяться. Так сказать, путеводная звезда, еще не достигнутая сверхзадача. :))))
июля 10, 2007 22:29
Комментариев нет:
Отправить комментарий