АВТОМАТИЗОВАНЕ КОМПОЗУВАННЯ WEB- С Е Р В І

АВТОМАТИЗОВАНЕ КОМПОЗУВАННЯ WEB- С Е Р В І С І В ЗА ДОПОМОГОЮ ПЛАНУВАННЯ АСИХРОННИХ ДОМЕНІВ О. О. СЛАБОСПИЦЬКА Інститут програмних систем НАН України, Київ 26 червня 2014 Р.

ВИЗНАЧЕННЯ Web-CЕРВІСУ Визначення сервісу в SOA ü Сервіс це функція, що є чітко визначеною, самодостатньою незалежною від контексту чи стану інших сервісів. і Визначення Web-сервісу Консорціумом UDDI ü самодостатній модульний бізнес-застосунок, що має відкритий стандартизований інтерфейс, орієнтований на Інтернет. Визначення Web-сервісу Консорціумом W 3 C ü програмний застосунок, що ідентифікується URI, інтерфейс і засоби зв’язування якого визначаються й описуються як артефакти XML. Web Services Architecture Requirements, W 3 C Working Group Note, 11 Feb. 2004, http: //www. w 3. org/TR/wsa-reqs/ 2/25

ПІДХІД ПРОЕКТУ A S T R O (2004 -2008): ЗАСАДИ ТА ЗДОБУТКИ ü Використання “ПЛАНУВАННЯ ЧЕРЕЗ ПЕРЕВІРКУ МОДЕЛЕЙ” як алгебраїчного й технологічного інструментарію [16, 77, 32, 15] (завдяки продуктивності обчислень і врахуванню різних форм недетермінованої поведінки Webсервісів) ü Розгляд сервісів, поданих за допомогою де-факто стандартних мов WS-BPEL, WSDL (для створення конструктивних засобів вирішення реальних проблем композування) ü Проблему автоматизованого композування сервісів на функціональному й процесному рівнях (для досяжних вимог і скінченої множини станів) формально поставлено й вирішено як ПРОБЛЕМУ ПЛАНУВАННЯ недетермінованого, частково спостережного, асихронного домену ü Розроблено новітній підхід до планування таких доменів та доведено його коректність і повноту 3/25

АВТОМАТИЧНЕ ПЛАНУВАННЯ: НЕФОРМАЛЬНИЙ ОПИС ПРОБЛЕМА ПЛАНУВАННЯ – пошук такого плану доцільних дій у певному середовищі, який призведе до заданої цілі. Середовище подається концептуальною моделлю – доменом планування, формалізованим як система з переходом між станами. Ціль – вимоги, що мають задовольнятися, описані умовами на стани домену. План – комбінація дій у домені. Постановка Домен Класична Загальна Скінчений, детермінований, спостережний, синхронний Нескінчений, недотермінований, частково спостережний, асинхронний Ціль Досяжна, описана умовами на кінцеві стани, що мають досягатися після виконання плану Розширена – множина прийнятних дерев, відповідних бажаним еволюціям домену. Зокрема, розширена часом, що подає умови на все дерево станів домену після виконання плану План Послідовність дій, визначе-них до виконання плану Дія залежить від наявної інформації про історію попередніх кроків 4/25

АВТОМАТИЧНЕ ПЛАНУВАННЯ ЯК ПЕРЕВІРКА МОДЕЛЕЙ 5/25

АВТОМАТИЗОВАНЕ КОМПОЗУВАННЯ Web-сервісів : НЕФОРМАЛЬНИЙ ОПИС Проблема полягає в конструюванні нового композитного сервісу, що виконує певні бажані функції за допомогою взаємодії з наявними компонентними сервісами, які мають стани і потребують складних протоколів взаємодії для виконання своїх завдань. 6/25

СТАНДАРТНЕ ПОДАННЯ СЕРВІСІВ 7/25

КОМПОЗУВАННЯ Web-сервісів vs ПЛАНУВАННЯ 8/25

ТЕХНОЛОГІЧНА СХЕМА ПРОЦЕСУ КОМПОЗУВАННЯ Wеb-СЕРВІСІВ (1) 9/25

