Создание и использование WEB-сервисов

Содержание

Содержание

Недостатки предыдущих технологий и предпосылки перехода к СОА

Как решается задача интеграции приложений? Традиционный подход —  построение промежуточного программного слоя того или иного типа. Оптимальной для объединения разнородных платформ и решений выглядела технология взаимодействия распределенных объектов CORBA, позволявшая инкапсулировать бизнес-логику приложений, выполняющихся на разных платформах и созданных с использованием разных языков программирования, организовав связь между ними на базе строго описанных интерфейсов. Аналогичные возможности — правда, с естественным ограничением гетерогенности — предлагала корпорация Microsoft в рамках своей компонентной модели DCOM. Однако этим решениям не хватало универсальности; даже применение CORBA сильно зависело от реализации в продуктах разных поставщиков, появлялись новые объектные модели, не поддерживающие CORBA, интеграция по-прежнему реализовывалась на достаточно низком уровне, практически исключая возможность динамичного изменения связей между приложениями в ходе выполнения. Важно и то, что все предлагаемые средства интеграции фокусировались на технологических особенностях реализации приложений и не позволяли учитывать специфику бизнес-процессов, в которых эти приложения использовались.

В то же время новые  потребности бизнеса диктуют  и новые условия интеграции. Динамичность ИТ-среды, ее нацеленность на решение  бизнес-задач, необходимость быстрых изменений в ответ на изменение этих задач — эти характеристики приобретают ключевое значение при проектировании или реформировании корпоративных ИТ-инфраструктур. В этих условиях отдельные, «точечные» решения по интеграции настолько усложняют и саму инфраструктуру, и процесс управления ею, что становятся абсолютно неприемлемыми. Представим себе, к примеру, что в компании существует несколько приложений, каждое из которых интегрировано со всеми остальными посредством соответствующих интерфейсов. Если таких приложений — n, то всего потребуется n(n-1) интерфейсов. С добавлением всего лишь одного нового приложения появится 2n новых интерфейсов, для которых потребуется соответствующее документирование, тестирование и поддержка. В примере на рис. 1 пять взаимодействующих приложений порождают 20 интерфейсов, а добавление шестого приложения потребует еще 10. При этом придется вносить модификации в код каждого из существующих приложений для учета новых интерфейсов и проводить соответствующее тестирование. Чтобы избежать этого, нужна модель интеграции, которая позволит максимально упростить процесс добавления новых приложений и минимизирует число интерфейсов взаимодействия.

Рис. 1. Прямая интеграция приложений

Еще одна серьезная проблема — избыточность программных компонентов и сложность их многократного использования.

Все эти интеграционные проблемы и привели к появлению  идеи сервисно-ориентированной архитектуры (service-oriented architecture, SOA). Для разрешения этих проблем простого набора технологий уже недостаточно. Нужен общий, архитектурный подход, концепция архитектуры программной среды предприятия, в которой возможна адекватная потребностям бизнеса динамика разработки, интеграции и эксплуатации приложений.

Очень часто становление  того или иного подхода сопровождается появлением неверных или ошибочных трактовок:

SOA не является чем-то  новым: IT-отделы компаний успешно  создавали и развертывали приложения, поддерживающие сервис-ориентированную  архитектуру, уже много лет  - задолго до появления XML и  Web-сервисов.

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

Покупка самых новых  продуктов, реализующих XML и Web-сервисы, не означает построения приложений в  соответствии с принципами SOA.

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

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

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

Отметим некоторые из этих принципов.

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

Как бы неожиданно это ни показалось, перечисленные принципы были сформулированы американским архитектором Кристофером Александером в отношении архитектуры современного мегаполиса. В 1987 году он и его коллеги опубликовали работу под названием «Новая теория городского проектирования» (A New Theory of Urban Design), где излагались взгляды на возможность децентрализованного развития городов. В своей работе Александер показал, как можно осуществлять развитие городов с учетом существенной демографической разнородности жителей. Аналогичным образом SOA, основанная на адаптации этих принципов, позволяет объединить в общий взаимодействующий организм информационные системы, принадлежащие различным автономным организациям и их относительно автономным структурным подразделениям.

Собственно Web-сервисы

