СИСТЕМА И СПОСОБ ДЛЯ ОБЪЕДИНЕНИЯ УПРАВЛЕНИЯ РЕСУРСАМИ МЕЖДУ СЕРВИСАМИ ПРИЛОЖЕНИЙ И ПРИЛОЖЕНИЯМИ Российский патент 2009 года по МПК G06F13/00 

Область техники

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

Предшествующий уровень техники

В традиционных системах управления ресурсами сервисы приложений обычно выполняют функции во взаимосвязи с приложениями. Такие сервисы приложений могут управлять каждый различными компонентами ресурса. Например, два сервиса приложения могут управлять различными компонентами способа санкционирования ссуды. А именно первый сервис приложения может управлять компонентом истории кредита в способе санкционирования ссуды, тогда как второй сервис приложения может управлять компонентом первоначальной оплаты в способе санкционирования ссуды. Каждый сервис приложения может управлять связанными объектами услуг, ассоциированными со способом санкционирования ссуды. Например, первый сервис приложения может управлять объектами сервиса "заявитель", тогда как второй сервис приложения может управлять связанными объектами сервиса "ссуда".

Приложения, работающие во взаимодействии с сервисами приложений, могут быть, например, приложениями электронной почты, приложениями обработки текста или приложениями электронных таблиц, которые делают возможным выпуск документов. Такие документы могут зачастую называться объектами сервисов и оказывать влияние на управление объектами сервисов в сервисах приложений. Например, документ может включать в себя текст: "Джон Смит пропустил платеж по кредитной карте". "Джон Смит" может быть экземпляром как объекта "заявитель", управляемого первым сервисом приложения, так и объекта "ссуда", управляемого вторым сервисом приложения. Таким образом, документ может воздействовать на управление объектом "Джон Смит" "заявителя" и объектом "Джон Смит" "ссуды". Конкретно документ может воздействовать на пользователя для изменения состояния объекта "Джон Смит" "заявителя" в первом сервисе приложения на состояние "отказать в ссуде". Документ может также вызвать состояние объекта "Джон Смит" "санкционирования ссуды" во втором сервисе приложения для изменения состояния "возместить первоначальную оплату".

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

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

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

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

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

Сущность изобретения

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

Приложение сохраняет метаданные приложения, соответствующие объектам приложения. Когда объект приложения выбран в приложении, сервис исполнения может извлечь метаданные приложения, соответствующие выбранному объекту приложения, и передать такие метаданные приложения в контекстный сервис.

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

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

Дополнительные признаки и преимущества изобретения поясняются в последующем подробном описании иллюстративных вариантов выполнения со ссылками на чертежи.

Краткое описание чертежей

Иллюстративные варианты выполнения поясняются в последующем подробном описании со ссылками на чертежи, на которых

Фиг.1 - блок-схема, представляющая универсальную компьютерную систему, в которой могут быть реализованы аспекты настоящего изобретения и/или его части;

Фиг.2 - блок-схема приведенной для примера существующей системы управления ресурсами;

Фиг.3а и 3b - блок-схема алгоритма, приведенного для примера бизнес-способов;

Фиг.4 - примерный документ;

Фиг.5 - блок-схема приведенной для примера системы управления ресурсами в соответствии с настоящим изобретением;

Фиг.6 - приведенный для примера пользовательский интерфейс приложения в соответствии с настоящим изобретением;

Фиг.7а и 7b - блок-схемы алгоритма приведенного для примера способа для управления объектами сервисов из приложения в соответствии с настоящим изобретением; и

Фиг.8 - пример пользовательского интерфейса приложения, включающий в себя доступные действия в соответствии с настоящим изобретением.

Подробное описание иллюстративных вариантов выполнения

I. Иллюстративная компьютерная среда

