Журнал о компьютерных сетях и телекоммуникационных технологиях
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК:
    Домой
 
   
АРХИВ ЖУРНАЛА
   

2008: 1 2 3 4 5 6 7 8 9 10 11 12 13
2007: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2006: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2005: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2004: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2003: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2002: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2001: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2000: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
1999: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
1998: 1 2 3 4 5 6 7 8 9 10 11 12
1997: 1 2 3 4 5 6 7 8 9 10 11 12
1996: 1 2 3 4 5 6 7 8 9 10


Rambler's Top100

  

SOA: что дальше?

Энди Дорнан

Рынок продуктов для сервис-ориентированной архитектуры (Service-Oriented Arhitecture — SOA) в настоящее время переживает этап консолидации. При этом компании-новички стремятся расширить занимаемые ими ниши, а более крупные игроки предлагают комплексы, претендующие на охват всех задач в области интеграции бизнес-сервисов. Эта консолидация частично подпитывается перекрытием функциональных возможностей, которое характерно для разных компонентов традиционного набора SOA-продуктов, а частично — экспансией поставщиков из других секторов рынка корпоративного ПО в область SOA.

Существуют четыре основные категории продуктов SOA: продукты типа ESB (Enterprise Service Bus), системы администрирования разработки приложений (design-time governance), системы управления средой исполнения сервисов (runtime management) и шлюзы безопасности (security gateway). Функциональные возможности продуктов всех четырех категорий перекрываются, но тем не менее продукты каждой из них имеют определенные уникальные характеристики, которыми не располагают продукты других категорий.

Наиболее отработанный тип продуктов — это шины ESB, которые обеспечивают транспорт данных между сервисами. Наименее зрелая категория — средства администрирования разработки приложений, осуществляющие управление проектированием метаданных приложений и их исходного кода. Эти компоненты SOA-архитектуры предлагаются поставщиками исключительно в виде ПО. Системы же администрирования сервисов и шлюзы безопасности вполне соответствуют категории прикладной сетевой инфраструктуры и соответственно предлагаются в виде как аппаратных, так и программных средств, причем иногда одними и теми же поставщиками.

Кроме того, все увеличивающаяся роль SOA поощряет поставщиков, работающих в других секторах рынка, переходить в эту область. Если говорить о ПО, то продукты для управления бизнес-процессами всегда были тесно связаны с SOA — как и нарождающееся сейчас направление обработки информации о сложных событиях (Complex Event Processing — CEP). Интерес к веб-сервисам стимулируется так называемыми развитыми Интернет-приложениями (Rich Internet Application — RIA) Web 2.0. Если перейти к аппаратным средствам, то компании, работающие на рынке сетевой инфраструктуры, тоже идут в область SOA, предлагая системы администрирования и обеспечения безопасности. Обычно — это аппаратные устройства, располагающиеся перед приложениями (Application Front End — AFE), обеспечивающие предварительную обработку входных данных и способные ускорять работу всех четырех категорий продуктов.

Полную версию данной статьи смотрите в 5-м номере журнала за 2008 год.

Задействование и «оркестровка» сервисов

ESB имеет две ключевые функции, критически важные для интеграции приложений: задействование сервисов (service enablement) и их «оркестровка» (orchestration). Первое реализуется на нижнем уровне и представляет собой просто набор интерфейсов-конверторов, которые транслируют различные API-интерфейсы приложений и интерфейсы устройств на единый язык, чтобы они могли «понимать» друг друга. Это могут быть унаследованные приложения для мэйнфреймов, системы ERP или CRM. На более высоком уровне связующее ПО ESB помогает формировать из вновь представляемых сервисов так называемые композитные, или составные, приложения.

Наличие множества стандартов означает, что функция задействования сервисов в общем случае продолжает оставаться необходимой, даже если поставщики уже пользуются преимущественно «родными» интерфейсами веб-приложений. Правда, от этой функции можно отказаться, когда речь идет о среде с продуктами от одного поставщика. Кроме продуктов ESB, эта функция присутствует и в некоторых продуктах администрирования разработки приложений, а также в специализированных пакетах интеграции. «Оркестровка» сервисов в чем-то перекрывается с функциями управления бизнес-процессами (Business Process Management — BPM), и многие поставщики предлагают продукты, объединяющие эту функциональность. Однако стандартизация обмена информацией между пакетами BPM и ESB разных производителей практически отсутствует.

На стыке между двумя упомянутыми основными функциями ESB находятся функции трансляции (посредничества), которые необходимы в большинстве SOA-продуктов для связывания приложений, предназначенных для исполнения на нескольких разных платформах, или приложений, разработанных разными поставщиками. Эти функции также могут реализоваться пакетами управления средой исполнения сервисов и распадаются на две основные категории: XML-преобразование и протокольное посредничество. Обе они имеют дело с преобразованием форматов данных и протоколов: XML-преобразование — на уровне приложений, а протокольное посредничество — на более низком уровне. Например, многие организации используют Java-службу обмена сообщениями (Java Message Service — JMS). При этом для работы в Интернете эти сообщения должны быть преобразованы в веб-формат.

