На пути к SOA

Несмотря на то что в аббревиатуре SOA используется строительный термин «архитектура», эта концепция организации ИТ-инфраструктуры напоминает скорее не застывшую конструкцию из стекла и бетона, а живой организм, способный изменяться...

Наталья Дубова

Стандартные интерфейсы (standards-based).

В SOA вместо частных, закрытых API, предлагаемых тем или иным вендором, используются интерфейсы, нейтральные по отношению к специфике реализации сервиса, которая накладывается в результате учета особенностей аппаратной платформы, операционной системы, языка программирования. Подобный нейтралитет обеспечивает универсальность взаимодействия сервисов в разнородной среде и снижает затраты на интеграцию.

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

Web-сервисы и их предшественники

До сих пор, говоря о сервисах и SOA, мы сознательно избегали термина «Web-сервисы», с которым сегодня устойчиво ассоциируются реализации сервис-ориентированной архитектуры. Действительно, на данном этапе развития технологий интерфейсы и протоколы взаимодействия сервисов в SOA — это стандарты Web-сервисов. Однако сама концепция SOA не тождественна идее Web-сервисов, скорее ее воплощение в жизнь стало возможным благодаря появлению стандартов и технологий Web-сервисов.

На самом деле попытки реализовать архитектуру приложений, в которой распределенные прикладные модули представлены как объекты, взаимодействующие посредством четко описанных интерфейсов, предпринимаются уже довольно давно и с определенным успехом. Чтобы убедиться в этом, достаточно вспомнить хорошо известные ИТ-специалистам модели построения компонентных приложений Common Object Request Broker Architecture (CORBA) и Microsoft Distributed Component Object Model (DCOM). Внешне они действительно похожи на SOA, но более детальный анализ показывает, что в этих ранних подходах к сервисной ориентации программных систем не выполняются или выполняются с определенными ограничениями базовые принципы SOA. Так, в CORBA и DCOM взаимодействующие объекты являются сильносвязанными, и внесение изменений в реализацию программных компонентов, предоставляющих и использующих определенный сервис, должны быть скоординированы между собой. Запросы к объектам (сервисам) в этих архитектурах, как правило, содержат небольшой объем информации, учитывающей специфику реализации сервисов («мелкозернистая» — fine-grained — структура сервисов), и потому порождают значительный сетевой трафик между поставщиком и потребителем сервиса. В DCOM взаимодействие программных компонентов основано на закрытых интерфейсах Microsoft. CORBA не принадлежит частной компании, эта архитектура — плод усилий международного консорциума OMG, который ставил своей целью создание универсальной платформы интеграции разнородных программных компонентов на базе стандартного языка описания интерфейсов. Однако реализации спецификаций CORBA сильно варьируются в продуктах разных производителей, что ограничивает интероперабельность систем на базе CORBA. Кроме того, и CORBA, и DCOM имеют существенные ограничения по поддержке действительно распределенных систем, их протоколы взаимодействия объектов слишком сложны для организации производительной связи сервисов, реализованных на разных машинах.

С появлением XML открылся путь к созданию интерфейсов, нейтральных к платформе реализации. Основанный на XML язык описания Web-сервисов WSDL и использование XML для обмена сообщениями между сервисами обеспечивают тот универсальный механизм взаимодействия разнородных компонентов, без которого невозможна SOA. Стандартный протокол SOAP обеспечивает простую связь между сервисами по сети. Реестр сервисов, построенный по стандарту UDDI, позволяет компонентам системы получить информацию о доступных сервисах. Таким образом, Web-сервисы обеспечивают базовые технологии для создания приложений по принципам архитектуры SOA. Эти технологии будут эволюционировать и в перспективе могут оказаться вытесненными другими, более прогрессивными решениями, что не изменит общей сущности SOA, хотя, возможно, внесет коррективы в подходы к реализации этой архитектуры.

SOA — концепция, которая не дает точного описания того, как должны взаимодействовать сервисы, но говорит о том, как добиться, чтобы они понимали друг друга и могли быть интегрированы. Принципиальное различие между SOA и Web-службами — это различие между стратегическим подходом к процессам интеграции приложений и конкретной тактикой этой интеграции с той лишь оговоркой, что в данный момент развития ИТ именно эта тактика является оптимальной.