Фиг.1 и последующее обсуждение предназначено для обеспечения краткого общего описания соответствующей компьютерной среды, в которой может быть осуществлено настоящее изобретение и/или его части. Хотя это и не требуется, изобретение описано в общем контексте компьютерно-выполняемых команд, таких как программные модули, выполняемые компьютером, таким как клиентская рабочая станция или сервис приложения. Как правило, программные модули включают в себя подпрограммы, программы, объекты, компоненты, структуры данных и тому подобное, что выполняет частные задачи или воплощает частные абстрактные типы данных. Кроме того, следует иметь в виду, что изобретение и/или его части могут быть осуществлены с другими конфигурациями компьютерной системы, включающими в себя карманные устройства, многопроцессорные системы, основанную на микропроцессорах или программируемую бытовую электронику, сетевые ПК, мини-компьютеры, мейнфреймовые компьютеры и т.п. Изобретение может также быть осуществлено в распределенных вычислительных средах, где задачи выполняются удаленными устройствами обработки, которые соединяются через сеть связи. В распределенной компьютерной среде программные модули могут быть расположены как в местных, так и в удаленных устройствах памяти.

Как показано на Фиг.1, универсальная компьютерная система включает в себя обычный персональный компьютер 120 или тому подобное, в том числе блок 121 обработки, системную память 122 и системную шину 123, которая соединяет различные системные компоненты, включая системную память, с блоком 121 обработки. Системная шина 123 может иметь любую из нескольких типов шинных структур, в том числе шину памяти или контроллер памяти, периферийную шину и местную шину, используя любую из множества шинных архитектур. Системная память включает в себя постоянно запоминающее устройство 124 (ПЗУ) (ROM) и оперативную память 125 (ОЗУ) (RAM). Базовая система ввода-вывода 126 (БСВВ) (BIOS), содержащая основные подпрограммы, которые помогают передавать информацию между элементами в персональном компьютере 120, такую как во время запуска, хранится в ПЗУ 124.

Персональный компьютер 120 может далее включать в себя дисковод 127 жесткого диска для считывания с жесткого диска и для записи на него (не показано), дисковод 128 магнитного диска для считывания со сменного магнитного диска 129 и для записи на него и дисковод 130 оптического диска для считывания со сменного оптического диска 131, такого как CD-ROM или другой оптический носитель, и для записи на него. Дисковод 127 жесткого диска, дисковод 128 магнитного диска и дисковод 130 оптического диска соединены с системной шиной 123 интерфейсом 132 дисковода жесткого диска, интерфейсом 133 дисковода магнитного диска и интерфейсом 134 дисковода оптического диска соответственно. Дисководы и их соответствующие машиночитаемые носители обеспечивают энергонезависимую память компьютерно-читаемых команд, структур данных, программных модулей и других данных персонального компьютера 120.

Хотя приведенная для примера среда использует жесткий диск, сменный магнитный диск 129 и сменный оптический диск 131, ясно, что в этой среде могут использоваться и другие типы машиночитаемых носителей, которые могут хранить информацию, доступную компьютеру. Такие другие типы носителей включают в себя магнитные кассеты, карточку флэш-памяти, цифровой видеодиск, картридж Бернулли, оперативное запоминающее устройство ОЗУ, постоянно запоминающее устройство ПЗУ и тому подобное.

Некоторое число программных модулей может быть сохранено на жестком диске, магнитном диске 129, оптическом диске 131, в ПЗУ 124 или ОЗУ 125, в том числе операционная система 135, одно или более приложений 212 программ 136, другие программные модули 137 и программные данные 138. Пользователь может вводить команды и информацию в персональный компьютер 120 через входные устройства, такие как клавиатура 140 и координатное устройство 142, такое как мышь. Другие входные устройства (не показаны) могут включать в себя микрофон, джойстик, игровую приставку, вспомогательный диск, сканнер и т.п. Эти и другие входные устройства часто соединяются с блоком 121 обработки через интерфейс 146 последовательного порта, который связан с системной шиной, но могут соединяться и другими интерфейсами, такими как параллельный порт, игровой порт или универсальная последовательная шина (USB). Монитор или другие типы устройств отображения также соединены с системной шиной 123 через интерфейс, такой как видеоадаптер 148. В дополнение к монитору 147 персональный компьютер включает в себя другие периферийные выходные устройства (не показаны), такие как громкоговорители и принтеры. Система по Фиг.1 также включает в себя главный адаптер 155, шину 156 интерфейса малых вычислительных систем (SCSI) и внешнее устройство 162 хранения, соединенное с шиной 156 (SCSI).

