Архитектура и компоненты портала

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

Портлеты и контейнеры портлетов

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

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

J2EE — одна из самых известных серверных компонентных моделей. В J2EE серверные компоненты размещаются в специальных контейнерах. Контейнер представляет собой среду времени исполнения для серверного компонента; он вызывает компонент и предоставляет специфические для компонента службы (например, информация о пользователе и сохранение состояния объекта между сеансами).

Точно так же портлеты размещаются в контейнерах портлетов. API портлетов определяет интерфейс между портлетом и контейнером портлетов.

Рис. 2. Простой портлет. Здесь приведена реализация портлета, подготовленная для среды Apache Jetspeed

На рис. 2 показана простая реализация портлета. Как и сервлет, портлет существует в единственном экземпляре, который создается один раз в контейнере портлетов, а затем может многократно использоваться в различных нитях управления. В состав API портлетов входят следующие элементы:

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

Портлеты существуют в нескольких режимах. Пользователи могут видеть представленное информационное наполнение, запускать службу помощи для конкретного представления или редактировать представление таким образом, чтобы настроить его в соответствии со своими предпочтениями, а администраторы могут конфигурировать портал для предоставления настроенных служб. Режим, который пользователи выбирают, определяет, какой интерфейс портлета они видят. Кроме того, представление может находиться в одном из нескольких состояний, в том числе normal («нормальное»), maximized («максимизированное»), minimized («минимизированное»), closed («закрытое») и т.д. Как и дескрипторы размещения сервлетов, дескрипторы портлетов содержат свойства, существенные для размещения конкретного портлета.

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

Рис. 3. Строительные блоки сервера порталов.

На рис. 3 показаны типичные строительные блоки сервера порталов, созданного как приложение сервлета. Ядро портала получает запрос сервлета от контейнера сервлета и преобразует этот запрос в запрос портлета, который оно направляет соответствующему портлету. Портлет должен извлечь информационное наполнение, используя службы портлета, предоставленные сервером порталов. Затем ядро портала объединяет множество ответов портлетов и возвращает ответ сервлета пользователю. Чтобы корректным образом вывести страницу, служба агрегирования должна учесть предпочтения пользователей и возможности устройства.

Удаленные портлеты

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


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

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

Рис. 4. Портлеты работают на локальном сервере порталов. В этом случае кадровый портал предоставляет пользователям доступ к Internet-службе погоды и кадровым приложениям из внутренней ERP-системы

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


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

Чтобы обеспечить интероперабельность между различными серверами порталов и поставщиками информационного наполнения, необходима стандартизованная модель взаимодействий для посредника портлета и удаленного портлета. В настоящее время над стандартом на Web-службы для удаленных портлетов работает организация Organization for the Advancement of Structured Information Standards (OASIS).

Web-службы для удаленных порталов

Web-службы для удаленных порталов (Web services for remote portals, WSRP) представляют собой визуальные, настроенные на пользователя компоненты Web-служб, которые подключаются визуально, методом буксировки к порталам или другим промежуточным Web-приложениям, объединяющим информационное наполнение из различных источников. Поставщики информационного наполнения и приложений реализуют свою службу как Web-службу удаленного портала и публикуют ее в общедоступном каталоге (например, в реестре Universal Description, Discovery, and Integration). Этот каталог позволяет владельцам порталов легко находить необходимые службы. Элементы каталога, опубликованные в формате Web Services Description Languag, кратно описывают компонент WSRP и предоставляют детальную информацию о службах. Посредник портлета связывается с компонентом WSRP через SOAP, а протокол удаленного вызова портлета (remote portlet invocation, RPI) гарантирует корректное взаимодействие между обеими сторонами. На рис. 5 показан пример того, как портал находит и интегрирует удаленный портлет.

Рис. 5. Размещение удаленных портлетов. Сервер портлетов находит удаленные портлеты путем поиска в реестре UDDI и вызывает портлеты, которые используют посредников портлетов

Попытки стандартизации серверов порталов

Попытки стандартизации предпринимаются в двух важных областях: API-интерфейсы портлетов и Web-службы для удаленных порталов.

API-интерфейсы портлетов

Эксперты Java Community Process работают над расширением стандарта J2EE с целью унифицировать свободно распространяемое программное обеспечение и коммерческие продукты различных производителей. Помимо унификации необходимо гарантировать, что API-интерфейсы портлетов будут основаны на открытых стандартах.

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

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

Web-службы для удаленных порталов

Технический комитет организации Organization for the Advancement of Structured Information Standards сейчас разрабатывает стандарт на Web-службы для удаленных порталов. Данный стандарт, WSRP, позволит организовать взаимодействие ориентированных на пользователей Web-служб с порталами и другими Web-приложениями промежуточного слоя. Это также даст возможность реализовывать удаленные портлеты на любой платформе, будь то J2EE, .NET или некоторая служба, поддерживающая SOAP.

Службы и использование порталов

Типы порталов варьируются в зависимости от пользователей, которым они адресованы, и служб, которые они предлагают.

Общедоступные порталы, такие как Yahoo, открыты для всех и объединяют информацию из различных источников и приложений и поступающую от разных людей, предлагая персонифицированные Web-сайты для произвольных категорий посетителей. Порталы предприятий (или "корпоративные рабочие пространства") предоставляют сотрудникам доступ к характерным приложениям и информации, используемым внутри организации. Торговые порталы, такие как eBay и ChemWeb, - это торговые площадки, которые связывают продавцов и покупателей. Специализированные порталы, такие как портал MySAP.com, предлагают путь доступа к приложениям определенного вида.

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

Служба настройки (customization) распознает различных пользователей и предлагает им информационное наполнение, сконфигурированное с учетом их специфических требований. Эта служба основана на сборе информации о пользователях и сообществах пользователей и должна предоставлять нужное информационное наполнение в нужное время. Служба агрегирования информационного наполнения (content aggregation) готовит информацию, полученную из различных источников для различных пользователей. Она учитывает ориентированный на конкретного человека контекст, идентифицируя пользователя с помощью службы защиты и службы настройки. Служба получения информационного наполнения (content syndication) накапливает информацию из различных источников. Поставщики коммерческого информационного наполнения часто предоставляют информацию в стандартизованных форматах, таких как RSS (rich site summary, "расширенное резюме сайта"), NITF (news industry text format, "текстовый формат индустрии новостей") и NewsML, стандарт на базе языка XML, используемый для представления и управления новостями на протяжении всего их жизненного цикла.
Самая распространенная операция - "клиппировать" (вырезать) информацию с существующих Web-сайтов, скопировав ее в формате HTML на портал. Портал для сотрудников, к примеру, может вырезать ее из внутрикорпоративной интранет-сети. Служба поддержки устройств (multidevice support) готовит информационное наполнение для различных каналов коммуникаций (например, проводные и беспроводные телефоны, пейджеры и факсы), анализируя их характеристические особенности. Как правило, для этого необходимо фильтровать информационное наполнение (скажем, из информации, предназначенной для беспроводного телефона, при этом удаляют все изображения, а для беспроводных соединений WML - преобразуют HTML в язык разметки). Служба единой регистрации (single sign-on) позволяет службе получения информационного наполнения обращаться к внутрикорпоративным системам и извлекать информацию, ориентированную на конкретного пользователя, не требуя, чтобы пользователь каждый раз подтверждал свою личность. Число систем, которые требуют аутентификации и должны быть доступны через портал, быстро растет. Один из примеров - корпоративные приложения управления кадрами. Администрирование портала (portal administration) определяет, как пользователи видят портал. Это не только внешний вид; также в зависимости от природы портала должны задаваться группы пользователей, каналы коммуникаций и информация о правах доступа. Управление пользователями портала (portal user management) меняется в зависимости от аудитории портала. Пользователи, как правило, могут подписываться на общедоступные Web-порталы, но не на корпоративные порталы. Кроме того, в зависимости от типа портала число пользователей может варьироваться от десятков до десятков тысяч и миллионов. В некоторых случаях администраторам приходится распределять пользователей портала по группам таким образом, чтобы портал мог предоставлять информационное наполнение с учетом роли пользователя, его интересов, местонахождения, функций или служебного положения.

Технология сервера порталов

Кристиан Веже

19.09.2002
Открытые системы, #09/2002

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

Порталы, в основном, базируются на существующей технологии Web-приложений, такой как Web-серверы и Java 2 Platform Enterprise Edition (J2EE). В статье предлагается обзор типов порталов и их служб, а также более детальный анализ архитектур и компонентов, предназначенных для построения порталов.

Рис. 1. Страница с портала Yahoo. На ней содержится информация, ориентированная на конкретного пользователя и сформированная с помощью специальных компонентов настройки

и потому фрагментарная область, но

