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

Три причины рождения SOA

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

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

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

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

Аналитики не скупятся на прогнозы. По оценкам Gartner, к 2006 году более 60% компаний будут рассматривать SOA как основу для построения бизнес-приложений. IDC, Meta Group, Giga Group также заявляют о прекрасных перспективах новой технологии. Опираясь на эти оценки, основные производители, включая IBM, SAP, Microsoft и BEA, рассматривают SOA как новую парадигму архитектуры своих продуктов. Все это очень похоже на вновь создаваемый бум.

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

Интеграционная среда

Первый и самый нижний архитектурный уровень SOA - это интеграционная среда. Интеграционная среда SOA направлена на компоновку и взаимодействие, вне зависимости от того, создаете вы приложение или интегрируете множество приложений. Обеспечивается это благодаря следующим положениям:
1. Последовательное развитие и интеграция осуществляются на основе стандартных сервисов и процессов. Основываясь на стандартах, можно повторно использовать процессы и сервисы по всему предприятию.
2. Используется сервисный подход к построению архитектуры, благодаря чему уменьшается сложность систем.
3. Минимизируется зависимость между компонентами и пользовательскими интерфейсами. Важно, что в SOA это реализуется благодаря многоярусным интерфейсам на уровне протоколов, а не семантики. Платформа для интеграции "притягивает" сервисы друг к другу, так что можно легко агрегировать интерфейсы для формирования новых составных интерфейсов.
4. Использование новых методов организации разработки функциональности. Основная цель - сокращение промежутка между разработкой и интеграцией.

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

Преимущества согласованности

Безусловно, реализация подобных идей стала возможна благодаря стандартизованной инфраструктуре сообщений, использующей Интернет и XML. Последний представляет собой гибкий, открытый и широко распространенный стандарт обмена сообщениями и является принципиальным новшеством, п осравнению в предидущими реализациями идей распределенных сервисов. Так был создан необходимый минимальный базис для объединения подходов разных вендоров.

В принципе SOA приняли все основные разработчики приложений для предприятий, интеграции, платформ и средств разработки. Эта ситуация существенно отличается от недавнего прошлого, когда производители приложений для предприятий продвигали закрытые продукты, собственную связность приложений и собственные компонентные технологии (SAP), а провайдеры платформ предлагали собственную, дорогую интеграцию (IBM). Хотя у каждого есть собственная версия и каждый исходит из конкурентных интересов, единство вокруг SOA несомненно отличается в лучшую сторону.

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

Синтезированные вычисления

Второй абстрактный уровень SOA - это так называемые синтезированные вычисления (synthesized computing). В типичном бизнес-процессе участвует множество корпоративных (например, ERP, CRM и унаследованное ПО), настольных (Excel и Word) и коммуникационных приложений (e-mail, телефон и факс). Эти три типа систем охватывают почти все бизнес-процессы. Так, например, чтобы определить, продлить кредит или нет, требуются обмен сообщениями по электронной почте и телефонные звонки между отделами продаж, бухгалтерией и службой работы с клиентами. Для решения по обслуживанию кредита требуются данные и процессы из ERP- и CRM-систем. Тот факт, что заказы, покупатели и товары отслеживаются системами, устраняет много действий, выполняемых вручную, даже если входные данные по-прежнему вводит человек. Аналогичное повышение продуктивности возможно для большинства бизнес-процессов, когда вы связываете набор задач, выполняемых вручную, включая установку напоминаний в календарь, заполнение форм, телефонные звонки, отправку факсов, регистрацию, почту, которые необходимы для выполнения бизнес-процесса. Повышение степени автоматизации улучшает взаимодействие людей и систем, особенно на стыках многослойных процессов и границах корпорации в целом.

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

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

Таксономия абстрактных сервисов

Третий важный архитектурный компонент SOA - таксономия абстрактных сервисов (Abstract service taxonomy, AST). Под таксономией обычно понимают функциональный профиль какой-либо системы. Как правило, функциональный профиль определяет параметры, классы, варианты, подмножества стандартов, необходимых для работы нужного набора служб. В сложившемся в рамках архитектуры SOA понимании это выжимка функциональности бизнес-систем и модулей платформы в специальные компоненты, которые служат интерфейсом верхнего уровня SOA. Эти компоненты содержат модули корпоративных приложений и систем (включая порталы, системы управления бизнес-процессами и серверы приложений). Основная цель - предоставление и повторное использование функциональности корпоративных и других систем, управление избыточной информацией и использование функциональности конкретных корпоративных процессов на благо всех.

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

