КАТЕДРА “КОМПЮТЪРНИ СИСТЕМИ”

Маг. Инж. СИМЕОН ЕМИЛОВ ЦВЕТАНОВ

ИНТЕГРИРАНА ПЛАТФОРМА ЗА IN-SILICO ИЗСЛЕДВАНИЯ В ГРИД И

„ОБЛАЧНИ” СРЕДИ БАЗИРАНА НА РАБОТНИ ПОТОЦИ

АВТОРЕФЕРАТ

на дисертация

за присъждане на образователна и научна степен „ДОКТОР”

по научна специалност „Компютърни системи, комплекси и мрежи”

Научен ръководител: проф. д-р инж. Пламенка Боровска

София, 2013 г.

Т Е Х Н И Ч Е С К И У Н И В Е Р С И Т Е Т – С О Ф И Я

2

Дисертационният труд е обсъден и насочен за защита от катедрен съвет на катедра „Компютърни системи“ при ФКСУ, Технически

университет – София.

Защитата на дисертационния труд ще се състои на 18.03.2013 г. от 14:00 ч. в зала 1434.

Материалите по защитата са на разположение на интересуващите се в канцеларията на ФКСУ, каб. 1443А на ТУ–София.

Автор: маг. инж. Симеон Емилов Цветанов Заглавие: Интегрирана платформа за in-silico изследвания в грид и „облачни” среди базирана на работни потоци Тираж: 40 бр. Печатна база на ТУ-София

3

ОБЩА ХАРАКТЕРИСТИКА НА ДИСЕРТАЦИОННИЯ ТРУД

Актуалност на проблема

Дисертационният труд е посветен на съвременните технологии за предоставяне на услуги в Грид и „облачни” среди. Разработката е свързана със създаването на интегрирана платформа за in-silico изследвания в Грид и „облачни“ среди, предоставяща унифициран достъп до високопроизводителни изчислителни ресурси като услуги. Проблемът е актуален, като се имат предвид съвременните компютърни приложения, изискващи разпределена информационната обработка и наличието на множество интензивни научни изследвания и разработки в областта на компютърните системи и софтуерното инженерство, свързани с Грид и „облачните” изчисления.

Цел и задачи на дисертационния труд

Основната цел на дисертацията е разработването на интегрирана платформа за in-silico изследвания в Грид и „облачни“ среди базирана на работни потоци и предоставяща унифициран достъп до високопроизводителни изчислителни ресурси като услуги. Най общо подходът се състои в предоставянето на високопроизводителни изчислителните ресурси като услуги, които от своя страна биват декомпозирани и свързвани в комплексни конвейерни структури, наричани работни потоци. За изпълнението на основната цел се дефинират следните задачи:

1. Да се предложи модел и съответната архитектура за изграждане на платформа предоставяща високопроизводителни изчислителни ресурси като услуги.

2. Да се проектира и имплементира система за управление на работните потоци с удобен потребителски интерфейс, позволяваща интегрирането на услугите в комплексни конвейерни структури.

3. Да се проектира и имплементира каталог за състоянието на услугите, както и схема за тяхното описание и декомпозиране.

4. Да се изгради потребителски портал, през който удобно и лесно да се използват услугите, а така също и middleware за достъп до съответните ресурси.

5. Да се разработят сценарии за тестване с цел верификация и оценка на ефективността на платформата.

Научна новост

На базата на направените анализи и изводи е предложен модел и съответната архитектура на платформа, предоставяща информационни услуги, комбинирани в работни потоци, с което да се улесни достъпът на изследователите, прилагащи in-silico експерименти, до необходимите им изчислителни ресурси. Предложен е подход за декомпозиране на услугите като изграждащи блокове и представянето им в база знания. Имплементиран е каталог на услугите достъпен отдалечено през RESTful API, чрез който партньорите във виртуалната организация могат да споделят информация за предоставяните от тях услуги. Имплементиран е собствен сървър, представящ

4

като услуга достъпa до компютърните клъстери, което увеличава надеждността и дава повече възможности за контрол на всички операции. Успешно са комбинирани различни технологии, чрез които е постигнато предоставяне на високопроизводителните изчислителните ресурси като услуги. Изграден е потребителски портал за удобно и лесно използване на услугите, както и middleware за комуникация с ресурсни брокери Slurm и BPS. Проектирана е и е имплементирана система за управление на работните потоци, позволяваща интегрирането на услугите в комплексни конвейерни структури. Разработен е удобен потребителски интерфейс, обединяващ софтуера за управление на работните потоци и мобилните технологии, чрез което се разширяват възможностите за експерименти и значително улеснява използването на платформата.

Приложимост и полезност

Получените резултати от дисертационния труд са внедрени в учебния процес за обучение на студенти от магистърска степен по дисциплината „Облачни изчисления и Грид“, както и в научно-изследователски проект FFNNIPO_12_01386 „Виртуален център за трансфер на in-silico scientia и технологии ViSTa“, финансиран от фонд „Научни изследвания”, МОН.

Апробация

Резултатите от дисертационния труд са докладвани изцяло в катедра „Компютърни системи“ на Технически Университет-София, а основните и части са публикувани в сборници на следните конференции: International Conference ETAI 2007, Ohrid, Macedonia, Международна научна конференция „Informatics In The Scientific Knowledge“ 2010, Международна научна конференция Compsystech 2009 (The paper was awarded as Best Paper in Session IIIA “Application Aspects of Computer Systems and Technologies”), Национална школа и борса за научни идеи в областта на информационните технологии, технологии, част от международната конференция CompSysTech 2013, Списание „Computer and Communications Engineering”.

Обем и структура

Дисертационният труд съдържа основен текст, структуриран в четири глави, заключение и списък с цитирана литература. Обемът е 114 страници, списъкът на литературните източници включва 101 заглавия. Представен е списък на 5 публикации, свързани с дисертационния труд.

5

I ГЛАВА. УПРАВЛЕНИЕ НА РАБОТНИТЕ ПОТОЦИ ПРИ ПРЕДОСТАВЯНЕ НА ИНФОРМАЦИОННИ УСЛУГИ В РАЗПРЕДЕЛЕНИ СРЕДИ

Научните изследвания стават все по-интердисциплинарни и разчитащи на

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

Допълнително усложнение се явява асинхронният характер на достъпа до изчислителните ресурси, свързан с различната им натовареност. Последният проблем е актуален въпреки наличието на добри примери при автоматичното преразпределение на изчислителните ресурсите.

Тези предпоставки определят прилагането на принципите на работни потоци при управление на процесите, свързани с използването на високопроизводителни изчислителни ресурси в областта на Грид и „Облачните” технологии.

Проблемът за моделирането и управлението на процесите при предоставянето на информационни услуги в хетерогенни, разпределени и многопластови (GRID и Cloud) системи е основен както за доставчиците, така и за ползвателите на информационните услугите.