Технология серверов порталов — еще довольно новая и потому фрагментарная область, но сейчас уже разрабатываются необходимые стандарты. Тем не менее, на рынке уже есть несколько достаточно зрелых продуктов, которые определяют состояние дел в этой области.
Большинство современных серверов порталов базируются на Java. Компании Epicentric и Plumtree, пожалуй, первыми предложили серверы порталов как отдельные продукты. С приобретением компании TopTier корпорация SAP смогла присоединиться к ним имеющемуся в ее системе уровню интеграции приложений iViews. Корпорация IBM предлагает WebSphere Portal Server, который базируется на технологиях свободно распространяемой портальной платформы Jetspeed, реализованной в рамках проекта Apache. Со своей стороны, Apache принимает участие в разработке спецификаций для API портлетов в стандарте J2EE, благодаря чему Jetspeed стал серьезным кандидатом на роль эталонной реализации нового стандарта. Еще одна свободно распространяемая портальная платформа Zope реализована компанией Python. Помимо функций портала Zope предлагает некоторые возможности управления информационным наполнением и общие службы Web-приложений. (Этот список, конечно, не полон.)
В ближайшем будущем мы станем свидетелями стабилизации и более надежной интероперабельности между серверами порталов различных производителей по мере того, как они будут реализовывать ориентированные на порталы стандарты. Включение в состав спецификации J2EE интерфейса API портлетов также будет способствовать значительному расширению использования технологии портальных серверов, учитывая известность спецификации J2EE.Что касается других элементов спецификации J2EE, популярность свободно распространяемых реализаций будет расти, вынуждая к тому производителей, стремящихся сохранить свои конкурентные преимущества. В ближайшем будущем скорость внедрения технологии будет определять жизнеспособность рынка служб портлетов. Наконец, в перспективе, технология серверов порталов может распространяться на новые области. Представьте, к примеру, принтер, который предлагает свой пользовательский интерфейс управления как Web-службу удаленного портлета в рамках портала системного управления, обратиться к которому можно по телефону.
Крстиан Веже () — аспирант университета Тюбингена (Германия) и разработчик приложений корпорации DaimlerChrysler. К области его научных интересов относятся архитектура программного обеспечения и взаимозависимость между эволюцией программного обеспечения и эволюцией методологии.
Christian Wege, Portal Server Technology. IEEE Internet Computing, May-June 2002. All rights reserved, 2002, IEEE Computer Society. Translated and reprinted with permission.

Перспективы

Совершенно очевидно, что SOA "набирает обороты". По крайней мере, около года назад сотрудники Gartner уверенно заявили о том, что к 2008 году преобладающей практикой проектирования и разработки компьютерных программ станет сервис-ориентированная архитектура (с вероятностью 0,7). Таким образом, SOA положит конец господствовавшей последние 40 лет архитектуре монолитного программного обеспечения.

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

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

Сотрудники ZapThink прогнозируют, что 2005 год станет "годом SOA". Причем количество перейдет в качество: увеличится число внедрений сервис-ориентированной архитектуры и, как следствие, развертывание SOA будет рассматриваться как стратегическая задача, а не как тактическое решение, рамки которого пока ограничиваются одним подразделением. Таким образом, SOA станет обязательным подходом для большинства крупных компаний, а не перспективным направлением для немногих дальновидных организаций.

Преимущества использования SOA

Прежде чем, перечислить преимущества использования SOA, будет уместным напомнить, что преимущества бывают разные: стратегические и тактические. SOA обладает рядом достоинств как стратегических, так и тактических.

Стратегическая ценность SOA:

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

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

Тактические преимущества SOA:

Более простые разработка и внедрение приложений. Использование текущих инвестиций. Уменьшение риска, связанного с внедрением проектов в области автоматизацией услуг и процессов. Возможность непрерывного улучшения предоставляемой услуги. Сокращение числа обращений за технической поддержкой. Повышение показателя возврата инвестиций (ROI).

Публикации

Хао Хи (Hao He) "Что такое сервис-ориентированная архитектура" (). Клив Финкельштейн (Clive Finkelstein) "Корпорация: сервис-ориентированная архитектура" (). Джерими Уэстерман (Jeremy Westerman) "Сервис-ориентированная архитектура сегодня: введение в SOA" (). Джерими Уэстерман (Jeremy Westerman) "Сервис-ориентированная архитектура сегодня: значение SOA для бизнеса" (). Материалы, опубликованные на сайте Консорциума по интеграции (). Материалы, опубликованные на сайте аналитической компании .

Сервис-ориентированная архитектура

Подготовлено: по материалам зарубежных сайтов
Перевод:

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

Сервис-ориентированная архитектура: основные понятия

Очень часто становление того или иного подхода сопровождается появлением неверных или ошибочных трактовок, как это было, например, с концепцией . Не миновала "сия чаша" и сервис-ориентированную архитектуру. Так, по крайне мере, считает представитель компании BEA Джерими Уэстерман (Jeremy Westerman). Именно поэтому в одной из своих статей, посвященных SOA, он специально останавливается на "проблемных местах" и приводит подробные пояснения:

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

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

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

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

В самом общем виде SOA предполагает наличие трех основных участников: поставщика сервиса, потребителя сервиса и реестра сервисов (см. рис. 1). Взаимодействие участников выглядит достаточно просто: поставщик сервиса регистрирует свои сервисы в реестре, а потребитель обращается к реестру с запросом.

Рис. 1. Общая схема SOA

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

Любой разговор о SOA невольно переходит на рассуждение о роли и месте Web-сервисов. Несмотря на то, что основные положения SOA сложились задолго до появления Web-сервисов, сегодня Web-сервисы занимают центральное место в SOA (см. рис. 1). Так, Джерими Уэстерман отмечает, что использование XML и Web-сервисов "поднимает SOA на более высокий уровень".

Действительно, открытые стандарты, описывающие XML и Web-сервисы, позволяют применять SOA ко всем технологиям и приложениям, установленным в компании.Как известно, Web-сервисы базируются на широко распространенных и открытых протоколах: HTTP, XML, UDDI, WSDL и SOAP. Именно эти стандарты реализуют основные требования SOA - во-первых, сервис должен поддаваться динамическому обнаружению и вызову (UDDI, WSDL и SOAP), во-вторых, должен использоваться независящий от платформы интерфейс (XML). Наконец, HTTP обеспечивает функциональную совместимость.

Наконец, сегодня Web-сервисы рассматриваются как эффективный инструмент для интеграции, в том числе для взаимодействия процессов, выполняемых в различных компаниях. Особое место среди различных спецификаций, предназначенных для описания систем и приложений на уровне бизнес-процессов, занимает язык BPEL4WS (подробнее см. "").

Значение SOA

По словам Клива Финкельштейна (Clive Finkelstein), автора инфотехники (information engineering), до появления концепции SOA при разработке систем в качестве отправного момента для программирования бизнес-логики использовались диаграммы рабочих потоков и блок-схемы систем. Разработанные вручную программы тщательно тестировались, после чего внедрялись. Сегодня ситуация изменилась коренным образом: современные инструменты управления бизнес-процессами позволяют обойтись без ручной разработки и тестировании. Так, с помощью методов моделирования можно проверять корректность исполнения бизнес-логики, представленной в диаграммах, а затем автоматически получать описания этих диаграмм на XML-языках управления бизнес-процессами.

По мнению Клива Финкельштейна, такая технология управления бизнес-процессами является большим шагом вперед с точки зрения повышения эффективности разработки систем; по значимости ее можно сравнить с созданием в конце 50-х годов компиляторов языка высокого уровня. Действительно, данный подход позволяет упростить вызов Web-сервисов из любого местоположения и их выполнение на основе бизнес-правил. Кроме того, при изменении этих правил, корректируется соответствующая логика в диаграммах: диаграммы автоматически генерируются заново. Таким образом, закладываются предпосылки для перехода от медленного ручного кодирования, используемого сейчас при создании систем, к автоматизированному. Благодаря этому компании смогут реализовывать изменение бизнес-правил за минуты или часы, а не за месяцы или годы.

Axis и поддержка WSDL

На момент написания этой статьи Axis поддерживает только SOAP 1.1, хотя реализует в ограниченном виде GET. Используя его унифицированный локатор ресурса и указав параметр method и другие параметры, можно активизировать любой запрос.

Предположим, например, что автор статьи реализовал по адресу (с унифицированным локатором ресурса) http://joker.psol.com/axis/order/Status.jws сервис, предназначенный для сообщения статуса заказа. У этого сервиса два метода - track и detailTrack, которые принимают номер заказа (number) в качестве параметра. Этот сервис может быть активизирован через http://joker.psol.com/axis/order/Status.jws?method=track&onumber=56544322.

Язык WSDL 2.0 (разработкой которого в настоящий момент занимается консорциум W3C) добавляет атрибут pattern в определение операций. Этот атрибут указывает, какую модель SOAP MEP поддерживает сервис (WSDL вызывает модели MEP, поэтому между SOAP и WSDL нет путаницы). Пример сервиса отслеживания приведен в Листинге 1.

Беглый взгляд на модели ответа MEP

Новые возможности, появившиеся в SOAP 1.2, позволяют более тесно связать Web-сервисы и структуру Интернет. Так, одно из нововведений – это метод GET. Этот метод имеет огромное значение, поскольку с его помощью можно выполнять разнообразную оптимизацию. Значимость GET подтверждает сам Web – достаточно вспомнить, настолько широко в нем используется данный запрос. Эта статья посвящена методу GET.