Персональный компьютер 120 может работать в сетевой среде, используя логические соединения с одним или более удаленными компьютерами, такими как удаленный компьютер 149. Удаленный компьютер 149 может быть другим персональным компьютером, сервисом приложения, маршрутизатором, сетевым ПК, одноранговым устройством или другим общим сетевым узлом и обычно включает в себя многие или все элементы, описанные выше, относящиеся к персональному компьютеру 120, хотя на Фиг.1 показано только устройство 150 памяти. Логические соединения, изображенные на Фиг.1, включают в себя локальную сеть 151 (LAN) и глобальную сеть 152 (WAN). Такие сетевые среды используются обычно в офисах, компьютерных сетях предприятий, интранете и Интернете.

При использовании в сетевой среде ЛС персональный компьютер 120 соединен с LAN 151 через сетевой интерфейс или адаптер 153. При использовании в сетевой среде WAN персональный компьютер 120 обычно включает в себя модем 154 или другие средства для установления связи по глобальной сети 152, такой как Интернет. Модем 154, который может быть внутренним или внешним, соединяется с системной шиной 123 через интерфейс 146 последовательного порта. В сетевой среде программные модули, показанные в связи с персональным компьютером 120, или их части могут храниться в удаленном устройстве памяти. Понятно, что показанные сетевые соединения приведены для примера и могут быть использованы другие средства установления линии связи между компьютерами.

II. Иллюстративная среда управления ресурсами

Традиционная система 200 управления ресурсами показана на Фиг.2. Система 200 включает в себя сервисы 210а и 210b приложения, работающие во взаимосвязи с приложением 232 на клиенте 230. Обычно сервисы 210 приложения управляют ресурсами, тогда как приложение 232 представляет и обменивается информацией о таких ресурсах.

Сервисы 210 приложения могут быть такими сервисами приложения, как, например, сервис приложения направления экономической деятельности (LOB), сервисами приложения базы данных, сетевыми сервисами приложения, сервисами приложения принтера и файловыми сервисами приложения. Конкретно сервис 210а приложения может быть сервисом приложения, который управляет компонентом истории кредита в способе санкционирования ссуды, тогда как сервис 210b приложения может быть сервисом приложения НЭД, который управляет компонентом первоначальной оплаты способа санкционирования ссуды.

Процесс 300а компонента истории кредита, управляемый сервисом 210а приложения, показан на Фиг.3а. В состоянии 302а принимается приложение ссуды. В состоянии 304а принимается история кредита. В состоянии 306а определяется, удовлетворительна ли история кредита. Если история кредита удовлетворительна, то затем в состоянии 308а санкционируется ссуда. Если история кредита является не удовлетворительной, то затем в состоянии 310а ссуда не дается.

Процесс 300b компонента первоначальной оплаты, управляемый сервисом 210b приложения, показан на Фиг.3b. В состоянии 302b принимается приложение ссуды. В состоянии 304b запрашивается первоначальная оплата. В состоянии 308а определяется, санкционирована ли ссуда. Если ссуда санкционирована, то затем в состоянии 308b запрашивается первый ежемесячный платеж. Если ссуда не санкционирована, то затем в состоянии 310b возмещается первоначальная оплата.

Сервисы 210 приложения управляют объектами 215 услуг, ассоциированных с процессами 300 компонентов. Сервис 210а приложения управляет объектами 215а и 215а' сервисов, тогда как сервис 210b приложения управляет объектами 215b и 215b' сервисов. Конкретно объект 215а сервиса может быть объектом "заявитель", ассоциированным с процессом 300а компонента истории кредита, тогда как объект 215b сервиса может быть связанным объектом 215b сервиса "ссуда", ассоциированным с процессом 300b санкционирования ссуды. Объекты 215а' и 215b' сервисов могут быть не связанными объектами сервисов, которые специфичны для каждого способа 300а и 300b компонентов, соответственно.

Сервисы 210 приложений могут сохранять сервисные метаданные 205, соответствующие таким объектам 215 сервисов. Сервисные метаданные 205 могут быть определены на языке, таком как, например, расширяемый язык разметки (XML). Сервисные метаданные 205 могут включать в себя атрибуты объектов 215 сервисов и могут также включать в себя уникальные ключи объектов 215 сервисов. Атрибуты объекта 215а "заявитель" и объекта 215b "ссуда" показаны ниже:

Объект 215а "Заявитель"