В условията на разпределена среда, след като услугите са договорени (за да бъдат физически доставени и управлявани) е необходимо прилагането на различни технически процедури, обикновено изискващи разнообразни инженерни дейности, върху разнородни ресурси (сървъри, суперкомпютри, комутатори и т.н.). Тези процедури отнемат време, изискват голям брой квалифицирани инженери, податливи са на грешки, и като цяло изискват и допълнителни ресурси.

Прилагането на принципите на работните потоци по елегантен начин решава поставените проблеми, чрез изграждане на адаптирани към нуждите на конкретния потребител комплексни услуги, съставени от наличните атомарни такива.

1. 1 Грид и „облачни” среди за разпределена обработка.

През 90-те години на миналия век се заформят опитите за осъществяване

на разпределени научни изчисления, изискващи интеграция на нехомогенни разпределени системи.

Интегрирането на хетерогенни технологии създава множество спорни въпроси, които предполагат използването на шаблони при различните проекти. Тези шаблони се явяват между приложния и системния слой като междинно ниво и естествено се наричат „Middleware”.

При изчисленията в Грид и “облачни” среди е характерно наличието на многослойна архитектура, а тенденциите са към абстрахиране от специфичните особености на хардуера.

Грид представлява система, изградена от протоколи и интерфейси, които реализират удостоверяване, даване на право за достъп до ресурс, откриване

6

на ресурси и достъп до самите ресурси. Тези протоколи трябва да са стандартни и отворени, за да бъдат поддържани от всяка една организация.

Обобщено, моделът на Грид дефинира йерархична разпределена архитектура за споделяне на ресурси, състояща от нехомогенни децентрализирано управлявани ресурси. От съвременните Грид системи се очаква да интегрират различните аспекти на мобилност, предоставяйки услуги навсякъде и по всяко време.

Тези характеристики са подобни като при „облачните” изчисления, а така също и изобщо за Интернет, като разпределена система, в която си взаимодействат несъвместими технологии.

Разделението между Грид и сходните концепции, като „облачни” изчисления е тънко. Грид изчисленията се асоциират с висока производителност (High Performance Computing HPC), докато при „облачните” среди се разчита главно на виртуализацията, но във всеки случай детайлите остават скрити в облака, а основната цел е да се осигури удобен достъп до ресурсите като се запазват изискванията за надеждност и сигурност.

1.1 Услуги в ГРИД и „облачни” среди

Услугата (под услуги се разбира web услуги) е колекция от "функции"

достъпни чрез софтуерен компонент и може да бъде използвана отдалечено. Услугата се дефинира посредством описание, в което се съдържа информация за протоколите за достъп до услугата, името на услугата и типа на данните, които може да обменя при взаимодействие.

Парадигмата „като услуга” се прилага при GRID и „облачните“ изчисления, с цел абстрахиране от специфичните особености на конкретните изчислителни ресурси и предоставяне на унифициран достъп до тях.

Ориентираната към услуги архитектура (Service Oriented Architectures) е архитектурен стил, който се прилага при изграждане на системи и приложения, като основна характеристика на модела е разделяне на логиката на обособени логически единици, които могат да бъдат самостоятелно използвани и независими една от друга.

Съществува огромно многообразие от налични информационни услуги, като в дисертационния труд се акцентира предимно върху такива, предоставящи достъп до ресурси за in-silico експерименти.

1.2 Бизнес модели и моделиране на бизнес процеси

Бизнес моделите, най-общо казано, представят взаимоотношенията между

различните участници на пазара. Взаимоотношенията между субектите често се представят чрез моделите Бизнес-към-Бизнес (B2B) и Бизнес към Клиент (B2C), съответно описващи връзките между доставчици на стоки и услуги и такива с крайния потребител.

Бизнес процесите моделират конкретни дейности от бизнес взаимоотношенията, като например „Заявка за получаване на услуга“.

7

Съществуват множество средства за формализация и управление на бизнес процесите. Поради своята същност представляваща поток от дейности, е удобно те да се моделират чрез технологиите „workflow“.

1.3 Приложение на работните потоци за моделиране и управление на процеси

Работен поток е определянето, изпълнението и автоматизирането на

процеси, при които задачи, информация или документи се предават от един участник на друг за действие, в съответствие с набор от процедурни правила.

Работните потоци автоматизират потока от задачи и дейности на служителите, намалявайки времето за извършване на процеса, както и броя на възможните грешки, причинени от човешка дейност. Работният поток прави процесите по-ефективни, съвместими, гъвкави и нагледни, като се гарантира, че всяка стъпка от процеса е строго определена, проследена във времето, и оптимизирана за максимална производителност.

Едно от преимуществата на web-услугите е възможността да бъдат свързвани в работни потоци “Workflow” и да се изпълняват като поток от свързани дейности, изпълнявани в съответствие със зададени правила.

Един процес, описан като работен поток, може да извиква други процеси, като се постига характерното за „облачните“ изчисления високо ниво на абстракция.

Платформата, която описва, създава и управлява работни потоци (по същество бизнес-процеси) с помощта на програмно осигуряване, работещо на една или повече машини „Workflow Management System“ (WMS) или „Workflow Modeling and Specification Platform (WfMSP) е способна да интерпретира описание на процеса, да взаимодейства с участниците в потока дейности и при необходимост да извиква съответните програмни приложения и инструментални среди.

Областта на работните потоци е в постоянно развитие и все още няма доминиращи стандарти. В миналото, когато започва консолидацията на корпоративните технологии към съвместни решения, започват да се появяват първите кандидати за стандарти.

В настоящата разработка е предвидено използването на две системи за управление на работните потоци (WMS) оптимизирани съответно за бизнес и научни работни потоци, които да управляват процесите по предоставянето услугите.

Конкретните средства за реализация зависят от избора на платформа за моделиране и спецификация на работни процеси, Workflow Modeling and Specification Platform (WfMSP).

Заключение

Научните изследвания разчитат все повече на компютърните изчисления, генерирайки огромни количества експериментални данни, което значително усложнява сложността на стимулационните програми;

8

Достъпът до изчислителните ресурси в Грид и „облачни“ среди е асинхронен и зависи от множество фактори, което също е мотивация за прилагане на работните потоци за управление на процесите;

Съществуват множество научни задачи, които могат лесно да се разделят на множество подзадачи, подходящи за паралелно изпълнение, чрез прилагане принципите на работните потоци;

Все още липсва единен набор стандарти за достъп до ресурсите в Грид и „Облачни среди”. Допълнителни трудности създават и разнообразните формати на различните услуги, което се преодолява с използването на работните потоци, тъй като специфичните технически детайли остават скрити за потребителя;

За ефективно провеждане на научните изследвания е важно да се подберат и подходящи средства. Често са налични множество услуги, които е необходимо да бъдат комбинирани за постигане на желания резултат.

II ГЛАВА. МОДЕЛ ЗА ИЗГРАЖДАНЕ НА ПЛАТФОРМА ЗА УПРАВЛЕНИЕ НА РАБОТНИ ПОТОЦИ В ГРИД И „ОБЛАЧНИ” СРЕДИ