«Дорожная карта» SOA

Фактическая связь между задачами бизнес-подразделений компании и ресурсами, которыми располагает ИТ-служба, в частности ресурсами приложений, осуществляется посредством бизнес-процессов. Бизнес-процесс — последовательность шагов для достижения некоторого результата, и каждый шаг, как правило, поддерживается некоторым технологическим решением.

Одно из основных преимуществ SOA состоит в том, что эта архитектура, в отличие от многих традиционных программных моделей, нацелена на поддержку не программы, а процесса. В программе, написанной исходя из представлений программиста об оптимальности, логика процесса может быть произвольным образом распределена между компонентами, что сильно затрудняет, если не делает невозможным, использование нужных компонентов в других процессах. В SOA приложение разрабатывается исходя из логики бизнес-процесса: процесс разбивается на некоторую последовательность шагов, каждый из которых реализуется как отдельный сервисный компонент приложения. Эти компоненты интегрируются таким образом, чтобы их выполнение в определенной последовательности приводило к нужному бизнес-результату. Каждый из компонентов-сервисов может участвовать в реализации разных приложений для поддержки разных бизнес-процессов. При этом SOA позволяет включить в бизнес-процесс и унаследованные приложения, снабдив их соответствующим интерфейсом (операция так называемого «обертывания» — wrapping — приложения в Web-сервис), и тем самым защищает инвестиции компании в программные ресурсы. Конечная цель SOA — формирование среды, в которой бизнес-аналитики и разработчики получат возможность смоделировать и реализовать логику бизнес-процесса как взаимодействие сервисов, и предоставление механизмов для динамической реконфигурации сервисов в соответствии с эволюцией бизнес-процесса.

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

Аналитики ZapThink ([2]) выделяют несколько основных этапов реализации сервисного подхода в корпоративной архитектуре, каждый из которых должен дать положительный показатель возврата на инвестиции, чтобы оправдать дальнейшие вложения в SOA:

• базовая реализация Web-сервисов;
• статические сервисы, имеющие критическое значение для бизнеса;
• пилотные проекты SOA;
• корпоративная инфраструктура SOA;

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

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

Будущее — за SOA

Индустрия находится сейчас в начале пути к SOA, но, похоже, дороги назад уже нет. Большинство пользователей присматриваются к идее, экспериментируя или активно внедряя технологии Web-сервисов. Однако преимущества, которые обещает комплексный сервис-ориентированный подход, включая гибкость программной платформы по отношению к изменениям в бизнесе, возможности интегрировать в единую среду на единых принципах существующие ресурсы компании и разнообразные решения извне, убеждают, что игра стоит свеч. В конечном итоге SOA меняет не только технологическую инфраструктуру, но и сами принципы взаимодействия бизнеса и ИТ. Уровень абстракции, который создают сервисы между логикой бизнес-процесса и ее технологической реализацией, с одной стороны, скрывает от бизнес-пользователей сложности этой реализации, а с другой — позволяет им непосредственно влиять на воплощение бизнес-процессов в технологиях.

Литература:

1. Daniel Sholler. Making SOA real. META Group, June, 2004.
2. Growing an agile service-oriented architecture. Zapthink LLC, September, 2003.

Наталья Дубова — научный редактор журнала «Открытые системы», dubova@osp.ru

Стандарты для SOA

На данном этапе своего развития сервис-ориентированные архитектуры для описания и организации взаимодействия используют базовые стандарты Web-сервисов:

• eXtensible Markup Language (XML) — для представления данных;
• Web Services Definition Language (WSDL) — для описания доступных Web-сервисов;
• Universal Description, Discovery, Integration (UDDI) — для создания каталога доступных по сети Web-сервисов;
• Simple Object Access Protocol (SOAP) — для обмена данными.

Взаимодействие сервисов осуществляется по принципу «публикация-поиск-соединение» (см. рисунок): приложение, предоставляющее определенный сервис (провайдер сервиса), размещает информацию о нем в каталоге сервисов. Потребитель сервиса — приложение, которому необходима функциональность данного сервиса, находит информацию о нем в каталоге, для того чтобы установить соединение с этим сервисом и послать запрос.

