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
Прочитал недавно очередной прогноз, касающийся 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