В тази глава се предлага модел за изграждане на платформа,

предоставяща интегрирани информационни услуги, комбинирани в работни потоци, като основната цел е да се улесни достъпът на изследователите, прилагащи in-silico експерименти, до необходимите им изчислителни ресурси.

2.1 Концептуален модел

Съществено изискване към предложения модел е възможността за

включване на нови участници към платформата, като всеки участник предоставя своите услуги за ползване от другите съобразно динамични бизнес модели.

Бизнес и техническите работни потоци могат да бъдат изпълнявани на една машини или да бъдат разпределени на различни в зависимост изискванията. На практика всеки партньор би имал поне една машина за своите работни потоци, която да взаимодейства с неговата система ERP (ако има такава) или да се изпълняват директно върху неговите изчислителни ресурси.

Всяка машина (workflow engine) действа като входна точка за работния поток и изпълнява бизнес и техническите работни потоци, докато специфичен локален вътрешен работен поток се изпълнява в самата система ERP. Работният поток чете и записва данни в „своята“ ERP система.

Работният поток взаимодейства с абстрактен изчислителен елемент през междинно звено с цел да се осъществи предоставянето на конкретна услуга. Абстракцията се постига чрез използване на middleware решения приложими в Грид и „облачни“ среди (Фиг. 1).

9

WF

Engine

Глобално

хранилище

Compute Element

3 ERP

WFEngine

2.1 ERP

1

Compute Element

Grid/Cloudmediation

Участник A

Участник B

Участнк C

ERP

Платформа за изпълнение на

работните потоци

Платформа за моделиране на работни потоци

Разпределение и управление на работните потоци

Хранилище за работни

потоци

WFEngine

WFEngine

Grid/Cloudmediation

Grid/Cloudmediation

Grid/Cloudmediation

Compute Element

Compute Element

Текстово описание

Графично представяне

Изпълнима форма

Фиг. 1 Архитектура на платформата при няколко партньора

Платформата по своята същност представлява виртуална организация

(обслужва бизнес взаимоотношенията). Управлението на ресурсите/услугите се поддържа от глобално хранилище, достъпно до всички партньори, чрез интерфейс за web услуги, съобразно принципите на Грид и „облачните“ изчисления.

Необходим е и каталог, в който да се съхраняват работните потоци, подобно на предоставяния от проекта myexperiment.org, който предоставя среда, в която изследователите могат да публикуват своите работни потоци и in silico експерименти.

2.2 Обобщена архитектура на ниво отделен партньор

Всеки отделен партньор разполага със собствена система, предоставяща

достъп до изчислителните ресурси. Необходим е информационен обмен между нивото, което представя услугите и съответните ресурсни брокери, управляващи разпределението на задачите на високопроизводителните компютърни системи (Фиг. 2).

10

Графичен потребителски интерфейл

Потребители Администратори

Управление на работните потоци

Услуги

Пращане на задачи

Ресурсни брокери

Изчислителни ресурси

Middleware

Глобални ресурси

Презентационен слой

Фиг. 2 Обобщена архитектура на ниво отделен партньор

Платформата може да взаимодейства с различни ресурсни брокери, чрез

набор от Middleware (bridges) и автоматично да разпределя заявките към тях, предоставяйки унифициран достъп до ресурсите, както и мониторинг на процесите.

Към архитектурата на системата са поставени изисквания да предоставя високопроизводителни изчислителни и информационни ресурси като услуги в ГРИД и „облачни” среди, като за осъществяване на достъпа до съответните ресурсни брокери, управляващи разпределението на задачите, е необходим междинен слой “Middleware”.

На върха на предложената архитектура е презентационен слой, чрез който потребителят може да управлява своите задачи за изпълнение в ГРИД и изобщо услугите, предлагани от „облака“.

При такова ниво на абстракция архитектурата естествено наподобява класическата Грид архитектура. Специфичните особеностите на конкретното решение са описани в следващия раздел.

2.3 Архитектура на платформата за in-silico изследвания

Основните компонентите, изграждащи платформата са представени на

(Фиг. 3). Архитектурата представя конкретните технологии, с които да бъде изградена платформата за предоставяне на информационни услуги в ГРИД и „облачни“ среди. Характерна особеност е наличието на различни интерфейси за достъп.

Като нов компонент се появява сървърът за бизнес услуги. Неговата роля е да предоставя услуги свързани с поддръжката на бизнес процесите, като пращане на електронна поща, текстови съобщения и др.

11

Услуги

Пращане на задачи

Ресурсни брокери

Middleware

Глобални ресурси

Презентационен слой Портал

Браузър

ssh

Сигурна връзка

WSIface

WSIface

WSIface

WSIface

е-мейл, SMS и др.

ERP

Клиент заWeb УслугиREST/SOAP

Терминал

WSIface

Taverna WorkflowEngine

Python сървър

Изчислителни възли

Рес

рус

ен м

ени

дж

ър

Компютърен клъстер 1

WSIface

BPEL WorkflowEngine

Клиент заWeb Услуги

SAOP

https

Bas

h с

кри

пт

Мобилен клиент

Компютърен клъстер 2

REST service

OC Android

MD

Каталог

SKB

Бизнес услуги

WSIface

Фиг. 3 Архитектура на платформата за in-silico изследвания

Предпочетени са две различни системи за управление на работните потоци. Първата е базирана на сървър Аpache ODE BPEL и е предназначена предимно за бизнес процесите. Втората е базирана на системата Taverna, която е оптимизирана за научни работни процеси. Имплементиран е също така и мобилен клиент за управление на работните потоци на сървъра Taverna.

Платформата поддържа интерфейси REST и SOAP, но тенденциите са за постепенно отпадане на SOAP.

Предполага се, че всеки от участниците притежава собствена ERP система, която съдържа информация за неговите клиенти, но е предвиден и каталог за услуги достъпен отдалечено през RESTful API, в който да се съхранява информация за услугите, предлагани от партньорите във виртуалната организация.

Платформата би могла да комуникира с разнородни изчислителни ресурси, но за конкретната имплементация са предпочетени ресурсните

12

брокери Simple Linux Utility for Resource Management (Slurm) и Portable Batch System (BPS), който са сред най-популярните и използвани.

2.4 Ресурсни брокери и Middleware

След като бъдат изпълнени бизнес операциите от заявката за получаване

на услуга, е необходимо да се прати заявка в съответния формат към изчислителните ресурси, за да се осъществи физическото предоставяне на услугата. Към настоящия момент, обаче, няма наложени стандарти за осъществяване на взаимодействието с изчислителните ресурси в ГРИД, каквито са например TCP/IP протоколите.

Middleware се явява междинно (свързващо) звено, чрез което се осъществява базовият принцип за запазване на хетерогенността при разпределените системи.