<applicant> (заявитель)

<ID> 1 </ID> (идентификатор)

<first name> John </first name> (первое имя)

<last name> Smith </last name> (последнее имя)

</applicant> (заявитель)

Объект 215b "Ссуда"

<loan> (ссуда)

<ID> 10 </ID> (идентификатор)

<applicant> (заявитель)

<name> John Smith </name> (имя)

</applicant> (заявитель)

</loan> (ссуда)

Сервисные метаданные 205 могут также включать в себя действия, доступные для объектов 215 сервисов. Такие действия могут быть статическими действиями, которые доступны вне зависимости от состояния процесса объектов 215 сервисов, или динамическими действиями, которые зависят от состояния процесса объектов 215 сервисов.

Статические действия могут быть действиями, такими как, например, действия просмотра и изменения атрибутов объектов 215 сервисов, действия для следования или обучения соотношениям, чтобы видеть связанные объекты, и всегда доступные действия для изменения состояния процесса. Метаданные для просмотра и изменения атрибутов могут включать в себя, например, механизмы предоставления просмотра, такие как запуск диалога.

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

Сервисные метаданные 205 могут также включать в себя информацию о доступе к объектам 215 сервисов. Такие метаданные могут включать в себя, например, ограничения по доступу или ограничения для особого пользователя или группы пользователей к примеру или классу объектов 215 сервисов, статическому действию или отношению. Санкционирование, такое как, например, действующий пароль или идентификатор, может быть запрошено для получения доступа к каждому такому примеру или классу объектов, статическому действию или отношению.

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

Сервисы 210 приложения сообщаются с клиентом 230 через сеть 220. Сеть 220 может быть LAN или WAN, такой как, например, Интернет. Клиент 230 может иметь вычислительное устройство, такое как вычислительное устройство 120 на Фиг.1. Клиент 230 может быть соединен с сетевым поисковым средством (веб-браузером) или другим приложением предварительной обработки для получения доступа к сервисам 210 приложений. Приложение 232 запускается в клиенте 230 и может быть приложением, таким как, например, текстовым процессором, электронной таблицей или системой электронной почты. Приложение 232 может обеспечить возможность создания, представления и обмена документом 234 между пользователями.

Документ 234 может относиться к управлению объектами сервисов и воздействовать на них. На Фиг.4 документ 234 включает в себя текст: "Джон Смит пропустил платеж по кредитной карте". Документ 234, таким образом, ссылается как на объект 215а сервиса "заявитель", так и на объект 215b сервиса "ссуда". Документ 234 может воздействовать на управление такими упомянутыми объектами 215а и 215b сервисов. Например, документ 234 может воздействовать на пользователя для изменения состояния объекта "Джон Смит" 215а сервиса "заявитель" из состояния 306а в состояние 310а. Документ 234 может также воздействовать на пользователя для изменения состояния объекта "Джон Смит" 215b сервиса "ссуда" из состояния 306b в состояние 310b.

Важно, что в традиционной системе 200, как показано на Фиг.2, пользователь не может управлять объектами 215 сервисов изнутри приложения 232. Таким образом, для изменения состояния объекта 215а сервиса "заявитель" пользователь должен отдельно обратиться к сервису 210а приложения и идентифицировать объект 215а сервиса "заявитель" изнутри сервиса 210а приложения. Более того, для изменения состояния объекта 215b сервиса "ссуда" пользователь должен отдельно обратиться к сервису 210b приложения и идентифицировать объект 215b сервиса "ссуда" в сервисе 210b приложения.

III. Системы и Способы, соответствующие Настоящему изобретению

В отличие от традиционной системы 200 по Фиг.2 настоящее изобретение обеспечивает возможность создания и определения объектов сервисов пользователю. Настоящее изобретение также обеспечивает возможность сопряжения и объединения связанных объектов сервисов. Каждый объект сервиса может быть ассоциирован с одним или более связанных объектов сервисов. Метаданные, соответствующие ассоциированным объектам сервисов, могут быть предоставлены приложению. Такие метаданные могут обеспечивать возможность управления ассоциированными объектами сервиса изнутри приложения.