Одним из недостатков первой версии спецификации SOAP (SOAP 1.0) считалась ее зависимость от метода HTTP POST. Хотя в SOAP и использовался популярный протокол (HTTP), архитектура, на основании которой был построен протокол SOAP, вызвала достаточно нареканий.

Этот момент был учтен в новой редакции SOAP, которая была разработана под эгидой W3C. Консорциум вложил немало усилий в абстрагирование многих черт этого протокола, что должно упростить его применение среди различных технологий. В результате, в SOAP 1.2 появилась поддержка SMTP (помимо HTTP), в спецификации также улучшено использование HTTP.

Фрагмент WSDL

<operation name="track" pattern="http://www.w3.org/2003/11/wsdl/out-only">
<output message="trackResponse"/>
</operation>

О методе GET

Чем же плох POST? Если попытаться объяснить в двух словах, то HTTP определяет различные методы для взаимодействия с сервером, основными из которых являются GET и POST. На практике GET используется для большинства запросов, тогда как POST предназначен для форм, которые обновляют сайт. Согласно спецификации HTTP, предназначение GET - извлечения информации, этот метод должен быть безопасным и идемпотентным.

В данном контексте безопасный означает, что эта операция предназначены для извлечения, а не модификации информации. Другими словами, у запроса GET обычно не должно быть побочного действия. Идемпотентный означает, что несколько запросов к одному и тому же унифицированному локатору (URL) ресурса должны выдавать одинаковый результат. Приведенные определения менее строгие, чем они могут показаться. По существу, их смысл состоит в том, что если пользователь обращается по ссылке, он должен быть уверен, что с его точки зрения он не изменяет ресурс.

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

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

Различие между GET и POST не всегда столь жёсткое, а некоторые их аспекты довольно непрозрачны. Многие сайты инкапсулируют извлечение информации в запросе POST, возможно, из-за того, что разработчики считали, что такой подход более простой.

Несмотря на то, что это обсуждение методов HTTP может показаться излишне абстрактным и теоретизированным, это далеко не так. Обеспечение оптимальной производительности браузеров и промежуточного программного обеспечения (прокси, брандмауэров и решений по доставке контента а-ля Akamai) зависит от возможности различать запросы (см. ).

Объединение SOAP и GET

Первоначально SOAP поддерживал только запросы POST. Однако, Web-сервисы могут предоставлять услуги, которые безопасны согласно приведенному выше определению. Например, сервис, который запрашивает о выполнении заказа, является и безопасным, и идемпотентным. В соответствии со спецификацией HTTP, он мог бы быть реализован как запрос GET. А согласно спецификации SOAP 1.0, он должен быть POST.

В спецификации SOAP 1.2 появились модели MEP (Message Exchange Patterns, модели обмена сообщениями) и новое связывание HTTP, комбинируя которые можно реализовать Web-сервисы, которые могут отвечать на запросы GET. Модели MEP регистрируют модели взаимодействия клиента и сервера. Модель SOAP Request-Response MEP (модель запрос-ответ SOAP) – это типичное взаимодействие Web-сервиса: клиент посылает запрос на сервер, а сервер отвечает.

В этой статье подробно рассматривается модель SOAP Response MEP (модель ответа SOAP). Эта модель определяет только ответ, без запроса. На практике, это означает, что отправленный запрос не является запросом SOAP – только ответ является сообщением SOAP. При комбинировании с этим новым связыванием HTTP модель Response MEP допускает запросы GET. Ниже описано, как работает эта модель:

Клиент выдает запрос GET. Чтобы запросить ответ SOAP, он присваивает заголовку Accept значение application/soap+xml.

Cервер отвечает, и клиент обрабатывает ответ как нормальный ответ SOAP.

Используя заголовок Accept, сервер отличает запросы SOAP от обычных запросов HTTP. Чтобы указать свои предпочтения, клиент может воспользоваться свойством q, задавая различный контент/тип в заголовке Accept.

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

Разумеется, поскольку запрос не является частью SOAP, может возникнуть вопрос о том, каким образом клиент узнает, какой унифицированный локатор вызвать и какие параметры передавать. Ответ на этот вопрос прост: сервер SOAP должен делать то, что делают обычные Web-серверы, и включать этот унифицированный локатор ресурса в предыдущее взаимодействие SOAP. Ничто не мешает соединять и сочетать GET и POST.

В качестве примера представим себе, что сервис используется для обрабатывания заказов офисных принадлежностей (ручек, бумаги, ножниц и т.п.). Этот сервис принимает такой заказ с помощью SOAP; очевидно, что подобный запрос не может считаться ни безопасным, ни идемпотентным, поэтому он отправляется как POST. Ответ с сервера может включать унифицированный локатор ресурса, предназначенный для отслеживания выполнения этого заказа. Это отслеживание безопасно и идемпотентно, следовательно, его лучше реализовывать как GET.

Ресурсы

Форум, посвященный обсуждению статей в колонке Беноита Марчала (Benoit Marchal) “XML в действии” (Working XML).

На странице WSDL 2.0 приведена информация о ходе работ над этим языком с учетом последних изменений в SOAP.

На странице рабочей группы XML Protocol консорциума W3C содержится подробная информация о SOAP.

Изучив страницу HTTP, можно узнать текущую позицию W3C в отношении этого протокола.

На сайте Брайена Д. Дэвисона (Brian D. Davison) приводится много полезной информации о кэшировании, прокси и доставке контента.

В статье Ли Доддса (Leigh Dodds) «Когда использовать GET» (When to use GET?) рассказывается об истории включения поддержки GET в SOAP.

Статья Расселла Бутека (Russell Butek) «Отправка и получения сообщений SOAP с JAX-RPC» (Send and receive SOAP messages with JAX-RPC) (developerWorks, сентябрь 2003г.).

IBM WebSphere Studio Application Developer – это продукт для разработки приложений, с помощью которого можно создавать всевозможные приложения, реализующие различные технологии: XML, JSPTM, сервлеты, HTML, Web-сервисы, базы данных и EJBs.

Множество других ресурсов в зоне XML рубрики developerWorks. Полный список статей колонки «Совет» (Tip) приведен на странице с кратким описанием этой рубрики. 

На странице информационный бюллетень Web-cервисов/Советов по XMLможно подписаться на еженедельную рассылку новостей рубрики developerWorks.

На странице IBM Certified Developer in XML and related technologies приведена информация о том, как стать сертифицированным разработчиком XML.

в основу Web, уже доказали

Простые принципы, положенные в основу Web, уже доказали свою масштабируемость и надежность. Поэтому можно только приветствовать то, что SOAP, один из главных стандартов, являющихся основой Web-сервисов, развивается в направлении, которое будет более тесно привязано к этой несомненно успешной архитектуре.
Автор рекомендует читателям, ожидающим того момента, когда в их любимых инструментальных средствах появится поддержка SOAP 1.2 и WSDL 2.0, пересмотреть свои Web-сервисы и выявить безопасные операции, являющиеся основными кандидатами на переход к связыванию GET.

Ответ «традиционалистов»

По мнению специалистов из WSAWG, позиция оппонентов из лагеря REST не учитывает возможности более широкого взгляда на явления. Они считают, что использование Web-технологий является конкретной и частной реализацией Архитектуры, ориентированной на сервисы, и, следовательно, определенным ограничением на общую архитектуру SOA. Это ограничение заключается в том, что агенты SOA обращаются к объектам, которые в World Wide Web принято считать ресурсами, и которые идентифицируются при помощи URI. С другой стороны, Web-приложения в стиле REST строятся в предположении еще больших ограничений, которые заключаются в использовании унифицированной семантики и унифицированных средств манипулирования ресурсами. В WSAWG различают два типа сервисов.

Сервисы, логически совместимые с REST, обеспечивающие прямое манипулирование с объектами, т.е. с представлениями на XML ресурсов Web, которые действительно возможны с использованием минимального числа типов операций. Сервисы, предназначенные для работы с распределенными объектами. Они в первую очередь должны обеспечивать возможность для более сложных операций над ресурсами, природа которых выходит за рамки традиционного представления о Web. Для выполнения такого рода сервисов ограниченного набора операций недостаточно. Это уже "посредничающие" сервисы, служащие средством для выполнения внешнего по отношению к ним кода.

Иначе говоря, «прямые» сервисы используют известные Web-серверы для манипуляций с данными, а «посредничающие» сервисы исполняются средствами внешних кодов, которые вызываются сообщениями и с помощью Web-серверов. Однако оба класса могут идентифицировать ресурсы общими средствами URI, использовать протоколы Web и форматы XML для обмена сообщениями.

Пути развития прикладных протоколов

Количественное и качественное развитие всевозможных Internet-приложений формирует потребность в новых прикладных протоколах. В их совершенствовании видится три возможных пути.

Традиционный подход к протоколам. Этот подход и соответствующая категория протоколов названы традиционными, потому что они появились раньше других и изначально были основаны на первичных протоколах Internet, а именно TCP и UDP. Недостаток этого подхода заключается в невозможности совместного использования ими инфраструктуры. Скажем, протокол RosettaNet существенно отличается от протокола ebXML а тот, в свою очередь, — от протокла Jabber. И хотя сейчас они сближаются поскольку стали использовать XML, реальная совместимость еще не достигнута. Опасность традиционного пути состоит в том, что при появлении новых требований всякий раз возникает потребность в создании новых протоколов.