Проведените експериментите се базират на различни сценарии в зависимост от използваните ресурсни мениджъри и “Middleware”. Имплементирани са два подхода за комуникация с ресурсните мениджъри. Първият е базиран на bash скрипт, а при втория е създадена собствена услуга (service), която да се изпълнява паралелно с ресурсния мениджър и да предоставя лесно за работа API към външния свят.

Въз основа на проведените проучвания са избрани следните ресурсни мениджъри:

Slurm е предназначен за Linux клъстери. Основната функция е да разпределя достъпа до ресурсите (компютърните възли) на потребителите за определен период от време, така че те да могат да си свършат работата, също така разпределя ресурсите на постъпващите заявки.

PBS (Torque) се състои от един главен възел (node), върху който се изпълнява pbs_server и един или повече изчислителни възела (compute nodes), върху които трябва да се изпълнява pbs_mom. Също е необходимо да има и диспечер на задачите „scheduler”, който обикновено се намира на главния възел и се казва pbs_sched.

2.5 Мотивация за избор на технологии за управление на работни потоци (Workflow management)

За бъдат изпълнени съответните бизнес процеси е необходима програма,

която да интерпретира описаните действия. Системата за управление на работните потоци (workflow management system) позволява на потребителя да дефинира работни потоци за различни типове задачи или процеси.

Изборът на подходяща система за управление на работните потоци е сложна задача, зависеща от множество критерии и в случая се основава на:

Използване на технологии за „оркестрация” като BPEL, които предоставят добавена стойност към разработката: необходимо е графично представяне на всички бизнес и технически процеси, необходимост от

13

функции от високо ниво като паралелизъм, корелация, асинхронни комуникации и т.н;

Използване на класически езици за програмиране (Java, PHP), когато се изисква базова информационна обработка, като например, добавяне в каталога на услугите.

Моделирането на работните потоци минава през три главни фази,

осигуряващи преобразуването на неформалното текстово описание до изпълним работен поток, който може да бъде разположен на платформата за изпълнение WMS (Workflow Management System) (Фиг. 4).

Първо, текстовото описание се формализира и от него се създава графична спецификация във формат BPMN. Този процес се нарича “хореография”. През фазата на изпълнението се вземат спецификациите от хореографията и се съпоставят със съответните изпълними такива, след което работният поток може да бъде разположен и изпълнен (фаза на оркестрация).

Текстово описаниеГрафично

представянеИзпълнима форма

Фиг. 4 Моделиране на бизнес процеси

Платформата, която описва, създава и управлява работни потоци (по

същество бизнес-процеси) с помощта на програмно осигуряване, работещо на една или повече машини WMS е способна да интерпретира описание на процеса, да взаимодейства с участниците в потока дейности и при необходимост да извиква съответните програмни приложения и инструментални среди.

Редакторите за изпълнение на работни потоци зависят от изхода на предишното ниво, а техният изход може да бъде разположен и изпълняван върху системата за изпълнение на работни потоци.

Taverna Workbench е софтуерен продукт, позволяващ графично създаване, редактиране и изпълнение на работни потоци на персонален компютър.

Модулът Taverna Workbench предоставя възможност за моделиране на бизнес процеси. Потребителят моделира процеса, като избира от наличните услуги в средата и ги подрежда за последователно изпълнение. Средата Taverna предоставя възможност на потребителя да създава процеси на базата на съществуващи услуги, както и да добавя нови услуги от налични описания на услуги. Потокът на предаване на информация при изпълнение на процеса е последователен, но е възможно и паралелно изпълнение на услуги. Софтуерът Taverna, предоставя функционалност за наблюдения на процеса и не предоставя възможност за намеса в процеса от човек или възможност за управление на правила за процеса.

14

Заключение

Предложен е концептуален модел на интегрирана платформа за in-silico изследвания в Грид и „облачни“ среди базирана на работни потоци и предоставяща унифициран достъп до високопроизводителни изчислителни ресурси като услуги;

Специфицирани са изискванията към платформата и основните компоненти;

Направен е избор на два вида системи за управление на работните потоци. Първата имплементира BPEL и е базирана на сървър apache ODE. Втората е базирана на сървър Taverna;

Направен е мотивиран избора на ресурсни брокери, като са предпочетени Slurm и BPS;

Анализирани са някои от особеностите, свързани с разработването на middleware за достъп до изчислителните ресурси, като е предложено разработване на собствен сървър, работещ съвместно с ресурсния мениджър, което дава повече възможности за контрол на всички операции и е по-надеждно;

Отчетена е липсата на удобен клиент за управление на сървъра Taverna и е предложено решение за обединяване на технологиите за управление на работните потоци и мобилните технологии, с което да се разширят възможностите за in-silico експерименти пред учените.

III ГЛАВА. ПРОЕКТИРАНЕ НА ПЛАТФОРМАТА

Платформата е интегрирано бизнес решение за автоматизиране на

процесите по предоставяне на услуги в хетерогенни системи, което е напълно контролируемо, стабилно и сигурно. Платформата е изградена от компоненти с отворен код, като повечето от тях са модифицирани в различна степен според специфичните изисквания, а други са целево разработени за конкретната имплементация, но биха могли да бъдат интегрирани и в други системи.

3.1 Разработване на мобилно приложение за управление на работните потоци

Workflow Player е мобилно приложение за изпълнение на работни потоци

изпълнявани на Taverna сървър в облачна изчислителна среда. До колкото е известно се планира пускането на такова приложение, но все още не е налично.

В разгледаното приложение потребителят има достъп до вътрешната памет или картата памет на мобилното устройство, от където да избере предварително съставен с Taverna Workbench работен поток. В текущата първа версия е разработен интерфейс за управление на два работни потока. Като изходните резултати от единия се използват като входни резултати в другия. Приложението позволява по нататъшно надграждане на функционалността, така че да се обработват по-голям брой работни потоци.

15

Преимущества на мобилното приложение за управление на работни потоци: Мобилност, Гъвкавост, Икономичност. В разглеждания проект се използват следните технологии: • Java • Android SDK 7 • Android API 16 • REST API • Taverna Server 2.4.1

Тъй като чрез приложението могат да се управляват работните потоци на сървъра Taverna, то е наречено Workflow Player. За разработването на мобилното приложение са използвани следните програмни средства:

Android Studio 0.2.2;

Taverna Workbench 2.4.0;

Taverna Server 2.4.1;

Poster Plug-in for Mozilla Firefox;

Fiddler Web Debugger (v2.4.4.7 beta).

3.2 Портал за достъп до информационните ресурси

Порталът се базира на проекта gUSE, който от своя страна е базиран на

системата за управление на съдържание Liferay. Имайки в предвид факта, че порталът е базиран на портлети JSR286, наличието на Java дистрибуция е задължително. В инструкциите за инсталация е споменато, че gUSE работи със всички версии от 5.0.95 до 5.5, но опитно беше установено, че най-подходяща е версия MySQL Server 5.1.63.

