Каждый предшествующий век начинался с очередной технической революции: XIX век — с появления паровых машин, XX-й — с электричества и двигателей внутреннего сгорания. Лет через пятьдесят потомки скажут с какой революции начался XXI век. Пока же можно предположить, что среди претендентов на первенство есть еще не нашедшие своего точного названия системные изменения в компьютинге. Возможно, в этом ряду могут оказаться и Архитектуры, ориентированные на сервис.

Увы, современники спешат с оценками. Часто получается так, что, к сожалению, компьютерные аналитики и пресса берут на себя примерно ту же самую функцию, что и дома высокой моды. Их объединяет общее стремление пропагандировать то, что еще пока никому не нужно — и, быть может, не станет нужным никогда. К тому же, любая мода — и компьютерная мода не исключение — обязательно должна быть не просто новой, а радикально новой. Старая мода нужна не больше, чем прогноз погоды на вчера.

Вокруг новинок создается излишняя шумиха, мешающая отделить мнимые новации от подлинных ценностей. К числу последних вполне можно отнести хиты нынешнего сезона: «Архитектура, ориентированная на сервисы» (Service Oriented Architecture — SOA) и «Сервисная шина предприятия» (Enterprise Service Bus — ESB). Это явления более чем серьезные, хотя есть и скептические мнения. Так, заметный резонанс получила статья инженера из американского отделения компании Software AG Майкла Чампиона [1], который язвительно называет хвалу SOA и ESB «пропагандой очередного сдвига парадигмы» и «десятой революцией из двух предсказанных». Под влиянием SOA может измениться, в том числе, и мир разработки приложений [2]. Чем же обусловлены грядущие изменения?

Мнения аналитиков

Gartner Group утверждает, что текущий год должен стать переломным в истории индустрии программного обеспечения. Заголовки предсказаний Gartner звучат так: «SOA изменяет программное обеспечение», «SOA вступает в эпоху Web-сервисов», «SOA взбудоражит рынок серверов приложений», «Сервисная шина предприятия вышла на свет».

IDC опубликовала отчет «Сервисная шина предприятия революционизирует информационные технологии», где в качестве базиса для этого технологического решения фигурирует, SOA. Менее известная аналитическая компания ZapThink также утверждает, что SOA станет в ближайшие годы основой для ориентированной на процессы интеграции приложений, а объем этого сегмента рынка всего за несколько лет вырастет до 8-10 млрд. долл. Схожие заявления о перспективности SOA можно найти и у Giga Group, Meta Group и др. Однако надо признать, что все более или менее именитые аналитики по части ИТ уступили пальму первенства небольшой компании из Сан-Франциско Stencil Group.

Специалисты Stencil одними из первых смогли не просто оценить перспективность SOA, но и показать глубинную природу изменений, происходящих в архитектуре корпоративных систем [3]. Согласно их трактовке, появление SOA есть следствие закономерного эволюционного процесса, который наблюдается в течение последних 40-50 лет (таблица 1).

Архитектура SOA, как считают в Stencil, представляет собой новый и вполне закономерный этап эволюции корпоративных систем. Предпринятая попытка классификации интересна и полезна, но стоит учесть, что она несколько поверхностна. В ней все сводится лишь к технической стороне, к тому, что обычно называют информационной системой; между тем, она, в свою очередь, является подсистемой всей корпоративной системы в целом. Информационная система, как совокупность аппаратных и программных средств, эволюционирует не автономно; она развивается в сложной взаимосвязи с развитием всего корпоративного организма. Поэтому первые четыре строки, непосредственно относящиеся к технологиям, можно принять без всякой критики; что же касается «пользователей» и «значения для бизнеса», то и c этой частью можно согласиться, но с определенной натяжкой. Дело в том, что при переходе от мэйнфремов к клиент-серверным конфигурациям и далее к SOA изменяется функциональность, пересматриваются представления об информации и данных, а это явления более глубокие, чем изменения в аппаратной или программной архитектуре.

Соответственно архитектуре меняются и средства разработки. Еще в 1998 году по используемым средствам разработки совокупность новых проектов делилась поровну [12]: 50% приходилось на долю технологии Microsoft DNA и 50% — на долю всех остальных. Язык Java обладал долей, составляющей всего лишь около 1%. В 2005 году средства разработки, связанные с Java, отнимут чуть менее 40% рынка и станут самым большим сегментом. Оставшуюся часть разделят примерно поровну средства Microsoft .Net и традиционные программные технологии, причем на Microsoft DNA придется всего несколько процентов. Соответственной этому будет и динамика занятости.

Попытки определения SOA

Неопределенность, наблюдаемая сегодня в представлениях о SOA, хорошо знакома — явный «эффект дежавю». Когда в конце 90-х заговорили о Web-сервисах, на читателей обрушился поток противоречивых определений: на сайте компании Systinet справедливо утверждается, что, если попросить помощи у пяти специалистов, то можно получить, как минимум, шесть определений [4].

Столь же противоречиво определяют сегодня и SOA.

I. Stencil Group. Архитектура, ориентированная на сервисы имеет четыре основные характеристики.

  1. является распределенной. Функциональные элементы приложений могут быть распределены по множеству вычислительных систем и способны к взаимодействию с использованием локальных или глобальных сетей. В частности, Web-сервисы позволяют использовать существующие протоколы, например, HTTP.
  2. строится с использованием слабосвязанных интерфейсов. Обычно приложения проектируются в расчете на жесткую связь всех элементов. Как следствие, система должна иметь целостный проект, его изменения в процессе эксплуатации затруднительны. Работу компонентов в слабосвязанных системах проще координировать, системы проще реконфигурировать.
  3. базируется на общепринятых отраслевых стандартах.
  4. проектируется с ориентацией на процессы (process-centric) с использованием сервисов, каждый из которых ориентирован на решение отдельных задач (task-centric).

II. Gartner Group. В Gartner видят в качестве основной черты SOA деление на два или более уровня [5]. Обращенный к пользователю презентационный уровень отделен от внутреннего, где реализуется бизнес-логика. Последний создается из крупных блоков (coarse-grained chunk), которые обеспечивают сервис клиентским программам презентационного уровня. В логический уровень могут включаться компоненты управления бизнес-процессами (business process management — BPM). Практически, как считают аналитики этой компании, SOA можно реализовать, в том числе, многозвенной клиент-серверной архитектурой, но не двухуровневой архитектурой с толстым клиентом, который совмещает как логику, так и презентацию.

III. International Data Corp. Аналитики IDC [6] определяют SOA как архитектуру, предназначенную для свободного размещения функциональных модулей, каждый из которых способен выполнять определенные действия. Эти модули представляют собой описывающие сами себя программные компоненты, достижимые через сеть. Модули публикуют свои интерфейсы таким образом, что их использование не требует знания использованных в них решений и технологий; их удобно воспринимать как черный ящик. SOA можно реализовать и без использования Web-сервисов, однако сервисы рассматриваются в качестве основного средства для создания подобной архитектуры.

IV. Barry & Associates. Данная консалтинговая компания определяет SOA как набор взаимодействующих между собой модулей [7]. Модули могут просто обмениваться между собой данными или каким-то образом координировать свои действия. Архитектура, ориентированная на сервисы, не представляет собой ничего нового, считают здесь. Ее первыми примерами стали брокеры объектных запросов, основанные на спецификации CORBA.

V. В компании ThoughtWorks утверждают: SOA представляет собой набор сервисов, которые совместно образуют систему, призванную заменить монолитные корпоративные приложения типа ERP [8]. Примерно такого же мнения придерживается обозреватель журнала EAI Майкл Паллос, считающий, что SOA представляет собой набор модулей для обеспечения бизнес-процессов [9]. Дон Редер из компании Iona Technologies соглашается с таким мнением, отмечая, что SOA предлагает методологию и набор средств интеграции приложений [10].

Обобщая эти и многие другие определения SOA, можно согласиться с Майклом Чампионом [1]: «И все же, мне кажется, за всей этой шумихой скрывается мощная идея, которая еще не вполне точно обозначена; она и называется сервисами». Эта идея размыта, поскольку пока не поддержана прозрачной и общепринятой моделью или набором моделей, подобных семиуровневой модели открытых систем.

Не находя общего языка, авторы в своих определениях под SOA понимают близкие, но все же разные вещи. Одни рассматривают SOA как своего рода механизм, создающий коммуникационную среду для модулей, реализующих прикладную бизнес-логику. Примерно в этом ключе высказывается Адам Босуорт, вице-президент компании BEA Systems [11]. В его представлении посредством сервисов вычислительная система преобразуется в своего рода коммуникационную систему для снабжения информацией; она превращается в сервис сродни водопроводу. Стоит обратить внимание на близость взглядов Босуорта с прогнозами Stencil Group относительно будущего баз данных. Различие между ними заключается в том, что Босуорт предлагает их прямую транспортировку в потоках данных вместо накапливания данных в базах. Подобный коммуникационный взгляд на SOA можно назвать «взглядом снизу». Но есть другой, более системный взгляд, «взгляд сверху» [8-10]. Прикладные модули, получающие данные или информацию посредством сервисов, сами в свою очередь являются сервисами, которые необходимо каким-то образом связать в одну систему.