Система 500 управления ресурсами в соответствии с настоящим изобретением показана на Фиг.5. Как правило, сервисы 210 приложения открывают сервисные метаданные 505, соответствующие объектам 215 сервисов, для контекстного сервиса 510 и сервиса 520 действий. Контекстный сервис 510 объединяет объекты 215 сервиса в контекстные объекты 515 на основании сервисных метаданных 505. Контекстный сервис 510 также объединяет сервисные метаданные 505 в контекстные метаданные 525. Сервис 520 действий определяет динамические действия, доступные над объектами 215 сервисов. Приложение 532 поддерживает метаданные 545 приложения, соответствующие объектам 535 приложения.

Сервисы 210 приложения открывают сервисные метаданные 505 для контекстного сервиса 510 через сеть 220. В отличие от традиционных сервисных метаданных 205 по Фиг.2 сервисные метаданные 505 в соответствии с настоящим изобретением могут включать в себя классификацию доступности действий, подлежащих выполнению во взаимосвязи с объектами 215 сервисов. Конкретно сервисы 210 приложения могут классифицировать действие как являющееся доступным повсеместно, оптимистично доступным или доступным согласно правилу.

Действие, которое является доступным повсеместно, является действием, которое может выполняться всегда. Такие действия не подвержены никаким правилам или состояниям.

Действие, которое является оптимистично доступным, является доступным предметом для конкретных правил и условий. Например, такие правила могут включать в себя число выполнения действия, временной интервал, в течение которого действие должно быть выполнено, пользователя или класс пользователей, которые могут выполнять действие, условие, которое должно происходить перед выполнением действия, условие, которое должно происходить после выполнения действия. Классифицирование действия как оптимистично доступного разрешает сервисам 210 приложения создавать действие, доступное без конкретизации всех возможных правил и условий, которые должны удовлетворяться, чтобы правило было доступным.

Действие, которое является доступным согласно правилу, является доступным только при согласии с конкретизированными правилами и условиями. Классифицирование действие как доступного согласно правилу разрешает сервисам 210 приложения отказывать в доступности действия до тех пор, пока не удовлетворяются определенные правила и условия.

Контекстный сервис 510 может быть приложением, запускающимся на вычислительном устройстве, таком как, например, вычислительное устройство 120 по Фиг.1. Контекстный сервис 510 может анализировать сервисные метаданные 505 для идентификации объектов 215 сервисов и соответствующих статических действий, доступных для этих объектов сервисов. Контекстный сервис 510 может подтверждать правильность сервисных метаданных 505, например, созданием "холостого" вызова для идентифицированных объектов сервисов в сервисы 210 приложения.

Контекстный сервис 510 объединяет объекты 215 сервисов в контекстные объекты 515. Для объединения объектов 215 сервисов контекстные сервисы сопрягают связанные объекты 215 сервисов и объединяют такие связанные объекты 215 сервисов в единый контекстный объект 515. Например, контекстный сервис 510 может сопрягать связанные объекты 215а и 215b сервисов и объединять их в контекстный объект 515а. Контекстный сервис 510 может также определять, что объекты 210а' и 210b' сервисов не связаны, и может, поэтому, объединять каждый из объектов 210а' и 210b' в отдельный контекстный объект 515b и 515с соответственно.

Контекстный сервис 510 сопрягает связанные объекты 215 сервисов на основании сервисных метаданных 505. Конкретно контекстный сервис 510 делает перекрестные ссылки атрибутов объектов 215 сервисов для идентификации действительного и возможного отношений. Контекстный сервис 510 может идентифицировать такие соотношения на основании номенклатуры атрибутов. Например, контекстный сервис 510 может сопрягать объект 215а сервисов "заявитель" с объектом 215b сервиса "ссуда", так как объект 215b сервиса "ссуда" включает в себя атрибут "заявитель". Контекстный сервис 510 может фрагментировать и составлять атрибуты. Более того, контекстный сервис 510 может выполнять преобразования над атрибутами. Например, контекстный сервис 510 может выполнять преобразование для сопряжения атрибутов "первое имя" и "последнее имя" объектов 215а сервиса "заявитель" с атрибутом "имя" объекта 215b сервиса "ссуда".