Основные функциональные элементы AST следующие:

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

2. Логика пользовательского интерфейса. Логика пользовательского интерфейса AST позволяет создавать гибкие составные представления, которые предоставляют доступ на запись и чтение, сохраняя целостность данных систем. Если пользователю необходимо получить доступ к пяти или десяти системам, компоненты пользовательского интерфейса помогают подготовить необходимую абстракцию этой функциональности и создать пользовательское представление. С представлениями могут взаимодействовать порталы и другие системы. Гибкость пользовательского интерфейса AST позволяет создавать составные представления. Таким образом, AST приносит на уровень пользовательского интерфейса некое подобие интеграции, доступной на среднем уровне.

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

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

BAM и события

И наконец, последний абстрактный уровень SOA - мониторинг бизнес-активности (Business Activity Monitoring, BAM) и событий. В процессе развития компании все больше заинтересованы в применении архитектуры, основанной на событиях. Архитектура на основе событий позволяет системам просматривать события, порождаемые деятельностью компании, и затем отсылать их заинтересованным сторонам. Технологии типа RFID сделают чрезвычайно важным наличие архитектуры, основанной на событиях. С помощью фильтрации лишней информации архитектуры, основанные на событиях, помогут организациям избежать информационных перегрузок и предотвратить ложную тревогу. В системе, ориентированной на события, последние влияют на каждый последующий шаг приложения. Сложные приложения, действующие сразу по нескольким направлениям, существенно выигрывают от этой повышенной гибкости.

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

В общем, существуют три уровня обработки сообщений:

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

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

Цифровой инструментарий и обработку событий обеспечивают BAM-приложения. Сегодня BAM-функциональность стала стандартным компонентом пакетов для управления бизнес-процессами (Business Process Management, BPM). Как часть пакета BPM BAM-приложение имеет доступ к многочисленным системам, вовлеченным в рассматриваемый бизнес-процесс. BAM-приложение совмещает эту информацию с данными прогнозирующих систем и хранилищ данных, получая сложные отчеты по деятельности предприятия. Таким образом, с помощью настроенного под конкретные задачи инструментария BAM предприятия могут получать различную информацию о своей работе. Например, можно увидеть ошибки процессов погрузки и разгрузки товара или сравнить в реальном времени ежедневные результаты с планируемыми цифрами.

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

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

SOA: необходимые стандарты

Для реализации идей SOA стандарты полезны как по отдельности, так и в совокупности. Если необходима просто возможность взаимодействия, хорошей комбинацией считается SOAP (Simple Object Access Protocol) и WSDL (Web Services Description Language). Для более сложного потока процессов необходимо выбирать BPEL (Business Process Execution Language). Совмещение стандартов в «компонуемую» архитектуру дает возможность иметь одни стеки протоколов для простых некритичных процессов и другие, более сложные, для построения процессов с партнерами. Сложные операции могут потребовать сложных стандартов, которые лежат на более высоких уровнях стека. Приведем список некоторых ключевых SOA-стандартов.
Транспортировка. SOA должна поддерживать стандартные протоколы Интернет: HTTP, HTTPS и SMTP. Другие, включая TCP/IP, не обязательны.
Сообщения. SOA должна поддерживать XML, SOAP и WS-Addressing. XML и XML Schema предоставляют стандартный способ описания сообщений. WS-Addressing отделяет адресацию от транспортировки. Эти стандарты полезны, когда нужно, чтобы асинхронные сервисы прослушивали различные адреса или поддерживалась взаимосвязь между долговременными сервисами, требующими вмешательства человека.
Описание. Web-сервисы предоставляют стандартизованный путь описания сервисов способом, который не привязан к конкретной платформе middleware, среде разработки или системным протоколам. Программа может описывать сервисы с использованием XML Schema, встроенных в WSDL-контракты. WS-Policy определяет семантическую информацию о сервисе, увеличивая возможности технического описания в WSDL и XML Schema Definition (XSD).
WSDL. Встроенные схемы в XSD описывают типы объектов: например, заказ клиента или заказ на поставку, а также синтаксис сообщений. Соглашения WSDL группируют сообщения согласно операциям, разделяя на синхронные и асинхронные, и связывают их с транспортными протоколами и пунктами назначения.