Интеллектуализация платформ для Cloud Computing (часть 2)

Краткая характеристика UFoCuP. Модифицированный стек облачных вычислений приведен на рис. 1. Управляемый агентами фреймворк замещает для облачного приложения API классической SEAP платформы.

Место управляемого интеллектуальными агентами API в стеке облачных вычислений

Рис. 1. Место управляемого интеллектуальными агентами API в стеке облачных вычислений

UFoCuP встраивается в стек облачных вычислений аналогичным образом (рис. 2).

Как видно из рис. 2, сервисы UFoCuP находятся для конечного пользователя на уровне обслуживаемых им SaaS-приложений и при желании могут даже заместить их. Т.е. пользователь имеет возможность запросить у платформы выполнение некоторой услуги, не указывая, какой из расположенных на ней сервисов должен обработать запрос. В этом случае платформа сама выбирает исполнителя по нескольким критериям, которые будут описаны далее.

Стек облачных вычислений при использовании UFoCuP

Рис. 2. Стек облачных вычислений при использовании UFoCuP

Основные новые задачи UFoCuP приведены в табл. 1.

Таблица 1

Задачи UFoCuP в контексте взаимосвязи с пользователем и опубликованным на платформе службами

Задачи UFoCuP в контексте взаимосвязи с пользователем и опубликованным на платформе службами

Далее приводятся методики реализации перечисленных задач UFoCuP.

Методика поиска и вызова необходимой службы, среди служб, развернутых на платформе, по семантическому описанию. Для обеспечения возможности поиска службы по описанию, близкому к естественному, предлагается привязывать к службе семантическую аннотацию. Ранние работы, посвященные методам компарации программных компонент, отдавали предпочтение сравнению их сигнатур и спецификаций, представленных как набор ограничений на методы и свойства программного элемента: инварианты, пред/пост условия выполнения методов. Этот подход эффективен для описания низкоуровневого поведения компонента, но слишком громоздок для формализации его назначения и возможностей. Известен также простой подход к описанию веб-службы набором ключевых слов, как предлагается в работе. В этом случае поиск по такому описанию должен вестись чисто статистическими методами, наподобие TF*IDF, со всем присущими им недостатками. В данной работе для описания, а, следовательно, поиска по запросу клиента предлагается использовать метод семантического аннотирования ресурса, основанный на технологии Semantic Web. Данный подход является продолжением методики к описанию профиля веб-сервиса на основе онтологической модели OWL-S (профиля OWL для описания веб-сервисов). В этой модели значительное внимание уделяется аннотации параметров сервиса и входящих в него процессов, но недостаточно развит раздел, описывающий категорию, к которой относится веб-сервис. Описание и поиск сервиса на основе расширенной аннотации его категории дополнит существующую модель и позволит значительно упростить и ускорить выполнение наиболее важных и часто решаемых UFo-CuP задач 1 и 2 (табл. 1).

Предлагаемая структура аннотации — это набор триплетов «объект-атрибут-значение», формализующих совершаемое сервисом действие и объект, над которым это действие выполняется. Такая структура аннотации упрощенно формализует отношения между частями простого предложения (верхний ряд примитивов на рис. 1). Пример аннотации сервиса по «Информированию о географическое местоположении объекта наблюдения» приведен на рис. 3.

Пример экземпляра аннотации сервиса

Рис. 3. Пример экземпляра аннотации сервиса

Для поиска службы по такому семантическому описанию предлагается запрос пользователя строить как аннотацию аналогичного вида и отбирать и упорядочивать все предоставляемые платформой службы путем вычисления степени семантической эквивалентности двух программных компонентов по их аннотациям. Степень семантической эквивалентности может быть выражена с помощью одной из метрик расстояния между двумя RDF графами, вычисляемых на основе сравнения использованных в них понятий, определенных в единой онтологии задач.

Аналогичные аннотации, но прикрепленные к параметрам веб-службы, позволят не только детализировать критерии поиска, но и вызывать службу на основе её OWL-S описания. С их помощью в момент вызова становится возможным сопоставлять параметры, передаваемые клиентом в службу, с ожидаемыми ею параметрами. При этом больше нет необходимости привязываться при сопоставлении к таким негибким критериям, как имя или порядковый номер параметра.

Читайте также:

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.