За да се интегрира порталът на gUSE наречен PGRADE с портала Liferay е необходимо от менюто Go To ↓ в горният десен ъгъл на екрана да се избере Control Panel. От появилият се нов екран се избира My Pages от списъка в ляво. В прозореца в дясно натискаме бутона Import. За да се свърже портала с услугите на gUSE трябва да се достъпи Service Wizard приложението и да

свържем gUSE с PGRADE от адрес: http://localhost:8080/information/

След началният екран се въвежда метода за връзка на gUSE до базата

данни. Използват се името и паролата (guse/guse), и IP адреса до базата данни,

а на следващият екран опционално се попълват емейл сървъра и адреса на администратора.

Ако интеграцията мине успешно, страниците предоставени от PGRADE

ще се появят в списъка под Import бутона и ще бъдат видими за останалите

регистрирани потребители на портала през публичните страници.

16

3.3 Разработване на Middleware за връзка с ресурсния мениджър

Сценарият е имплементиран чрез сравнително проста програма на Python,

работеща като „deamon”, която има отговорността за комуникация с локалният ресурсен мениджър и да предоставя начини за достъп до резултатите от изпълнението на дадена задача (Фиг. 5).

Този „deamon” би могъл да се разшири и да подържа работа с различни ресурсни мениджъри, предоставяйки възможности за работа с отдалечени клиенти, за които да не бъде необходимо да имат потребителски акаунти на сървъра и знание на какъв точно клъстер ще бъде изпълнено тяхното приложение.

При този сценарий, където самият клъстер предоставя като услуга достъп

до ресурсите, са възможни множество различни средства за реализация на по-горните нива.

Фиг. 5 Архитектура на модула за връзка с ресурсните мениджъри

3.4 Каталог на услуги и ресурси

Този каталог съдържа информация, която се споделя между партньорите и

достъпът до данните в него се предоставя като услуга. Като технология за реализация е избрана Java Persistence API (JPA), защото представя данните като класове и обекти, което значително улеснява програмирането.

17

Процесът на свързване на Java обекти с таблици на бази данни и обратно се нарича "Object-relational mapping" (ORM). Java Persistence API (JPA) е вид ORM. JPA е спецификация и има няколко имплементации. По-известните от тях са Hibernate, EclipseLink и Apache OpenJPA. В проекта се използва имплементацията на JPA EclipseLink. JPA дефинира език за заявки, подобен на SQL за статични и динамични заявки към базата. Повечето JPA имплементации дават възможността за автоматично създаване на схема на базата с помощта на мета информацията.

Техническите описания на услуги се отнасят до всички партньори, те са независими от клиентите и са събрани в Service Knowledge Base (или каталог за услуги) на нивото на клъстера. Този каталог съдържа основните глобални знания споделени между всички партньори.

Очевидно е, че понякога няколко различни услуги трябва да бъдат комбинирани, за да се удовлетвори конкретно желание на клиента. В този случай няма смисъл да се описват всички възможни комбинации от услуги в Service Knowledge Basе, a вместо могат да се групират в набор от услуги (Service Set).

Наборът услуги има няколко административни характеристики като дървото на изграждащите услуги, идентификация на потребител, идентификация на офертата, която съответства по партньор (или клъстер), и др. Наборът от услуги се групира в каталог (service set catalogue) локално за всеки участник в клъстера.

Една инстанция на услуга се характеризира със своя списък от характеристики (или атрибути или параметри) с определена стойност, свързани с всяка характеристика в списъка. Всяка задължителна характеристика трябва да присъства в списъка, докато всяка незадължителна характеристика може да присъства само веднъж в списъка. Инстанциите на услугите се съхраняват в база на инстанциите на услугите Service Instance Base (SIB). Всяка инстанция на услуга е свързана с даден набор услуги, определен партньор, който я притежава и определен клиент, който я ползва.

3.5 Разработване на услуги, подпомагащи бизнес процесите

При разработването на всяка сложна бизнес система се достига до

нуждата от имплементиране на email услуга, която да бъде използвана при нужда за комуникиране с клиентите.

JavaMail е Java API, което се използва за изпращане и получаване на email през SMTP, POP3, IMAP. Чрез класът Jersey се извършва реалното изпращане на JSONObject, от който се извличат всички данни за изпращаният e-mail.

Таблица 1 Интерфейс JSON на услугата

senderFullName

string Пълно име на изпращача на съобщението

senderEmail string Еmail на изпращача на съобщението. В зависимост от това дали email сървърът поддържа маскиране на

18

email

content string Съдържание на съобщението

subject string Заглавие на съобщението

emailType string Тип на email съобщението. В зависимост от тази стойност се интерпретира по различен начин съдържанието content. PlainText - съдържанието се интерпретира като чист текст. При въведен html не се интерпретират таговете.

recipients array Получатели на съобщението. Формат:

[ { “test@tu-sofia.bg” } , { “s_tsvetanov@tu-sofia.bg” } ]

attachments array Прикачени файлове. Формат: [ { "fileName" : "some_image_id.jpg", "fileContents" : "BASE64" } ]

Email услугата се конфигурира през xml файл, намиращ се в WebContent/WEB-INF/lib.

<?xml version="1.0" encoding="UTF-8"?>

<Settings>

<SmtpServer>smtp.gmail.com</SmtpServer>

<username>tusofiawebservice@gmail.com</username>

<password>tu-sofia123</password>

</Settings>

Заключение

Имплементирана е платформа, позволяваща на даден участник да стартира елементарни административни дейности върху набор услуги или инстанции на услуги;

Имплементирани са два вида системи за управление на работните потоци. Първата е базирана на apache ODE BPEL сървър, а втората е на сървър Taverna;

Разработен е информационен портал, който позволява пращане на задачи на компютърните клъстери. Разработен е middware за комуникация с ресурсни брокери Slurm и BPS. Имплементиран е собствен сървър, представящ като услуга достъпa до клъстера, което е по-надеждно и дава повече възможности за контрол на всички операции;

Имплементиран е каталог за услуги достъпен отдалечено през RESTful API, чрез който партньорите във виртуалната организация могат да споделят информация за предоставяните от тях услуги. Предложен е подход за

19

декомпозиране на услугите като изграждащи блокове и представянето им в база знания;

Разработена е услуга за изпращане на електронна поща, която е необходима за поддържане на бизнес процесите.

Имплементиран е удобен клиент за управление на сървъра Taverna, който чрез обединяване на софтуера за управление на работните потоци и мобилни технологии разширява възможностите за експерименти и значително улеснява използването на платформата.

IV ГЛАВА. ИМПЛЕМЕНТАЦИЯ НА ПЛАТФОРМАТА И АНАЛИЗ НА РЕЗУЛТАТИТЕ

С цел прилагане на систематичен подход при проверката на

работоспособността на системата са разработени различни тестови сценарии, проверяващи взаимодействието между отделните компоненти и гарантиращи достоверни резултати.

Предоставяне на услуга;

Взаимодействие между клиента и системата;

