Сервисы, архитектура и унаследованные системы

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

Существуют методы превращения разрозненной ИТ-среды в сервисную, в которой отдается предпочтение слабым связям, абстрагированию низкоуровневой логики, гибкости, а также возможности многократного использования и обнаружения компонентов [1, 2]. Эти и другие руководящие принципы изложены в «Манифесте SOA»¹.

Основы SOA

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

Плюсы SOA:

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

Минусы:

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

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

Веб-сервисы

Для многих организаций простейший путь к созданию слабо связанной архитектуры — это веб-сервисы. Взаимодействие элементов реализуется с помощью группы открытых спецификаций, основанных на XML, таких как WSDL, SOAP и UDDI, стандартизующих построение, публикацию и использование веб-сервисов.

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

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

Для унаследованного приложения можно создать оболочку, представляющую его в виде SOA-сервиса. Такая оболочка переводит запросы на язык старой системы и сама отвечает по HTTP. Это несложно, c учетом того, что HTTP-сообщение — это обычный текст, который может формироваться любой системой и языком программирования.

Технологии

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

При проектировании веб-сервиса нужно задать набор правил обмена информацией, и сегодня главные инструменты для этого — SOAP и REST. Протокол SOAP был разработан как интернет-альтернатива технологиям наподобие CORBA и может пользоваться различными протоколами транспортного уровня (HTTP, SMTP и т. д.), что дает ему больше гибкости. Обмен данными происходит в формате XML, в связи с чем возможны проблемы с быстродействием при передаче больших объемов данных. SOAP можно использовать с Web Services Security, стандартом для подписывания и шифрования сообщений, который позволяет защитить обмен  информацией. 

REST — более новый протокол, пользующийся транспортом HTTP и допускающий использование различных форматов данных (XML, JSON и т. п.); запросы могут представлять собой обычную строку URL. По существу, REST — это облегченная альтернатива SOAP. Поскольку REST не предъявляет строгих требований к реализациям, у него больше гибкости, он менее ресурсоемок и обходится меньшим объемом документации. REST допускает HTTP-запросы типа GET, тогда как SOAP — только POST; кроме того, кэширование для REST может осуществляться не только на уровне сервиса, но и на более низком.

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

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

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

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

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

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

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

• Интеграционные фреймворки. Самая простая из альтернатив: это просто библиотеки, реализующие интерфейсы программирования для различных сред разработки (Java-фреймворки Apache Camel и Spring Integration, библиотека NServiceBus для платформы .NET).
• Решения, реализующие сервисную шину предприятия. Помимо возможностей интеграционных фреймворков, предлагают инструменты развертывания, администрирования и мониторинга. ESB (Enterprise Service Bus) обеспечивает связь между производителями и потребителями сервисов и дает более полный набор инструментальных средств, существенно уменьшая затраты и уровень сложности, позволяя решать задачу интеграции с более высоким уровнем абстракции. Примеры ESB — Oracle Service Bus и Mule ESB.
• Интеграционные пакеты. Включают в себя не только функции ESB, но и инструменты для бизнеса — например, средства управления бизнес-процессами и мониторинга бизнес-деятельности, сервисные репозитории. Богатство функциональности позволяет быстрее проводить изменения.

Три способа интеграции корпоративных приложений

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

Сравнение решений для интеграции корпоративных приложений

Как сделать выбор

Выбор наилучшей альтернативы зависит от конкретных потребностей и уровня сложности. Прежде всего надо решить, достаточно ли будет какого-либо одного фреймворка. К примеру, если нужно соединить только два приложения или будет достаточно одной технологии (скажем, REST), то можно взять на вооружение самый простой подход — интеграционный фреймворк, несмотря на скудость инструментов и ограниченность поддержки; в других случаях больше подойдет ESB. Но если нужны дополнительные возможности, то более удачным выбором будет функционально богатый интеграционный пакет.

***

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

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

По прогнозу Gartner, к 2016 году как минимум 35% организаций средних и крупных размеров во всем мире будут пользоваться какими-либо формами iPaaS, однако эксперты считают, что iPaaS не станет заменой SOA: традиционные сервисные среды по-прежнему будут нужны для сложных сценариев интеграции — например, для построения систем обмена сообщениями с малой задержкой или выполнения транзакций с обработкой больших объемов данных.

Литература

1. N. Gold et al. Understanding ServiceOriented Software. IEEE Software, vol. 21, no. 2, 2004, P. 71–77.
2. S. Jones. Toward an Acceptable Definition of Service. IEEE Software, vol. 22, no. 3, 2005, P. 87–93.

Николя Серрано, Хосуне Эрнантес, Горка Галлардо ({nserrano, jhernantes, ggallardo}@tecnun.es) — сотрудники Университета Наварры (Испания).