На пути к приемлемому определению сервиса

Методология Rational Unified Process (RUP) требует многословных документов, созданных в текстовом процессоре [2]. Приверженцы методологий типа экстремального программирования (XP) относятся к ним с отвращением [1], но текстовые документы по-прежнему остаются основной формой описания большинства систем и утверждения изменений.

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

Обе методологии претендуют на работу с сервисно-ориентированной архитектурой (service oriented architecture, SOA), но ни одна из них не создавалась с учетом ее особенностей. Они ориентированы преимущественно на поставку готового продукта, а не на формирование исходных концепций. Предлагаются множество подходов к определению корпоративной архитектуры (таких как платформа Захмана [3], проприетарные подходы и, конечно, стандарты IEEE [4]), причем в какой-то степени в них рассматриваются и сервисы. Однако, большинство таких подходов обеспечивают просто поиск «коробок» для размещения и учета элементов, а не рассмотрение этих «коробок» с точки зрения сервиса с целью понять, какими они должны быть. Даже когда основой подхода является сервис, инструментальная поддержка остается ограниченной и неэффективной, а проектная группа и другие заинтересованные лица при общении между собой применяют неструктурированные тексты, обычно созданные в Word.

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

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

Единственный путь — стандартизация

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

Стандарт часто складывается под воздействием органов стандартизации, которые примиряют интересы множества сторон и их представления о путях развития. Такими стандартами не только поддерживались, но даже инициировались основные технологические взрывы последней четверти века (рис. 2). Сектор беспроводных локальных сетей Wi-Fi дает классический пример стандартов, создавших рынок и определяющих его существование.

Архитекторы проектов должны, однако, помнить что успешная стандартизация невозможна без активной поддержки со стороны отрасли. CORBA — лишь один из примеров «почти-стандарта», который не достиг полного успеха, поскольку одна из ведущих компаний, Microsoft, отказалась его принять. Чтобы преуспеть, стандарт не обязательно должен быть наилучшим способом решения задачи с технической или научной точки зрения — он лишь должен де-факто стать методом достижения определенной цели. Некоторые утверждают, что стандарты 802.11x — не самые лучшие [5], но без них точки беспроводного доступа Wi-Fi не смогли бы распространиться по всему миру.

Из чего состоит сервис?

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

Архитектура сервисов связана не только с технологией, которая является прерогативой SOA, но и с нетехнологическими аспектами. Здесь мы рассматриваем элементы, реализуемые с помощью технологии, но сервисы могут иметь множество атрибутов и эффектов, которые технология не в состоянии определить или измерить. Скорее всего, любая система будет использовать множество нетехнологических сервисов. А следовательно, сервис — это деликатная область управления, которая включает в себя набор задач, позволяющих достигнуть определенных целей. В хорошей архитектуре сервисы часто связаны с бизнес-подразделениями и их задачами. Мы можем также разбить сервис на составные части — подобно тому как компания делится на подразделения для лучшей организации ее работы. Если институт IEEE предоставляет услуги всем своим членам, то компьютерные услуги, являющиеся более низкоуровневыми, направлены на достижение целей конкретной фирмы (рис. 3). Таким образом, в определениях сервиса нужно рассматривать не только соглашения SLA для низкоуровневых сервисов, но и влияние на них высокоуровневых соглашений.

Содержание определения сервиса

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

Автомобиль является ярким примером определения сервиса. Все автомобили имеют одинаковые базовые возможности, и их обеспечение определяется вопросами «Что они должны делать?» и «Как заставить их это делать?». Если ограничиться рассмотрением автомобилей без автоматической коробки передач, то в терминах пользовательского интерфейса к сервису получатся почти идентичные спецификации. На рис. 4 показаны два представления одной и той же информации. Справа — простая диаграмма класса UML, а слева — визуализация данного класса в виде Web-сервиса. На этом рисунке в упрощенном виде показаны основные функции автомобиля, необходимые пользователю.

Рис. 4. Два представления сервиса: диаграмма класса UML и визуализация Web-сервиса

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

Основа сервиса — WSDL

За последние два года язык описания Web-сервисов WSDL (Web Services Description Language, [6]) стал стандартом определения не только сервисов, использующих протокол SOAP [7], но и вообще любых сетевых сервисов. Это изменение, произошедшее по инициативе BEA и IBM, двух поставщиков ПО J2EE (Java 2 Enterprise Edition), позволяет нам описывать как продукты на основе новых технологий, так и существующие системы и сервисы. Такое развитие жизненно важно для более широкого распространения SOA, поскольку не требует дополнительных разработок для перехода существующих систем к сервисно-ориентированным архитектурам.