Web-cервис это программный интерфейс, который описывает набор операций, которые могут быть вызваны удаленно по сети посредством стандартизированных XML сообщений. Для описания вызываемой операции или данных используются протоколы, базирующиеся на языке XML. Группа Web-сервисов взаимодействующая друг с другом подобным образом, определяет приложение Web-сервисов в рамках Серис-Ориентированной архитектуры (Service-Oriented Architecture - SOA).

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

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

• TCP/IP – универсальный протокол, понимаемый всеми сетевыми устройствами, от мэйнфреймов до мобильных телефонов и PDA;
• HTML – универсальный язык разметки, применяемый для отображения информации устройствами пользователей;
• XML – универсальный язык для работы с любыми типами данных.

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

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

Подробнее остановимся на плюсах и  минусах.

К плюсам веб-сервисов можно  отнести следующее:

1. Веб-сервисы позволяют компании интеграцию собственных бизнес-процессов с бизнес-процессами бизнес-партнеров и клиентов при меньшей стоимости нежели с использованием иных интеграционных технологий. Стоимость подобных решений на основе веб-сервисов доступна даже для SMB (Small and Medium Business), что откроет для таких компаний новые перспективы развития;
2. Поскольку веб-сервисы организуются в публичные реестры (UDDI-реестры, ebXML-реестры или иные), доступные заинтересованным лицам по всему миру, порог выхода компаний на новые рынки снижается, возможности же для наращивания клиентской базы напротив возрастают;
3. Веб-сервисы обеспечивают преемственность в отношении уже имеющихся в компании ИС, т. е. можно сказать, что веб-сервисы надстраиваются над существующими ИС, но не вместо них. Таким образом, обеспечивается сохранность уже сделанных инвестиций в IT-инфраструктуру и не идет увеличения требуемых, поскольку нет необходимости в радикальных изменениях;
4. Построение новых корпоративных решений с применением веб-сервисов реализуется быстрее и совокупно дешевле, поскольку основное внимание сосредотачивается на создании бизнес-логики решения, программирование самих веб-сервисов лишь по необходимости “обрамляет” этот процесс, не требуя больших трудозатрат за счет эффективного применения повторно используемого кода и адаптированных средств разработки (IDE и SDK).

Не менее подробно остановимся и на минусах веб-сервисов:

1. Стандарты интеграции бизнес-процессов, вопросы управления транзакциями и выработка единых бизнес- и IT-политик взаимодействующих посредством веб-сервисов компаний находятся пока на стадии разработки (мы отметим следующие начинания: Web Services Flow Language (WSFL), Business Process Execution Language 4 Web Services (BPEL4WS (аббревиатура “BPEL” произносится кратко как “бипль”)) корпорации IBM, XLANG корпорации Microsoft и спецификации WS-Coordination и WS-Transaction – результат сотрудничества IBM, Microsoft и BEA). Очевидно, без их четкой формализации и опубликования построение ИС на основе веб-сервисов может идти лишь с переменным успехом;
2. Динамическое использование информации бизнес-реестров веб-сервисов, вызов веб-сервисов “на лету”, требует решения вопросов доверительности отношений между различными бизнес-реестрами. Кроме того, есть трудности в совместном использовании бизнес-реестров различных форматов (например, задача поиска определенного веб-сервиса в UDDI-реестре и ebXML-реестре требует различных подходов в силу различия XML-документов, описывающих один и тот же веб-сервис в каждом из этих реестров. Хотя, надо отметить, что есть попытки решить эту проблему созданием единого браузера реестров. В качестве примера - графическая утилита Registry Browser корпорации Sun Microsystems, реализующая набор интерфейсов JAXR (Java API for XML Registries));
3. Добавление к функциям сервера приложений функциональности провайдера веб-сервисов (в т. ч. SOAP-сервера) в силу новизны технологий может представлять определенную трудность;
4. Вопросы безопасности функционирования ИС на основе веб-сервисов пока не урегулированы до конца. Спецификация WS-Security – продукт деятельности корпораций IBM и Microsoft – в настоящее время достаточно молода, не “устоялась” и частично все еще дорабатывается. Однако, в силу общности положений спецификации WS-Security, уже готовится к выпуску следующий слой спецификаций, посвященных вопросам безопасности: Web Services Policy Assertions, Web Services Policy Attachments, Web Services Policy Framework, Web Services Trust, Web Services Secure Conversation, Web Services Federation.

Стек технологий веб-сервисов

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