Структурный, или рамочный подход. Структурный подход родился из понимания неизбежности постоянного обновления прикладных протоколов. Как следствие, возникла мысль о рамочной конструкции (framework). Пример такого протокола являют собой SOAP,WSDL, а также менее известные протоколы BEEP/BXXP (Block Extensible Exchange Protocol). Рамочная конструкция предполагает несколько общих характеристик: тип системы; язык описания сервисов; адресную модель; связь с транспортными протоколами нижних уровней (binding); решения по безопасности; разбиение сообщений на компоненты (framing).

По сравнению с традиционной, эта стратегия позволяет создавать общую инфраструктуру. К слабостям рамочного подхода можно отнести то, что по своей логике он продолжает технологии DCOM и CORBA. Не полностью решается проблема безопасности, маршрутизации и асинхронных двунаправленных коммуникаций. Кроме того, не оправдались первые надежды на XML как на средство, которое обеспечит совместимость приложений, как только будет выбрана основная группа стандартов, например, SOAP/WSDL/UDDI. Со временем стала очевидной необходимость в дополнительных протоколах.
Начали появляться WS-Security, WS-Routing, WS-Inspect и т.д. Неопределенность всей картины в целом сильно сдерживает широкое распространение Web-сервисов и стимулирует многих занимать выжидательную позицию в надежде на W3C и другие организации, которые обеспечили бы взаимодействие.

REST и горизонтальный подход. Стратегия, опирающаяся на горизонтальный подход к протоколам, наиболее радикальна. Слово «горизонтальный» означает в данном случае сохранение существующего уровня, без выстраивания уровней поверх него. Предполагается отказаться от разработки новых протоколов, а использовать несколько хорошо проверенных, считая, что для работы с объектами вполне достаточно уметь выполнять четыре типа действий: создание (Creation), восстановление (Retrieval), изменение (Update) и уничтожение (Destruction). Из этих действий получается так называемый «шаблон проектирования» CRUD. Протокол Hypertext Transfer Protocol определяет методы GET/PUT/POST/DELETE, которые и реализуют шаблон CRUD.

Апологеты REST относят сервисы, построенные в этом стиле, ко второму поколению. Остальные Web-сервисы они объявляют сервисами первого поколения, подчеркивая при этом, что SOAP есть ни что иное, как DCOM или CORBA, но работающие через Internet. Действительно, первоначально технологии, подобные SOAP, называли Web-брокерами или объектными брокерами, построенными в Web. Как указывает Прескод [3], используемая в них модель RPC предназначена для замкнутого мира, где вы знаете каждого пользователя, где данные можно перераспределять между ними, где возможны прямые коммуникации. Для успешной работы в Web необходимо поддерживать сложный механизм, обеспечивающий взаимодействие на случай внесения системных изменений.

Требования со стороны защитников REST-сервисов выглядят иногда слишком экстремистскими. Так, Марк Бэйкер считает, что:

WSDL должен быть ограничен описанием взаимодействия в стиле REST; следует прекратить работы по хореографии сервисов; необходимо закрыть рабочую группу Web Services Architecture Working Group в W3C; новые требования, предлагаемые вновь созданными рабочими группами, должны исходить не из представлений об интеграции с Web-архитектурой, а в полном соответствии с ней.

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

REST + SOAP

Если обратиться к истории, то надо вспомнить, что на уровне языка ассемблера данные, и программы адресовались одинаково. Но уже тогда возникла проблема: как построить вызов к подпрограмме — подкомпилировать ее в тело кода, выполнив специальную макрокоманду, или же использовать вызов с передачей параметров. Сегодня стоит по сути дела та же самая проблема, но на другом уровне. В 70-е годы появилось структурное программирование, был предан анафеме оператор безусловного перехода goto, точнее обозначилось деление на данные и программы. В дальнейшем развитие оборудования хранения данных привело к созданию реляционных СУБД и языка SQL. Для работы с данными оказалось достаточным операторов insert, select, update и delete. В 90-е годы сети стали соединяться Internet-протоколами, подпрограммы с параметрами трансформировались в объекты с сообщениями, а хранимые процедуры стали нормой для операций, модифицирующих реляционные СУБД.

Конфликт «REST vs. SOAP» стоит рассматривать как диалектическое противоречие. Так или иначе оно будет разрешено, позволив более четко представить соотношение между кодами и данными на уровне архитектур SOA откроет путь к более продуктивному использованию Web-сервисов.

Литература

Fielding, Architectural Styles and the Design of Network-based Software Architectures. Dissertation for the degree of doctor of philosophy in Information and Computer Science. www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

Fielding, Richard Taylor, Principled Design of Modern Web Architecture. Proc. of the 2000 International Conference on Software Engineering (ICSE 2000). Limerick, Ireland, pp. 407-416, June 2000. Paul Prescod, Second generation Web Services. O'Reilly&Associates, XML.com, February 2002. Ruby, REST + SOAP. www.intertwingly.net/stories/2002/07/20/restSoap.html

Рой Филдинг и архитектурный стиль REST

Собственное видение проблем программного обеспечения Сети Филдинг описал в докторской диссертации «Архитектурные стили и проектирование архитектур сетевого программного обеспечение» [1]. Работа представляет собой не только фундаментальное исследование на означенную тему, но одновременно и прекрасный учебник.

В настоящее время Филдинг работает в должности научного руководителя компании Day Software, но миру профессионалов он гораздо лучше известен своими прежними достижениями и общественной деятельностью. Стоит вспомнить участие в разработке инфраструктуры World Wide Web, где именно он был главным архитектором Hypertext Transfer Protocol (HTTP/1.1), а также соавтором стандартов для HTTP и URI. Кроме того, Филдинг был в числе инициаторов нескольких проектов известных программных систем с открытым кодом (один из них — проект Apache HTTP Server, который, как признано, является основой более 60% Internet-сайтов). В сферу научных интересов Филдинга входят также архитектура программного обеспечения для сетевых приложений, сетевые протоколы прикладного уровня, средства совместной разработки программного обеспечения. За свои научные успехи, в частности, за проект Apache, в 1999 году он был удостоен ACM Software System Award. В том же году Филдинг был включен в почетный список Top100 молодых исследователей, который составляется журналом MIT Technology Review.

Стиль REST методично раскрыт в диссертации Филдинга, первые четыре главы которой посвящены определению понятия «архитектурный стиль» вообще и принципам построения сетевого программного обеспечения. В пятой главе изложены начала REST. В более сжатом виде идеи стиля REST изложены в [2]; прочтение этой статьи можно считать обязательным для того, кто хочет понять, что такое WWW и REST. В данном случае вполне можно ограничиться самым грубым приближением и сказать, что REST задуман как основа масштабируемого прикладного протокола, обеспечивающего доступ к информационным ресурсам. Подчеркнем, именно к ресурсам. Противопоставление REST остальному миру сервисов можно, в какой-то мере, сравнить с противопоставлением процессорной архитектуры RISC архитектуре CISC. В обоих случаях используется ограниченный набор операций; в случае доступа к ресурсам в стиле REST их всего четыре: GET, PUT, POST и DELETE. Этих четырех операций оказывается достаточно для оптимальных манипуляций с сетевыми ресурсами; главное, что они позволяют, — отделить размещение ресурсов на сервере от восприятия этой информации клиентом и потоковую передачу информации. Антиподом REST является подход, основанный на вызове удаленных процедур (Remote Procedure Call — RPC).

SOAP и REST, вместе или порознь?

18.09.2003

На протяжении последних двух лет в среде разработчиков стандартов для Web-сервисов развернулась активная дискуссия на тему: «SOAP против REST». С этими двумя аббревиатурами ассоциируются два почти диаметрально противоположных подхода к организации Web-сервисов. SOAP (Simple Object Access Protocol) — хорошо известный нижний уровень в стеке протоколов. REST (Representational State Transfer) — менее известное явление, называемое его авторами «архитектурным стилем». В творческом споре против основной массы сторонников SOAP выступает небольшая, никак формально не организованная, группа инакомыслящих, которые поддерживают REST. Скорее всего, победителя в этом противостоянии не будет; как обычно бывает, большинство учтет мнение меньшинства, и вместо противопоставляющего лозунга «SOAP против REST» появится конструктивный «SOAP + REST».

Утверждение, что будущее — за сетевыми архитектурами, превратилось в банальность, сейчас только и разговоров, что Grid да SOA (Service-Oriented Architecture). Но, как говорят англичане, «ободрать кошку можно по-разному», какими именно станут в будущем сетевые архитектуры, сказать сложно, однако наступила пора выбора. Есть взгляды, которых придерживается большинство; их разделяют и крупные компании. Но есть и мнения оппонирующих им «диссидентов».

Во всех нынешних начинаниях, связанных с сетями, так или иначе, присутствует World Wide Web. Первопроходец Всемирной паутины Тим Бернерс-Ли дал своему детищу гениальное по лаконичности определение: «Web — это просто пространство (буквально, «вселенная», universe — Л.Ч.) глобальной информации с сетевым доступом». Идеи, которые заложила возглавляемая им группа энтузиастов из CERN в фундамент архитектуры Web, были настолько продуктивными, что спустя несколько лет оказались востребованными в компьютерной индустрии.

