|
|
СОБЫТИЯ И СЕРВИСЫ — ДВЕ СТОРОНЫ МЕДАЛИЧасто 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. Потребитель подписывается па сведения об определенных категориях событии, описывая средствами метаданных интересующие его события. Провайдер сервисов или промежуточное звено анализирует заявку и передает сведения о событиях подписчику.
  ЧТО ТАКОЕ УВЕРЕННОЕ ПОВЕДЕНИЕ В МЕЖЛИЧНОСТНЫХ ОТНОШЕНИЯХ? Исторически существует три основных модели различий, существующих между...  Что делать, если нет взаимности? А теперь спустимся с небес на землю. Приземлились? Продолжаем разговор...  Конфликты в семейной жизни. Как это изменить? Редкий брак и взаимоотношения существуют без конфликтов и напряженности. Через это проходят все...  ЧТО ПРОИСХОДИТ ВО ВЗРОСЛОЙ ЖИЗНИ? Если вы все еще «неправильно» связаны с матерью, вы избегаете отделения и независимого взрослого существования... Не нашли то, что искали? Воспользуйтесь поиском гугл на сайте:
|
Маршрутизации сообщений о событиях отличается от двух описанных, механизмов тем, что в этом случае выполняется не простая механическая пересылка сообщений: вдобавок обеспечивается анализ контекста сообщения, а маршрутизация осуществляется в соответствии с имеющимися интеграционными сценариями.