"Телеком. Коммуникации и сети" 4/2008, с.56 (начало статьи в Телекоме 3/2008)

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

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

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

— интерфейс функциональных модулей таков, что их использование не зависит от технологии или платформы, в рамках которой они реализованы;

— возможен динамический поиск и подключение нужных модулей;

— архитектура базируется на общепринятых отраслевых стандартах.

Собственно SOA

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

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

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

— более быстрого и гибкого изменения бизнес-процессов;

— снижения OPEX на ИТ;

— безопасного и надежного сервиса;

— оперативного внедрения обновлений и дополнительных возможностей программных продуктов;

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

Понятие ориентированной на сервисы архитектуры сложилось в ходе развития концепции веб-сервисов. Однако существуют и другие подходы к реализации SOA: Java RMI (Sun), CORBA (OMG), DCOM (Microsoft), DCE (Open Group) и др.

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

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

— удаленный вызов процедуры (Remote Procedure Call, RPC);

— асинхронный обмен;

— однонаправленную передачу;

— широковещание;

— публикацию/подписку.

Разработчики ПО обычно предоставляют возможность привязки веб-сервисов к своим программным системам (СУБД, серверам приложений и брокерам интеграции). Для клиента взаимодействие с веб-сервисами может проявляться в интерактивной или пакетной форме, поддерживающей синхронную и асинхронную модели связи, а также как пользовательский интерфейс, написанный с применением Java, VB, офисных приложений или «толстых» клиентов СУБД.

Способы реализации

Веб-сервисы реализуются с помощью веб-ориентированных языков. Многие производители ПО уже приступили к созданию ключевых спецификаций. В данных работах можно выделить несколько альтернативных направлений, связанных с такими компаниями, как Microsoft (.NET), Sun (Java) и IBM (WebSphere). Все эти варианты являются совместимыми, по крайней мере в отношении реализации одинаковых спецификаций и интерпретации их подобным образом.

Microsoft поддерживает разработки с использованием инициативы .NET, в то время как Sun — Java 2 Platform Enterprise Edition (J2EE). Будучи основателем Java-направления, Sun опубликовала разработку Open Network Environment architecture (SunONE) как примерный план дальнейшей эволюции веб-сервисов. Microsoft, в свою очередь, определила архитектуру Global XML Architecture (GXA), обеспечивающую поддержку расширения веб-сервисов на основе .NET и за счет стандартизации. Для построения SOA IBM предлагает WebSphere Integration Developer, а дополнением к нему служат усовершенствованные средства Rational и Tivoli.

Сегодня, когда основные технологии получили широкое признание, следующим шагом является определение расширенной архитектуры для реализации дополнительных технологий (безопасность, поток процесса, надежная доставка сообщений, координация транзакций). Этим занимается рабочая группа консорциума W3C — Web Services Architecture Working Group.

Поскольку веб-сервисы решают проблему интеграции в масштабе предприятия, то производители брокеров интеграции (integration broker) используют веб-сервисы в качестве структурных блоков посредников (adapters) и компонентов интеграции (integration component). Проектировщики БД реализуют доступ интерфейсов веб-сервисов непосредственно к СУБД. Разработчики ERP и CRM в целях интеграции с другим ПО также поддерживают веб-сервисы. И, наконец, целый ряд производителей нацелен на реализацию непосредственно уровня веб-сервисов.

Компоновка веб-сервисов

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

Функциональные возможности каждого веб-сервиса определяются его входами, выходами, предварительными условиями и действиями, которые обозначают как IOPEs (inputs, outputs, preconditions, and effects). IOPE сервиса содержится в его WSDL-описании.

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

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

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

Стандарты хореографии и оркестровки опираются на WSDL. На уровне модели бизнес-процесса предложены такие проекты стандартов, как Wf-XML (Workflow Management Coalition), WSFL (IBM Web Services Flow Language), XLANG (Microsoft’s XLANG: Business modeling language for BizTalk), PIPs (RosettaNet’s Partner Interface Process). Наиболее распространены BPEL4WS (Business Process Execution Language for Web Services) от IBM, Microsoft, BEA Systems и отражающий концепцию хореографии WSCI (Web Service Choreography Interface), подготовленный компанией Sun. BPEL4WS предназначен для реализации оркестровки сервисов.

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

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

— Последовательность процессов. При пользовании веб-сервисом можно вызывать операции в любой последовательности. Так, клиент может обратиться к операции «перевод денег» до вызова операции «размещение заказа».

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

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

— Обработка исключений. К примеру, если клиент не подтверждает заказ на покупку или продажу в течение минуты, веб-сервис генерирует исключение о превышении времени ожидания.

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

Большинство составных сервисов формируются вручную, используя основанные на WSDL описания. Для автоматической компоновки программы должны уметь отбирать нужные веб-сервисы и комбинировать их. При этом результат должен являться приемлемым решением поставленной задачи. Информация, содержащаяся в UDDI (Universal Description, Discovery, and Integration), недостаточна для автоматической компоновки сервисов, так как не позволяет интерпретировать их семантику. Ни WSDL, ни UDDI не дают программе понять, для чего именно с точки зрения клиента служит сервис. Поэтому так важны механизмы отображения семантики сервисов и ее автоматизированного сопоставления с семантикой запросов клиентов. Проблемы компоновки можно решить, связав параметры сервисов с понятиями определенной предметной области и их семантическим обоснованием.

Интеллектуальные веб-сервисы

Цель проекта Semantic Web консорциума W3C — трансформация WWW в глобальную базу знаний. Подход Semantic Web к сервисам заключается в описании их возможностей и содержимого на однозначно интерпретируемом, поддающемся компьютерной обработке языке. Сервисы Semantic Web также должны обеспечивать автоматизацию ряда задач, ранее выполнявшихся вручную, обеспечивая автоматическую композицию, взаимодействие, контроль выполнения, обновление и т. д. Интеллектуальные сервисы (называемые часто семантическими, SW-сервисами) расширяют понятие обычных веб-сервисов. Хотя программы могут найти некий сервис в UDDI без помощи человека, она не в состоянии понять, как им пользоваться и для чего он предназначен. WSDL дает инструментарий описания, каким образом взаимодействовать с тем или иным веб-сервисом, тогда как семантическая разметка предоставляет  информацию о том, что и как делает данный сервис.

Распространенным средством представления семантики сервисов являются онтологии — целостные структуры понятий определенной предметной области (ПрО) в рамках единой системы взаимосвязанных компонентов. Это формализованное описание терминов, их определений и атрибутов, а также того, как они связаны друг с другом.

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

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

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

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

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

Сегодня наиболее распространенными являются подходы, основанные на единой онтологии.

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

Минусы веб-сервисов

Но за великий потенциал веб-сервисов приходится платить свою цену:

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

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

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

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

Анатолий Гладун, Международный научно-учебный центр информационных технологий и систем НАНУ и МОНУ, [email protected]

Robo User
Web-droid editor

      

Читайте також