Технологии реализации

Сервисная ориентация программной корпоративной архитектуры существенно меняет подходы к разработке, управлению, развертыванию, сопровождению и обеспечению безопасности приложений. Представление существующих программ и создание новых в соответствии с идеологией сервисов — ключевой, но далеко не единственный технологический компонент перехода к SOA. Реализация SOA связана с внедрением целого комплекса технологических решений.

Интегрированная среда разработки. SOA должна рассматриваться не только как архитектура для развертывания и выполнения распределенных прикладных решений, но и как модель программирования, в которой приложения строятся исходя из того, что они предоставляют в сетевой среде сервисы другим приложениям с помощью описания и публикации соответствующих интерфейсов. Поэтому одним из основных требований к реализации SOA является развертывание среды разработки на базе стандартной компонентной платформы (J2EE или .NET), которая предоставит инструментарий для разработки и тестирования Web-сервисов, обеспечит многократное использование создаваемых программных модулей и даст возможность представить существующие прикладные функции с помощью стандартных интерфейсов.

Инфраструктура интеграции и управления сервисами. Для организации взаимодействия сервисов необходима среда, которая обеспечит динамическую маршрутизацию запросов от прикладного компонента — потребителя сервиса и получение результатов от приложения — провайдера сервиса. Для этого может потребоваться поддержка синхронных и асинхронных коммуникаций более низкого уровня между приложениями, трансформация и высокоскоростное распределение данных, трансляция протоколов, кэширование функций Web-сервисов, виртуализация ввода/вывода и т. д. Для решения этих задач все большее распространение получает технология корпоративной сервисной шины (Enterprise Service Bus, ESB), которая предоставляет единый механизм для передачи запросов и получения результатов сервисов, выполнения необходимых преобразований сообщений и транспортных протоколов и управления потоком обращений к сервисам.

Инфраструктура безопасности сервисов. На основе корпоративных политик безопасности должны быть определены и обеспечены технологические правила доступа и использования прикладных ресурсов, организованных в виде сервисов. В частности, должна быть решена задача управления правами доступа пользователя к сервисам, которые могут инкапсулировать функции нескольких приложений.

Инфраструктура автоматизации и управления бизнес-процессами. Конечная цель SOA — обеспечить представление бизнес-процессов как взаимодействующих сервисов. Средства управления бизнес-процессами обеспечивают интеграцию в нужной последовательности сервисов, которые могут быть как локальными — реализованными в ИТ-инфраструктуре компании, так и удаленными, если процесс на определенных этапах обращается к ресурсам партнерских компаний. Стандартом для такой интеграции, которая в профессиональном лексиконе обозначается терминами «хореография» или «оркестровка» сервисов, становится разработанный IBM и Microsoft язык Business Process Execution Language (BPEL).

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

IBM, BEA Systems, Progress Software, TIBCO, Oracle включают в свои платформы интеграции приложений инструменты для реализации принципов SOA. В средах управления ИТ-инфраструктурой от Hewlett-Packard, Computer Associates, IBM, BMC Software появляются не только средства управления Web-сервисами, но и более комплексные предложения для мониторинга и контроля ресурсов в SOA. Интегрированные среды разработки приложений от IBM и Microsoft предоставляют возможности создания сервисов в идеологии SOA.

Наконец, одна из наиболее интересных тенденций последнего времени — обращение к SOA традиционных поставщиков ERP-систем, которые стремятся перейти от монолитных, громоздких решений к более гибким композитным приложениям, собираемым из компонентов-сервисов. Достаточно упомянуть платформу SAP NetWeaver, которая поддерживает интеграцию модулей, разработанных SAP и партнерами компании. SAP с ее стратегией развития корпоративной сервисной архитектуры (Enterprise Services Architecture, ESA) аналитики AMR Research (см. опубликованный 13 декабря 2004 года отчет SAP NetWeaver's Next Move: Navigating Standards-Based Interoperable Infrastructure) включают в немногочисленную групп вендоров, продукты которых смогут обеспечить полную экосистему разработки, развертывания и поддержки SOA. В эту группу входят также BEA, IBM, Microsoft и Oracle.

29.08.2005г

Также в разделе: