Вопросы вокруг SOA

Глеб Галкин

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

Разрушить шахты

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

На протяжении нескольких десятилетий после того, как ПО middleware появилось на ИТ-рынке, ИТ-директора упражняются в преодолении этих шахт. Концепция SOA (Service Oriented Architecture - сервисно-ориентированная архитектура) имеет множество задач, но главной остается облегчение контроля над распределенными вычислениями. Такая цель кажется знакомой? И не вам одному, потому что она уже четверть века волнует ИТ-директоров компаний всего мира.

Еще раз о SOA

Как мы уже писали (см. "В погоне за гибкостью", спецвыпуск), ориентированная на сервисы архитектура SOA - это новая парадигма в создании корпоративных приложений, основанная на идее их компоновки из модульных сервисов. В SOA нужная функциональность собирается из сетевых сервисов, являющихся слабосвязанными и общедоступными. Естественно, речь идет об их интеграции (и не только), но при использовании SOA интеграция выполняется на гораздо более высоком уровне абстрагирования, чем предусмотрено традиционными методами интеграции приложений. С точки зрения ИТ сервисы должны делать возможными сквозные процессы, транзакции и информационные потоки. В то же самое время они должны скрывать свою сложность аналогично тому, как организации скрывают свою внутреннюю кухню при контрактных соглашениях с партнерами. Разработчики активно рекламируют компоновку сервиса как ключевое преимущество предлагаемых решений, но способы получения сервисов разнятся: поставщики серверов приложений предлагают кодировать сервисы самостоятельно, поставщики интеграционных серверов - инкапсулировать, а авторы решений масштаба предприятия - покупать сервисы у них.

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

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

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

Шагая по территории, усыпанной непохожими друг на друга внутренними и внешними системами, ИТ нуждаются в SOA, т. е. в системе открытых и общих стандартов, позволяющих интегрировать более доступные и разнообразные системы, чем это было возможно с решениями типа "точка -- точка" или технологиями EAI (Enterprise Application Integration). Вообще говоря, технических возможностей для построения сервисно-ориентированной архитектуры множество. Однако SOA стала узнаваемым и популярным термином в 2003 году, когда первоначальный шум вокруг Web-сервисов пошел на спад ввиду отсутствия существенных подвижек.

Эволюция сервисов

Испытав все прелести роста на просторах Интернета, возмужав и придя в корпоративную среду, Web-сервисы смогли, кажется, отодвинуть на второй план ориентированные на объекты методы конструирования, моделирования и развития приложений, а также системы middleware, такие как CORBA (Common Object Request Broker Architecture) и UML (Unified Modeling Language). Фактически развитие Web-услуг строится на прочном основании опыта использования COBRA, естественно, с применением новых протоколов SOAP, HTTP и т. д. Существенный прорыв в области стандартизации привнес XML - через WSDL Web-сервисы сделали XML новым общепринятым языком общения в распределенных вычислениях. И этот процесс продолжается. Например, в технологии Asynchronous JavaScript (AJAX) XML используется для определения ряда методологий, отсутствовавших на ранних стадиях развития Web-сервисов.
Еще одна существенная для понимания сущности интеграции эволюция произошла на архитектурном фронте. Первое поколение Web-сервисов склонялось к испытанной модели дистанционного вызова процедур а-ля RPC по принципу "точка -- точка", которые требуют синхронных, сильно связанных соединений для проведения транзакций. Но когда Web-сервисы перешли на обслуживание тысяч клиентов и столкнулись с проблемой взаимодействия, безопасности и управления множественными системами, lkz SOAP/HTTP-технологий встала проблема масштабирования.

Что произошло дальше? Как уже бывало ранее, наступило некоторое охлаждение к модной технологии, и ИТ-менеджеры вернулись к проверенным messaging-oriented middleware (MOM). Как известно, MOM использует шину, через которую приложения "подписываются" на информацию, рассылаемую другими приложениями. Собственно на этой почве и родилась концепция ESB (Enterprise Service Bus) как единая шина для доступа к корпоративным Web-сервисам. Gartner Group описывает ESB как платформу, которая объединяет черты ряда предыдущих типов middleware "в одном флаконе" -- гарантированную доставку сообщений, трансформацию и маршрутизацию данных, безопасность, баланс нагрузки и восстановление после сбоев.

Реализации ESB убивают гибкость