В дополнение к объединению объектов 215 сервисов в контекстные объекты 215 контекстный сервис 510 объединяет сервисные метаданные 505 в контекстные метаданные 525. Конкретно в дополнение к объединению атрибутов объектов 215 сервисов контекстный сервис 510 объединяет динамические действия, доступные по объектам 215 сервисов. Например, контекстный сервис 510 может фрагментировать и составлять статические действия, доступные над объектами 215 сервисов. Более того, контекстный сервис 510 может выполнять преобразования над статическими действиями объектов 215 сервисов.

Контекстный сервис 510 может также объединять сервисные метаданные 505 о доступе к объектам 215 сервисов. Например, контекстный сервис 510 может сохранять контекстные метаданные 525, конкретизирующие, что конкретный класс пользователей имеет доступ к контекстному объекту 215а, но не имеет доступа к контекстному объекту 215b.

Контекстный сервис 510 может также объединять метаданные о примерах объекта и выделять действительные или возможные соотношения между такими экземплярами, представлениями и статическими действиями. Контекстный сервис 510 может также поддерживать визуализацию информации для сервисных метаданных 505. Контекстный сервис 510 может также осуществлять предварительную выборку сервисных метаданных 505 из сервисов 210 приложений для увеличения доступности сервисных метаданных 505. Контекстный сервис 510 может также сохранять процедуры для восстановления сервисных метаданных 505, когда сервисы 210 приложений переходят в автономный режим, как, например, в случае отключения электроэнергии.

Сервис 520 действий может быть приложением, исполняемым на вычислительном устройстве, таком как, например, вычислительное устройство 120 по Фиг.1. Обычно, сервис 520 действий определяет динамические действия, доступные над объектами 215 сервисов. Сервис 520 действий может запросить контекстный сервис 510 идентифицировать, какие из сервисов 210 приложений имеют динамические действия, доступные над объектом 215 сервисов. Сервис 520 действий может затем запросить идентифицированные сервисы 210 приложений для получения доступных динамических действий для объекта 215 сервиса.

В качестве альтернативы сервис 520 действий может запросить идентифицированные сервисы 210 приложений для получения информации о статусе для объекта. Сервис 520 приложения может затем извлечь сервисные метаданные 505, соответствующие объекту, для определения доступных действий для объекта 215 сервиса.

Сервис 520 действий включает в себя механизм 522 слежения, который следит за выполнением действий над объектами 215 сервисов в сервисах 210 приложений. Механизм 522 слежения определяет, когда пользователь вызывает способ изменения состояния над процессом, и отслеживает успех, неудачу или ожидающее завершение способа.

Сервис 520 действий также включает в себя механизм 524 защиты от конфликтов, который предотвращает выполнение и рекомендует не выполнять динамические действия в сервисах 210 приложений, которые являются не работоспособными или могут привести к конфликтам. Механизм 524 защиты от конфликтов оценивает классификацию доступных действий, подлежащих выполнению над объектами 215 сервисов. Конкретно, как описано выше, такие действия могут быть классифицированы, как доступные повсеместно, оптимистично доступные или доступные согласно правилу. Механизм 524 защиты от конфликтов использует и интерпретирует такие классификации вместе с действиями, прослеживаемыми механизмом 522 слежения, для определения, доступны ли действия, и для обнаружения динамических действий, которые могут вызывать действительные или возможные конфликты.

Приложение 532 может быть таким приложением, как, например, текстовый процессор, электронные таблицы или системы электронной почты, которые разрешают создание, выпуск и обмен документа 534. Обычно, в отличие от традиционного приложения 232 по Фиг.2, приложение 532 разрешает создавать и определять объекты 535а и 535b сервисов. Приложение 532 может сохранять метаданные 545 приложения, соответствующие таким объектам 535 приложения. Такие метаданные 545 приложения могут включать в себя, например, атрибуты соответствующих объектов 535 приложений.

Пользователь может определить экземпляр объекта 535 приложения, например, вводом имени этого экземпляра в текст документа 534, подсвечивая это имя с помощью приложенной клавиатуры мыши или т.п. и выбирая опцию "определить экземпляр" из меню приложения. Пользователь может затем, например, выбрать объект 535 приложения из списка предварительно определенных объектов 535 приложения или создать экземпляр "нового" объекта 535 приложения. Если пользователь выбирает заранее заданный объект 535 приложения, то может быть отображено представление атрибутов заранее заданного объекта 535 приложения, и пользователь может определять атрибуты для экземпляра. Если пользователь создает новый объект 535 приложения, то затем пользователь может создать набор атрибутов для объекта 535 приложения и может определить этот набор атрибутов для экземпляра.