На наших глазах почти в точности повторяется история заимствования корпоративными intranet-сетями технологий из Internet, которая имела место лет пять-семь назад. Однако есть и отличия, вполне очевидно, что архитектура WWW осмыслена адаптаторами в гораздо меньшей мере, чем в свое время архитектура Internet.
В той трактовке Web, которая получила распространение и усиленно эксплуатируется (особенно, когда речь идет о Web-сервисах), все сводится к представлению Web исключительно в качестве коммуникационной среды, что явно противоречит приведенному определению. Web-cервисы, построенные на основе протокола SOAP, не используют возможности Web в полной мере — в том числе, и возможности механизма адресации информационных ресурсов, основанного на универсальных идентификаторах ресурсов (URI).

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

За фасадом победного шествия архитектур, ориентированных на сервисы, и Web-сервисов, вне сферы внимания коммерческой прессы идет невидимое миру противоборство приверженцев различных точек зрения на устройство Web-сервисов. С одной стороны выступает вся индустрия, возглавляемая такими могучими компаниями, как IBM, Microsoft, Sun Microsystems, которые продвигают идеи Web-сервисов на основе «святой троицы» протоколов SOAP/WSDL/UDDI, с другой — крошечная группа энтузиастов идеологии Web в чистом виде. И это не просто борьба технических идей, а скорее отчаянное сопротивление «пуристов», сопротивление, как им кажется, искажению и коммерциализации принципов Всемирной паутины. Острие их нападок направлено на группы Technical Architecture Group (TAG) и особенно Web Services Architecture Working Group (WSAWG), которые действуют в составе основного координирующего органа Web, консорциума W3C. По их мнению, наиболее полно выраженному Марком Бэйкером, в конце 2004 года коммерческие подходы к Web-сервисам ожидает серьезный кризис. В TAG, напротив, считают проповедуемые альтернативные сервисы на основе архитектурного стиля REST частным случаем использования HTTP и не видят за ними серьезного будущего.Наиболее выдержанные специалисты, например, Дэвид Орчард (David Orchard), директор по технологиям компании BEA Systems, являются выразителями более умеренных взглядов.

Консолидированная точка зрения большинства на Web-сервисы представлена в статье «SOA — шаг за горизонт», публикуемой в этом номере журнала. Но двумя лицами дело не ограничивается; может быть и третье, и четвертое. В этой же статье представлена точка зрения меньшинства; знакомство с ней будет полезно хотя бы потому, что позволит лучше понять, почему название «Web-сервисы» используется в основном не вполне корректно. Название неудачное: троица протоколов не имеет по сути своей никакого отношения к Web, кроме использования механизма адресации. Однако название уже прижилось, как говорится, «термин занят». В данной статье, чтобы различить два подхода, будем временно использовать термин «SOAP-сервисы» для обозначения сервисов, построенных на основе SOAP/WSDL/UDDI, и «REST-сервисы» для альтернативного подхода.

Постановка проблемы

Существовавшая до 2002 года практика разработки программ для доступа к информации в Управлении информационного обеспечения ФГУП "Воткинский завод" предусматривала прямое чтение программами информации из таблиц баз данных. Недостатками такого подхода являются:

необходимость детального знания разработчиками аналитических программ всех, читаемых разрабатываемыми программами, таблиц;

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

Решение проблемы

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

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

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

Рис.1. Предполагаемый состав основных Web-сервисов

Предполагается, что каждый из Web-сервисов будет иметь две группы методов. Первая группа методов будет сообщать о факте наличия/отсутствия информации о конкретной детали или сборочной единице (ДСЕ) и, при наличии информации, возвращать структуру, содержащую имеющуюся информацию о ДСЕ. Вторая группа методов должна сообщать о перечне ДСЕ, информацию о которых можно предоставить. Эта группа методов содержит методы: сообщения количества ДСЕ, соответствующих критерию; выдачи перечня возможных символов, следующих в обозначении ДСЕ за некоторой переданной строкой; и непосредственно выдачи перечня ДСЕ в количестве, не превышающем указанного.

Рис.2. Web-сервисы, относящиеся к материальному планированию

Веб-сервисы как вариант основы информационной инфраструктуры предприятия

, ,ФГУП Воткинский завод,

, Ижевский Государственный Технический Университет

В процессе своей деятельности современное

В процессе своей деятельности современное машиностроительное предприятие создаёт для дальнейшего использования значительное количество разнообразной информации.
Частью создаваемой информации является информация о материальных составах изделий. Такая информация создаётся в процессе конструкторско-технологической подготовки производства и используется в процессах планирования, материально-технического обеспечения, управления и др., как, впрочем, и в самом процессе конструкторско-технологической подготовки производства.
Исторически первоначально, единственным хранилищем создаваемой информации о материальных составах изделий являлись бумажные документы (например, как на ФГУП "Воткинский завод", т.н. маршрутно-материальные ведомости). Именно на их основе создавались различные сводки, и к ним обращались при возникновении производственных вопросов. Способом создания сводок в этом случае являются рукописные подсчёты.
Следующим шагом развития, как правило, являлось создание баз данных информации о материальных составах изделий, заполняемых и поддерживаемых путём ввода информации с первичных бумажных документов силами специально сформированных групп операторов. На этом шаге сводки (или, по крайне мере, какая то их часть) подсчитываются компьютерно и подготавливаются машинопечатно. Частично начинает применяться доступ к информации, содержащейся в базах данных, как альтернатива обращения к бумажным документам.
Развитием такого шага является (а для некоторых предприятий уже и являлось) создание программ, позволяющих заполнять/корректировать базы данных одновременно (или практически одновременно) с компьютерной разработкой необходимых, уже машинопечатных, документов. На таком этапе развития рукописная подготовка обобщающих сводок используется в единичных случаях, а практика обращения к информации, содержащейся в базах данных, как альтернатива обращения к бумажным документам, становятся массовым явлением.
Возможным завершением приведённой линии развития является отказ от печати разрабатываемых документов и переход к использованию разрабатываемой и обобщающей информации путём непосредственного чтения на экранах ПЭВМ и ноутбуков/палмтопов.
Необходимым условием использования накопленной в базах данных информации является наличие программ для её переработки и показа получаемых результатов. Такие программы должны быть разработаны в необходимом количестве, причём стоимость разработки программ не должна превышать экономического выигрыша от их использования.

у разработчиков аналитических программ не

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

Business Process Execution Language

В предыдущих статьях я рассматривал Web-сервисы, как одиночные Web-сервисы. Я показал, как создать Web-сервисы, используя JAX-RPC – интерфейс прикладного программирования (API) в среде J2EE (J2EE Web services API), и привел примеры того, как некоторое решение из управления Web-сервисов может естественным образом работать с этими Web-сервисами. Понятно, что для бизнеса полезны даже отдельные Web-сервисы, но настоящую ценность для большинства представляет возможность интеграции множества Web-сервисов в более крупные приложения, часто называемые композитными приложениями или бизнес-процессами.

В следующих статьях я рассмотрю соединение нескольких Web-сервисов в бизнес-процесс. Я буду использовать стандарт, называемый Business Process Execution Language (BPEL). BPEL – это стандарт на основе XML, который Oracle, BEA, IBM, Microsoft и другие поставщики интенсивно разрабатывают как механизм для "оркестрирования" "сквозных" (end-to-end) бизнес-процессов, построенных на базе Web-сервисов. Хотя этот стандарт все еще находится в процессе разработки в комитете OASIS, его спецификация уже достаточно продвинута и появились продукты, поддерживающие ее, от ряда поставщиков, включая Oracle.

Почему BPEL?

Часто первая реакция разработчиков, услышавших о BPEL, такова: "Зачем мне нужен этот стандарт для решения задачи, которую можно сделать обычным программированием?" Разумеется, ничто не принуждает разработчика использовать BPEL. Он может создать простенький бизнес-процесс, который сначала вызывает один Web-сервис, затем принимает его результат и вызывает другой Web-сервис. Но проблема становится намного более интригующей, когда вы попытаетесь разобраться с анатомией типичного долгоживущего бизнес-процесса. Сразу встает ряд непростых вопросов:

Как устроить асинхронные вызовы Web-сервисов, когда вызванный Web-сервис является долгоживущим и должен вернуть управление позднее в Web-сервис, из которого он вызван? Как коррелировать, координировать запросы (на вызов Web-сервисов) между многими одновременно выполняющимися бизнес-процессами? Как вызывать Web-сервисы параллельно? Как сделать откат долгоживущей транзакции, в которой произошел сбой? Как составлять большие бизнес-процессы из небольших? Как гарантировать надежную доставку сообщений?

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

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

Пример "Заем [денег]"

Давайте разберем детали на примере. Я постараюсь на простеньком бизнес-процессе показать, как определяется процентная ставка (interest rate) возможного заемщика (loan customer), когда услуги по заемам нескольких банков запрашиваются в соответствии с требованиями его заема.