Кроме того, ESB-продукты в общем случае предусматривают контентно-зависимую маршрутизацию, под которой понимается маршрутизация, базирующаяся на XML-элементах или других прикладных протоколах, а не на сетевых адресах. Данная функция предлагается и в продуктах администрирования сервисов. Ее исполнение может быть ускорено специализированными аппаратными и программными средствами XML-процессинга в составе шлюзов безопасности. Контентно-зависимую маршрутизацию все чаще начинают предлагать поставщики AFE-продуктов, рассматривая ее как естественное продолжение функции балансировки нагрузки.

Поскольку развертывание архитектуры SOA весьма затратное мероприятие, первые ESB-продукты использовались только очень крупными организациями. Сейчас они становятся все более популярными благодаря появлению соответствующих предложений в области открытого ПО и внедрению соответствующих функций в продукты других категорий. Корпоративная шина ESB уже является стандартным решением для поставщиков серверов приложений и, по всей вероятно-сти, вскоре станет типовым компонентом пакетов BPM. Для решения этой задачи поставщики ESB сейчас перемещают этот продукт на более высокий уровень ПО — в направлении BPM, CEP и RIA.

Администрирование разработки

В принципе, задача администрирования разработки приложений для SOA-архитектуры заключается в согласовании работы сервисов с бизнес-процессами — от проектирования сервисов до момента обращения к ним составного приложения. Администрирование разработки сервисов охватывает два ключевых направления, в которых обычно работают одни и те же поставщики, хотя часто они реализуют их в отдельных продуктах.

Первое направление — репозиторий. Это база данных, в которой отслеживается информация о каждом сервисе в данной реализации SOA, а также соответствующие метаданные и информация о правилах политики безопасности. Можно создать бизнес-правила, которые предписывают выполнение подлежащих реализации операций, но при этом обойтись без вмешательства разработчиков и тестировщиков все же невозможно. Поскольку репозиторий играет в цикле разработки очень большую роль, многие поставщики средств администрирования разработки приложений предлагают также в той или иной форме функции задействования сервисов. Кроме того, эти средства перекрываются по функциям со средами управления разработкой кода, изначально не предназначенными для работы в среде SOA.

Второе направление — реестр, каталог всех имеющихся веб-сервисов. К нему могут обращаться разработчики в процессе программирования или приложения во время исполнения, что в общем случае делает спрос на него более активным по сравнению с репозиторием. В результате функции реестра UDDI (Uniform Description, Discovery and Integration) начнут, по-видимому, предлагать поставщики, работающие в других секторах рынка — в области ESB и управления средой исполнения сервисов — даже если в настоящее время они не намерены развивать соответствующие продукты до уровня полномасштабных репозиториев.

Системы администрирования разработки SOA-приложений являются наименее зрелой категорией продуктов в этой сфере, поскольку необходимость в специализированных решениях возникает только в сравнительно крупных системах. Администрирование разработки, вероятно, станет направлением расширения области интересов поставщиков ESB-продуктов и продуктов для управления средой исполнения веб-сервисов, желающих повысить ценность предлагаемых ими систем. В то же время здесь может проходить линия раздела, поскольку данные виды продуктов ориентированы на разные цели. ESB-продукты вышли из мира разработки приложений и поэтому имеется большая вероятность их экспансии в область репозиториев, а платформы управления средой исполнения сервисов, вероятнее всего, будут предлагать функцию формирования их реестра.

Проблемы управления средой исполнения сервисов

Управление средой исполнения SOA полностью опирается на средства администрирования веб-сервисов, поэтому многие из этих продуктов предназначены также для применения c веб-сервисами, не объединенными в SOA. В результате они во многом дублируют функции XML-процессинга и контентно-зависимой маршрутизации, имеющиеся в ESB. В то же время они редко используются для обеспечения задействования (enablement) сервисов — все, с чем они имеют дело, уже заложено в веб-сервисе.

Однако наиболее важная задача комплекса для SOA-администрирования — мониторинг всех веб-сервисов в рамках SOA. Это очень важно с точки зрения контроля соответствия веб-сервисов установленным правилам, политике безопасности и соглашениям об уровне обслуживания (Service-Level Agreement — SLA), а также при поиске неполадок. В сложных SOA-решениях одни веб-сервисы зависят от других, поэтому администраторы нуждаются в отслеживании этих взаимосвязей и получении информации, помогающей им разбираться в том, как один сервис влияет на другой.