SOA и Web-сервисы

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

Рис. 1. Архитектура, ориентированная на сервисы

Поставщик сервиса регистрирует его у некоторого брокера, потребитель там же его обнаруживает, после чего между ними устанавливается связь в соответствии с контрактом и осуществляется требуемое действие. Для создания SOA необходимы три основных типа соглашений:

  • транспортное, определяющее форматы и протоколы;
  • описание сервиса, для чего нужен некий читаемый машиной язык, на котором описываются выполняемые сервисом операции; после компиляции описания формируется код, определяющий процесс взаимодействия между клиентом и поставщиком сервиса;
  • протокол, который определяет способ обнаружения сервиса.

Идея сервисов в информационных системах как таковая не нова. Хорошо известны следующие подходы к ее реализации:

  • Java RMI от компании Sun Microsystems (Java Remote Method Invocation);
  • CORBA консорциума Open Management Group (Common Object Request Broker Architecture);
  • DCE предложенная ассоциацией Open Group (Distributed Computing Environment);
  • Microsoft DCOM (Distributed Component Object Model).

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

Главная отличительная черта Web-сервисов состоит в использовании XML. Что же привнес этот язык в идею сервисов? Это чрезвычайно интересный вопрос, на который нельзя дать полноценный ответ без глубинного анализа, без рассмотрения различий между данными и информацией, не обращаясь не столько к техническим, сколько к философским вопросам теории информации.

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

В таблице 2 приведена классификация сервисов и поддерживающих их соглашений и стандартов [4].

Два лица SOA

Наличие двух возможных точек зрения на SOA и на Web-сервисы привело к тому, что над вопросами стандартизации в параллель работают две группы: в рамках комитета W3C и в составе Organization for the Achievement of Structured Information Standards (OASIS). Работа первой группы сосредоточена на основных спецификациях сервисной инфраструктуры, а второй — на расширении функциональности.

В рамках W3C работы по стандартизации Web-сервисов начались в 2000 году, когда была создана рабочая группа XML Protocol Working Group (XMLP), а затем сложилось объединение Web Services Activity, состоящее из трех рабочих групп и одной координирующей. Деятельность Web Services Architecture Working Group (WSAWG) сосредоточена на развитии стандартов для трех компонентов сервисов, включая транспорт, описание и обнаружение, максимально близких к SOAP, WSDL и UDDI. Работа групп WS-Desc и XMLP непосредственно связана с разработкой XML-спецификаций для описания Web-сервисов. Координирующая группа WSCG связывает деятельность W3C в области сервисов с другими организациями.

OASIS имеет в своем составе более тридцати технических комитетов, деятельность которых связана архитектурой Web-сервисов; в большинстве своем они были созданы после 2000 года. Так, Web Security Technical Committee разрабатывает стандарты, обеспечивающие безопасную передачу данных средствами, построенными на основе SOAP. Со своей стороны, XML-Based Security Service Technical Committee работает над стандартизацией механизма авторизации и аутентификации с использованием XML, в том числе, языка Security Assertion Markup Language (SAML). Есть комитеты, отвечающие за выработку языков управления ресурсами, за обмен биометрической информацией и целый ряд других.

Web-сервисы в интерпретации W3C

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

В качестве рабочего органа, который должен взять на себя эту обязанность, в январе 2002 года в рамках W3C была образована рабочая группа Web Services Architecture Working Group [13]. За прошедшее время группой опубликован целый ряд документов, в том числе глоссарий терминов из области Web-сервисов [14]. В августе 2003 года была опубликована рабочая версия документа «Архитектура Web-сервисов» [15], устранив противоречия, которыми страдали отдельные публикации, и предложив единую платформу для понимания того, что такое Web-сервисы и SOA. Оговоримся сразу — все, что предлагает эта рабочая группа, относится к действующей модели Web; кроме того, существуют академические исследования, в которых разрабатываются Web-сервисы для Семантической Сети, но это сфера пока еще далека от реального внедрения.

