АРИС Текст 2. Водяхо А. И., Выговский Л. С., Дубенецкий В. А., Цехановский В. В. Архитектурные решения информационных систем
 Скачать 4.65 Mb.
|
|
[Уникальный идентификатор]”> описания .. URLType=”http”>http://www... Descriptions, .. Описания, URL, .. ... ... ... Для работы с реестром UDDI пользователю предоставляется API. Функции, входящие в состав UDDI API, модно разделить на четыре группы: функции, позволяющие регистрировать и изменять описания сервисов в UDDI реестре, которые называют save_xxx функции; функции для получения информации о сервисах, которые называют get_xxx функции; функции для поиска сервисов, которые называют find_xxx функции; функции для удаления сервисов, которые называют delete_xxx функции; Под символами "ххх" имеется в виду тип объекта ("business", "service", "binding", "tModel"). С точки зрения пользователя, UDDI реестр – это Web-сервис, для обращения к которому ему следует направить SOAP послание, поэтому пользовательский интерфейс можно определить и в терминах SOAP посланий, которые можно направлять на вход реестра. Для работы с UDDI реестром существует много библиотек классов и отдельных функций, написанных на различных языках. В среде Java программистов часто используется пакет классов UDDI4J (UDDI for Java), разработанный фирмой IBM, который доступен на сайте http://sourceforge.net/projects/uddi4j/. (На момент написания книги последней версией была версия 2.0.5 от 2006 года.) В данном пакете все обращения к реестру UDDI идут через класс-посредник UDDIProxy, который преобразует все обращения в функции UDDI API. Методы этого класса называются так же, как и функции UDDI API: save_business (), find_service () и т.п. Они возвращают объекты классов, которые представляют собой SOAP-структуры [146, 147]. Бизнес-реестр ebXML. Электронный реестр для поддержки систем электронного бизнеса (ebXML) была разработана центром международной торговли и электронного бизнеса ООН (http://www.uncefact.org/) и (http://www.oasis-open.org/). Информация о ebXML доступна на сайте http://www.ebxml.org/. Основной целью разработки ebXML было создание протокола, описывающего взаимодействия партнеров, реализующих взаимодействие по типу Business to Business (В2В). В ebXML организации, осуществляющие взаимодействие, называются сторонами (parties). Стороны реализуют деловое сотрудничество (Business Collaboration). В реестре ebXML хранится информация о каждой стороне и их сотрудничестве. Информация о сотрудничестве описывается в терминах заявлений о сотрудничестве СРР (Collaboration Protocol Profile) и соглашений о сотрудничестве СРА (Collaboration Protocol Agreement). Соглашение о сотрудничестве – это также XML документ, в котором находятся технические сведения о соглашениях двух сторон, которые собираются из заявлений о сотрудничестве или составляются стороной, заинтересованной в получении услуг. Заявление о сотрудничестве формируются в процессе переговоров, в процессе которых стороны обмениваются сообщениями. Соглашение достигается следующим образом: 1. Сторона, оказывающая услуги, составляет заявления о сотрудничестве и регистрирует его в реестре ebXML. 2. Сторона, заинтересованная в получении услуги, находит в реестре подходящее заявление о сотрудничестве. 3. Сторона, которая хочет получить услуги, создает собственное заявление, затем на основании обоих заявлений составляет проект соглашения и посылает его стороне, оказывающей услуги. 4. Стороны достигают соглашения, обмениваясь сообщениями. После достижения соглашения стороны хранят копии соглашения СРА на своих серверах и/или в реестре. При обмене сообщениями может использоваться электронная подпись. Более подробную информацию можно найти в [152], а также на официальном сайте ebXML (http://www.ebxml.org/). Язык WS Inspection для поиска Web-сервисов. Одним из самых старых и простых реестров является система WS-Inspection, которая была разработана фирмами Microsoft и IBM в 2001 году. Основной целью создания данного средства было предельное упрощение процедуры поиска сервиса. В отличии от UDDI и ebXML, которые решают задачи не только поиска, но также описания и изменения записей WS-lnspection позволяет только найти требуемый вервис в пределах конкретного сервера. Если UDDI и ebXML – это распределенные базы данных, то для работы WS-lnspection требуется только один XML файл и поддержка сервера приложений. В рамках WS-Inspection задача поиска решается следующим образом. Web сервисы описываются на языке WS-lnspection Language (WSIL) и помещается в файл с расширением .wsil, который представляет собой XML файл. Данный файл помешается в определенный каталог сервера приложений. Получив запрос, сервер приложений просматривает все wsil файлы и находит описание требуемого сервиса. Файл wsil для словаря синонимов будет иметь следующую очень простую структуру. xmlns="http://schemas.xmlsoap.org/ws/2001/10/inspection/"> referencedNamespace="http://schemas.xmlsoap.org/wsdl/" location="http://www.myvocab.ru/wsdl/Thesaurus.wsdl"/> Корневым элементом wsil является элемент Спецификации WS-*. Помимо основных спецификаций и стандартов, таких как SOAP WSDL и UDDI существует ряд спецификаций, предназначенных для расширения концепции Web-сервисов на основе SOAP и WSDL с целью обеспечения надежности, безопасности, поддержки состояния и качества обслуживания. Указанные спецификации, название большинства из которых начинается с префикса WS-, основываются на технологиях W3C, и ориентированы преимущественно на использования в рамках КИС. Они ориентированы на решение частных задач в рамках КИС, таких как поддержка работы с транзакциями, маршрутизации, безопасность и работу с состояниями. Большинство транспортных протоколов Интернет не поддерживают работу с состоянием и являются ненадежными, и их использование для реализации транзакции вызывает проблемы. Это приводит к тому, что если разработчик хочет реализовать транзакции в рамках бизнес-процессов, которые будут рассмотрены далее, то ему придется реализовывать механизмы работы с транзакциями внутри приложения. Вызовы сервисов, которые осуществляются через асинхронный обмен сообщениями, должны обладать возможностью пакетного выполнения в качестве единой атомарной единицы, чтобы при сбое хотя бы одного вызова выполнять откат всех вызовов как единого целого [23]. Спецификации WS-Coordination и WS-Transaction решают описанную проблему для Web-сервисов. Спецификация WS-Coordination определяет способ создания и распространения информации о контексте всеми службами, участвующими в продвижении потока сообщений в асинхронном режиме или при наличии сбоев синхронизации. WS-Transaction определяет способ мониторинга и измерения успешности или неуспешности отдельного каждого действия в потоке действий. Когда сообщение SOAP прибывает в конечную точку, из него из него извлекается заголовок и передается для анализа координатору транзакций. В рамках спецификации WS-Transaction определяются два типа координации: атомарная транзакция (atomic transaction — AT) я бизнес-активность (business activity — ВА). Первая применяется для осуществления операций с относительно коротким временем жизни, в которых допускаются блокирование ресурсов таких как нити, элементы данных и т.п. Бизнес-активность представляет собой "долгоживущий" процесс, который может состоять из нескольких атомарных транзакций. Глобальный откат такой большой транзакции в случае возникновения единственного сбоя обычно нежелателен. Гораздо лучше, если сбой одной атомарной транзакции в рамках бизнес-активности будет инициировать запуск другого набора вызовов сервисов и отправку других сообщений. Отправка сообщений может представлять собой некоторый механизм, позволяющий устранить последствия ошибки таким образом, чтобы сохранить часть истории выполнения бизнес-активности. Спецификация WS-Reliability определяет механизм обмена сообщениями в асинхронном режиме, с гарантированной доставкой, без дубликатов и с упорядочиванием сообщений. Для реализации данного механизма к заголовкам SOAP посланий добавляются элементы MessageHeader, ReliableMessage, MessageOrder и RMResponse, которые содержат идентификаторы сообщений такие, как порядковый номер сообщения в последовательности сообщений и идентификатор группы, метку времени, время жизни, тип сообщения, сведения об отправителе и получателе, а также информацию о подтверждении получения. Получатель послания либо подтверждает его получение, либо отправить сообщение об ошибке, используя элемент RMResponse заголовка SOAP. Если отправитель исходного сообщения не получит подтверждение, он еще раз отправит то же самое сообщение с тем же идентификатором, что и у исходного сообщения. Отправитель обязан хранить исходное сообщение, пока у того не истечет время жизни, либо пока не будет получено подтверждение получения или же пока получатель не сообщит об ошибке. Получатель также обязан хранить сообщение, пока оно не будет надежно передано логике приложения. Чтобы гарантировать доставку сообщений по принципу "один и только один раз", в спецификации WS-Reliability предусмотрен механизм хранения порядкового номера сообщения в последовательности сообщений. Сообщения SOAP, сгруппированные в последовательность, могут иметь общий идентификатор группы, однако в заголовке каждого из них будет указан собственный порядковый номер. Это поможет получателю расположить сообщения в правильном порядке, прежде чем передавать их приложению. В спецификации WS-ReliableMessaging описывается аналогичный протокол, предназначенный для надежной доставки сообщений между распределенными приложениями при наличии сбоев. Его описание не основывается на какой-либо конкретной технологии, а значит, данный протокол может быть реализован с использованием целого ряда сетевых транспортных технологий и привязок. Спецификация WS-ReliableMessaging опирается на те же принципы, что и WS-Reliability. В ней тоже используются подтверждения, обратные вызовы, идентификаторы и постоянные хранилища сообщений, а также предполагается выдача подробных сообщений об ошибках. Кроме того, она обеспечивает доставку сообщений в соответствии с одной из четырех базовых схем доставки: не более чем один раз; как минимум один раз; один и только один раз; в том же порядке, в котором были отправлены сообщения. Ключевым различием между конкурирующими спецификациями надежности является тот факт, что WS-ReliableMessaging опирается на другие важные спецификации Web-служб, такие как WS-Security и WS-Addressing. Спецификация WS-Conversation описывает протокол, предназначенный для управления асинхронным обменом сообщениями с поддержкой состояния между отправителем и получателем. WS-Security является своеобразным мостом между SOAP и существующими технологиями безопасности и включает в себя описание универсальных, расширяемых средств сопоставления маркеров безопасности с сообщениями SOAP и передачи этих маркеров конечным точкам SOAP. Она позволяет работать с двоичными маркерами безопасности, такими как цифровые сертификаты и билеты Kerberos. Данная спецификация определяет универсальный набор механизмов, позволяющих реализовать различные протоколы безопасности и внедрить в схему защиты любое число доменов доверительных отношений, форматов цифровых подписей и технологий шифрования. Помимо проверки подлинности отправителя, WS-Security может обеспечивать целостность сообщения, посредством использования разработанных консорциумом W3C стандартов XML Signature и XML Encryption. В модели безопасности, описанной в WS-Security, предполагается, что отправитель сообщения SOAP передает вместе с сообщением ряд сведений о себе: идентификатор отправителя, группу, привилегии и т.п. Все эти сведения группируются в так называемый подписанный маркер безопасности. Получатель сообщения должен подтвердить эти сведения. Маркеры и подписи передаются внутри заголовка SOAP, а точнее — с помощью элемента security пространства имен WS-Security. Из всех спецификаций WS-* эта получила, наибольшую поддержку среди главных производителей платформ для Web-служб. Существуют и другие спецификации WS-*, такие как WS-Addressing, WS-Policy. WS-Addressing, определяющая XML-элементы, с помощью которых в сообщении идентифицируются конечные точки Web-служб и является стандартным способом задания, кем было отправлено сообщение ("От:") и кому оно предназначается ("Кому:"), что облегчает решение задачи рассылки посланий на списка получателей. Спецификация WS-Policy, определяет синтаксис описания политик Web-сервиса. Политики описывают требования к службе, предпочтения, возможности и желаемое качество обслуживания. Сопутствующая спецификация Web Services Policy Assertions Language (WS-PolicyAssertions) позволяет проверить, поддерживает ли конечная точка сервиса или сообщения конкретную политику. Процесс проверки включает в себя анализ объявлений WS-Policy на предмет конкретной требуемой политики. Следует отметить, что перечисленные выше стандарты поддерживаются далеко не всеми производителями инструментальных средств для работы с Web-сервисами. 11.5. Язык описания бизнес-процессов BPEL Web-сервисы представляют собой интерфейсы для доступа к автономным, модульным приложения. Для того чтобы обратиться к Web-сервису необходимо послать SOAP послание по определенному адресу, которое представляет собой XML документ, при этом не имеет значения каким именно образом формируются эти послания. BPEL (Business Process Execution Language) – это язык, который позволяет описывать бизнес-процесс в терминах некоторой последовательности обращения к Web-сервисам. BPEL, по существу, является скриптовым языком программирования, который поддерживает синхронные и асинхронные взаимодействия, параллельное выполнение и обработку исключений. Программа (приложение), написанное на языке BPEL, является XML документом. Язык BPEL позволяет задавать бизнес-процессы, при этом приложение, написанное на языке BPEL, можно рассматривать как Web-сервис, и к нему можно обращаться посредством посылки SOAP посланий. BPEL является интерпретируемым языком и для его использования необходимо наличие процессора (движка). Основу BPEL составляют три ключевые свойства: асинхронность, координация потоков и управление исключительными ситуациями. Асинхронность имеет дело с асинхронными взаимодействиями, корреляцией сообщений и надежностью. За счет разделения запросов на обслуживание и соответствующих им откликов асинхронность повышает масштабируемость и помогает избежать узких мест при выполнении приложения. Кроме того, она допускает непрерываемое выполнение, когда сервисы временно недоступны и когда клиенты работают в автономном режиме или отключены. Координация потоков включает параллельные потоки выполнения, образцы соединений и динамические потоки. В реальных приложениях бизнес-потоки могут включать образцы сложных взаимодействий как с синхронными, так и с асинхронными сервисами. Координация потока включает интерфейс с WSDL, действия потока, переменные XML и отвечает за координацию. BPEL использует WSDL для обращения к сообщениям, вызванным операциям и типам портов. Действия с потоком используют общие переменные XML, так что компенсационные обработчики (compensationhandlers) должны сохранять снимки данных, которые могут быть использованы обработчиком. Компенсационные обработчики могут отменить шаги, которые были уже завершены. Управление исключительными ситуациями. Управление исключительными ситуациями имеет дело с синхронными ошибками, асинхронным управлением исключительными ситуациями и компенсацией бизнес-транзакций. Для того чтобы автоматизировать бизнес-процессы, большие усилия сосредоточены на управлении исключительными ситуациями, и BPEL упрощает управление исключительными ситуациями для Web-сервисов. При возникновении исключительных ситуаций вызываются локальные обработчики ошибки, связанные с Web-сервисами, и асинхронные сервисы уведомляются об этих исключительных ситуациях. BPEL был разработан на базе двух более ранних языков описания бизнес-процессов WSFL и Xlang фирмы IBM и Microsoft соответственно. Первый стандарт BPEL (BPEL4WS) сразу в версиях 1.0 и 1.1 появился в 2003 г. На момент написания данной книги последней была версия WS-BPEL 2.0, которая появилась в апреле 2007 года и доступна на сайте http://docs.oasis-open.org/wsbpel/2.0/. В июне 2007 г. были опубликованы спецификации BPEL4People и WS-HumanTask, где описывались возможности реализации в BPEL взаимодействия с людьми. Последние версии этих документов можно найти по адресу http://docs.oasis-open.org/. Оркестровка и хореография Web-сервисов. Принято выделять два основных подхода к объединению Web-сервисов в бизнес-процессы: - оркестровка (Orchestration); - хореография (Choreography). Идея оркестровки состоит в том, что в системе имеется единственный BPEL-процессор (движок), который выполняет функции интерпретатора BPEL-файлов. Для внешнего мира BPEL-процессор доступен как Web-сервис. Получив запрос, движок уже от своего имени рассылает SOAP послания Web-сервисам, участие которых необходимо для реализации бизнес-процесса. Задействованные Web-сервисы не знают, что они вовлечены в бизнес-процесс более высокого уровня. Только движок обладает полной информацией о выполняемой задаче, и поэтому оркестровка является централизованным механизмом с явным определением операций и порядком инициирования работы Web-сервисов (рис. 11.3).  Рис. 11.3. Схема оркестровки  Рис. 11.4. Схема хореографии Использование хореографии (рис. 11.4), напротив, не предполагает использование центрального координатора. Каждому из Web-сервисов, участвуюших в хореографии, известно, когда следует выполнить те или иные операции и с какими Web-сервисами необходимо взаимодействовать. Хореография представляет собой совместное действие, ориентированное на обмен сообщениями при реализации бизнес-процессов, в которых участвует несколько организаций, при этом все участники должны знать бизнес-процесс, выполняемые операции, сообщения, которыми они обмениваются, и синхронизировать эти обмены сообщениями. На первый взгляд, кажется, что оркестровка и хореография представляют собой альтернативные подходы к организации бизнес процессов, однако, если предположить, что за Web-сервисами, участвующими в оркестровке, стоят отдельные движки, то различия между оркестровкой и хореографией уже не столь очевидны. Обычно оркестровка используется для создания исполняемых BPEL-файлов, а хореография как средство для описания протоколов, описывающих взаимодействие, например, между организациями, при этом не предполагается использовать эти описания в качестве исполняемых файлов. BPEL поддерживает два различных способа описания бизнес-процессов, которые поддерживают оркестровку и хореографию. Исполняемые процессы (Executable processes) позволяют определять точную детализацию бизнес-процессов. Исполняемый процесс моделирует поведение участников определенного бизнес-взаимодействия, в сущности, моделируя частный поток работ. Исполняемые процессы находятся в парадигме оркестровки и могут быть выполнены механизмом оркестровки. Абстрактные бизнес-протоколы (Abstract business protocols) определяет обмен публичными сообщениями между участниками. Они не включают внутренние детали потока процессов, не являются выполнимыми и находятся в парадигме хореографии. BPEL. Общие сведения. BPEL – это алгоритмически полный язык, система типов которого соответствует языку XML; язык с выразительными управляющими конструкциями, поддержкой параллельного исполнения, обработкой исключений, поддержкой транзакций, взаимодействия процессов между собой и др. возможностями. BPEL предоставляет такие механизмы управления вычислительным процессом, такие как присваивание значений переменным, условные операторы, возможность организации циклов, работа с событиями и др. Описание процессов в BPEL. BPEL-процесс состоит из активностей (activities). Различают базовые (basic) и структурные (structured). Базовые активности не включают в себя другие активности и выполняют такие элементарные действия как прием сообщения от партнера или выполнения элементарных действий с данными. Структурированные активности включают в себя другие активности и обеспечивают реализацию бизнес логики. Важнейшими базовыми активностями являются активности, ориентированные на получение и отправку сообщений. Это активности типа invoke, receive и reply, которые определяют два способа взаимодействии: асинхронное и синхронное взаимодействия. Активность типа invoke предполагает одностороннее взаимодействие. Вызывающая сторона посылает сообщение и продолжает функционирование. Получение ответа не предусматривается. Синхронное взаимодействие реализуется с помощью пары активностей. Сервис реализует активность типа receive – находится в состоянии ожидания запроса. Получив запрос, сервер формирует ответ, посредством реализации активности reply . До получения ответа вызывающая сторона находится в состоянии ожидания, т.е. находится в заблокированном состоянии. Имеются и другие базовые активности, такие как активности, ориентированные на присвоение значений переменным (assign), остановка реализации сервиса (terminate), отсутствие действий (empty), также активность типа pick и Event Handler, ориентированные на поддержку работы с событиями. В рамках BPEL определен достаточно широкий набор структурированных активностей, основными из которых являются следующие: задание последовательности выполнения действий ( цикл ( выбор одного из нескольких альтернативных маршрутов ( параллельное выполнение ( обработка ошибок объединение нескольких действий ( и др. Управление исключительными ситуациями работает с синхронными ошибками, асинхронным управлением исключительными ситуациями и компенсацией бизнес-транзакций. При автоматизации бизнес-процессов значительное внимание уделяется управлению исключительными ситуациями, и BPEL упрощает управление исключительными ситуациями для Web-сервисов. При возникновении исключительных ситуаций вызываются локальные обработчики ошибок, связанные с Web-сервисами, и асинхронные сервисы получают соответствующие уведомления. Существуют специальные компенсационные обработчики (compensationhandlers), сохраняющие снимки данных, которые могут быть использованы обработчиком. Компенсационные обработчики могут отменить шаги, которые были уже завершены. Кроме обработки ошибок и таймаутов оркестрованные web-сервисы должны гарантировать доступность ресурсов при выполнении длительных распределенных транзакций. Традиционные транзакции обычно не вполне пригодны для реализации длительных распределенных бизнес-операций, поскольку не позволяют блокировать необходимые ресурсы на продолжительный срок. При использовании компенсирующих транзакций каждый метод включает в себя операцию отмены, которую координатор транзакций может вызвать в случае необходимости (под компенсирующей транзакцией понимают возможность отката операции при ее отмене процессом или потребителем). Структура BPEL-документа. В самом общем виде структура документа BPEL выглядит следующим образом: Определение партнерских связей --> Определение переменных --> BPEL бизнес-процесса --> Внутри контейнера, заключенного в теги - партнерские связи - описания переменных - описание последовательности обращений к web-сервисам В качестве примера рассмотрим простейший бизнес-процесс. Допустим, что сотруднику организации требуется оформить приобретение некоторого оборудования (картриджа для принтера, компьютера или автомата для приготовления кофе). Для того, чтобы приобрести оборудование сотрудник должен получить разрешение соответствующего менеджера. Затем просматривается возможность приобретения данного оборудования у разных поставщиков, в качестве которых выступают Компания А и Компания В. Информация о лучшем с точки зрения цены предложении возвращается сотруднику.  Рис. 11.5. Пример структуры бизнес процесса Структура данного бизнес процесса показана на рис. 11.5. Бизнес-процесс представляет собой сервис, реализующий асинхронный режим функционирования. Менеджер представлен синхронным сервисом, работающим по принципу запрос-ответ. Компания А и Компания В представлены асинхронными сервисами. Функционирование сервиса выглядит следующим образом. Когда сотруднику потребуется заказать оборудование, он запускает клиентское приложение, которое может быть, например, портлетом и вводит информацию о необходимом оборудовании и отсылает запрос. Клиентское приложение формирует асинхронный запрос к основному сервису, который назовем Сервисом Закупки (PurchaseService). После этого формируется синхронный запрос к сервису Менеджер (ManagerService) , который возвращает послание, в котором содержится разрешение на покупку оборудования. В качестве Менеджера может выступать либо приложение, которое может, например, обратиться к базе данных с проверкой наличия средств на счете подразделения, либо Менеджером может быть реальный человек. В последнем случае на портале менеджера появляется информация о том, что на его имя пришел запрос. В последнем случае Менеджер открывает соответствующий портлет и заполняет требуемые поля. Если Менеджер не дает разрешения, то вызывается активность типаterminate. После получения разрешения формируются запросы к серверам компаний, которые занимаются продажей требуемого оборудования. В рассматриваемом примере формируются два параллельных асинхронных запросов к сервисам компаний. После того как обе компании прислали свои цены на требуемое оборудование, выбирается минимальная цена и сообщается пользователю. Рассмотрим более подробно проектирование данного сервиса. Ниже будет рассмотрен процесс «ручного» проектирования BPEL-процесса, хотя на практике для этого используются инструментальные средства разработки. Разработка BPEL-процесса обычно включает в себя следующие этапы: определение web-сервисов, участвующих в разрабатываемом BPEL-процессе; разработка WSDL-описания BPEL-процесса; определение партнерских связей; декларирование переменных; разработки логики процесса. Определение партнерских связей ( |