Взаимодействието на Middleware - автоматизирането на техническите процеси взаимодействащи с изчислителните ресурси;

Възможността за взаимодействие с различни доставчици на услуги;

Разполагането на услугите.

4.1 Мобилно приложение за управление на работни потоци в биоинформатиката

Този тест цели да провери работоспособността на приложението, чрез

използване на проста услуга, която при получаване на съответен идентификатор, осъществява търсене в база данни и връща секвенция във формат fasta. За краткост услугата като и свързания с нея работен поток, ще бъдат наричани също fasta. Тази услуга би могла да представлява част от процес по създаване на нови лекарства Computer-Aided Drug Discovery (CADD).

В биоинформатиката, FASTA е текстово базиран формат за представяне на нуклеотидните или пептидни последователности, в които нуклеотиди и аминокиселини са представени чрез едно-буквени кодове. Следва пример за последователност във формат FASTA:

>gi|5524211|gb|AAD44166.1| cytochrome b [Elephas maximus maximus]

LCLYTHIGRNIYYGSYLYSETWNTGIMLLLITMATAFMGYVLPWGQMSFWGATVITN

LFSAIPYIGTNLVEWIWGGFSVDKATLNRFFAFHFILPFTMVALAGVHLTFLHETGSN

NPLGLTSDSDKIPFHPYYTIKDFLGLLILILLLLLLALLSPDMLGDPDNHMPADPLNTPL

20

След като потребителят стартира приложението, трябва да премине през автентикация, за да получи достъп до сървъра Taverna.

Стъпка 1: Потребителят попълва своето потребителско име („User Name“). Стъпка 2: Потребителят попълва своята парола („Password“). Стъпка 3: Потребителят изпраща своето потребителско име и парола за верификация, чрез натискане на бутона „Log in“

След успешна автентикация на потребителя в системата, той бива пренасочен към екрана „HOME“. Това е основният екран в приложението, в който се реализира навигацията.

За да качи свой файл с работен поток на сървъра, потребителят натиска бутон „Upload“ от екран „Home“ и бива пренасочен към екран „Upload“, a за да избере работен поток, той натиска бутон „Select flow“. В резултат се отваря нов екран наречен „File picker“

В този екран потребителят получава достъп до вътрешната памет и/или картата памет, където се съхраняват работните потоци. В разгледания случай работните потоци се намират във вградената памет на телефона (…\sdcard\), директория “Flows”.

Потребителят избира желания файл, чрез натискане върху неговото име, след което бива пренасочен обратно към екран „Upload“. Selected Flow показва пътя до избрания работен поток.

Фиг. 6 Въвеждане на входни данни - генен идентификатор и получаване на изходните резултати във формат Fasta

21

При получаване на отговор от сървъра, в долния край на екрана над бутона “Upload“ се изписва съобщение за статуса на заявката. При получен отговор от сървъра „201 Created“съобщението гласи „File uploaded“. При получаване на код за грешка съобщението гласи „File not uploaded! Error: <Error Code>“.

Потребителят подава като входни данни - генен идентификатор в полето “Input data” (Фиг. 6). Чрез натискане на бутон „Submit“, данните се изпращат към входящия порт ID на FASTA работния поток.

При натискане на бутона „Submit“ последователно се изпращат входните данни за работния поток и се променя неговия статус от “Initialized” в “Opearting”. Целта на последователното извикване на двете функции е оптимизиране на времето за изпълнение на работния поток и подобряване на потребителския опит.

Сървърът Taverna не връща автоматично отговори при изпълнение на работните потоци, ето защо се налага потребителят да проверява периодично статуса на изпълнявания работен поток.Това се осъществява чрез натискане на бутона „Flow Status“.Ако работният поток все още се обработва, статусът е „Operating“.

Когато сървърът върне отговор „Finished“ след проверка на статуса на работния поток се променя стойността на поле „Status“ от „Operating“ на „Finished“ и автоматично се прави заявка към сървъра за изходните резултати. В разглеждания случай изходните резултати се изпращат с GET заявка към изходния порт „Sequence“ на работния поток.

След получаване на изходните данни потребителят изтрива създадения работен поток, чрез натискане на бутона „Stop Flow“.

4.2 Портал за достъп до изчислителните ресурси

Функционалността на разработения портал се тества чрез създаване и

изпълнение на примерен работен поток. Създаването на работния поток е показано на (Фиг. 7)

Фиг. 7 Създаване на работен поток

22

След това е необходимо да се конфигурира вида на изпълнимия файл, като се избира MPI и се указва брой процесори за изпълнение.

Следенето на статуса на стартираните през портала работни потоци е показано на Фиг. 8.

Фиг. 8 Статус на стартираните през портала работни потоци

Разработен е работен поток, който прави сравнение на резултати от

изпълнението на три изчислителни задачи. Получените резултати от изпълнението, както и тяхното сравнение, се изписват на конзолата след изпълнение на всичките задачи.

4.3 Сървър за работни потоци, базиран на BPEL и модул за управление

Целта на този тест е да се провери работоспособността на сървъра за

работни потоци BPEL, ERP системата и услугата за пращане на електронна поща, според представената на схема (Фиг. 9).

Този експеримент демонстрира описването на бизнес процеси като BPEL с помощта на Eclipse BPEL дизайнери и разполагането в WSO2 BPS BPEL Exporter.

Разработената платформа е базирана на мащабируема и разпределена технология (SOA), където всички услуги и компоненти са представени като web услуги, описани от WSDL интерфейси. Компонентите са в XML формат и са лесни за обработка от интерфейси WSDL, изпълними технически процеси (BPEL) и други.

23

Submit a service demand

Receiving a request

Check the customer status

Check the service status

Retrieving customer details

Check validity of the service

Retrieving the price of the service

Updating the customer account

Provisioning of the service

Confirming the avaiability of the service

Error message

CRM

OSS WS

CRM

CatalogERP

Accounting ERP

Store ERP

OSS

WorkflowEngine

BSS/OSS

Error message

Error message

Email explaining the refusal of the

service

Email notifying about the

provisioning

Фиг. 9 Работен поток „Предоставяне на услуга“

Тези компоненти, както и техническите процеси, на свой ред могат да

бъдат извиквани от външни приложения. Разработени са и постоянно се развиват нови middleware приложения за взаимодействие с нови OSS (например мрежови елементи, сървъри и т.н.) и BSS (напр. ERP) компоненти. Базовият софтуерен пакет се свързва посредством middleware, приложения с мрежови компоненти и сървъри през прокси web услуги, и др. С поставянето на този междинен слой (middleware приложения) между разработената платформа и OSS или BSS системите, се гарантира сигурността на предаваните данни - комуникацията межди тези мрежови елементи е кодирана, т.е. разработената платформа не е необходимо да знае или да управлява данни или пароли към BSS и OSS компоненти.

24

4.4 Тестов сценарий 1

Целта на този тест е да се потвърди работоспособността на основната