Как только экземпляр объекта 535 приложения определен, он может появиться в тексте документа как ссылка, показанная, например, подчеркнутой и специально выделенным цветом текстом. Пользователь может затем выбрать экземпляр, например, щелкая по ссылке с помощью приложенной мыши. Выбор экземпляра может вызвать отображение атрибутов экземпляра.

На Фиг.6 показан примерный пользовательский интерфейс 605 приложения. Пользовательский интерфейс 605 может быть отображен на устройстве отображения, таком как монитор, присоединенный к клиенту 230. Пользовательский интерфейс 605 включает в себя окно 610 документа, которое отображает документ 534. Документ 534 включает в себя текст: "Джон Смит пропустил платеж по кредитной карте". "Джон Смит" определен как экземпляр объекта 535а сервиса "заявитель", как показано ссылкой 612.

Пользовательский интерфейс 605 приложения также включает в себя окно 620 прикладных метаданных. Окно 620 прикладных метаданных может быть открыто щелчком по ссылке 612. Окно 620 объекта отображает прикладные метаданные 545а, которые включают в себя атрибуты объекта 535а приложения "заявитель". В альтернативном варианте выполнения прикладные метаданные 545а могут появляться в диалоговой рамке внутри документа 534.

Сервис 536 выполнения в приложении 532 подробно обсужден ниже со ссылками на Фиг.7а и 7b. Обычно, сервис 536 выполнения предоставляет выбранные прикладные метаданные 545 контекстному сервису 510. Сервис 536 выполнения также включает в себя механизм 538 просмотра состояния и соотношения для обеспечения просмотра связанных объектов 215 сервисов.

Блок-схема алгоритма примерного способа управления объектами 215 сервисов из приложения 532 в соответствии с настоящим изобретением показана на Фиг.7а и 7b. В общем случае выбранный объект 535 приложения ассоциируется с объектами 215 сервисов, и сервисные метаданные 505 для ассоциированных объектов 215 сервисов выдаются в приложение 532. Выданные сервисные метаданные 505 обеспечивают управление ассоциированными объектами 215 сервисов из приложения 532.

На этапе 710 объект 535 приложения выбирается в приложении 532. Например, объект 535а сервиса "заявитель" может быть выбран в приложении 532 щелчком по ссылке 612 с помощью присоединенной мыши.

На этапе 712 сервис 536 выполнения на клиенте 230 извлекает прикладные метаданные 545, соответствующие выбранному объекту 535 приложения, из приложения 532. Например, если выбирается объект 535а приложения "заявитель", то затем сервис 536 выполнения может извлечь соответствующие прикладные метаданные 545а. На этапе 714 сервис 536 выполнения пропускает извлеченные прикладные метаданные 545а в контекстный сервис 510.

На этапе 716 контекстный сервис 510 сопрягает выбранный объект 535 приложения с ассоциированными контекстными объектами 515. Сопряжение объектов подробно обсуждено выше со ссылкой на Фиг.5 и может быть выполнено, например, перекрестной ссылкой атрибутов объектов, включенных в прикладные метаданные 545 и контекстные метаданные 525. Например, контекстный сервис 510 может сопрягать объект 535а сервиса "заявитель" с контекстным объектом 515а на основании общих атрибутов.

На этапе 718 контекстный сервис 510 идентифицирует ассоциированные объекты 215 сервисов, из которых извлекают ассоциированные контекстные объекты 515. Например, контекстный сервис 510 может идентифицировать, что контекстный объект 515а выделен из объекта 215а сервиса "заявитель" и объекта 215b сервиса "ссуда".

На этапе 720 контекстный сервис 510 рассматривает контекстные метаданные 525 для определения статических действий, доступных на ассоциированных объектах 215 сервисов. Контекстный сервис 510 может формировать граф ассоциированных объектов 215 сервисов, соотношения с этими объектами и статические действия, доступные на этих объектах и соотношениях.