ТЕХНОЛОГІЧНА СХЕМА ПРОЦЕСУ КОМПОЗУВАННЯ Wеb-СЕРВІСІВ (2) 10/25

СКІНЧЕННА СТС: СУТНІСТЬ ТА ВИЗНАЧЕННЯ Складові СТС описує динамічну систему, що перебуває в одному з можливих станів (деякі вважаються початковими). Стан – набір пропозиціональних властивостей, які мають місце в ньому. Він може замінятися іншими станами наслідок виконання певних дій: вхідних, що відображають отримання повідомлень, вихідних, які подають повідомлення, надіслані зовнішнім сервісам, внутрішньої ( ) для відображення еволюції, не спостережної зовнішніми сервісами. Відношення переходу описує зміну стану на підставі дій: вхідних, вихідних, . Функція міток зіставляє стану множину властивостей, що можуть виконуватися в ньому. Означення 1. СТС , визначена на множині висловлювань Prop, - кортеж = S, So, I, O, R, L , де S – скінчений набір станів; So – набір початкових станів; I, O – скінчені набори вхідних і вихідних дій; L: S 2 Prop – функція міток; R S (I O { }) S – відношення переходу. 11/25

КОРИСНІ ОЗНАЧЕННЯ ЩОДО СТС Означення 2. Стан s S зветься досяжним (s RC( )), якщо і тільки якщо (s So) ! ((so So) (si, i=1, …, n-1)|(sn=s, i=1, …, n-1 a I O { })|(si, a, si+1) R. Говорять, що в стані s має місце розходження (він є дівергентним), якщо існує нескінченна послідовність переходів з s. Далі розглядаються СТС без дівергентних станів. Означення 3. (виконаність пропозиціональної формули для властивостей). Нехай = S, So, I, O, R, L - СТС, визначена на множині висловлювань Prop, ρ, φ, ψ – пропозиціональні формули на Prop, зформовані з використанням логічних зв’язок. Говорять, що стан s S задовольняє формулу ρ ( ), якщо й тільки якщо: 12/25

Крок 1. ПЕРЕТВОРЕННЯ WEB-СЕРВІСУ В СТС(1) 13/25

ПЕРЕТВОРЕННЯ WEБ-СЕРВІСУ В СТС (2) Перетворення здійснюється в два етапи: 1) сервіс перетворюється в автомат, де стани подано змінними, що можуть мати невизначені діапазони значень, тобто він не обов’язково скінченний; 2) усім змінним зіставляються скінченні діапазони, завдяки чому отримується скінченна СТС. Застосовується графічне подання, що має такі особливості: 1) стани СТС – множини значень типізованих змінних, відповідних складовим структурованих змінних абстрактного WS-BPEL; додається також спеціальна змінна pc “програмний лічильник ” для подання поточного кроку виконання сервісу; 2) вхідні й вихідні дії СТС подаються схемою, утвореною ім’ям дії та множиною типів її аргументів (можливо, порожньою); 3) можна оголосити функцію, входами якої є деякі типізовані аргументи, а виходом – один типізований аргумент; 4) переходи подаються схемою, яка визначає множини передумов (щонайбільше одну вхідну або вихідну дію) та пост-умов. Передумови визначають первинні стани, а пост-умови – цільові стани постулюванням значень змінної pc та, можливо, інших змінних стану. Дія описується ім’ям і змінними, визначеними в списку аргументів у її декларації. 14/25

КРОК 4. ОБЕРНЕНЕ ПЕРЕТВОРЕННЯ ДЕТЕРМІНОВАНОЇ СТС У WEБ-СЕРВІС (1) СТС властива недетермінована поведінка двох типів: 1) “зовнішній” недетермінізм, обумовлений тим, що домен, який взаємодіє з СТС, може мати поведінку, a priori непередбачувану СТС ( прийняття чи відкидання пропозиції Виробника не контролюється ним); 2) “внутрішнім ” недетермінізм полягає в тому, що СТС може розвиватися різними шляхами згідно з внутріщніми рішеннями, що є неявними в СТС. Прийняте далі спрощене трактування детермінованої СТС як такої, що не має внутрішнього детермінізму (хоча може мати зовнішній), встановлює Означення 4. СТС = S, So, I, O, R, L є детермінованою, якщо й тільки якщо: 1) має єдиний вхідний стан |So|=1; 2) s S якщо (s, r, s*) R, то жодний інший перехід з s не належить R; 3) s S якщо (s, a, s*) R, a O, то жодний інший перехід з s не належить R. 15/25