WSAWG предлагает следующее определение: «Web-сервис — это реализуемая программными средствами система для поддержки межмашинного взаимодействия через сеть. Интерфейс сервиса описывается на языке, читаемом машиной, например, WSDL. Другие системы взаимодействуют с Web-сервисом способом, указанным в его описании, используя сообщения в стандарте SOAP, передаваемые с использованием HTTP и XML и в сочетании с другими стандартами, относящимися к Web». Физически Web-сервис представляет собой фрагмент программного обеспечения, называемый «агентом». Агент способен передавать и принимать сообщения, он реализует абстрактную функциональность сервиса. Следует проводить различие между агентом и сервисом, один и тот же сервис может быть обеспечен разными агентами. Это вполне тривиальная с инженерной точки зрения идея: скажем, в компьютере должен быть отвод тепла, в таком случае сервис — это охлаждение, а вентилятор — это агент; один вентилятор может быть заменен другим.

Web-сервис предназначен для предоставления некоторой функциональности от лица ее владельца (поставщика), это может быть человек или организация (provider entity), которая использует соответствующий собственный агент (provider agent). Запрашивающая сторона (requester entity) тоже может быть человеком или организацией, желающими использовать сервис. Для этого она тоже использует свой агент (requester agent). Агенты взаимодействуют между собой посредством обмена сообщениями. Для того чтобы этот обмен был успешным, стороны прежде должны достичь соглашения об общем понимании семантики механизме обмена сообщениями.

Механизм обмена сообщениями документирован в описании сервисов (WSD), которое представляет собой читаемую машиной спецификацию интерфейса, включающую: форматы сообщений, типы данных, транспортные протоколы, форматы сериализации, используемые при обмене между агентами заказчика и поставщика услуг. Она также содержит указание на одну или несколько точек в сети (endpoint), откуда поставщик доступен и еще может содержать информацию о предполагаемом шаблоне (pattern) сообщения, используемого для обмена.

Семантика сервиса представляет собой содержание так называемого «контракта» между сторонами; она также содержит некоторые дополнительные сведения о механизмах обмена сообщениями, которые не отражены в WSD. Важно отметить, что, хотя контракт содержит всеобъемлющее представление о сервисе, он не должен быть документально зафиксированным. Контракт может быть явным или скрытым, устным или письменным, в форме, доступной машине или человеку. Различие между описанием сервиса и контрактом заключается в том, что первое определяет механизм взаимодействия с сервисом, а второй — смысл и предназначение этого взаимодействия.

Web-сервисы в основном предназначены для автоматизации процессов управления, которые могли бы быть выполнены вручную, однако в архитектуре Web-сервисов остается место и человеку. Во-первых, его участие требуется при достижении соглашения по семантике и описанию. Человек (или организация) является юридическим владельцем Web-сервисов; именно люди должны согласиться с тем, что данная семантика и данное описание будут управлять взаимодействием между сервисами. Возможно, что со стороны поставщика участие может ограничиться публикацией и предоставлением возможности использовать сервис только в той форме, в какой тот существует (take-it-or-leave-it); иными словами, контракт предполагает неизменяемые условия с его стороны. Есть и другие формы установления отношений, в том числе, через координирующие организации или даже по запросу заказчика. Во-вторых, агенты заказчика и поставщика сервисов создаются людьми, которые отвечают за исполнение соглашений об описании и семантике услуги.

Рис. 2. Архитектура, ориентированная на сервисы, с учетом предложений WSAWG

На рис. 2 представлена схема обмена между потребителем и поставщиком сервисов с учетом предложений, сделанных WSAWG.

Архитектурные модели SOA

Одной из самых интересных находок, сделанных в [15], можно назвать предложенные архитектурные модели SOA.

  • Модель, ориентированная на сообщения (Message Oriented Model, MOM), сосредоточена на сообщения, их структуру, способы транспортировки и другие компоненты, ни как не связанные с причинами обмена сообщениями и их семантикой.
  • Модель, ориентированная на сервисы (Service Oriented Model, SOM), сосредоточена на действиях, выполняемых сервисами.
  • Модель, ориентированная на ресурсы (Resource Oriented Model, ROM), сосредоточена на системных ресурсах.
  • Модель политик (Policy Model, PM) определяет политики, связанные с архитектурой, в основном она представляет собой ограничения, накладываемые на поведения агентов и сервисов, в том числе ограничения, связанные с требованиями безопасности, качества обслуживания.
  • Модель управления (Management Model, MM).

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

Рис. 3. Архитектурные модели Web-сервисов

Оркестровка и хореография Web-сервисов

