События и сервисы — две стороны медали

↑

▷ Содержание

⇐ ПредыдущаяСтр 60 из 62Следующая ⇒

Часто 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. Потребитель подписывается па сведения об опреде­лен­ных категориях событии, описывая средствами метаданных интересующие его события. Провай­дер сервисов или промежуточное звено анализирует заяв­ку и передает сведения о событиях подпис­чику.

Маршрутизации сообщений о событиях отличает­ся от двух описанных, механизмов тем, что в этом слу­чае выполняется не простая механическая пересылка сообщений: вдобавок обеспечивается ана­лиз контек­ста сообщения, а маршрутизация осуществляется в соответствии с имеющимися  интегра­цион­ными сце­нариями.

Познавательные статьи:



Техника прыжка в длину с разбега

Тактические действия в защите

История Олимпийских игр

История развития права интеллектуальной собственности