ПЕРЕТВОРЕННЯ ДЕТЕРМІНОВАНОЇ СТ В ОПИС АБСТРАКТНИМ WS-BPEL (2) Детермінованість СТС у сенсі Означення 4 дуже спрощує її перетворення: 1) вилучення операцій входу/виходу WS-BPEL та його змінних, що подають змінні СТС (крім pc) здійснюється безпосередньо оберненням відповідних операцій Кроку 1; 2) для відтворення потоку робіт WS-BPEL, виходячи з множини переходів СТС, спочатку вилучаються всі –переходи. Потім здійснюється рекурсивний огляд дерева переходів з початкового стану із застосуванням процедур, обернених щодо процедур перетворення базових і структурованих операцій WS-BPEL на Кроці 1. Зокрема, відбувається конвертування: вихідних переходів в операції invoke або reply ; Assignments – в операції присвоєння; одиничного вхідного переходу – в операцію receive; послідовності вхідних переходів, які змінюють свій початковий стан, відповідають операції pick та послідовності операцій on. Message. 16/25

КРОК 2. ФОРМАЛЬНЕ ВИЗНАЧЕННЯ КОНТРОЛЬОВАНОГО ДОМЕНУ ПЛАНУВАННЯ В індукованій проблемі планування домен планування являє собою СТС, що відображає всі можливі поведінки компонентних сервісів, які мають контролюватися композитним сервісом. Пропонується визначати її як паралельний добуток (частковий випадок асинхронного добутку ) відповідно до Означення 5. Нехай 1= S 1, So 1, I 1, O 1, R 1, L 1 і 2= S 2, So 2, I 2, O 2, R 2, L 2 - дві СТС такі, що (I 1 O 1) (I 2 O 2)=. 17/25

КРОК 2. ФОРМАЛЬНЕ ВИЗНАЧЕННЯ КОНТРОЛЕРА ДОМЕНУ ПЛАНУВАННЯ 18/25

КРОК 2. ЗАБЕЗПЕЧЕННЯ УЗГОДЖЕНОСТІ КОНТРОЛЕРА Й ДОМЕНУ ПЛАНУВАННЯ Означення 6, 7 припускають конфлікт (deadlock) контролера Σc і домену планування : зокрема, Σc виконує вихідну дію а момент часу, коли Σ нездатна на неї відреагувати. 19/25

КРОК 2. ФОРМАЛІЗАЦІЯ ВИМОГ ДО КОМПОЗИЦІЇ ЯК ЦІЛІ ПЛАНУВАННЯ Вимоги формулюються в термінах досяжності кінцевих станів компонентних сервісів і подаються кон’юнкцією умов щодо потоку даних між ними та логіки управління. Змістовно, контролер є вирішенням проблеми композування (і планування) з вимогами ρ = ρc ρd тоді й й тільки тоді, коли він “гарантує”, що вимоги досягаються. Формально це означає, що кожне виконання контрольованої СТС (Означення 7) закінчується станом, де ρ виконується. 20/25

КРОК 2. ВИЗНАЧЕННЯ ОБРАЗУ ДОМЕНУ ПЛАНУВАННЯ НА РІВНІ ПЕРЕКОНАНЬ Означення 11 дозволяє: 1) безпосередньо перевіряти, чи задовольняє певний контролер С вимоги ρ за допомогою технік Model Checking; 2) автоматично генерувати контролер С , що є вирішенням проблеми з вимогами ρ. Для цього необхідно переформулювати проблему, щоб висвітлити спосіб ідентифікації контролера за допомогою формування адекватного простору пошуку і його перегляду з ефективними техніками планування. В підході ASTRO таким простором є простір переконань щодо частково спостережуваної поведінки недетермінованого домену планування ||. 21/25