Видимо, встреча SOA и ESB была предрешена свыше. И хотя изначально SOA отнюдь не была так сильно ориентирована на технологию ESB, сейчас последняя с огромной скоростью превращается в центр реализации сервисно-ориентированной архитектуры. Однако не всё так радужно. Дело в том, что, во-первых, внутри самой концепции ESB не все единодушны относительно ее реализации. Имеющие большой вес в мире интеграции приложений традиционные поставщики EAI-систем (такие, как Sonic Software, PolarLake и Fiorano Software) хотя и предлагают ПО для развертывания ESB, оно скорее походит на старые централизованные EAI-решения. Более того, в ущерб другим компонентам SOA (см. "В погоне за гибкостью", спецвыпуск IE, № 6/2005,) эти компании сосредотачиваются только на одном хорошо им знакомом компоненте -- обмене сообщениями между внутренними операциями. Аналогично Microsoft, хоть и не выводит на рынок ESB-продуктов, вместо них предлагает для функций передачи сообщений BizTalk Server и другие элементы на платформе Windows, стремясь обеспечить асинхронной SOA такое же качество транзакций, как синхронному вызову в стиле старой технологии RPC (точка -- точка).

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

Но отнюдь не все аналитики разделяют беспокойство по поводу централизации SOA. "Слабые стороны звездообразной архитектуры больше не играют большую роль, -- утверждает Кен Воллмер, главный аналитик исследовательской компании Forrester Research. - Интегрированные платформы middleware могут образовывать что-то наподобие кластеров". Отчет компании Forrester Research по ESB, изданный в ноябре 2005 года, высоко оценил игроков рынка EAI, использующих ESB в своих программах. Скорее всего эти споры отражают скрытую динамику развития SOA/ESB, но куда все это придет, пока неясно.

Интеграция процессов и бизнес-интеграция

Наконец, поговорим об еще одной технологии, которая очень близка к предмету нашей статьи. Это технология BPM (Business Process Monitoring). Согласно теории Робина Милнера о ?-исчислении бизнес-процессы - это акт коммуникации. А обработка событий - не обязательный, но очень важный компонент SOA. Если произошло событие -- например, задерживается заказ на погрузку, -- то основанная на SOA система может инициировать некоторые действия, запустив другие сервисы. Немногие компании смогли реализовать у себя все возможности BPM-решений. Причина в том, что интеграция с корпоративным ПО оказалась сложной, исключительно затратной и требующей массы частных решений. Через сервисы легко осуществить прямой доступ к другим интеллектуальным ресурсам предприятия, которые могут быстро проанализировать оправданность тех или иных действий. В результате этого SOA легко становится интеграционной платформой, необходимой для реализации BPM-решений.

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

Будущее BPM, судя по всему, неразрывно связано с SOA, но оно пока еще не наступило. Есть явные недостатки в стандартах защиты Web-сервисов, надежности доставки сообщений и управления транзакциями. Правда, эти дефекты уходят по мере достижения зрелости стандартов и их реализации в коммерческом ПО. Есть менее очевидный, но очень важный вопрос, который имеет прямое отношение к теме интеграции. Но к интеграции за пределами транзакций корпоративных приложений, к бизнес-интеграции -- могут и должны ли задачи делопроизводства (workflow) описываться в рамках модели компоновки сервисов?

Дело в том, что в современном стандарте BPEL это не предусмотрено. BPEL не содержит атрибутов процесса, таких как роли, приоритеты задач и ограничения, несмотря на то что они являются важными компонентами живого делопроизводства в языках вроде XPDL (Extensible Process Description Language). По этой причине большинство поставщиков решений для BPM, в том числе FileNet, Savvion и Fuego, утверждают, что BPEL-компоновка должна ограничиваться автоматизированными операциями типа "сквозной обработки данных" (Straight-Through Processing, STP) и интеграции транзакционных приложений. И этот вопрос тоже принципиальный. Фактически это означает: сможет ли технология BPM/SOA реализовать все задачи бизнес-интеграции, включая поддержку коллективной работы и обеспечение взаимодействия пользователей?

С другой стороны, поставщики инфраструктурных решений, такие как IBM, BEA, Microsoft и Oracle, рассматривают полный сквозной процесс как BPEL-компоновку (или набор связанных BPEL-процессов) и разработали специализированные методики делопроизводства с участием человека в рамках парадигмы компоновки Web-сервисов. Но подобный подход к бизнес-процессам, в которых задействованы люди, ведет к компоновке процессов, не переносимых на платформы других поставщиков. В попытке устранить этот разрыв организация Business Process Management Initiative (BPMI.org) приступила к разработке уровня расширения BPEL (BPXL) со стандартизованной интеграцией процессов с участием людей, который должен стать одним из ключевых усовершенствований. Но как это будет реализовано?

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