На рисунке 1 представлены первые шаги, необходимые для составления процесса получения заема (loan process). Я сначала проведу вас по схеме процесса (process flow), особо обращая внимание на некоторые ключевые конструкции языка BPEL, а затем рассмотрим фрагменты кода реального процессного языка. (Рассматриваемый пример скачан с OTN.) При изучении течения процесса акцент будет сделан на синтаксисе процессного языка, взаимодействию процесса с конечным пользователем будет уделено меньше внимания.

Рисунок 1: Начальные шаги для получения заема

Первое, запрос для оценки заявки на заем (loan assessment) – это вызов Web-сервиса, полученый через действие . Далее, данные о клиенте выбираются и приводятся к формату, совместимому с сервисом каждого банка, через действие. Сервисы The United Loan Service и the American Loan Service вызываются параллельно из действия , содержащего два действия . По завершению оценки, сервис каждого банка возвращает управление бизнес-процессу получения заема со своей оценкой. Этот входящий (inbound) запрос представлен действием .

Далее, эти результаты сравниваются друг с другом, чтобы определить наилучшую ставку, благодаря использованию действий и , аналогичных конструкции if-then-else в языках программирования. В рамках действия выбирается наилучшая ставка и ее значение присваивается переменной для возврата , благодаря использованию действия . Наконец, результат обоих этих вызовов посылается обратно источнику вызова, благодаря другому действию .

Рассмотрим детали реализации

Процесс, определенный в BPEL, как правило, состоит из двух больших секций: секции деклараций и секции процессных действий, окруженных внешним элементом, который называется и идентифицирует имя/название процесса.

Глобальные декларации. Как правило, первая секция процесса содержит глобальные декларации, в том числе те, которые определяют используемые Web-сервисы и называются , а также те, которые определяют используемые переменные и называются .
На приведены листинги деклараций United Loan и American Loan, а также декларации , ожидаемые этими Web-сервисами. Эти конструкции создаются в Oracle BPEL Designer в начале этапа проектирования до того, как сам процесс написан.
Другие высокоуровневые конструкции, такие, как обработчики глобальных ошибок (global error handlers), называемые , обработчики ошибок глобальных транзакций (global transaction failure handlers), называемые , также декларируются в этой первой секции.
Определение процесса. Вторая часть BPEL-процесса содержит логику процесса — шаги, которые будут предприняты, и Web-сервисы, которые будут использованы для выполнения полезной работы. Попросту говоря, есть два типа действий:
Действия-примитивы процессов и данных (Primitive process and data activities) для вызовов и получения вызовов от Web-сервисов, такие как (вызвать), (получить) и (ответить); действия для управления процессом, такие как (ждать) и (завершить); и, наконец, действия для манипулирования данными, такие как (назначить).
Структурированные действия для простого программного контроля над тем, какие шаги будут выполняться в бизнес-процессе, включая предложения, циклы, конструкции параллельного исполнения, такие как (течение) и конструкции последовательного исполнения, такие как .
На приведен код, обеспечивающий вызов the United Loan Service и American Loan Service. Для вызова каждого банка и включены в некоторую последовательность (sequence), тем самым вынуждая их исполняться один за другим. Но оба действия сами включены в действие , тем самым вынуждая обе подпоследовательности для каждого сервиса (бизнес-процесса получения заема) исполняться параллельно.

Соединяя Web-сервисы (Weaving Web Services Together)

(Mike Lehmann), главный менеджер корпорации Oracle по продукту Oracle Application Server Containers for J2EE.

Источник: журнал "Oracle Magazine", no.4, 2004,

http://www.oracle.com/technology/oramag/oracle/04-jul/o44dev_web.html

Перевод:

Не нужно много времени для

Не нужно много времени для уяснения эффективности стандартизованного способа создания бизнес-процессов на базе Web-сервисов. И не только потому, что основную процессную функциональность можно немедленно использовать в любой сервисно-ориентированной архитектуре, но и потому, что она построена на базе стандартов, которые получили беспрецедентное признание в отрасли.
Эта ситуация аналогична ситуациям с SQL и J2EE — стандартами, которые, будучи приняты отраслью, создала целые рынки для серверов, инструментальных средств и услуг. Поставщики технологий отныне не пытались решать базисные проблемы доступа к данным и построения бизнес-логики; вместо этого они сосредоточились на новаторских решениях на базе этих стандартов.
BPEL находится в такой же ситуации раскрытия тех же самых возможностей для интеграции бизнес-процессов. В следующих статьях будут рассмотрены построение, управление и выполнение BPEL-процессов.
Следующие шаги:
Узнайте больше о BPEL
СКАЧАЙТЕ примеры к этой статье

Web-сервисы == или != распределенные объекты?

Дэвид Орчард (David Orchard)
Оригинал
Перевод:

За последние несколько лет тема Web-а, Web-сервисов и распределенных объектов не раз приковывала внимание автора этой статьи: я провел немало времени, размышляя о том, чем они отличаются друг от друга и что необходимо для их успешного применения. На этот счет высказываются самые разные соображения, включая, на мой взгляд, откровенную рекламную чушь: «Web-сервисы – это то, что надо, потому что это нечто новое и совершенное. Для вас они могут даже окраситься в красный цвет!»

Однако, чем же на самом деле отличаются друг от друга Web, Web-сервисы и распределенные объекты? В чем состоят конкретные архитектурные различия? Задавая этот вопрос, я не хотел бы услышать двусмысленный ответ в духе: «Web-сервисы – это крупно структурированные объекты, а распределенные объекты – мелко структурированные».

По моему мнению, одно из различий между Web-ом, Web-сервисами, с одной стороны, и распределенными объектами, с другой, состоит в том, что первые позволяют человеку читать и понимать передаваемый формат данных (HTML, XML,..), объектные ссылки (URIs), протокольные сообщения и описание[1]. Хотя, возможно, язык WSDL далеко не самый удобочитаемый. Распределенные объекты же позволяют читать и понимать описание (IDL – язык описания интерфейса), а формат передачи, объектные ссылки и протокольные сообщения делают бинарным. Так что, возможно, этого вполне достаточно. Хотя существует множество других различий, например, позднее связывание (late binding of the information content to the user), возможность получения высокой производительности благодаря использованию протокола HTTP и URI для установления эквивалентности и т.п.

Вместе с тем, на мой взгляд, существует еще один важный и незатронутый ранее аспект: расширяемость. Если сравнивать Web с распределенными объектами, необходимо отметить, что механизмы вызовов весьма различены. В случае распределенных объектов можно написать что-нибудь вроде: public interface PO { getMyPo( in int poId, out PO purchaseOrder); }

тогда как HTTP мог бы быть смоделирован следующим образом: public interface HTTP { get (in URI address, out MIME body ); }

Давайте очень кратко остановимся на «HTML-ой версии» этого примера, поскольку именно с HTML связано большинство вызовов. Поэтому немного изменим интерфейс: public interface HTTP { get (in URI address, out HTML body ); }

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

Поэтому может показаться, что благодаря произвольной расширяемости интерфейса в стиле dist-obj (распределенные объекты), эта конфигурация должна была бы иметь огромный успех. Однако существует нечто чрезвычайно важное, что не выражается в этом интерфейсе. Возможно, именно поэтому в выигрыше оказываются системы, которые основываются на соглашениях, а не на интерфейсах прикладного программирования (API). Хотя интерфейс HTTP и ограничен определенным набором команд, содержимое может быть расширено. В него можно поместить XML, MIME

Возвращаясь к HTML, стоит отметить, что в спецификации присутствует важная часть информации. Это – правило "Необходимо пропускать" ("Must Ignore"). Другими словами, и для HTML, и для заголовков HTTP, и даже для значительной части спецификации URI существует правило, согласно которому любое неизвестное должно быть пропущено. Если какое-либо содержимое появляется в произвольном месте, и получатель об этом не знает, его можно проверить на допустимость, как если бы это неизвестное содержание было бы «выброшено» из экземпляра. Хотя данное правило указано в спецификации HTML, оно не выражено в схеме/dtd.


По мнению автора, если бы HTML не имел возможности выразить правило "Необходимо пропускать" вне схемы, HTML, вероятно, не допускал бы столь широкую расширяемость.

В результате, стало возможным развитие HTML, которое, однако, не повлияло на интерфейс прикладного программирования HTTP, поскольку они ортогональны. Эти форматы и команды развиваются отдельно друг от друга.

Системы распределенных объектов навязали решение о том, что для расширения любого вида необходимо, чтобы обе стороны понимали расширенный интерфейс. Это – ошибка «единственного администратора». На устранение недостатков систем распределенных объектов была потрачена масса усилий, и, по убеждению автора, отсутствие «локальной» расширяемости ("touchless" extensibility) явилось основной причиной недостаточного понимания и успеха Web-а.

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

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

А что с Web-сервисами? Похоже, что большинство разработчиков Web-сервисов при проектировании своих интерфейсов принимают такое же решение, как и в случае распределенных объектов. Они заново создают метод распределенного объекта "getPO" в сообщении SOAP, не допуская расширяемость в PO.


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

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

