Предположим, что организация (поставщик услуг) выполняет некоторую услугу и предоставляет информацию об этой услуге в понятной форме всем заинтересованным сторонам (например, через репозиторий услуг). Другая сторона при выполнении сложного бизнес-процесса уже не нуждается в реализации всех мельчайших подпроцессов: она просто выполняет декомпозицию исходного бизнес-процесса до уровня, позволяющего передать работу поставщикам услуг, которые зарегистрировались в репозитории.
Но тут следует заметить, что такой подход может быть реализован и при помощи простого взаимодействия, основанного, например, на веб-службах. Для того, что такой подход дал существенные преимущества, в него надо добавить возможность автоматической компоновки потока работ бизнес-процесса, который может быть описан на языке высокого уровня (например, BPEL). Далее в этой работе исследуются возможности языка Entish по автоматической компоновке таких приложений, анализируются его преимущества и недостатки, предлагается ряд усовершенствований.
Возможность компоновки (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 предназначен для реализации оркестровки сервисов.
В нижеследующих подразделах данной работы приводится концептуальное описание некоторых из вышеперечисленных стандартов.
2.1 Язык BPEL
На сегодняшний день создано огромное количество технологий и продуктов, которые решают задачи автоматизации бизнес-процессов предприятия. При этом главными проблемами в контексте предприятия в целом были и остаются задачи взаимодействия приложений от разных производителей и возможности динамического создания новых бизнес-цепочек на основе существующих модулей автоматизации.
Язык BPEL (Business Process Execution Language) и концепция web-сервисов, с которой он тесно связан, представляет собой новый подход к описанию как собственно бизнес-процессов, так и механизмов их взаимодействия. Он открывает новые возможности для создания гибких, динамических бизнес-цепочек, способных быстро адаптироваться к меняющимся требованиям.
На сегодняшний день BPEL представляет собой фактически единственный перспективный стандарт описания бизнес-процессов, на который ориентируются все ведущие производители программных продуктов и технологий. С момента включения BPEL в продукты таких вендоров, как Microsoft, IBM, Oracle начался постепенный процесс вытеснения собственнических (proprietary) технологий и интеграции корпоративных приложений.
Теперь стандартный сценарий автоматизации бизнес-процессов состоит из двух этапов. На первом этапе предполагается создание набора компонентов, реализующих элементы бизнес функциональности, которые обычно реализуются в виде web-сервисов (хотя и не ограничиваются этим форматом). Второй этап - это организация взаимодействия приложений (сервисов) в рамках бизнес-процессов, так называемая "оркестровка".
По существу, язык BPEL объединяет возможности языка WSFL (Web services flow language, Язык организации потоков Web-сервисов), разработанного компанией IBM, и языка XLANG, используемого в Microsoft BizTalk Server 2002. BPEL включает WSFL для поддержки графоориентированных процессов, а XLANG - для поддержки структурных конструкций для процессов. Таким образом, BPEL предназначен для поддержки реализации бизнес-процессов любой сложности, а также для описания интерфейсов бизнес-процессов. Надо отметить, что язык BPEL "неразрывно связан" со спецификациями WS-Coordination ("Координация Web-сервисов") и WS-Transaction ("Транзакции Web-сервисов"), которые были определены для совместного использования с BPEL и разработаны для координации транзакций и процессов. Так, в спецификации WS-Coordination описываются стандартные механизмы создания и регистрации протоколов транзакций, которые координируют выполнение распределенных операций в среде Web-сервисов. С помощью спецификации WS-Transaction можно отслеживать успех или неудачу каждого отдельного скоординированного действия в бизнес-процессе, задавать гибкую модель транзакций, которая обеспечивает целостность и надежность операций в распределенной среде Web-сервисов и позволяет бизнес-процессам обрабатывать сбои в ходе выполнения.
2.3 Описательный язык WSCI
WSCI - это описательный язык интерфейсов на основе XML, который работает в связке с WSDL. Его цель — позволить корпорациям использовать возможности веб-служб для создания процессов, отражающих меняющиеся требования бизнеса. Язык позволяет компаниям представлять свои прикладные программы и ресурсы в виде веб-служб, чтобы другие фирмы могли оперативно находить их и применять в своих бизнес-процессах.
Большинство составных сервисов формируются вручную, используя основанные на WSDL описания (например, WSCI). Для автоматической компоновки программы должны уметь отбирать нужные службы и комбинировать их. При этом результат должен являться приемлемым решением поставленной задачи. Информация, содержащаяся в UDDI (Universal Description, Discovery, and Integration), недостаточна для автоматической компоновки сервисов, так как не позволяет интерпретировать их семантику. Ни WSDL, ни UDDI не дают программе понять, для чего именно с точки зрения клиента служит сервис. Поэтому так важны механизмы отображения семантики сервисов и ее автоматизированного сопоставления с семантикой запросов клиентов. Проблемы компоновки можно решить, связав параметры сервисов с понятиями определенной предметной области и их семантическим обоснованием.
Как было уже сказано выше, проблема компоновки служебно-ориентированного приложения возникает, когда разработчик хочет избавиться от проблемы ручной привязки частей приложения к конкретным конечным точкам веб-сервисов (или просто сервисов). Для этого необходим протокол, позволяющий приложению-клиенту выражать свои намерения, а сервису-поставщику понимать эти намерения, анализировать их и при необходимости предоставлять информацию клиенту о готовности выполнить то или иное действие при условии удовлетворения некоторых предусловий.
Одной из разработок в направлении автоматической компоновки служебно-ориентированных приложений является язык описания и компоновки Entish, который подробно рассмотрен в следующих подразделах этой работы.
3.1 Основные компоненты языка Entish
Язык описания, включенный в Entish, базируется на использовании расширенного языка разметки, то есть языка xml. Подробное описание всех схем и структур, используемых в языке описания, приводиться не будет, так как их всех можно посмотреть в литературе, которая указана в списке источников. В этом разделе будет схематично указана иерархия основных понятий и структур данных.
Имена описываются типом Concept, который состоит из короткого и длинного имени. Длинное имя является URI указателем и может быть опущено в случае, когда имя ссылается на константу.
Описание типов, отношений и функций на макро уровне состоит из двух частей: определяющего выражения (definiens) и определяемого выражения (definiendum), то есть из того, что определяется, и из того, как определяется.
Формулы определяются как простые (состоят из одной операции) или как составные (состоят из нескольких формул, связанных отношением «и», «или» или «влечет»).
Состояние определяется адресом, целями, намерениями, обязательствами и знаниями владельца. Цели и обязательства описываются как два списка формул, каждый из которых формирует предусловия и постусловия соответственно. Намерения в свою очередь состоят из трех списков формул: плана (используется для поддержки процесса конструирования потока работ и выражения текущих намерений), потока работ (описывает сконструированный, конструируемый или выполняемый поток работ), реализованный список формул (хранит уже реализованные формулы).