функционалност на платформата, а именно да предоставя средства за in-silico изследвания като услуги.

Представената услуга извършва множествено подравняване на секвенции, чрез използване на програмата clustalw2. Тази услуга е подходяща за целите на експериментите, защото MSA изчисленията са с висока алгоритмична сложност (NP-трудни) и имат сравнително малки входно изходни данни.

Като вход се подава файл в Fasta формат съдържащ множество последователности. Множествена последователност във FASTA формат може да се постигне чрез сливането на отделни последователности, както на примера по-долу.

При този сценарии се тестват основните компоненти на платформата, като се преминава през графичния интерфейс, слоят предоставящ услугите, междинния слой осъществяващ връзката с глобалните изчислителни ресурси и конкретните операции на конкретния компютърен клъстер (Фиг. 10).

Услуги

Пращане на задачи

Ресурсни брокери

Middleware

Глобални ресурси

Презентационен слой Портал

Браузър

sshСигурна връзка

WSIface

Python сървър

Изчислителни възли

Ре

срус

ен

ме

ни

дж

ър

Компютърен клъстер 1

httpsB

ash

скр

ип

т

Фиг. 10 Последователността от операции при предоставяне на услугата множествено подравняване на секвенции

25

Фиг. 11 Конфигуриране на входен порт и прикачване на входен файл за работния поток

Първоначално е необходимо да се конфигурира създадения работен поток, като за тип на изпълнимия файл се избира MPI и се указва брой процесори за изпълнение и като параметър се задават имената на входния и изходния файл които трябва да съвпадат с имената на портовете (Фиг. 11).

След това е необходимо да се укаже име на изходен порт и след като бъдат записани направените промени, може да се стартира работният поток.

След като процесът се е изпълнил успешно, потребителят може лесно да достъпи изходните данни (Фиг. 12).

Фиг. 12 Достъп до изходните данни за даден процес

26

На Фиг. 13 е показано съдържанието на входния файл, а на Фиг. 14 съдържанието на изходния, където се вижда подреждането на секвенциите.

Фиг. 13 Съдържание на входен файл съдържащ неподредени секвенции

Фиг. 14 Съдържание на изходния файл съдържащ подредените секвенции

4.5 Тестов сценарий 2

При този сценарии се верифицира възможността чрез разработеното

мобилното приложение да се управляват сложни работни потоци интегриращи множество услуги.

InterProScan е инструмент, който комбинира различни методи за разпознаване на протеинови сигнатури в един ресурс. Броят на бази данни на сигнатурите и свързаните с тях инструменти за сканиране, както и допълнителното усъвършенстване на процедурите, увеличава сложността на проблема.

Моделите са изградени от аминокиселините последователности на известни семейства или домейни и впоследствие се използва за търсене и класифициране на неизвестни последователности (такива като тези, произтичащи от ново открити последователности в генома).

Последователности се подават във формат FASTA, изчисляват се съвпаденията със сигнатурите в базата данни, a резултатите се подават на изхода в различни формати. Входни данни на InterProScan InterProScan може да приеме нуклеотидна или протеинова секвенция в стандартен формат като суров формат, FASTA или EMBL. Той ще преформатира секвенцията, ако е необходимо и ще я транслира, преди да започне с изпълнението на задачите за търсене.

27

Изходни данни на InterProScan InterProScan подава като изходни данни резюме на хомоложните секвенции, текстови и XML файлове, съдържащи съвпадения и графика, която показва съвпаденията и къде те се случват в последователността. Хомоложност - сходство между секвенции, което по презюмция идва от общ прародител.

Изходните данни се представят като текст, XML или изображение в PNG формат. Той използва новите услуги на Европейския институт по биоинформатика (EBI), които са асинхронни и изискват многократно преминаване през вложен поток (Status) до завършването на работния поток. Стъпка 1: Качване на работен поток

Тази стъпка е напълно аналогична на Стъпка 1, Изпълнение на работен поток Fasta. Единствената разлика е в избора на файла, съдържащ работния поток : ebi_interproscan_newservices_702837.t2flow. Заявка: POST http://81.161.243.95/tavernaserver/rest/runs HTTP/1.1 Content-Type: application/vnd.taverna.t2flow+xml Authorization: Basic dGF2ZXJuYTp0YXZlcm5h Content-Length: 103069 Host: 81.161.243.95 Connection: Keep-Alive Отговор: HTTP/1.1 201 Created Server: nginx/1.2.6 (Ubuntu) Date: Sat, 31 Aug 2013 20:54:16 GMT Content-Length: 0 Connection: keep-alive Location: http://81.161.243.95/tavernaserver/rest/runs/3f3287be-b856-4315-87b8-14e5d414f94c Стъпка 2: Въвеждане на входни данни

Този работен поток има два входни порта „email“ и „sequence“. За правилното му изпълнение потребителят трябва да подаде следните данни:

e-mail адрес;

нуклеотидна или пептидна последователност във формат FASTA. Чрез натискане на бутон „Submit“, данните се изпращат с две

последователни PUT заявки към входящите портове. Заявка: PUT http://81.161.243.95/tavernaserver/rest/runs/3f3287be-b856-4315-87b8-14e5d414f94c/input/input/email HTTP/1.1

28

Content-Type: application/xml Authorization: Basic dGF2ZXJuYTp0YXZlcm5h Content-Length: 177 Host: 81.161.243.95 Connection: Keep-Alive <?xml version="1.0" encoding="UTF-8"?> <t2sr:runInput xmlns:t2sr="http://ns.taverna.org.uk/2010/xml/server/rest/"> <t2sr:value>taverna@test.com</t2sr:value> </t2sr:runInput> Отговор: HTTP/1.1 200 OK Server: nginx/1.2.6 (Ubuntu) Date: Sat, 31 Aug 2013 20:56:28 GMT Content-Type: application/xml Content-Length: 707 Connection: keep-alive Стъпка 3: Стартиране на работния поток

При натискане на „Submit“ бутона последователно се изпращат входните данни за работния поток и се променя неговия статус от “Initialized” в “Opearting”. Целта на последователното извикване на функциите е оптимизиране на времето за изпълнение на работния поток и подобряване на потребителския опит. Стъпка 4: Проверка на статуса на работния поток

Taverna сървъра не връща автоматично отговори при изпълнение на работните потоци, ето защо се налага потребителя да проверява периодично статуса на изпълнявания работен поток.Това се осъществява, чрез натискане на бутона „Flow Status“.Ако работния поток все още се обработва статуса е „Operating“. Стъпка 5: Извеждане на изходни резултати

Когато сървърът върне отговор „Finished“ след проверка на статуса на работния поток се променя стойността на поле „Status“ от „Operating“ на „Finished“ и автоматично се прави заявка към сървъра за изходните резултати. В поле “Output data” потребителят получава линк към изходните данни, които са в формат PNG. Потребителят може да копира линка и да го обработи по удобен за него начин или да го отвори директно чрез натискане на бутон „Open“.

