Часто SOA и EDA различают но трем параметрам — по связанности приложении, режиму обмена сообщениями между ними и уровню синхронизации приложений.
Перечислим свойства, характерные для SOA.
Слабая связанность. SOA позволяет разработчикам, провайдерам и потребителям сервисов взаимодействовать вне зависимости от использованных ими технических решений и с минимальным знанием друг о друге — достаточно умения идентифицировать и использовать необходимый сервис.
Обмен сообщениями в режиме «запрос-ответ». SOA предполагает, что потребитель запрашивает получение не которых данных или некоторой функциональности, а провайдер сервиса отвечает ему, реализуя этот запрос.
Синхронность. SOA поддерживает синхронный режим сервиса, то есть при отработке запроса обе стороны находятся в режиме взаимодействия.
EDA, в первом приближении, отличается по этим показателям иными характеристиками.
Отсутствие связи. В EDА публикатор сообщении не знает, кто является подписчиком, и наоборот. Взаимодействие oграничивается обменом данными, и между отдельными подсистемами не устанавливается каких-либо тесных отношений.
Обмен сообщениями в режиме «публикация-подписка». EDА поддерживает отношения «многих со многими», то есть публикатор делает сообщение известным всем входящим в есть, а те, кто подписаны на сообщении или авторизованы, могут их получать,
Асинхронность. EDA поддерживает режим, в котором сообщение посылается без ожидания немедленной реакции на него. Из перечисленных несовпадений делается вывод, что перед нами — два совершенно разных явлении. Но так ли это? Чтобы лучше разобраться в том, что общего между ЕDA и SOA и чем они различаются, вернемся к основополагающим вещам — событиям, сервисам и архитектуре.
|
|
События. Простым событием называют происходящее в реальном мире изменение состояния окружающей среды, В бизнесе простым событием может быть изменение состояния предприятия или окружающей его среды, заказ товара, поставка, поступление платежа. Простое событие в программном обеспечении —это запись о простом событии. Сложным событием является связка из двух и более простых событий.
Сервисы. Обычно под сервисами понимают представление функциональности программного обеспечения в виде интерфейсов, обеспечивающих прием и передачу сообщений,
Архитектура, Согласно стандарту IEEE P1471/D5.3, архитектура программного обеспечения является основополагающим руководством для построении какой-либо системы, реализованным в виде ее компонентов, их отношений между тобой и с внешней средой, а также принципов проектирования и эволюции системы
SOA и EDA представляют собой первые попытки построить архитектуры, хоть в какой-то мере соответствующие многообразию окружающего мира.
SOA КАК ОСНОВА EDA.
События, сервисы и архитектура образуют единое целое. События — это форма проявления жизни, они происходят в реальном мире. Сервисы — один из возможных способов (если не единственный) установления взаимодействия между компонентами сложных систем. Наконец, архитектура определяет, как такие системы строятся.
С появлением Web-сервисов, а потом и SOA возникло понимание того, что компоненты систем могут быть слабо связанными. Из этого был сделан однозначный вывод: слабая связанность является обязательным признаком сервисной архитектуры. Но, рассмотрев примеры систем в окружающей среде, мы увидим, что связанность компонентов и ориентация на сервисы представляют собой независимые характеристики. Системы могут быть жестко, слабо или совсем не связанными, но одновременно с этим ориентированными или не ориентированными па сервисы. Кроме того, они могут управляться или не управляться событиями.
|
|
SOA и EDA.
В отчете компании ZapThink, датированным октябрем 2004 года, рассмотрены четыре возможных способа реализации SOA: простой обмен сообщениями, «публикация/подписка», маршрутизация сообщений о событиях и надежный обмен сообщениями. Здесь сервис рассматривается как частный случай события.
Первым механизмом реализации SOA стал непосредственный обмен сообщениями между провайдером и потребителем сервисов (replay/request). Предполагается, что потребитель посылает запрос в виде сообщения и ждет ответного сообщения, содержащего нужный сервис. Сообщение заказчика должно содержать обратный адрес и спецификацию желаемого действия. Ответное сообщение поставщика может содержать желаемые сведения или, к примеру, быть пустым.
Механизм «публикация/подписка » в некоторых случаях ассоциируют с EDA, хотя он точно так же может быть использован и для создания SОA. Потребитель подписывается па сведения об определенных категориях событии, описывая средствами метаданных интересующие его события. Провайдер сервисов или промежуточное звено анализирует заявку и передает сведения о событиях подписчику.
Маршрутизации сообщений о событиях отличается от двух описанных, механизмов тем, что в этом случае выполняется не простая механическая пересылка сообщений: вдобавок обеспечивается анализ контекста сообщения, а маршрутизация осуществляется в соответствии с имеющимися интеграционными сценариями.