лекция по бизнесс процессам. 12 лекция ИИС Бизнес-процессы. Лекция 12 Webсервисы композиция бизнеспроцессов
 Скачать 0.85 Mb.
|
|
ЛЕКЦИЯ 12 Web-сервисы -КОМПОЗИЦИЯ БИЗНЕС-ПРОЦЕССОВ Web-сервисы являются быстро развивающимся и практическим подходом для интеграции широкого массива приложений потребителей, поставщиков и бизнес партнеров. В то время как многие компании начали развертывать свои индивидуальные Web-сервисы, организации получат настоящую выгоду, когда сумеют соединить свои сервисы вместе. Именно технология Web-сервисов является двигателем прогресса в современном Интернет. На рисунке 1 представлена тенденции развития сети Интернет и динамика вовле- чения технологий в данном процессе. Рисунок 1. Тенденции развития сети Интернет С появлением Web-сервисов возникли термины «композиция Web-сервисов» (Web- services composition) и «поток Web-сервисов» (Web-services flow), используемые для описания потока работ, выполняемых с их помощью. Недавно им пришли на смену два более выразительных термина — оркестровка и хореография Web-сервисов. Под оркестровкой понимают то, как сервисы взаимодействуют друг с другом на уровне сообщений, включая бизнес-логику и кооперацию при выполнении сложных процессов в пределах одного предприятия. Оркестровка основывается на открытых стандартах для создания бизнес-процессов, включая BPEL4WS, WSCI и BPML. Хореография в данном контексте охватывает более широкий круг участников взаимодействия, в том числе поставщиков, потребителей и партнеров предприятия.Хореография ассоциируется с публичным обменом сообщениями между множеством Web-сервисов, а не с одним бизнес-процессом, осуществляемым на одном предприятии. Хореография — более публичный процесс. Оркестровка отличается от хореографии тем, что она описывает последовательность технологических операций между сервисами, контролируемыми одной стороной. Более общая, по своей природе, хореография отслеживает поток сообщений, вовлекающий множество участников, где не один из участников не является владельцем процесса общения. На рисунке 2 схематически представлены понятия Оркестровки и Хореографии Web-сервисов. Рисунок 2 . Оркестровка и Хореография Web-сервисов Технические требования к оркестровке и хореографии Следующие требования важны как для языка, так и лежащей в его основе инфраструктуры: • Гибкость (Flexibility): Одним из наиболее важных аспектов является гибкость представляемая языком. Гибкость может быть достигнута путем чистого разделения между логикой процесса и вызываемого Web- сервиса. Данное разделение чаще всего достигается за счет движка (инструмента) оркестровки, который управляет всей последовательностью операций (process flow). При помощи такой гибкости организация мо- жет легко заменять сервисы при изменении бизнеса. • Базовые и структурированные действия (Basic and structured activities): Язык оркестровки должен поддерживать действия как для коммуникации с другими сервисами, так и для управления семантикой производственного процесса. Базовое действие можно рассматривать как компонент, который взаимодействует с чем-то внешним по отношению к самому процессу. Напротив, структурированные действия управляют всем рабочим потоком, определяя какие действия должны выполняться и в каком порядке. • Рекурсивная композиция (Recursive composition): Один бизнес-процесс может взаимодействовать с множеством Web-сервисов. Однако, бизнес-процесс может быть сам представлен Web-сервисом, позволяя тем самым бизнес-процессу быть собранному из процессов боле высокого уровня. В дополнение к этому, оркестровка и хореография Web-сервисов должны поддерживать некоторые базо- вые требования для управления общей целостностью и слаженностью взаимодействий. Данные требования включают: • Хранение данных и взаимосвязь (Persistence and correlation): Способность управлять состоянием сквозь запросы Web-сервисов является важным требованием, особенно когда идет речь об асинхронных Web-серви- сах. Язык и инфраструктура должны предоставлять механизм для управления хранением данных и кор- релированием запросов с целью построения высокоуровневого обмена сообщениями. • Транзакции и обработка исключений (Exception handling and transactions): Оркестрируемые Web-серви- сы, которые предоставляют свои услуги на долгосрочной основе, должны обрабатывать исключительные ситуации и поддерживать транзакционную целостность. Например, ресурсы могут быть заблокированы в транзакции, которая превысила допустимое времяисполнения. Стандарты оркестровки и хореографии К настоящему моменту предложено несколько технологий для построения композитных сервисов: XLANG (фирмы Microsoft) , BPML (консорциума BPML.org), WSCI (Sun, SAP, BEA, консорциум W3C), BPSS (консорциум ebXML/OASIS), WSCL(Hewlett-Packard) . В этой ожесточенной борьбе де-факто победа досталась новому игроку BPEL4WS,которую поддержала критическая масса фирм—разработчиков ПО и которая унаследовала многие из позитивных свойств предшественников. Одним из наиболее интересных средств описания оркестровки стал язык BPEL4WS (Business Process Execution Language for Web Services), предложенный компаниями IBM, Microsoft и BEA Systems. Язык пред- назначен для описания исполнения исполняемых бизнес-процессов и позволяет описать поведение и взаи- модействия Web-сервисов в бизнес-процессе. WSCI (Web Service Choreography Interface). WSCI определяет расширение стандарта WSDL для взаимодействия Web-сервисов. Изначально был предложен Sun, SAP, BEA, and Intalio, он был недавно опубликован как записка от W3C. WSCI является языком хореографии Web-сервисов, который описывает сообщения, которыми обмениваются Web-сервисы, участвующие в бизнес-процессе. Ключевым аспектом WSCI является то, что он описывает только обозримое поведение Web-сервисов. Он не затрагива- ет определений исполняемого бизнес-процесса. WSCI может рассматриваться как надстройка над существующим стеком протоколов Web-сервисов. Каждое действие в WSCI представляет едини- цу работы, которая обычно будет соответствовать одной WSDL операции. WSCI является расширением WSDL, который описывает как взаимодействие операций может быть организовано. Другими словами, WSDL описывает точку входа в каждый сервис, тогда как WSCI будет описывать взаимодействия между WSDL операциями. BPEL4WS. Стандарт BPEL4WS представляет объединение идей двух других стандартов языков исполнения производственных процессов, XLANG (XML LANGuage) and WSFL(Web Services Flow Language). Компании Microsoft, IBM, Siebel Systems, BEA, и SAP представили версию 1.1 в качестве полноценной спецификации в мае 2003 года. Он представ- ляет XML-базированный синтаксис для описания управляющей логики, необходимой для координиро- вания Web-сервисов, принимающих участие в производственном процессе, и является надстройкой над WSDL. BPEL4WS определяет порядок исполнения WSDL операций. BPEL4WS поддерживает как абстрактные бизнес протоколы, так и исполнимые бизнес протоколы. Биз- нес протокол в BPEL4WS определяет открытый обмен сообщениями между участниками. Бизнес протоколы не являются исполнимыми и, следовательно, не выражают внутренних деталей последовательности технологических операций, в этом он подобен WSCI.Исполнимый процесс моделирует поведение участни- ков конктретных бизнес взаимодействий, существенным является моделирование закрытых последова- тельностей технологических операций. Исполнимые процессы предоставляют поддержку оркестровки, описанную выше, тогда как бизнес протоколы концентрируют внимание на оркестровке Web-сервисов. Спецификация BPEL4WS поддерживает базовые действия для общения между Web-сервисами. Ти- пичным сценарием является получение сообщений в исполнимом процессе в BPEL4WS. Процесс далее может вызывать набор внешних сервисов для сбора дополнительных данных и затем послать ответ про- цессу, пославшему запрос. На рисунке 3 сообщения Рисунок 3. Последовательности технологических операций в BPEL4WS 4. Постановка задачи Процесс создания бизнес процессов на основании Web-сервисов состоит в том, что сначала создается ис- полнимый файл на одном из языков оркестровки и хореографии, а далее передается на исполнение движку этого языка, который и производит соответствующие вызовы Web-сервисов для достижения поставленной цели. Как было продемонстрировано ранее де-факто победителем среди языков хореографии и оркестровки является язык BPEL4WS. Однако он обладает рядом недостатков и основной его недостаток - это жесткая завязка на конкретные сервисы и типы передаваемых значений (точнее говоря, завязка на конкретных «партнеров» и их описания в WSDL-документах).Это, в свою очередь, может означать невозможность исполнения процесса, если один из сервисов будет недоступен, т.е. нет механизма отказоустойчивости. С другой стороны, привязка к конкретным сервисам сильно ограничивает организацию, использующую данный язык, так как вероятнее всего, что со временем появятся более производительные и менее до- рогостоящие сервисы, а такая жесткая структура не позволит легко перейти на их использование. Ведь для осуществления такого перехода потребуется изменения всех BPEL4WS файлов, в которых используется конкретный Web-сервис. Но опять таки мы приходим к жесткой привязке на конкретный сервис, что в свою очередь не предполагает механизма отказоустойчивости. Задачей данного исследования является снятия ограничений на созданный бизнес процесс. Он позволит избежать жесткой привязки к конкретным сер- висам и обеспечит динамическое переподключение сервисов во время исполнения процесса. При этом не будет необходимости вручную изменять файлы или вносить изменения в спецификацию языка. 5. Интеграция web-сервисов и программных агентов Суть подхода - это использования тандема Web-сервис – программный агент. Агент в этой связке играет роль владельца Web-сервиса и одновременно хранителя метаинформации о нем. Как показано в , программные агенты являются наиболее подходящей платформой для построения семантических Web-сервисов. Однако, если в предлагается новое понимание Web-сервисов как программных агентов с соответствующим онтологическим описанием, то в предполагаемом решении Web-сервисы - это всего лишь существующие Web-сервисы, а вот агенты, которые должны работать с ними в связке, это некий новый тип агентов. В качестве платформы для реализации агентов предлагается использовать платформу JADE , она является идеальным решением для данной задачи, так как поддерживает множество протоколов для взаимодействия агентов и проведения переговоров между ними и соответствует спецификациям FIPA . Каждый агент хранит информацию о Web-сервисе или Web-сервисах за которыми он закреплен. Информа- ция может храниться в базе данных. Кроме стандартной информации, описываемой WSDL файлом, агент хранит метаинформацию, такую как стоимость выполнения операции, количество времени, которое в среднем необходимо выполнение операции, точность проводимых расчетов (если метод вычисляет какие-то значения) и т.п. Вся эта информация будет использоваться на этапе выбора Web-сервисов кандидатов на исполнение.Перед тем как исполнить бизнес процесс агент, закрепленный за bpel-движком, производит опрос агентов об имеющихся у них сервисах для выполнения конкретных операций. Далее на основании полученных ответов идет построение списка агентов, с которыми будут производиться переговоры по использованию их сервисов. После завершения процесса переговоров исполнимом BPEL-файле вызовы Web-сервисов заменяются на вызовы Web-сервисов, выбранных на предыдущем этапе. А затем уже этот измененный файл передается bpel-движку на исполнение. Рассмотрим пример бизнес процесс, обрабатывающий заказ на покупку товаров. При получении заказа от клиента процесс инициирует три конкурентные задачи (выполняющиеся параллельно): расчет конечной стоимости заказа, выбор поставщика и составление расписания обработки и доставки заказа. В то время как некоторые из действий могут выполнятся параллельно, существует зависимость от данных и управления между этимим тремя задачами. Обычно цена доставки требуется для того, чтобы рассчитать окончательную стоимость заказа, а дата доставки необходима для составления окончательного расписания сделки. После завершения всех трех задач выполняемая обработка счета может продолжаться и счет отправляется покупателю. На рисунке 4 представлена схема такого бизнес процесса. Пунктирными линиями на рисунке изображены последовательности действий. Группирования таких последовательностей отображает параллельные задачи. Сплошными линиями показаны контролирующие связи, которые используются для синхронизации параллельных задач. Рассмотрим BPEL4WS описание изложенного выше процесса. Фрагмент данного описания представлен на рисунке 5. Выделенный фрагмент содержит часть, в которой идет жесткая привязка к конкретным Web-сервисам, а точнее их описаниям. Данное описание содержит 4 основных раздела: переменные ( ссылка на партнеров ( ); обработчики ошибок ( последовательность операций ( Раздел переменных определяет переменные, используемые процессом. Определение производится в терминах типов сообщений WSDL, простых типов XML Schema или элементов XML Schema. Переменен- ные позволяют управлять состоянием данных и обрабатывать историю обмена сообщениями. Рисунок 5. BPEL4WS описание процесса покупки товаров Раздел ссылок на партнеров определяет разных участников, которые взаимодействуют в процессе об- работки заказа. Четыре элемента partnerLink, представленные здесь, соответствуют отправителю заказа (покупателю), а также обработчикам (провайдерам)цены (invoicingProvider), доставки (shippingProvider), и сервису, построения расписания доставки (schedulingProvider).Каждая из ссылок на партнеров характе- ризуется типом ссылки и именем роли. Эта информация определяет функциональность, которая должна предоставляться бизнес процессом и сервисами-партнерами для успешного завершения всего процесса, то есть portTypes, которые процесс обработки заказа и партнеры должны реализовать (имплементировать). Раздел обработчиков ошибок содержит обработчики, определяющие действия, которые должны про- изводиться в случае ошибок. В BPEL4WS все ошибки внутренние или ошибки вызова внешних сервисов определяются уникальным именем. Обычно каждая WSDL ошибка определяется в BPEL4WS именем, формируемым из целевого пространства имен WSDL-документа, в котором соответствующий тип порта (portType) и ошибка объявлены, и имени ошибки.Последний раздел содержит описание нормально- го поведения бизнес процесса для обработки заказа.В данном процессе участвуют 3 Web-сервиса, по одному для осуществления каждого из описанных действий. Перед тем как отдать бизнес процесс на выполнение, агент обращается к некому хранилищу Web-сервисов или точнее серверу агентов этих сервисов, с запросом на получение списка сервисов кандидатов. В данном запросе агент передает portType для каждого из интересующих его сервисов, ведь именно этот portType должен быть реализован сервисом для успешного выполнения бизнес процесса. Для того чтобы сформировать запрос агент bpel-движка сначала извлекает portType для каждого сервиса из соответствующих WSDL- описаний на которые ссылает BPEL4WS. В данном примере такое описание одно и расположено оно по такому адресу http://manufacturing.org/wsdl/purchase. В ответ сервер формирует список агентов владеющих сервисами канди- датами для каждого запрашиваемого типа сервисов в следующем формате: <сервис#1>=><список имен агентов> и так для всех запрашиваемых сервисов. После получения списка, агент bpel-движка инициирует процесс переговоров с каждым из агентов Web-сервисов. Простой сценарий переговоров может выглядеть как последовательный опрос агентов и затем выбор наилучшего кандидата для замещения каждого из сервисов (выполнимых операций). Так как платформа JADE предоставляет возможность широ- ковещательного (одновременного) опроса одним агентом всех, то реализация такого сценария значительно упрощается. После отправки запроса всем агентам и получения от них всех ответов, агент bpel-движка вы- бирает лучшего кандидата на замещения сервиса. Выбрав, сервис-кандидат запрашивает у его мастер агента информацию о WSDL-описании. Такой процесс переговоров происходит для каждого из сервисов, которые будут вызываться из BPEL4WS-документа. Конечный этап данного процесса - это изменение BPEL-файла и его исполнение. Изменение BPEL-файла включает в себя замену всех ссылок на WSDL-описания ранее используемых сервисов на вновь полученные описания, а также добавление или элиминацию пространств имен, которые на них ссылаются. Добавление - в случае, если ранее несколько сервисов описывались одним WSDL- документом, а теперь используются сервисы с описаниями, находящимися в разных WSDL-документах. Удаление пространств имен происходит в обратном случае, когда вновь выбранные сервисы разделяют одно WSDL-описание. После проведения всех необходимых изменений BPEL4WS-файл отдается на исполнение bpel-движку. |