Однако, эти решения не совсем такие. Так, XML-схема предоставляет элемент wildcard, который делает возможным присутствие в экземпляре элементов ограниченных пространств имен. Если схема PO обеспечивает групповые символы, разработчики PO могут воспользоваться групповыми символами для расширяемости. Они не получат произвольную расширяемость, присущую HTML – по мнению автора, это весьма проблематично. Существует общая модель, допускающая элементы из пространств имен, отличных от целевого пространства имен. Это обеспечивает по крайней мере какую-то расширяемость, хотя эта модель не исключает некоторых сложностей, которые детально рассмотрены в статье Examining wildcards for versioning. В статье Versioning XML Languages (Управление версиями XML-словарей), опубликованной на xml.com, показано, как их можно использовать для получения «локальной» расширяемости с полной проверкой допустимости; отмечу, однако, что в этом случае разработчик должен по-прежнему активно определять точки расширения.

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


В этом случае мы могли добавить всю функциональность это правила в инфраструктуру, и не требовать, чтобы каждый формат данных и соответствующий код определял, где пропускаемые элементы допустимы, а где нет. И с учетом «уроков HTML» механизм определения правила "Must Ignore", возможно, следует выражать вне языка схемы.

Однако, высказывается мнение, что отсутствие команд с ограничениями (это мнение так называемых «рестафарианов» [RESTafarian]) свидетельствует о «недолгом веке» Web-сервисов. Автор полагает, что хотя сложность в обеспечении «локальной» расширяемости ухудшает возможность развертывания вободно связанных приложений, имеется достаточно способов, с помощью которых можно построить свободно связанные Web-сервисы. Но для этого потребуется явные действия от разработчика интерфейса. Именно поэтому, на мой взгляд, должна появиться более легкая модель, предназначенная для создания и проверки допустимости расширяемых XML-языков.

Имеется в виду язык WSDL (Web Services Description Language - язык описания Web сервисов) [прим. перев.]

Использование новой инфраструктуры в Oracle Application Server

В номере Oracle Magazine за май/июнь 2004 года опубликована моя статья "Управление web-сервисами" ("Managing Web Services"), в которой я представил несколько концепций, применяемых в зарождающейся области управления Web-сервисами, включая такие классические, как мониторинг, аудит и безопасность, а также более специфические для Web-сервисов, такие как обеспечение (provisioning), виртуализация (virtualization) и маршрутизация (routing). Я также указал, что в основе управления Web-сервисами лежат модель передачи сообщений протокола Simple Object Access Protocol (SOAP) и публичный контракт Web Services Description Language (WSDL), описывающий ее расширения.

В этой статье я представлю новые возможности управления Web-сервисами в Oracle Application Server 10g Release 10.1.3. В отличие от моего первого "программистского" вхождения в эту область, когда я написал несколько обработчиков (handlers) для интерфейса JAX-RPC, чтобы реализовать простейшие функции управления, на этот раз я воспользуюсь тем, что предоставляет сервер приложений, и, как разработчик, я смогу сфокусироваться на бизнес-функциях, а не на ручном кодировании поддерживающей инфраструктуры.

Я продолжу использовать мой пример Web-сервиса для предметной области "Кадры" (human recources), HRService - с операцией getEmpSalary - как базовый пример, и в этой статье подробно рассмотю специфические аспекты возможностей управления Web-сервисами, включая аудит, журнализацию, надежность и безопасность.

Конфигурирование политик

Политики для Web-сервисов устанавливаются в иерархии, соответствующей структуре WSDL. Сервисы, как правило, содержат один или несколько портов, которые содержат связи (bindings) к одной или более операциям. Чтобы соответствовать такой структуре, политики управления могут быть установлены на уровне порта или операции.

Чтобы получить представление об этих политиках, давайте изучим a snippet файла wsmgmt.xml для Web-сервиса "Кадры": 1 <port app="HR-Emp-WS" 2 web="WebServices" 3 service="HRService" 4 port="EmpInterfacePort"> 5 <runtime enabled="security,auditing"> 6 <security> 7 <inbound> 8 <verify-username-token password-type="DIGEST" 9 require-nonce="false" 10 require-created="false"/> 11 <verify-signature/> 12 <decrypt/> 13 </inbound> 14 </security> 15 <reliability> 16 <ack-interval value="6"/> 17 <order-interval value="6"/> 18 <cleanup-interval value="60"/> 19 <ack-limit value="60"/> 20 <max-age value="60"/> 21 <repository type="jdbc" jndiLocation="jdbc/SCOTTCoreDS"/> 22 </reliability> 23 </runtime> 24 <operations> 25 <operation name="getEmpSalary"> 26 <runtime> 27 <auditing request="true" response="false" fault="true"/> 28 </runtime> 29 </operation> 30 </operations> 31 </port>

Прежде всего, заметим на строке 5, что политики могут быть включены (enabled) или выключены (disabled). В этом примере политики безопасности и аудита включены, в тоже время политика надежности, заданная в строках 15-22 отключена только тем, что она не упомянута как атрибут, включенный для этапа выполнения.

Далее, в строках 6-14 устанавливается политика безопасности для всех операций порта EmpInterfacePort сервиса HRService — политика, которая требует, чтобы для каждой операции был заданы provided with a username and password authentication token.

И наконец, в строках 26-28 приведен пример политики на уровне операции для аудита, showing that requests and faults are audited on the getEmpSalary operation but responses are not. Политики безопасности также могут установлены на уровне операции.

Понимание "движущихся частей"

Чтобы понять как использовать эти возможности, я прежде всего должен дать обзор "движущихся частей" (moving parts) в среде управления Release 10.1.3. Рисунок 2 показывает три основных компонента этого продукта, которые и составляют решение: компонент этапа проектирования (the design time) с Oracle JDeveloper, компонент этапа выполнения (the runtime) с Release 10.1.3 и среда управления с Oracle Application Server Control.

Рисунок 2: Конфигурирование управления в перспективе

Обратите внимание, что на этом рисунке между консолями компонент этапов проектирования и выполнения находится файл wsmgmt.xml. Это файл конфигурирования политик к Web-сервисам (Web services policy configuration file) для Oracle Application Server, позволяющий администраторам-пользователям Application Server Control устанавливать политики аудита, журнализации, надежности и безопасности.

Способ, характерный для разработчика, конфигурирования этого файла политик заключается в декларировании политик управления в файле oracle-webservices .xml. Этот файл oracle-webservices.xml является специфичным для сервера приложений соединением (binding) к инфраструктуре Oracle. Этот файл дополняется стандартным для JAX-RPC файлом webservices.xml, который определяет платформно-независимое поведение Web-сервисов.

