Время SOA еще не пришло

Проблема в корне

SOA набирает обороты. Об этом свидетельствует как постоянно возрастающий интерес к Web-сервисам, на технологии которых основана эта концепция, так и данные аналитических компаний. По оценкам экспертов Gartner, к 2006 году более 60% компаний будут рассматривать сервис-ориентированную архитектуру как основу для построения и выполнения своих бизнес-приложений, а специалисты Giga Research считают, что в ближайшие два-три года большинство производителей буду использовать технологии, основанные на Web-сервисах в качестве расширения существующих решений.

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

Эволюция программных архитектур

Классическим примером первой ступени, мейнфрейма, может служить система SAP R/2. В клиент-серверной архитектуре таким образцом стала широко распространненая SAP R/3, а в качестве сервис-ориентированного решения компания SAP позиционирует свою новую интеграционную платформу NetWeaver. "Теперь SAP производит не только и не столько ERP-систему, а скорее специализированную оболочку — набор средств для быстрой и эффективной интеграции всего того, что уже работает на предприятии, - отмечает Тимур Аитов, директор по развитию бизнеса РБК СОФТ. - Сервисно-ориентированный подход, лежащий в основе платформы NetWeaver, позволяет резко облегчить и ускорить внедрение корпоративной информационной системы на любом предприятии" - подчеркивает он.

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

Справедливости ради, стоит отметить, что после анонсирования Microsoft Visual Studio Team System 2005, а также предложений IBM по конкретным решениям, основанным на SOA, это противостояние стало минимальным, и можно ожидать продвижения в разработке единых стандартов, регламентирующих использование Web-сервисов. Для успеха концепции сервис-ориентированной архитектуры необходимо наличие единого интерфейсного языка, описывающего Web-сервисы. В последнее время активно ведется работа над совершенствованием такого языка – Web Services Description Language (WSDL).

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

«Подводные камни» SOA

Классическое представление SOA реализуется в виде треугольника, во которого главе стоит реестр сервисов (Universal Description, Discovery and Integration - UDDI), а в двух остальных вершинах – провайдер и потребитель Web-сервиса.

Классическое представление концепции SOA

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

Другой немаловажный вопрос, связанный с самой технологией Web-сервисов, - использование протокола HTTP для передачи данных. С одной стороны это позволяет реализовать саму идеологию интеграции распределенных гетерогенных систем и обеспечить ее универсальность, а с другой - вызывает большое количество проблем, связанных с надежностью и безопасностью проведения транзакций. Более того, при использовании Web-сервисов, когда компоненты одного приложения могут отключаться и взаимодействовать с компонентами совершенно другого приложения, особенно остро встает проблема разграничения доступа и построения распределенной архитектуры защиты.

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

Подобных, достаточно спорных вопросов в реализации SOA довольно много. Безусловно, использование XML обеспечивает необходимую универсальность, но с другой стороны, закономерно встает проблема производительность SOA-приложений, скорость работы которых напрямую связана с так называемым «весом» XML-транзакций, на обработку которых требуется значительно большее время, нежели на классические двоичные транзакции. Сторонники SOA видят решение этой проблемы в появлении специализированных программных решений – «ускорителей» XML.

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

Верно, но рано

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

Тем не менее, говорить о широком применении и конкретных реализациях SOA еще рано. Аналитики из компании ZapThink, которая специализируется на вопросах и проблемах сервис-ориентированной архитектуры, считают, что ближайшие два-три года станут периодом совершенствования концепции SOA в области стандартов и программных решений. Необходима тщательная детализация архитектуры и проработка многих технологических вопросов, в частности, задачи взаимодействия между Web-сервисами в рамках выполнения определенной бизнес-задачи и соблюдение SLA (Service Level Agreement – соглашение об уровне обслуживания) в случае использования «стороннего» сервиса. Ведь именно потенциальная возможность построения распределенных гетерогенных систем (и, как следствие, возможность передачи части бизнес-функций на аутсорсинг удаленному сервису исходя из относительной стоимости организации подобного сервиса собственными силами) – одно из основных достоинств SOA.

Важно отметить само «зачаточное» состояние рынка SOA-решений – ни один поставщик на сегодняшний день не в состоянии предоставить полнофункциональное решение. Существует множество подходов к реализации сервис-ориентированной архитектуры, каждый из которых лоббируется определенным игроком ИТ-рынка. Свои принципы построения адаптивного предприятия предлагают такие крупные компании, как Microsoft, IBM, SAP, Hewlett-Packard, Computeer Associates, Bea Systems, Sybase и другие.

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

Алексей Куваев / CNews

Короткая ссылка на материал: //cnews.ru/link/a1004