SOA (Service Oriented Architecture, сервис-ориентированная архитектура) представляет собой сравнительно новую парадигму, прошедшую в своем развитии целый ряд этапов. В основе SOA лежит концепция Web-сервисов, позволяющая изменить подход к самой организации работы отделов ИТ. Web-сервисом называется модульный, независимый фрагмент программного кода с хорошо определенной функциональностью, который можно вызывать через сеть. Основные компоненты SOA - это провайдеры сервисов, потребители сервисов и реестр сервисов. UDDI (Universal Description, Discovery and Integration, универсальный стандарт описания, обнаружения и интеграции) - это стандарт на базе XML, позволяющий создавать реестры, в которых компании могут регистрировать свою контактную информацию, предлагаемые сервисы и техническую информацию о них. Потребитель, запрашивающий сервис, может выполнить поиск в этом реестре, найти необходимый сервис и начать взаимодействовать с ним. Web-сервисы преимущественно используются через Интернет, поэтому реестр UDDI устраняет ограничения на размещение Web-сервиса. Вместе с тем реестр UDDI может предложить коллекцию сервисов, выполняющих определенные задачи, предоставляя пользователям возможность выбрать наиболее подходящий к конкретной ситуации. Спецификация UDDI стала стандартом де-факто для регистрации сервисов. Она предоставляет двойное преимущество: во-первых, организации имеют обычный реестр для всех своих служб, независимо от их географического расположения, бизнес-подразделения и отдела, во-вторых, они могут консолидировать системные ресурсы и экономить бизнес-расходы и время.
Web-сервисы, как правило, представляют собой независимые элементы с абстрактным бизнес-интерфейсом, который не зависит от лежащей в его основе реализации; а процесс разработки подразумевает комфортабельность и удобство доступа для клиентов. С точки зрения сервера нам нужно иметь возможность создать любой пользовательский Web-сервис и представить WSDL (описание метаданных Web-сервиса) клиенту, который сможет соответствующим образом подключиться к нему. Для такой архитектуры необходим унифицированный и простой механизм принятия и распространения исправлений и изменений. Интерфейс UDDI в этой архитектуре является центральным компонентом, следовательно, в этом плане он удовлетворяет требованиям. Тем не менее в UDDI не хватает жизненно важной информации: механизма обеспечения безопасности и стратегии отслеживания изменений бизнес-сервисов.
Сегодня компании стали гораздо более динамичными, чем когда-либо раньше, и должны уметь быстро адаптироваться к ситуации. Это означает, что бизнес-процессы тоже должны стать гибкими. Когда Web-сервис реализует бизнес-процесс, этот процесс может иметь несколько одновременно существующих версий. Хотя более ранние версии могут быть объявлены устаревшими, они обычно продолжают поддерживаться. Например, некое финансовое учреждение размещает Web-решение, отображающее процентные ставки за определенный год и месяц. Ему необходимы разные версии, чтобы обеспечить поддержку формул для изменяющихся тенденций бизнеса в своем бизнес-сервисе. В корпоративной архитектуре необходимо решение для управления конфигурациями, которое позволило бы избавить и сервер, и клиента от трудностей с управлением версиями. Задача в том, чтобы исключить необходимость явно информировать каждого потребителя об изменении версии.
Регулярно появляются стандарты, призванные предоставить заинтересованным сторонам более простой и эффективный протокол для участия в бизнес-интеграции на уровне организации в целом. Поскольку провайдеры сервисов повсеместно используют стандарт UDDI, мы рассмотрим расширение функций UDDI; во-первых, путем предоставления подробных настроек безопасности каждого сервиса, чтобы все клиенты знали, какие политики и протоколы необходимо использовать для доступа к сервису, и, во-вторых, путем распространения UDDI в качестве наиболее подходящего инструмента для управления конфигурациями сервисов.
В этой статье мы объясним, почему необходимо предоставлять сторонним пользователям подробные сведения о настройках безопасности и архитектурной модели, а затем рассмотрим необходимость поддержки с помощью UDDI ключевой области процесса (key process area, KPA) "управление качеством бизнеса". Кроме того, авторы предлагают техническое решение, использующее текущий вариант спецификации UDDI для управления версиями сервисов в рамках корпорации.
UDDI - важная часть философии SOA, занимающая свое место в знаменитом треугольнике Publish -- Find -- Bind (публикация - поиск - связывание). Провайдеры сервисов публикуют свои сервисы в UDDI, где инициаторы запросов могут найти эти сервисы и установить связь с ними с помощью указанных механизмов. Логическая структура UDDI подразделяется на три категории: «белые страницы», «желтые страницы» и «зеленые страницы». В «белых страницах» хранятся сведения о компании и ее контактная информация; желтые страницы предназначены для хранения информации о сервисах, которые предлагает эта компания; зеленые страницы служат для хранения всей технической информации о сервисе. В UDDI можно выделить четыре основные структуры данных:
- BusinessEntity;
- BusinessService;
- BindingTemplate;
- TModel.
Элемент BusinessEntity соответствует компании, которая предлагает некоторый сервис, указанный в элементе BusinessService. Элемент BindingTemplate определяет способ, которым потребитель, запрашивающий сервис, может связаться с этим сервисом. Элемент TModel представляет собой техническую модель сервиса. Благодаря этому для каждой записи в реестре создается иерархическая структура; в ней присутствуют также другие элементы и вложенные элементы, представляющие прочие детали, например, классификации и даты
Пробный проект: Усовершенствование UDDI
Мы подробно рассмотрим различные решения с использованием одного из ведущих серверов приложений J2EE - IBM WebSphere Application Server v6. Этот сервер демонстрирует возможности взаимодействия с сервисом с использованием различных версий и различных политик безопасности при помощи реестра узлов UDDI. Бизнес-уровень представлен сервером .NET, на котором мы разместим Web-сервисы.
Чтобы протестировать концепцию обмена данными о политиках безопасности, наш провайдер сервисов создает сервисы с двумя различными политиками безопасности. Для проверки поддержки управления версиями мы создаем два сервиса с различными реализациями и еще один сервис с совершенно другой сигнатурой или интерфейсом. Эти сервисы размещаются на другом компьютере с платформой .NET.
На уровне реестра сервисов мы регистрируем все сервисы компании и конфигурируем их в соответствии с механизмом, который рассматривается в данной статье.
На стороне потребителя мы разделяем клиентские компоненты на две категории. Первый набор клиентских компонентов мы построим таким образом, чтобы наш клиент понимал файлы политик и мог использовать их, чтобы соответствовать реализации политики безопасности, заданной разработчиком сервиса. Затем мы воспользуемся набором клиентских компонентов для доступа к разным версиям сервиса. Этот набор будет иметь механизм обработки исключений, позволяющий ему подстраиваться под постоянно изменяющиеся версии и, в конечном итоге, обращаться к Web-сервису с минимальными сложностями и усилиями. Кроме того, мы создадим клиентскую заглушку и пользовательские компоненты на платформе Java на постороннем компьютере (отличном от тех, где мы разместили реестр сервисов и генератор сервисов).
Обмен данными о политике безопасности
В текущей версии UDDI обеспечение политики безопасности Web-сервисов не описывается. С точки зрения бизнеса безопасность в обмене данными с Web-сервисами важна потому, что большинство бизнес-процессов и транзакций осуществляются через небезопасную зону - Интернет. Еще одно ограничение связано с тем, что транзакции с Web-сервисами больше затрагивают взаимодействия типа процесс-процесс, чем человек-процесс; следовательно, в данном случае динамическая схема обеспечения безопасности приобретает еще большее значение. В связи с тем, что использование Web-сервисов постоянно расширяется, количество участников среды Web-сервисов будет расти в геометрической прогрессии; следовательно, нам нужен масштабируемый и адаптивный механизм обеспечения безопасности. Такие стандарты, как WS-Security (стандарт безопасности Web-сервисов), XACML (Extensible Access Control Markup Language, расширяемый язык разметки управления доступом) и SAML (Security Assertion Markup Language, язык разметки условий безопасности) описывают реализацию обеспечения безопасности на уровне сервиса, но не предлагают эффективного способа распространения информации по безопасности в постоянно меняющихся сценариях взаимодействия. Именно в этом нам может помочь UDDI.
Чтобы обеспечить безопасность Web-сервиса, обычно используются маркеры безопасности, например, маркеры имени пользователя, маркеры XML, двоичные маркеры, маркеры Kerberos, сертификаты безопасности, например, сертификаты X.509, а также подписи и шифрование. Основное внимание уделяется обеспечению безопасности обмена сообщениями SOAP между двумя сторонами. Такие стандарты, как WS-Security и WS-SecurityPolicy предоставляют механизм реализации обеспечения безопасности Web-сервисов. WS-Security позволяет дополнить сообщение SOAP информацией по безопасности. WS-SecurityPolicy - инфраструктура WS-Policy, разработанная ведущими компаниям отрасли, в том числе IBM, Microsoft и Verisign, - предоставляет модель общего назначения и соответствующий синтаксис для описания и обмена данными о политиках Web-сервиса. WS-Policy определяет базовый набор конструкций, которые другие спецификации Web-сервисов могут использовать и дополнять, чтобы описывать широкий диапазон требований, параметров и функций сервиса. WS-SecurityPolicy описывает способ, которым Web-сервисы могут выражать свои требования и условия, имеющие отношение к обеспечению безопасности. Файл WS-SecurityPolicy, ассоциированный с Web-сервисом, декларирует способ обеспечения безопасности с точки зрения используемых типов маркеров, криптографических алгоритмов и механизмов. Использование механизма обеспечения безопасности на транспортном уровне является частью общей конструкции и допускает эволюцию с течением времени. Файл политики безопасности информирует потребителя, запрашивающего сервис, об удостоверениях безопасности, которыми располагает сервис, чтобы потребитель мог осуществить доступ соответствующим способом. Механизмы обеспечения безопасности могут быть разными, поэтому необходимо отделить их от фактического описания бизнес-сервиса.
Обоснование необходимости политики безопасности
Как правило, интегрированные приложения или системы "бизнес-бизнес" имеют созданные вручную соглашения о политике безопасности. Оба приложения связаны этим соглашением и информируют зависимые клиенты аналогичным способом. Генератор, используемый для создания сервиса, предоставляет набор мер обеспечения безопасности, а затем клиент следует этим мерам при доступе к сервису. В долгосрочное перспективе исполнение установленных соглашений является непростым делом. Это приводит к::
- Ошибкам ручного ввода от неосведомленных участников;
- Дополнительным расходам на повторную реализацию процессов;
- Тенденции к пересмотрам политики безопасности на стороне сервера с целью уточнения.
Когда компании вносят свои сервисы в реестр UDDI, в нем сохраняется URL WSDL в структуре TModel и конечная точка сервиса в шаблоне связывания. Потребитель сервиса может выполнить поиск по реестру и обратиться к конечной точке и URL WSDL. Точно так же в реестре можно предусмотреть возможность хранения файлов политики и безопасности сервиса; предполагается, что потребитель, запрашивающий сервис, умеет адаптироваться к его политике безопасности.
С Web-сервисом ассоциируется файл WS-SecurityPolicy, определяющий политику безопасности, которой следует данный конкретный Web-сервис. Потребитель, запрашивающий сервис, должен соблюдать эту политику в своем запросе при вызове Web-сервиса. В реестре UDDI нужен механизм, который позволял бы потребителю находить политику безопасности Web-сервиса аналогично тому, как это делается при поиске WSDL. Мы предлагаем хранить в реестре UDDI URL файла политики безопасности точно так же, как хранится URL WSDL в элементе TModel. В TModel URL WSDL сохраняется в элементе OverviewURL. Поскольку допускается иметь любое количество OverviewURL, можно сохранить файл политики безопасности во втором OverviewURL в той же структуре TModel. На рисунке 1 показаны два элемента OverviewURL в одном элементе TModel одного тестового узла UDDI в приложении IBM WebSphere App Server 6.
Рисунок 1. Общий вид документа
Файл политики можно извлекать программно так же, как и WSDL, кроме того, можно использовать его во время исполнения на клиентской машине при вызове Web-сервиса. Клиент должен уметь применять политику безопасности, предлагаемую файлом политики безопасности.
Это дает обеим сторонам гибкость в разработке политики безопасности с учетом своих конкретных бизнес-требований. Для оперативного обмена информацией вам не нужно иметь установленное соглашение об уровне сервиса (service-level agreement, SLA). Этот процесс уже встроен в архитектуру, поэтому обе стороны связываются между собой без всяких проблем. Связывающиеся стороны обмениваются некоторым набором общих предположений об определенных политиках или протоколах через гибкий и динамичный обмен информацией о конечных точках в жестко связанной среде.
Чтобы следовать принципу постепенности, пользователи и клиенты могут обмениваться файлами WSDL и соответствующими файлами политики безопасности через UDDI, как показано на рисунке 2.
Рисунок 2. Использование UDDI на разных этапах
Таким образом компания реализует доступ не только к WSDL, но и к политике безопасности.
Мы взяли текущую версию UDDI и создали на ее основе решение для управления безопасностью. Мы предлагаем включить это изменение в следующую версию UDDI.
UDDI как инструмент управления конфигурациями
За прошедшие годы возникло множество подходов к управлению версиями Web-сервисов. Один из таких подходов, WS-Versioning, определяет конструкции для уведомления пользователя о любых изменениях информации, связанной с версиями. WS-Addressing - это совместная разработка корпораций (сBEA, IBM, Microsoft, SAP и Sun Microsystems, определяющая две конструкции для передачи информации, обеспечивающие совместимость разных решений. Как правило, эти конструкции реализуются на уровне транспортных протоколов и систем обмена сообщениями. Описанные конструкции переводят исходную информацию в унифицированный формат, который можно обрабатывать независимо от транспорта или приложения. Эти две конструкции представляют собой ссылки на конечные точки и информационные заголовки в сообщениях. Принцип WS-Addressing также улучшает стандарт WS-Versioning за счет механизма управления версиями.
Согласно спецификации UDDI v3, "Подписка предоставляет клиентам (подписчикам) возможность зарегистрировать свою заинтересованность в получении информации по поводу изменений, внесенных в реестр UDDI. Эти изменения могут предоставляться в объеме, который определен в запросе." Таким образом, UDDI сообщает пользователю об изменениях информации, но не показывает информацию о версии.
Мотивация для создания решения по управлению конфигурацией
С течением времени Web-сервисы неизбежно изменяются. Например, Web-сервис для подсчета подоходного налога может изменяться каждый год. Этот факт необходимо учитывать при создании реестра сервисов. Пользователи должны иметь информацию о последней версии Web-сервиса и возможность при желании в любое время обратиться к старой версии. Это положение иллюстрируется рисунком 1.
Чтобы лучше понять необходимость управления версиями, давайте рассмотрим реальный пример. Финансовая компания выплачивает проценты по инвестированным с ее помощью капиталам. Для вычисления процентной ставки она использует общепринятый или свой собственный алгоритм. Предположим, что процент рассчитывается помесячно, исходя из двух величин: базовой составляющей, которая всегда постоянна, и переменной составляющей, которая может изменяться каждый месяц (опять-таки по какому-то алгоритму). Пользователь может подсчитать сумму процентов за месяц с помощью Web-сервиса компании через Интернет. Если пользователю нужно узнать сумму процентов за текущий месяц, он воспользуется последней версией Web-сервиса. Если ему нужно узнать, какие проценты он получил за прошлый месяц (прошлые месяцы), ему придется выбрать прежнюю (прежние) версию (версии) этого Web-сервиса, поскольку сумма будет разной из-за переменной составляющей в формуле подсчета процентов. Как компании однозначно объявить все версии Web-сервиса в реестре UDDI, чтобы пользователь всегда получал правильную версию? Как видите, поддержка версий - это важная функция для компаний и конечных пользователей. Хотя UDDI является ведущим стандартом для Web-сервисов и имеет весомую поддержку в отрасли, тем не менее, он не поддерживает безопасность и управление версиями Web-сервисов в достаточной степени.
По мере эволюции Web-сервисов они, естественно, становятся все более сложными, чтобы иметь возможность поддерживать решения корпоративного уровня. Вместе с дополнительной информацией Web-сервис превращается в тяжеловесный компонент, несущий в себе всю информацию, которую можно было бы распределить по уровню, где происходит регистрация Web-сервисов.
У стандартов для Web-сервисов существуют два потенциальных недостатка:
- Стандарты на Web-сервисы делают конструкцию сообщений сложной и тяжеловесной;
- Web-сервис включается в механику управления сервисами вместо того, чтобы гранулярно управлять бизнес-логикой.
Мы знаем, что в структуре данных UDDI элемент BusinessEntity содержит один или более элементов BusinessService, содержащих элементы BindingTemplate, которые, в свою очередь, содержат модели TModel. BusinessEntity, BusinessService и TModel содержат элементы IdentifierBag и CategoryBag. Элемент IdentifierBag идентифицирует конкретные сервисы или компании, тогда как элемент CategoryBags упорядочивает записи в UDDI, создавая структуру. Элементы делятся на категории по общепринятым схемам классификации, например, UNSPSC, NAICS, ISO 3166 и т.д. Мы устанавливаем соответствие между элементами BindingTemplate и TModel с помощью элементов IdentifierBag и/или CategoryBag. В ПО WebSphere Application Server v6 мы можем воспользоваться элементами CategoryBag и добавить информацию о категоризации через графический интерфейс администрирования.
Рисунок 3. Технические детали модели в WebSphere Application Server v6
Информацию управления версиями можно добавить в элемент CategoryBag с помощью ключа с именем "Version", значением которого является номер версии. Поскольку элемент BindingTemplate уже привязан к конкретному элементу BusinessService, нам не придется явно сопоставлять их. Однако в UDDI v3, где элементы CategoryBags включены в BindingTemplates, можно явно сопоставить BindingTemplate и BusinessService, поместив имя сервиса в элемент CategoryBag элемента BindingTemplate.
Рисунок 4. Информация о связывании в окне администрирования WebSphere Application Server v6
Теперь, чтобы связать TModel с элементом BindingTemplate, остается только, чтобы потребитель сервиса, указал, какую версию он хочет использовать. После этого можно найти элементы TModel (а, следовательно, URL WSDL) по номеру версии. В процессе выполнения потребители сервиса могут извлекать элементы TModel, ассоциированные с конкретным элементом BindingTemplate, а затем находить конкретный номер версии в их элементах CategoryBag.
UDDI в корпоративном программном решении выполняет функции одной из ключевых областей процесса (key process area) модели технологической зрелости организации (Capability Maturity Model (CMM) - управления конфигурациями. Как и в стандартах WS-*, в реестре UDDI могут присутствовать несколько версий описаний Web-сервиса. Это позволяет провайдеру сервисов не только организовать широковещательное распространение информации о новейшей версии, но и обеспечить гибкость переключения между различными версиями Web-сервиса в зависимости от бизнес-требований. Следует иметь в виду несколько факторов:
- Расширенная версия UDDI является средством описания и обнаружения текущих Web-сервисов и репозиторием истории их изменений;
- В рамках одного бизнес-объекта и бизнес-сервиса генератор может учитывать потребности различных потребителей, предлагая разные версии одной и той же разновидности Web-сервиса;
- Генератор может предложить одну и ту же разновидность Web-сервиса разным потребителям с разными политиками безопасности; об этом говорилось в предыдущем разделе;
- Помимо всего прочего, UDDI помогает компаниям поддерживать качество управления конфигурацией.
Мы создали нашу реализацию как временное решение в рамках спецификации UDDI v3. UDDI не поддерживает управление версиями зарегистрированных сервисов. Применение UDDI в приложениях корпоративного уровня требует наличия в UDDI средств управления конфигурациями Web-сервисов. Это, в свою очередь, порождает необходимость ввести в следующую версию UDDI поддержку этого элементарного подхода, который поможет архитекторам корпоративных приложений на базе SOA реализовать комплексный и ориентированный на качество подход к этой проблеме.
UDDI передает информацию о политике и версии потребителю на лету. UDDI вполне можно использовать в качестве централизованного и интегрированного решения для управления и настройки. Предложенное в этой статье здесь временное решение выполнено в рамках существующих стандартов и платформ. Для его реализации необходимо встроить эти функции в существующие стандарты UDDI.
Как мы убедились, обеспечение безопасности и управление версиями - важные аспекты реализации Web-сервисов, а по мере роста компании проблемы обеспечения безопасности и управления версиями становятся более заметными, и их трудно игнорировать. Мы показали, вполне возможно решить эти проблемы на основе существующих и признанных стандартов, и продемонстрировали, как можно использовать UDDI, чтобы предоставить клиенту Web-сервиса информацию о безопасности и версиях, не внося серьезных изменений на уровне компании в целом. Выполнив описанную небольшую коррекцию спецификации UDDI, можно было бы получить идеальное решение.