Изучение рисунка 2 слева направо показывает, как разработчик должен использовать такой инструмент, как Oracle Jdeveloper или его аналог с интерфейсом типа командная строка Web Services Assembler, чтобы сформировать (to package up) файл типа архив предприятия (enterprise archive (EAR), содержащий политики из oracle-webservices.xml. Затем, после развертывания в инфраструктуре Oracle Application Server 10g Release 10.1.3, эти политики будут автоматически зарегистрированы в файле политик этапа выполнения wsmgmt.xml.

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

Разделение проблем

Из вышеприведенного рассмотрения ясно, что подход к управлению Web-сервисами с применением средств Oracle Application Server вышел за рамки программистского подхода к более административному, декларативному, на основе политик подходу.

Это не означает, что в данном случае навыки программирования разработчику не нужны, они необходимы для разработки "крюков" (hooks) для обработчиков стандарта JAX-RPC. Но подход на основе политик обеспечивает логическое и физическое разделение проблем для тех организаций, которые хотят воспользоваться его преимуществами. Он дает возможность разработчикам сфокусироваться на построении бизнес-функциональности Web-сервисов и администраторам на определении операционной политики к Web-сервисам.

Мы рассмотрим подробно эти новые возможности управления Web-сервисами в следующих нескольких статьях и научимся определять, где такое разделение очевидно и где находятся естественные точки соприкосновения. Чтобы на практике оценить сказанное в этой статье, скачайте Oracle Application Server 10g Release 10.1.3 Developer Preview из сети OTN, установите пример Web-сервиса "Кадры" с интерфейсом JAX-RPC, и затем проверьте новые возможности управления Web-сервисами в Oracle Application Server Control.

Скачать

Oracle Application Server 10g Release 10.1.3 JAX-RPC Java Web service

Управление Web-сервисами уже здесь! (Web Services Management Arrives)

(Mike Lehmann), главный менеджер корпорации Oracle по продукту Oracle Application Server Containers for J2EE.

Источник: журнал "Oracle magazine", no.6, 2004,

http://www.oracle.com/technology/oramag/oracle/04-nov/o64dev_web.html

Перевод:

Возможности управления Web-сервисами

Основные возможности управления Web-сервисами, которые можно конфигурировать в Oracle Application Server 10g Release 10.1.3, таковы:

Аудит (Auditing) — ведение полного и согласованного фиксирования SOAP-запросов и ошибочных ситуаций

Журнализация (Logging) — обеспечение создания журналов на базе контента с применением Xpath, чтобы запрашивать входящие (inbound) и выходящие (outbound) SOAP-сообщения.

Надежность (Reliability) — конфигурирование надежной доставки сообщений, обеспечение последовательного порядка прохождения сообщений (message ordering) и недопущения дупликатов сообщений в соответствии со стандартом WS-Reliability.

Безопасность (Security) — конфигурирование аутентификации, целостности благодаря использованию цифровых подписей и конфиденциальности благодаря шифрованию в соответствии со стандартом WS-Security.

Основные возможности управления жизненным циклом (Basic lifecycle management) — включение (enabling) и отключение (disabling) сервисов и их возможностей управления.

Развертывание (Deployment) — конфигурирование стандартных и переносимых планов развертывания для Web-сервисов в соответствии со стандартами J2EE 1.4.

Они дополняются средой мониторинга для действий, связанных с Web-сервисами: запросов (requests), ответов (responses) и сообщений об ошибочных ситуациях (faults).

Эти возможности полностью конфигурируемы в среде управления Oracle Application Server Control. Разработчики смогут также декларативно сконфигурировать их до размещения в Oracle JDeveloper. Рисунок 1 показывает административную, входную страницу управления Web-сервисами в среде Oracle Application Server Control. Эта среда (Application Server Control) в Oracle Application Server 10g Release 10.1.3 может быть типовым образом вызвана заданием URL http:// :1810/ascontrol.

()

Рис. 1: Конфигурирование управления Web-сервисами в Oracle Application Server Control

Использование преимуществ SOAP

Если вы полагаете, что термин Web services определяется не строго, поищите четкое определение термину управление Web-сервисами (Web services management). Некоторые думают, что он просто означает конфигурирование, мониторинг, аудит и журнализацию Web-сервисов (Web service configuration, monitoring, auditing, and logging). Другие определяют его более абстрактно, используя такие термины, как визуализация, уведомление, взаимодействие с протоколами и предоставление сервисов (service virtualization, notifications, protocol mediation, and provisioning).

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

Особенности SOAP

Хотя управление Web-сервисом, как компонентом, необходимо предлолагает начало деятельности Web-сервиса, необходимо подчеркнуть тот ключевой аспект, который отличает большинство Web-сервисов от протоколов передачи двоичных данных в моделях программирования таких, как CORBA и DCOM: Web-сервисы – это технология работы с сообщениями, в которой и передача сообщений основана на XML (Simple Object Access Protocol [SOAP]), и они сами описываются на XML (Web Services Description Language [WSDL]).

В моей предыдущей статье я объяснил, как написать хендлер JAX-RPC для аудита и журнализации контента на основе SOAP. Сила такого подхода заключается в возможности манипулировать, перехватить и запросить “сырое” XML-сообщение по дороге к его пункту назначения.

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

Если вы отступите дальше и представите работу с Web-сервисами в разнородной среде, а это, скорей всего, наиболее типичное использование Web-сервисов, поскольку они по сути – технология интеграции, то применение хендлеров становится еще более проблематичным, так как они привязаны к JAX-RPC и не работают, если конечная точка (endpoint) вашего Web-сервиса реализована на C, Visual BASIC или Perl.

Таблица 1: Пример того, как может измениться входное сообщение

Тело оригинального входящего SOAP-сообщения	SOAP-сообщение с новым параметром
... <env:Body> <ns0:getEmpSalaryElement> <String_1>7369</String_1> </ns0:getEmpSalaryElement> </env:Body> ...	... <env:Body> <ns0:getEmpSalaryElement> <String_1>7369</String_1> <salary_type>Commission</salary_type> </ns0:getEmpSalaryElement> </env:Body> ...

Стандарты, стандарты, стандарты

Уже реализуется скоординированное движение к обеспечению управлению Web-сервисами как ресурсом. Стандарт, к которому стремятся большинство поставщиков, - это Web Services for Distributed Management (WSDM), разрабатываемый OASIS, который сделает для Web-сервисов то, что Java Management Extensions (JMX) сделали для приложений среды J2EE: предоставить независимый от поставщиков и реализаций способ для трактовки разнородных Web-сервисов как управляемых ресурсов (manageable resources).

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

Технический комитет OASIS по WSDM начал свою работу над таким стандартом в феврале 2003 года продолжает работать над версией 1.0 стандарта, которая должна завершиться в середине 2004 года.

И будьте уверены, в каждой большой версии Oracle Application Server управлению Web-сервисами будет уделяться все нарастающее внимание.

Следующие шаги:

СКАЧАЙТЕ

Посмотрите к этой статье

Прочитайте об

Управление компонентами Web-сервисов

На самом нижнем уровне Web-сервис – это просто еще одна программа, выполняющаяся в недрах вашей вычислительной инфраструктуры. С точки зрения управления, существует некоторое множество основных (ключевых) функций, которые применяются для управления Web-сервисами. В их числе - развертывание, конфигурирование и обеспечение безопасности (deployment, configuration, and security support), они комбинируюттся с некоторыми основными возможностями мониторинга и диагностики.

Эти ключевые функции реализованы в Oracle Application Server Control, консоли управления сервера приложений Oracle Application Server 10g, как показано на . Используя эту консоль, с которой можно работать через Web-браузер, вы можете легко управлять любым Web-сервисом в среде Java (J2EE Web service).

По мере перехода отрасли на платформу J2EE 1.4, эта консоль будет развиваться, чтобы обеспечить разработчиков средствами конфигурирования и мониторинга всех новых артефактов стандарта JAX-RPC, включая конфигурирование согласно спецификации JSR 109 (JSR 109 configuration), хендлеры JAX-RPC и затем обеспечение надежности, транзакций и безопасности Web-сервисов (Web services reliability, transactions, and security). Эта интегрированная консоль управления имеет особое значение в стандартизации JAX-RPC как части J2EE—инфраструктуры управления, которую ваш J2EE-сервер предлагает, чтобы в равной степени использоваться как с Web-сервисами, так и с классическими J2EE-компонентами.

В версии Oracle Application Server Containers for J2EE 10g (OC4J) Developer Preview 10.0.3, когда я создавал примеры JAX-RPC (см. врезку “Следующие шаги”), инфраструктура управления, лежащая в основе Application Server Control, была расширена для включения Java Management Extensions (JMX). В данном случае эти ранее реализованные возможности по-прежнему доступны, но новая консоль управления будет предоставлять возможности конфигурирования и мониторинга Web-сервисами через стандартные модули (beans - “бобы”) JMX MBeans. Чтобы взглянуть на эти “бобы” (Web service Mbeans) через JMX-браузер прямо, перейдите на страницу http://127.0.0.1:8888/adminoc4j вашей OC4J 10.0.3 Developer Preview и запросите Web service MBeans.

Управляя сообщением

Более общий подход заключается в том, что ввести “посредника” между потребителем сервиса и и его провайдером. Перехват сообщения на уровне трафика для его обработки - не новая идея. Она уже используется в Web-мире на уровне как оборудования, так и софтвера для балансирования загрузки, ускорения, маршрутизации и кеширования (load balancing, acceleration, routing, and caching).

Как только вы поймете, что вы можете не только инспектировать и манипулировать контентом SOAP-сообщения, но и применяя WSDL, получить полное представление о формате этого сообщения, его операторов и конечных точек, возможности этого подхода становятся весьма интересными.

Например, рассмотрим простой случай использования сервиса с таблицей Employee salary из моей предыдущей статьи. Этот сервис на основе номера служащего (employee number) возвращает соответствующую информацию о зарплате. Представьте, что после нескольких месяцев применения, этот сервис начинает использоваться несколькими крупными подразделениями в компании, и многие люди просят, чтобы сервис предоставлял и информацию о комиссионных. Разработчики решают просить пользователей этого сервиса изменить входящее сообщение, которое ранее содержало только номер служащего, чтобы оно включало дополнительный параметр, <salary_type> (тип зарплаты), отмечая что именно: зарплата (salary), комиссионные или они оба должны быть возвращены. Таблица 1 показывает разницу между двумя этими форматами.

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

Решение? Есть немало возможностей на уровне управления, с которыми можно “понять” передаваемое сообщение. Одна из них заключается в том, чтобы “ловить” передаваемые сообщения со старой подписью и маршрутизировать их к старой реализации (old implementation) — простое решение на основе версий.
Другой подход заключается в том, чтобы преобразовать сообщения старого формата (old-style messages) без параметра <salary_type> в новый формат с включением значения по умолчанию для этого параметра. Такой тип абстракции реализации называется виртуализацией сервиса (service virtualization).

Результат этого подхода – провайдер сервиса может выполнять модернизацию по расписанию, независимому от потребителей сервиса. Еще лучше то, что процесс управления происходит на “лету” независимо от реализации, можно проводить модернизацию, даже если ваша внутренняя (back-end) среда состоит из разнородных реализаций Web-сервисов. Соответственно, потребители сервисов могут выбирать модернизацию или воспользоваться преимуществом новых функций по своему собственному расписанию.

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

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

Управляя Web-сервисами (Managing Web Services)

(Mike Lehmann), главный менеджер корпорации Oracle по продукту Oracle Application Server Containers for J2EE.

Источник: Oracle Magazine, no.3, 2004,

http://www.oracle.com/technology/oramag/oracle/04-may/o34dev_web.html

Перевод:

---

---