Мониторинг может осуществляться тремя способами. Один из них, характеризующийся тем, что позволяет наиболее плотно «наблюдать» за приложениями, использует программы-агенты, которые встроены в прикладную платформу или ESB-продукт и работают параллельно с сервисами. Недостатки этого способа — необходимость написания отдельного агента для каждой администрируемой программы и устройства и то, что этот вариант работает только внутри одной организации. Второй способ мониторинга применяется тогда, когда агент не может исполняться на платформе непосредственно, и сводится к исполнению агента на сервере-посреднике (proxy server), через который направляется весь трафик. Серверы-посредники легче поддаются масштабированию, но они могут весьма ощутимо снизить производительность. Третий и самый новый способ мониторинга позволяет полностью отказаться от агентов благодаря обращению к «родным» API, но внедрение подобной системы требует тесного взаимодействия с поставщиком.

Веб-сервисы, доступ к которым осуществляется через Интернет, нуждаются в функциях обеспечения информационной безопасности, которые отсутствуют в ESB-продуктах, рассчитанных на использование за межсетевым экраном (МЭ). Поэтому большинство SOA-продуктов администрирования сервисов могут также выполнять шифрование/дешифрование, реализовать функцию цифровой подписи, а также аутентификацию, авторизацию и учет ресурсов (Authentication, Authorization, Accounting — AAA). Как правило, эта функциональность реализуется в шлюзах безопасности, именно этот факт стал стимулом к вовлечению поставщиков шлюзов в область администрирования сервисов. Таким образом, они предлагают сейчас аппаратные системы, которые конкурируют с традиционными программными решениями.

Концепция Web 2.0 придала ESB-продуктам администрирования второе дыхание, так как многие RIA-приложения работают и вне архитектуры SOA. Такие системы могут постепенно превращаться и сложные SOA-решения, требующие ESB, но при этом всегда остается возможность использовать автономные средства администрирования.

Двери — на замок

Разработка шлюзов безопасности начиналась с устройств — ускорителей XML-процессинга, предназначенных для разгрузки систем, несущих бремя обработки громоздких, насыщенных текстами XML-сообщений. Шлюзы по-прежнему могут исполнять многие из необходимых для этого функций, ускоряя контентно-зависимую маршрутизацию и администрирование с привлечением сервера-посредника. Однако очень скоро поставщики обнаружили, что коронной задачей для XML-устройств является обеспечение информационной безопасности, поскольку существует риск, что вместе с сообщениями веб-сервисов через МЭ в корпоративную систему могут проникать соответствующие угрозы.

В результате стандартные МЭ наделяются функциями распознавания потоков данных от различных приложений. Межсетевые экраны, специализирующиеся на XML, переходят на более высокий уровень в иерархии ПО: они считывают содержимое XML-сообщений, с тем чтобы определять, не несут ли в себе последние угрозу безопасности. Поскольку RIA часто используют форматы, не являющиеся XML-форматами, или инициируют команды через заголовки протоколов, современные межсетевые экраны XML должны работать не только с XML-сообщениями — им надо анализировать весь трафик, идущий на уровне приложений. На данный момент шлюз безопасности является единственным продуктом, который может реализовывать функциональность межсетевых экранов XML. Правда, сейчас в данную область входят поставщики устройств AFE.

Шлюзы безопасности предназначены также для исполнения и других функций обеспечения защиты веб-сервисов, включая XML-шифрование, установление подлинности цифровых подписей и функции AAA. В этой части они конкурируют с ПО управления средой исполнения сервисов или дополняют его. Шлюзы могут также помочь в реализации низкоуровневых протоколов обеспечения безопасности, таких, как протокол SSL (Secure Sockets Layer), однако в этом случае они конфликтуют с устройствами AFE и обычными МЭ.

Несмотря на то что первые шлюзы безопасности были аппаратными устройствами, сейчас они все чаще реализуются в виде ПО. Правда, некоторые поставщики предлагают их и в виде виртуальных устройств. Такой переход от аппаратной к программной реализации побуждает некоторых поставщиков заняться разработкой средств управления веб-сервисами и администрирования архитектуры SOA. Аппаратные межсетевые экраны XML все чаще будут внедряться в сетевую инфраструктуру и оснащаться AFE-акселераторами, которые могут обеспечивать аппаратное ускорение и других функций SOA..

  
5 '2008
СОДЕРЖАНИЕ

бизнес

• Операционный контроль эффективности call-центра

• «Зеленый» CeBIT

инфраструктура

• Тестируем оборудование для БЛВС малых и средних предприятий

• Унифицированные коммуникации — что, зачем, когда?

• Нерешительные покупатели услуг широкополосной мобильной связи

информационные системы

• Как овладеть мастерством обработки электронной почты

• SOA: что дальше?

• Социальные сети становятся все более популярными

• Новая медиаэкосистема: сопротивление бесполезно

• Переосмысление концепции мобильных приложений

кабельные системы

• Кабельная система для сетевого видео

• Оптические соединения — это то, что нужно в ЦОДе

• Пожаробезопасные кабельные системы для ЦОДов

защита данных

• Виртуальные машины и виртуальные страхи

• Mozilla предупреждает пользователей об опасных сайтах

новые продукты

• Маршрутизирующий коммутатор от MRV Communications


• Калейдоскоп


Реклама:
 Copyright © 1996-2008 ООО "Сети и Системы Связи". вверх