На этапе 722 контекстный сервис 510 запрашивает сервис 520 действий для определения динамических действий, доступных на ассоциированных объектах 215 сервисов. Сервис 520 действий выдает доступные действия на объектах 215 сервисов, а также любые действия, которые могут привести к конфликту. Сервис 520 действий может также выдавать ограничения на множественное использование тех же самых или множественных динамических действий из того же самого способа.

На этапе 724 контекстный сервис 510 обеспечивает доступные действия для сервиса 536 выполнения. Контекстный сервис 510 может также выдавать другие сервисные метаданные 505 для ассоциированных объектов 215 сервисов. Если доступ к одному из ассоциированных объектов 215 сервисов ограничен, то от пользователя может потребоваться облегчить авторизацию для приема метаданных для этого объекта. Например, от пользователя может потребоваться зарегистрироваться с идентификатором или паролем.

На этапе 726 сервис 536 выполнения вырабатывает отображение действий, доступных на ассоциированных объектах 215 сервисов. Сервис 536 выполнения включает в себя механизм 538 представления состояния и соотношения для обеспечения представлений соотношений между связанными объектами 215 сервисов. Такие соотношения могут быть отфильтрованы для обеспечения только тех, которые являются релевантными для определения функций состояния, включенных в защиту от конфликта. Механизм 512 представления состояния и соотношения может выдавать информацию о получении, успехе, неудаче и текущем статусе способов изменения состояния для связанных объектов 215 сервисов.

На Фиг.8 дисплей 815 показывает действия, доступные на ассоциированных объектах 215 сервисов. Дисплей 815 показан в окне 630 действий сервисов приложений. Дисплей 815 включает в себя первую дисплейную часть 815а, показывающую доступные статические и динамические действия для ассоциированных объектов 215а и 215b сервисов. Дисплей 815 также включает в себя вторую дисплейную часть 815b, показывающую информацию о доступности действий в сервисах 210 приложений. Вторая дисплейная часть 815b показывает соотношения между компонентными процессами 300а и 300b, состояние каждого компонентного процесса 300а и 300b и доступность действий объекта 215а сервиса "заявитель" и объекта 215b сервиса "ссуда" в каждом процессе 300а и 300b соответственно. Информация об удаче, неудаче и состоянии рассматриваемых действий в процессах 300а и 300b может быть отображена, например, щелчком на процессе на дисплее 815 присоединенной мышью.

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

На этапе 728 пользователь может запросить действие из дисплея 815. Пользователь может запросить действие, например, щелкнув по действию присоединенной мышью. Если, например, пользователь выбирает "Просмотреть атрибуты" или "Изменить атрибуты", то атрибуты ассоциированных объектов 215а и 215b сервисов могут появиться в новом окне или в диалоговой рамке в пользовательском интерфейсе 805. Пользователь может затем просмотреть и изменить атрибуты.

В альтернативном варианте выполнения сервис 536 выполнения может выполнять доступные действия автоматически без отображения таких действий для пользователей.

На этапе 730 запрашиваемое действие передается к соответствующему сервису 210 приложения. Если запрашиваемое действие является статическим действием, то оно может передаваться к соответствующим сервисам 210 приложения через контекстный сервис 210. Если запрашиваемое действие является динамическим действием, то оно может передаваться к соответствующим сервисам 210 приложения через сервис 520 действий.

На этапе 732 действие может быть выполнено в соответствующем сервисе 210 приложения. Выполнение действия может быть зарегистрировано механизмом 522 слежения.

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

Изобретение относится к средствам управления ресурсами между сервисными приложениями. Техническим результатом является расширение функциональных возможностей управления за счет согласования связанных объектов сервисов на основе сервисных метаданных. В системе и способе объект приложения создают и определяют пользователи. Связанные объекты сервисов, управляемые различными сервисами приложения, могут согласовываться и объединяться. Объект приложения может быть ассоциирован с одним или более связанных объектов сервисов. Метаданные, соответствующие ассоциированным объектам сервисов, могут выдаваться в приложение. Такие метаданные могут обеспечивать возможность управления ассоциированными объектами сервисов в приложении. 3 н. и 21 з.п. ф-лы, 10 ил.

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

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

выбор из отображения в приложении действия, подлежащего выполнению на первом объекте сервиса в первом сервисе приложения.

выполнение выбранного действия в первом сервисе приложения.