ВИКОРИСТАНІ ДЖЕРЕЛА • ЛІТЕРАТУРА (базова) 1. Symbolic Techniques for planning with extended goals in non-deterministic domains. ITC IRST University of Trento. M. Pistore Renato Bettin and P Traverso 2. Planning as Model Checking for extended goals in non-deterministic domains. ITC IRST University of Trento. M. Pistore P Traverso download_5. pdf 3. Planning with a language for extended goals. Ugo Dal Lago and M. Pistore and P Traverso 4. Specifying Data-Flow Requirements for the automated Composition of Web Services. ITC IRST University of Trento Annapaolo Marcony and M. Pistore and P Traverso AM_SEFM 06. pdf 5. Automated Synthesis of Composite BPEL$WS Web Services. ITC IRST University of Trento Annapaolo Marcony and M. Pistore and P Traverso and P. Bertolly 6. Implicit vs. Explicit Data-Flow Requirements in Web Services composition Goals. ITC IRST University of Trento Annapaolo Marcony and M. Pistore and P Traverso AM_ICSOC 06. pdf 7. A Minimalist Approach to Semantic annotations for Web Processes compositions. ITC IRST University of Trento. M. Pistore Luca Spalazzi and P Traverso 8. Web Service Discovery at Process-level Based on Semantic Annotation. ITC IRST University of Trento. Francesco Pagliarecci M. Pistore Luca Spalazzi and P Traverso 9. An approach for the Automated Composition of BPEL Processes. ITC IRST University of Trento. M. Pistore and P Traverso and Annapaolo Marcony and P. Bertolly 10. Planning and monitoring Web Service Composition. ITC IRST University of Trento. M. Pistore and P Traverso and P. Bertolly F. Barbon and D. Shaparau pistore. pdf AAAI 02 -068. pdf 22/25

ВИКОРИСТАНІ ДЖЕРЕЛА (2) 11. Bertoli P. , Pistore M. , Traverso P. Automated composition of Web services via planning in asynchronous domains Artificial Intelligence, 174 – 2010. – P. 316– 361 (!!) 12. Cimatti A. , Pistore M. , Traverso P. Chapter 22. Automated Planning - P. 841867 // Harmelen F. , Lifschitz V. , Porter B. Handbook of Knowledge Representation - Elsevier, 2008 - 1035 P. (!!) 13. Сайт Проекта ASTRO ” The automated composition of distributed business processes ” Available at http: //www. astroproject. org/index. php. 14. Ghallab M. , Nau D. , Traverso P. Automated Planning Theory and Practice - Elsevier, 2004 - 635 с. 15. Карпов Ю. Г. MODEL СHECKING. Верификация параллельных и распределенных программных систем - БХВ-Петербург, 2010 - 560 с. (!) 16. Карпов Л. Е. Материалы к специальному курсу для студентов 3, 4, 5 курсов кафедр программистского потока "Архитектура распределенных систем программного обеспечения " 17. Карпов Л. Е. Архитектура распределенных систем программного обеспечения Москва, МАКС Пресс, 2007 130 с. 23/25

СПЕЦІАЛЬНІ ПИТАННЯ ДЛЯ ПОДАЛЬШОГО РОЗГЛЯДУ 1. Альтернативні моделі композиції Web-сервісів. 2. Самодостатнє автоматичне планування за допомогою Model Checking. 3. Автоматичний синтез контролера для вимог у просторі переконань 4. Алгоритми та інструментальні засоби композування Web-сервісів за допомогою Model Checking. 5. Автоматизована трансляція абстрактних WS-BPEL описів у СТС і навпаки. 6. Продовження проекту ASTRO: адаптивна композиція ділових процесів під час виконання у Фонді Бруно Кесслера. 24/25

З а п и т а н н я ? Д Я К У Ю З А У В А Г У !