Последний продукт IBM с длинным названием IBM WebSphere Business Integration Server Foundation (сервер интеграции бизнес-процессов) позволяет архитекторам определить сервисно-ориентированную архитектуру, которая дает возможность приложениям CICS (customer information control system) на мэйнфрейме взаимодействовать с Web-сервисами на базе SOAP. Платформа BEA Weblogic Platform предлагает подобные же средства, обеспечивая единый «контейнер», в котором клиенты могут управлять сервисами. Компании BEA и IBM наряду с Microsoft, Sun, Oracle, SAP, другими поставщиками сервисных архитектур [8] и группами аналитиков [9] разрабатывают более стандартизированное представление SOA. Они утверждают, что через несколько лет WSDL станет фактическим стандартом описания сервисов, а определение существующих систем с помощью WSDL поможет предприятиям придать гибкость своим вычислительным средам.

WSDL — это пример стандарта, который, может быть, лишен академической чистоты, но позволяет отрасли развивать следующее поколение ИТ-систем. Будучи стандартом, по которому достигли соглашения основные поставщики программного обеспечения и крупные корпорации, он уже сейчас позволяет строить сети для совместной работы. А по своей ценности он превзошел все предыдущие попытки наладить межкорпоративное сотрудничество, в том числе с помощью электронного обмена данными [10].

WSIF. Один из способов создания стандарта — выпустить его в открытом коде и заставить рынок двигаться вокруг него. Этот способ становится все более популярным и используется при развитии таких технологий, как BEA BeeHive на платформе Linux, Sun Solaris [11] и IBM Web Services Invocation Framework (WSIF) [12]. Правда, WSIF — технология, предназначенная только для Java, но все поставщики Java рассматривают и зачастую реализуют ее. Для обеспечения оконечных точек, построенных без применения SOAP, в технологии WSIF задействуются средства WSDL.

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

WS-Policy. Этот стандарт на оформление сервисов предложен компаниями IBM, Microsoft, BEA и SAP, которые стремятся определить платформу для придания сервисам атрибутов. WS-Policy обеспечивает гибкую расширяемую грамматику для определения возможностей, требований и общих характеристик объектов в системе Web-сервисов на основе XML. WS-Policy устанавливает структуру и модель для выражения этих свойств в виде политик. В таких выражениях допускаются как простые декларативные утверждения, так и более сложные условные утверждения [13]. Это — еще не окончательное решение, но в новых проектах оно помогает учитывать окружающую среду.

Исходная предпосылка состоит в том, чтобы задействовать WS-Policy для определения стандартов безопасности, использование которых предписывает сервис. Это означает, что мы уже можем перейти от многословных текстовых документов к метаданным на базе XML, чтобы определить тип шифрования, способ аутентификации и метод аудита в применении к политике безопасности.

Код, представленный на рис. 5, взят непосредственно из проекта спецификации. Данный пример показывает, как сервис определяет разные формы дескрипторов безопасности, которые он будет принимать при идентификации.

Рис. 5. Пример WS-Security

Политика для автомобиля. В приведенной нами метафоре «автомобиль» политика безопасности реализуется с помощью ключа зажигания. Определение сервиса не изменяется, но теперь оно ограничено политикой безопасности, которая требует, чтобы опознанный пользователь подтверждал свою аутентификацию с помощью дескриптора (ключа). В зависимости от типа автомобиля на сервис могут быть наложены и другие ограничения. Например, сервис «Форд Фокус» будет характеризоваться максимальной скоростью 120 миль в час и пятью передачами плюс задний ход, а сервис «Астон Мартин DB9» — скоростью 190 миль в час и шестью передачами плюс задний ход. С помощью WS-Policy и WSDL мы получим функционально эквивалентные интерфейсы, но ограничим определение сервиса. В схему будут внесены ограничения на диапазоны изменения данных, а политика безопасности будет применена к сервису в целом.

Последствия обращения к функциям. Слабое место стандартов Web-сервисов — определение последствий вызова конкретной функции сервиса. Это — одна из ключевых областей, вокруг которых идут споры между организациями, предоставляющими сервисы, и поставщиками инструментальных средств. Бертран Мейер предложил метод проектирования по контракту [14], нацеленный на договорное определение сервиса. Этот метод включает в себя традиционные, входные и выходные условия, инварианты и обязательства по качеству сервиса. Часть элементов контрактов удастся выполнить путем определения диапазона входных значений, которые можно передать сервису. Такие ограничения диапазона легко реализуются в XML и позволяют уменьшить влияние неожиданных системных ошибок «выхода за границы».

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

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

Первая стадия этого перехода уже завершена. Опираясь на инструменты IBM, Microsoft, BEA, SAP, Sun и Oracle, архитекторы и разработчики используют для определения сервисов WSDL и WS-Security. Они определяют первичный контракт для сервиса в терминах ограничений на диапазоны входных данных и процессов, к которым такой сервис может обратиться, а также необходимых цифровых удостоверений. Это обеспечивает минимизацию трудозатрат по сравнению с практикой определения сервисов в виде документов Word. Хороший пример — влияние методов определения диапазонов в WSDL: они минимизируют необходимость в излишне подробном документировании моделей данных, необходимых для взаимодействия.