С появлением Web-сервисов возникли термины «композиция Web-сервисов» (Web-services composition) и «поток Web-сервисов» (Web-services flow), используемые для описания потока работ, выполняемых с их помощью. Недавно им пришли на смену два более выразительных термина — оркестровка и хореография Web-сервисов. Под оркестровкой понимают то, как сервисы взаимодействуют друг с другом на уровне сообщений, включая бизнес-логику и кооперацию при выполнении сложных процессов в пределах одного предприятия. Оркестровка основывается на открытых стандартах для создания бизнес-процессов, включая BPEL4WS, WSCI и BPML. Хореография в данном контексте охватывает более широкий круг участников взаимодействия, в том числе поставщиков, потребителей и партнеров предприятия. Хореография ассоциируется с публичным обменом сообщениями между множеством Web-сервисов, а не с одним бизнес-процессом, осуществляемым на одном предприятии [15]. Хореография — более публичный процесс.

Одним из наиболее интересных средств описания оркестровки стал язык BPEL4WS (Business Process Execution Language for Web Services), предложенный компаниями IBM, Microsoft и BEA Systems. Язык предназначен для описания исполнения исполняемых бизнес-процессов и позволяет описать поведение и взаимодействия Web-сервисов в бизнес-процессе.

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

Литература
  1. Michael Champion, SOA: One acronym to bind them all? weblogs.java.net.
  2. Jonathan Sapir, Will Web services and SOA change the development world? www.TechRepublic.com, August 2003.
  3. Laws of Evolution: A Pragmatic Analysis of the Emerging Web Services Market. Stencil Group, April 2002.
  4. Introduction to Web-services Architecture. Systinet.
  5. Schutle, Predicts 2003: SOA Is Changing Software, Gartner Group, December 2002.
  6. Enterprise Service Bus Will Revolutionize Information Technology, IDC, March 2003.
  7. Service-oriented architecture (SOA), definition. Barry&Associates, www.service-architecture.com.
  8. Gregor Hohpe, Web Services: Pathway to Service-oriented architecture, ThoughtWorks.
  9. Michael Pallos, Service-oriented architecture: A Primer. EAI Journal, December 2001.
  10. Don Roeder, The Next Wave of Integration Platforms. EAI Journal, September 2002.
  11. Леонид Черняк, "Следующая волна технической революции: от баз данных к распределению данных". // Открытые системы, № 3, 2003.
  12. Dion Wiggins, Net vs. Java: Competition or Coopetition? Gartner Group.
  13. Web Services Architecture Working Group, http://www.w3.org/2002/01/ws-arch-charter.
  14. Web Services Glossary, http://www.w3.org/TR/2003/WD-ws-gloss-20030808.
  15. Web Services Architecture, W3C Working Draft 8, August 2003, www.w3.org/TR/2003/WD-ws-arch-20030808.
  16. Сhris Peltz, Web services orchestration, a review of emerging technologies, tools, and standards. Hewlett-Packard, January 2003.

Необходимое замечание

Между терминами «Web-архитектура», «архитектура Web-сервисов» (Web Services Architecture — WSA) и «архитектура, ориентированная на сервисы» (Service Oriented Architecture — SOA) следует проводить различие. SOA — более широкое понятие, это тип организации распределенных систем, а Web-архитектура и WSA являются его подмножествами. Архитектура SOA предполагает наличие дискретных программных агентов, которые, взаимодействуя, обеспечивают заданную функциональность. Агенты размещены в разных обрабатывающих средах, поэтому для согласования между ними требуется стек аппаратных и программных протоколов. Очевидно, что это снижает производительность и надежность по сравнению с системами, построенными на прямых вызовах, работающих в общей аппаратной среде. Кроме того, разработчикам следует учитывать непредсказуемость распределенной среды, в том числе задержки, возможность возникновения конкуренции, вероятный выход из строя части системы. Сущностью, ключевым компонентом SOA являются сообщения, которыми между собой обмениваются агенты и механизм транспортировки, сообщений.

С этой точки зрения, World Wide Web — это и есть SOA, оперирующая в сетевой информационной среде, на которую наложены следующие ограничения: агенты идентифицируют объекты, называемые ресурсами с помощью идентификаторов URI. Агенты взаимодействуют с использованием представлений в принятых форматах (например, XML, HTML, CSS, JPEG, PNG). Агенты обмениваются этими представлениями с использованием протоколов и URI для идентификации и прямой или косвенной адресации ресурсов.