29

Фиг.15. Въвеждане на входни данни и извеждане на изходни резултати на работения поток в PNG формат

Стъпка 6: Извеждане на изходни резултати

При натискане на бутон „Open“ изходните резултати се зареждат в нов екран, удобен за преглед на направения анализ (Фиг. 15). След преглед на резултатите потребителят може да се върне към предходния екран, чрез натискане на системния „back“бутон.

Заключение

Проведените експериментите се базират на различни сценарии в зависимост от използваните ресурсни мениджъри и “Middleware”;

Тествани са системите за управление на работните потоци базирана на BPEL apache ODE сървър и на Таверна сървър. Чрез използването на тези технологии е постигната по-добра ефективност, съвместимост и гъвкавост на процесите, което улеснява както ползвателите, така и доставчиците на услугите;

30

Тествана е функционалността на разработения модул за комуникация между информационния портал и специфични ресурсни мениджъри, който позволява представянето на специфичните приложения за in-silico научни изследвания като информационни услуги;

Тествана е основната функционалност на информациония портал, middeware нивото и ресурсните мениджъри, чрез експерименти с реални данни от биоинформатиката;

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

ЗАКЛЮЧЕНИЕ

В настоящата разработка e предложено решениe за автоматизиране на

процесите по предоставяне и управление на услуги, както и други операции, извършвани като част от целия жизнен цикъл на услугите в ГРИД и „облачни” среди.

Разработената платформа в последствие може да бъде доразвивана чрез

включване на допълнителни функции за обогатяване на модулите и интеграция в intercloud.

Експериментално е потвърдена заложената функционалност на

платформата чрез прилагане на изследвания в областта на биоинформатиката, като търсене на геномна секвенция в геномни бази данни и множествено подравняване на геномни секвенции.

Разработената платформа позволява автоматизиране на процесите по

предоставяне на информационни услуги в разпределени системи стабилно и сигурно. Реализирания софтуерен продукт е SOA ориентиран и комуникира с външни приложения чрез технологията web услуги, което позволява разработените технологии да се прилагат в различни области, където се изисква интегриране на информационни ресурси.

ПРИНОСИ

Извършено е изследване и анализ на методи и средства за предоставяне

на услуги и управление на работните потоци в Грид и „облачни“ среди, въз основа на което е предложен модел и съответната архитектура за изграждане на платформа, предоставяща високопроизводителни изчислителни ресурси като услуги.

Проектирана е и е имплементирана система за управление на работните потоци с удобен потребителски интерфейс, позволяваща интегрирането на услугите в комплексни конвейерни структури.

31

Проектиран е и е имплементиран каталог за състоянието на услугите, както и схема за тяхното описание и декомпозиране.

Изграден е потребителски портал, през който удобно и лесно да се използват услугите, както и middleware за достъп до съответните ресурси.

Разработени са тестови сценарии за верификация и оценка на ефективността на платформата, които потвърждават постигнатото ниво на улеснение при представянето на изчислителните ресурси като услуги и тяхната интеграция в работни потоци.

СПИСЪК С ПУБЛИКАЦИИТЕ ПО ДИСЕРТАЦИЯТА

1. Tsvetanov S. ,Applying workflow principles for network devices’ International

Conference ETAI, Ohrid, Macedonia, 19-21 September, 2007, Т1-4.

2. Tsvetanov S. ,Tsenov M. ,Trichkov K.,Open source solution for workflow execution archtecture’ Compsystech, 14-15 June, 2009, Rousse, Bulgaria, 2009, IIIA.14.1- IIIA.14.6 (The paper was awarded as Best Paper in Session IIIA “Application Aspects of Computer Systems and Technologies”)

3. Tsvetanov S., Methodology for Service Decomposition and Technical Process Modelling in ICT Domain, Proceeding of the International Scientific Conference "Informatics In The Scientific Knowledge 2010", Varna, Bulgaria, June 26-28 2010

4. Цветанов, С., „Управление на работните потоци при предоставяне на изчислителни ресурси за научни изследвания в ГРИД и "облачни" среди”, „Национална школа и борса за научни идеи в областта на информационните на комуникационни технологии”, 27-29 юни 2013, Русе, България, 206-211.

5. Боровска, П., Докомес, Х., Ганчева, В., Цветанов, С.,„Архитектура на ГРИД ресурсен брокер базиран на модел за планиране с метаданни”, Computer and Communications Engineering, 2013

Внедряване на резултатите

Резултатите от дисертационния труд са внедрени в проект FFNNIPO_12_01386 „Виртуален център за трансфер на in-silico scientia и технологии ViSTa“, както и в учебния процес по дисциплината „Облачни изчисления и Грид“

32

SUMMARY Nowadays, grid and cloud technologies have been implemented and promoted in

order to overcome the complexity of using distributed, heterogeneous computer systems by providing reliable services to the users.

Increasing of computing power extensively allows the usage of computer simulations for speedup the rate of discovery while reducing the need for expensive lab work and trials.

As research process becomes more data-intensive and more reliant on the usage of computers, the experiments existing inside the computers, so called in-silico, become an important factor in almost any scientific research.

The in silico experiments provide a lot of advantages, but suffer from an increased complexity of simulation systems, which often include a range of heterogeneous components. Interaction with such kind of systems involves a great amount of purely computing aspects and the regular researcher may have difficulties to use them.

The major goal of the thesis is developing a workflow-based integrated platform for in-silico experiments in grid and cloud environments. The platform interacts with different service providers and global resources through abstract middleware.

There are two global objectives: The first one is to present the complex high-performance computing resources as services and the second one - to decompose and combine those services as building blocks into complex structures called workflows.

The thesis proposes a conceptual model of a workflow-based integrated platform for in-silico experiments in grid and cloud environment which is based on service oriented architecture. The architecture specifies the system components and it is also used for choosing the suitable technologies in order to provide unified access to computing resources.

Abstract middleware for hiding the specific features of the computing resources has been developed using tailored Python server running on the computer clusters. That solution increases the reliability and provides better control for all technical operations.

The information portal interacts with the resource managers Slurm and PBS via the developed middleware and provides the users with opportunity to transparently run jobs on the multiprocessor computer clusters.

Service catalogue and scheme for service decomposition have been designed for sharing information between the partners regarding the available services. The service catalogue and all business support services provided by the platform are accessible via RESTful API.

The service oriented modular architecture of the platform allows the building component to be changed. In particular there are two workflow managements systems. One for business workflows based on Apache ODE Server and another for scientific workflows witch is based on Taverna server.

Mobile application client for Taverna server have been have implemented. Taverna allows users to upload and manage their own workflows. In this way the workflow software is presented as a service.

The efficiency of the developed platform has been verified and evaluated experimentally in very scientific experiments. Testing scenarios for services life cycle have been applied. The basic functionality of the platform covering the business and technical processes and system integration has been applied for in-silico experiments with bioinformatics datasets.