В таблице приведено текстовое определение ограничений автомобиля. Мы можем заменить его XML-схемой. А затем мы используем эту XML-схему, чтобы сгенерировать связанные с проектом сервис и код, обеспечить прямое отображение архитектурных и аналитических ограничений на реализацию и выполнение сервиса. Контракт не может быть нарушен, поскольку мы способны полностью проследить его соблюдение на всем «пути» от требований клиента до поставки готовой системы. Мы получаем простой механизм обслуживания определений атрибутов в проекте и стандартный способ внесения модификаций. Например, если в новом автомобиле угол отклонения педали должен изменяться лишь на 10-40 градусов, достаточно ввести более жесткие ограничения, а затем проследить воздействие изменения на все те элементы, которые ссылаются на предыдущий артефакт XML.

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

Дальнейшее развитие стандартов и инструментов. Основываясь на первых шагах от текстовых спецификаций к более формальному определению сервиса, несколько новых стандартов должны улучшить положение дел в области стандартизации Web-сервисов. К сервисам будут добавлены еще больше элементов оформления, которые позволят уменьшить объем требуемой документации и поднять на новый уровень управляемость систем. Ключевой мерой успеха станет степень их принятия поставщиками инструментов. Сумев определить и измерить главные характеристики сервиса (интерфейс, контракт, безопасность, производительность и надежность), мы существенно снизим трудозатраты на определение сервисов в виде текстовых документов.

Для достижения успеха инструменты должны предоставлять общую информацию каждому действующему лицу проекта. Это разнообразие представлений единой информационной модели является основой для разработок в рамках модельно-ориентированной архитектуры (Model-Driven Architecture, MDA) [15]. Рисунок 6 детализирует проблемы, с которыми сталкиваются поставщики инструментов в попытках обеспечить подобную среду.

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

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

ЛИТЕРАТУРА

Кент Бек. Экстремальное программирование. — СПб.: Питер, 2002.
Rational Unified Process. — IBM. — Mar. 2005; www-3.ibm.com/software/awdtools/rup.
J.A. Zachman. A Framework for Information Systems Architecture // IBM Systems J. — Vol. 26, no. 3. — 1987. — Pp. 276-292.
IEEE Std. 1003.1. Standard for Information Technology — Portable Operating System Interface (POSIX). — IEEE. — 2004.
J.-P. Saindon. — Techniques to Resolve 802.11 and Wireless LAN Technology in Outdoor Environments // Security Magazine. — 8 May 2002; www.securitymagazine.com/CDA/Articlelnformation/ features/BNP_Features_Item/0,5411,77206,OO.html.
E. Christensen et al. Web Services Description Language (WSDL) 1.1. World Wide Web Consortium (W3C) note. — Mar. 2001; www.w3.org/TR/wsdl.
SOAP Version 1.2. World Wide Web Consortium (W3C) recommendation. — June 2003; www.w3.org/TR/soap.
M. Op ?t Land. Usability of Capgemini?s Integrated Architecture Framework (IAF) Compared with the Extensible Architecture Framework (xAF) // Proc. Dutch Nat?l Architecture Congress 2004 (LAC 2004). — 2004; www.lac2004.nl/docs/fvbg2hdsb83/ Track8/M.%20Op%20%27t%20Land.pdf.
SOA Blueprints // Middleware Research. — Mar. 2005; www.middlewareresearch.com/soa-blueprints.
G. Papadopoulos. Rules of the Game: Moore?s Law Meets Gilder?s Law Meets Metcalfe?s Law // Proc. Accelerating Change Conf. 2003; www.sun.com/executives/perspectives/rules.html.
Open Source and Open Learning. — Sun. — Mar. 2005; www.sun.com/2004-0720/feature.
B. Lublinsky. Web Services Invocation Framework // WebSphere Developer?s J. — June 2003; www.findarticles.com/p/articles/ mi_m0MLX/is_6_2/ai_104209589.
A. Anderson. IEEE Policy 2004 Workshop, 8 June 2004. Comparing WSPL and WS-Policy. — Sun Labs. — 2004; www.policy-workshop.org/2004/slides/Anderson-WSPL_vs_ WS-Policy_v2.pdf.
B. Meyer. Applying «Design by Contract» // Computer. — Vol. 25, no. 10. — 1992. — Pp. 40-51.
First European Workshop on Model Driven Architecture with Emphasis on Industrial Application. — 2004; modeldrivenarchitecture.esi.es/ mda_worksProc&Pres.html.

Стив Джонс (steve.g.jones@capgemini.com) возглавляет группу Enterprise Java в компании Capgemini, является корпоративным архитектором, консультирующим по техническим стратегиям и стратегиям реализации.