ОБНАРУЖЕНИЕ И ПУБЛИКАЦИЯ СЛУЖБЫ Российский патент 2009 года по МПК G06F1/00 

ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ

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

УРОВЕНЬ ТЕХНИКИ

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

Например, рассмотрим ситуацию, в которой приложение выполняет поиск для перечисления доступных принтеров. При выполнении в администрируемой корпоративной среде приложению может потребоваться использование облегченного протокола доступа к директориям (LDAP) для обмена данными с хранилищем службы директорий Microsoft Active Directory® для обнаружения зарегистрированных корпоративных принтеров, NetBT для обнаружения серверов печати, и Bluetooth для обнаружения принтеров в персональной сети. Дополнительно приложению может потребоваться задействовать API менеджера устройств для обнаружения непосредственно подсоединенных принтеров и UpnP™ API для обнаружения UpnP принтеров. Каждый из этих механизмов требует понимания конкретного API, протокола и семантики запроса.

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

РАСКРЫТИЕ ИЗОБРЕТЕНИЯ

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

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

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

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

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

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

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

На Фиг.1 схематически показано иллюстративное компьютерное устройство;

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

Фиг.3 является блок-схемой, иллюстрирующей операции при обнаружении службы.

Фиг.4 является блок-схемой, иллюстрирующей операции при публикации службы.

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

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

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

Фиг.8 является псевдокодом, иллюстрирующим применение языка программирования C# для обнаружения цветных принтеров, которые печатают 50 страниц в минуту, используя объект SimpleFilter в протоколе Active Directory.

Фиг.9 является псевдокодом, иллюстрирующим применение языка программирования C# для обнаружения веб-служб.

Фиг.10 является псевдокодом, иллюстрирующим применение языка программирования C# для обнаружения служб, поддерживающих определенный интерфейс tModel, используя объект SimpleFilter и протокол UDDI.

Фиг.11 является псевдокодом, иллюстрирующим применение Visual Basic.Net для обнаружения служб, поддерживающих определенный интерфейс tModel, используя объект SimpleFilter и протокол UDDI.

Фиг.12 является псевдокодом, иллюстрирующим применение языка программирования C# для обнаружения принтера с именем, похожим на Office Printer, используя RichFilter с Active Directory.

Фиг.13 является псевдокодом, иллюстрирующим применение Visual Basic.Net для обнаружения принтера с именем, похожим на Office Printer, используя RichFilter с Active Directory.

Фиг.14 является псевдокодом, иллюстрирующим применение языка программирования C# для публикации службы определенного типа, идентифицированной определенным уникальным идентификатором, используя SSDP протокол.

Фиг.15 является псевдокодом, иллюстрирующим применение Visual Basic.Net для публикации службы определенного типа, идентифицированной определенным уникальным идентификатором, используя SSDP протокол.

Фиг.16 является псевдокодом, иллюстрирующим применение языка программирования C# для удаления службы из SSDP протокола.

Фиг.17 является псевдокодом, иллюстрирующим применение Visual Basic.Net для удаления службы из SSDP протокола.

Фиг.18 является псевдокодом, иллюстрирующим применение языка программирования C# для применения SimpleFiltre для регистрации на события определенного типа, с использованием SSDP протокола. Зарегистрированная функция обратного вызова будет вызываться для каждого события, соответствующего фильтру и соответствующий объект ServiceEntry будет предоставлен обработчику.

Фиг.19 является псевдокодом, иллюстрирующим применение Visual Basic.Net для регистрации на события определенного типа, с использованием SSDP протокола.

ОСУЩЕСТВЛЕНИЕ ИЗОБРЕТЕНИЯ

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

Иллюстративная рабочая среда

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

Компьютерное устройство 130 включает в себя один или несколько процессоров или процессорных блоков 132, системную память 134 и шину 136, соединяющую различные компоненты системы, в том числе системную память 134, с процессорами 132. Шина 136 представляет одну или несколько типов шинных структур, в том числе шину памяти или контроллер памяти, периферийную шину, порт графического ускорителя и процессорную или локальную шину, использующую любую из множества шинных архитектур. Системная память 134 включает в себя постоянное запоминающее устройство (ПЗУ) 138 и оперативное запоминающее устройство (ОЗУ) 140. Базовая система ввода/вывода (BIOS) 142, содержащая основные процедуры, помогающие передавать информацию между элементами компьютерного устройства 130, например, во время запуска, хранится в ПЗУ 138.

Компьютерное устройство 130 дополнительно включает в себя привод 144 жесткого диска для считывания и записи на жесткий диск (не показан), привод 146 магнитного диска для считывания и записи на сменный магнитный диск 148 и привод 150 оптического диска для считывания и записи на оптический диск 152, такой как CD-ROM или другой оптический носитель данных. Привод 144 жесткого диска, привод 146 магнитного диска и привод 150 оптического диска подсоединены к шине 136 через интерфейс 154 SCSI или какой-либо другой подходящий интерфейс. Приводы и связанные с ними машиночитаемые носители данных обеспечивают энергонезависимое хранение машиночитаемых инструкций, структур данных, программных модулей и других данных для компьютерного устройства 130. Хотя иллюстративная среда, изложенная в настоящем описании, использует жесткий диск, сменный магнитный диск 148 и сменный оптический диск 152, специалисты в данной области техники признают, что в иллюстративной рабочей среде также могут использоваться другие типы машиночитаемых носителей, которые могут хранить данные с возможностью доступа к ним компьютера, например, магнитные кассеты, карты флэш-памяти, цифровые видеодиски, память с произвольным доступом (RAM), постоянное запоминающее устройство (ПЗУ) и т.п.

Некоторое количество программных модулей может храниться на жестком диске 144, магнитном диске 148, оптическом диске 152, ОЗУ 138 или ПЗУ 140Б, в том числе операционная система 158, одна или несколько прикладных программ 160, другие программные модули и данные 164 программ. Пользователь может вводить команды и информацию в компьютерное устройство 130 через устройства ввода, такие как клавиатура 166 и указательное устройство 168. Другие устройства ввода (не показаны) могут включать в себя микрофон, джойстик, игровую консоль, спутниковую тарелку, сканнер и т.п. Указанные и другие устройства ввода подсоединены к процессорному блоку 132 через интерфейс 17, который связан с шиной 136. Монитор 172 или устройство отображения другого типа также подсоединено к шине 136 через интерфейс, такой как видеоадаптер 174. В дополнение к монитору персональный компьютер обычно включает в себя другие выходные периферические устройства (не показаны), такие как громкоговорители и принтеры.

Компьютерное устройство 130 обычно работает в сетевом окружении, используя логические соединения с одним или несколькими удаленными компьютерами, таким как удаленный компьютер 176. Удаленный компьютер 176 может быть еще одним персональным компьютером, сервером, маршрутизатором, сетевым ПК, одноранговым узлом сети или другим обычным узлом сети, и обычно включает в себя ряд или все элементы, описанные выше в связи с компьютерным устройством 130, несмотря на то, что на Фиг.1 изображено только запоминающее устройство 178. Изображенные на Фиг.1 логические соединения включают в себя локальную сеть (ЛС) 180 и глобальную сеть (ГС) 182. Такие типы сетевого окружения являются обычными в офисах, промышленных компьютерных сетях, интрасетях и Интернете.

При использовании в локальной сетевой среде компьютерное устройство 130 подсоединяется к локальной сети 180 через сетевой интерфейс или адаптер 184. При использовании в глобальной сетевой среде компьютерное устройство 130 обычно включает в себя модем 186 или другие средства для установления соединения через глобальную сеть 182, такую как Интернет. Модем 186, который может быть внутренним или внешним, подсоединен к шине 136 через интерфейс 156 последовательного порта. В сетевой среде программные модули, описанные в связи с компьютерным устройством 130, или часть их, могут храниться в удаленном устройстве хранения данных. Очевидно, что показанные сетевые соединения являются иллюстративными и могут быть использованы другие средства организации соединения между компьютерами.

В общем случае обработка данных в компьютерном устройстве 130 программируется при помощи инструкций, сохраненных в различное время на различных машиночитаемых носителях компьютера. Программы и операционные системы обычно распространяют, например, на флоппи-дисках или CD-ROM. Отсюда они устанавливаются или загружаются во вторичную память компьютера. При выполнении они загружаются, по меньшей мере частично, в главную электронную память компьютера. Изобретение, изложенное в настоящем описании, включает в себя упомянутые и другие различные типы машиночитаемых носителей, если такие носители содержат инструкции или программы, реализующие этапы, описанные ниже, в сочетании с микропроцессором или другим процессором данных. Изобретение также включает в себя сам компьютер, при условии, что он запрограммирован согласно способам и принципам, описанным ниже.

Обзор иллюстративной архитектуры программных средств

Фиг.2 является блок-схемой иллюстративной архитектуры 200 программных средств для обнаружения службы, которая может располагаться в системной памяти 134 по Фиг.1. При такой реализации системная память 134 может содержать множество прикладных программ 210. В сетевом окружении прикладные программы могут работать в качестве клиентских программ, тогда как в среде ПК приложения могут выполняться как изолированные программы. Конкретная природа прикладных программ не является существенной.

Прикладные программы 210 вызывают API 214 обнаружения службы для обнаружения служб, доступных в компьютерном окружении. API 214 обнаружения служы обеспечивает высокоуровневую грамматику для описания запросов обнаружения. Грамматика может быть реализована в OPath, естественном языке запросов, для описания запросов обнаружения. Такая высокоуровневая грамматика предоставляет разработчикам программного обеспечения более концептуальный механизм описания службы (служб), необходимых разработчику, чем это позволяет запрос при помощи более детализированных и ориентированных на протокол выражений, которые могут требоваться нижележащими протоколами 220-234. Разработчик может сформировать запрос, используя высокоуровневую грамматику, который затем может быть направлен либо определенному набору протоколов, называемому набором “конкретная область действия”, либо использовать “абстрактную область действия”, которая представляет собой заранее определенный или сконфигурированный набор «конкретная область действия». Дополнительно к поддержке обнаружения служб система поддерживает публикацию/удаление служб и отслеживание событий.

API 214 обнаружения службы, в свою очередь, вызывает один или несколько нижележащих протоколов, представленных на диаграмме протоколами с Протокола 1 220 по Протокол 8 234. Конкретное количество нижележащих протоколов не является важным. Определенные протоколы 220-234 могут представлять собой протоколы, поддерживаемые директорией, такие как, например, LDAP, Universal Description, Discovery and Integration (UDDI) и Domain Name System (DNS) Server (сервер доменных имен). Другие протоколы могут представлять собой протоколы ad-hoc (без узла доступа), такие как, например, Bluetooth, UPnP и NetBT. Один или несколько нижележащих протоколов 220-234 используют коммуникационное соединение 236 для связи с другими компонентами или службами, доступными в компьютерном окружении.

В ответ на запрос обнаружения API обнаружения службы возвращает набор объектов ServiceEntry (точка входа службы), которые представляют соответствующие службы, обнаруженные либо на локальной машине, либо в сети. Объект ServiceEntry представляет собой структуру данных общего вида, которая может представлять множество релевантных деталей, возвращаемых нижележащими протоколами, которые поддерживаются системой. Каждый объект ServiceEntry соответствует единичному экземпляру службы. В одном из вариантов осуществления объект ServiceEntry предоставляет дескрептивные и идентифицирующие свойства, включающие в себя: (1) имя службы; (2) описание службы; (3) конечные точки, которые обычно содержат сетевой адрес (адреса) службы; (4) ключ, который идентифицирует экземпляр службы; (5) свойства, например, расширяемый список пар имя-значение для характеристик службы или устройства; и (6) провайдер, например, идентификатор, который идентифицирует сущность, обеспечивающую данную службу.

Служба 212 обнаружения присутствия связывается с API 214 обнаружения службы. Помимо прочего, служба 212 обнаружения присутствия регистрирует для оповещения события ad-hoc протоколов. Служба обнаружения присутствия извещается в случае, если регистрируется событие оповещения, и служба обнаружения присутствия копирует информацию об оповещении службы в область памяти хранилища 240 данных. Сохранение подробностей службы в области памяти дает возможность выполнять обнаружение служб, которые могут быть недоступны в настоящий момент. Например, даже если принтер является в настоящее время выключенным, подробности о принтере могут быть зарегистрированы в области памяти и могут быть обнаружены. Дополнительно запросы службы не ограничиваются протоколом, который осуществляет связь со службой. Более того, производительность выполнения запроса в области памяти может быть гораздо лучше, чем выполнения широковещательного запроса обнаружения в сети.

Иллюстративные операции

В иллюстративном варианте осуществления API 214 обнаружения службы предоставляет методы для обнаружения службы, публикации службы и подписки на извещения о событиях службы. Фиг.3 представляет собой блок-схему, иллюстрирующую операции 300 для обнаружения службы. На этапе 310 приложение определяет область действия, на этапе 315 приложение определяет фильтр, на этапе 320 приложение выдает запрос на поиск. API 214 обнаружения службы принимает запрос на поиск, и на этапе 325 API 214 обнаружения службы выполняет грамматический разбор запроса на поиск. На необязательном этапе 330 API 214 обнаружения службы определяет, является ли запрос на поиск разрешимым, используя информацию, сохраненную в службе 212 обнаружения присутствия. В одном из вариантов осуществления информация, поддерживаемая службой 212 обнаружения присутствия, включает в себя индикатор времени жизни, который определяет время жизни информации в службе 212 обнаружения присутствия. В зависимости от управления и конфигурации API 214 обнаружения службы может выполнить запрос службы 212 обнаружения присутствия для определения, может ли быть удовлетворен запрос обнаружения, используя информацию, которую служба 212 обнаружения присутствия поддерживает в хранилище 240 данных. Если запрос обнаружения является разрешимым с использованием службы 212 обнаружения присутствия, тогда управление переходит к этапу 350, и объекты точки входа службы, полученные от службы 212 обнаружения присутствия, возвращаются приложению.

Напротив, в случае, если запрос обнаружения не разрешен или не является разрешимым, используя информацию, поддерживаемую службой 212 обнаружения присутствия, тогда управление переходит к этапу 335, и API 214 обнаружения службы выполняет вызов(вызовы) низкоуровневого API, требуемый для выполнения запроса обнаружения. На этапе 340 информация о службе, возвращенная вызовами низкоуровневого API, форматируется в виде объектов точки входа службы, и на необязательном этапе и 345 объекты точки входа службы направляются службе обнаружения присутствия, которая может сохранить объекты точки входа службы в хранилище 240 данных. На необязательном этапе 347 может выполняться дальнейшая обработка и фильтрация результатов точек входа службы, например, обнаружение и удаление дублирований. На этапе 350 объекты точки входа службы возвращают приложению для дальнейшей обработки на этапе 355. Конкретные подробности дополнительной обработки, выполняемой приложением, не существенны.

Фиг.4 представляет собой блок-схему, иллюстрирующую операции при публикации службы. На этапе 410 приложение определяет объект точки входа службы для публикации службы. На этапе 415 приложение определяет область действия для публикации службы. На этапе 420 приложение назначает уникальный ключ для публикации службы, и на этапе 425 приложение назначает тип службы для публикации службы. На этапе 430 приложение определяет конечные точки для публикации службы, на этапе 432 приложение определяет свойства для публикации службы, и на этапе 435 приложение генерирует запрос публикации. Выполняемые этапы могут отличаться согласно деталям информации, которая должна быть опубликована, и низкоуровневому API, который будет использоваться.

API 214 обнаружения службы принимает запрос публикации и на этапе 440 выполняет грамматический разбор запроса публикации. На этапе 450 API 214 обнаружения службы выполняет вызовы низкоуровневого API для выполнения запроса публикации службы. На необязательном этапе 455 публикация службы сохраняется в службе 212 обнаружения присутствия.

Публикация службы, выполняемая API 214 обнаружения службы, также может быть использована для удаления опубликованной службы. Фиг.5 представляет собой блок-схему, иллюстрирующую операции удаления службы. На этапе 510 приложение определяет объект точки входа службы для публикации службы. На этапе 515 приложение определяет уникальный ключ для упомянутой службы. На этапе 520 приложение определяет область действия для удаления службы. На этапе 530 приложение генерирует запрос удаления службы.

API 214 обнаружения службы принимает запрос удаления и на этапе 540 выполняет грамматический разбор запроса удаления. На этапе 550 API 214 обнаружения службы выполняет вызовы низкоуровневого API для выполнения запроса удаления службы. На необязательном этапе 555 публикация службы удаляется из службы 212 обнаружения присутствия.

API 214 обнаружения службы также может быть использован для извещения приложений о событиях службы, таких как появление или удаление новой службы или устройства определенного типа. Фиг.6 представляет собой блок-схему, иллюстрирующую операции 600 подписки на события службы. На этапе 610 приложение определяет область действия, которую устанавливает конкретный низкоуровневый протокол, который будет отслеживаться. На этапе 615 приложение определяет фильтр, который устанавливает тип события. На этапе 620 приложение определяет функцию обратного вызова, которая возвращает детали ServiceEntry при появлении соответствующих событий. На этапе 625 приложение генерирует запрос подписки, который направляется API 214 обнаружения службы.

API 214 обнаружения службы принимает запрос подписки и на этапе 630 выполняет грамматический разбор запроса подписки. На этапе 635 запрос обнаружения службы выполняет вызовы низкоуровневого протокола, требуемые для осуществления службы подписки. При появлении события службы низкоуровневый протокол предоставляет API обнаружения службы извещение о событии. На этапе 640 извещение о событии форматируется в виде объекта точки входа службы. На необязательном этапе 645 объект точки входа службы может быть сохранен в службе 212 обнаружения присутствия, и на этапе 650 объект точки входа службы возвращается в приложение. Используя предварительно определенную функцию обратного вызова, на этапе 655 приложение выполняет дальнейшую обработку объекта точки входа службы. Конкретные детали дальнейшей обработки, выполняемой приложением, не существенны.

Компоненты и операции системы более подробно описаны ниже.

Классы API

Фильтры

Фильтры представляют собой набор правил, при помощи которых можно оценивать описание службы, что дает в результате “истинно” (т.е. описание службы соответствует фильтру) или “ложно” (т.е. описание службы не соответствует фильтру). Фильтр может быть описан либо как простой фильтр, который определяет конкретные свойства, или как расширенный фильтр, который использует более выразительную грамматику. Выраженные как простой фильтр или расширенный фильтр запросы могут быть определены и выполнены посредством нескольких протоколов без модификации, в зависимости от возможностей нижележащих протоколов. Запрос API 214 обнаружения службы выполняет переформулировку запроса верхнего уровня в корректный формат для нижележащего протокола нижнего уровня. Например, запрос API 214 обнаружения службы может принимать запрос для определенного типа службы и выражать и выполнять его, используя LDAP для Active Directory и используя протокол UDDI для реестра UDDI веб служб. От разработчика приложения не требуется напрямую работать с отдельными протоколами.

В иллюстративном варианте осуществления запрос API 214 обнаружения службы требует модулей обнаружения для поддержки простого фильтра, обеспечивающих точное семантическое соответствие для представленных критериев, и расширенного фильтра, содержащего запрос, выраженный в грамматике Opath. Очевидно, что каждый из них также может поддерживать дополнительные “естественные” типы фильтров. Различные модули обнаружения могут иметь специфические для протокола типы естественных фильтров, например, UpnP может применять фильтры Xpath, Active Directory может естественным образом использовать фильтры LDAP, и UDDI может естественным образом использовать фильтр UDDI.

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

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

Тип службы может быть реализован в виде строки, которая определяет тип, которому должны соответствовать экземпляры служб. Обычный набор типов служб заранее определен в запросе API 214 обнаружения службы. Этот набор может быть расширен при идентификации ключевых сущностей в протоколах и хранилищах. Например, для принтеров в Active Directory это будет выглядеть таким образом: filter.ServiceType = CommonServiceTypes.Printer.

Интерфейсфы служб могут быть реализованы как набор строк, который определяет идентификаторы для интерфейсов, которым должны соответствовать службы. В качестве примера, для веб служб в UDDI могут быть определены следующие идентификаторы tModel:

Свойства могут быть выражены в словаре свойств, определяющим характеристики службы, которым должны соответствовать службы. В качестве примера, для принтеров в Active Directory могут быть определены следующие свойства: filter.Properties.Add(“printcolor”, “TRUE”); filter.Properties.Add(“pagesperminute”, “50”).

Расширенные фильтры обеспечивают механизм для выражения значительно более богатой семантики, используя, например, грамматику OPath, устанавливая свойство “строка Query”. В качестве примера, для веб служб в UDDI, строка Query может определять требуемое имя и требуемый поддерживаемый интерфейс:

В качестве более выразительного примера для нахождения принтеров в Active Directory, способных печатать более 25 страниц в минуту, в которых отсутствует бумага А4: filter.Query = “Printer[printPagesPerMinute > 20 + 5 and not (printmediaReady = 'A4')]”/.

Поскольку возможности нижележащих протоколов и хранилищ далеко не одинаковы, меняясь от базового NetBT, до богатой семантики запросов Active Directory, возможность использовать более выразительные конструкции OPath зависит от объема выбора (протоколов).

Области действия

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

API 214 обнаружения службы согласует конкретные области действия и абстрактные области действия. Конкретная область действия определяет домен запроса в трех частях. Идентификатор протокола, идентифицирующий определенный протокол, например, отображающий единичный модуль обнаружения, такой как ConcreteScope.NetBtProtocol или ConcreteScope.ADProtocol, (необязательный) идентификатор Adress, определяющий сервер, к которому направляют операции в данной области действия, такой как “http://intrauddi/uddi/inquire.asmx” для сервера UDDI интранет, и идентификатор (необязательный) пути, который идентифицирует раздел пространства имен модуля, такой как LDAP базу поиска, которая может быть установлена в “CN = joe-dev, CN = Computers, DC = corp, DC = fabrikam, DC = com” или имя области действия UPnP.

Запрос API 214 обнаружения службы передает конкретную область действия в модули. Запрос API 214 обнаружения службы не препятствует модулям выполнять дополнительное перенаправление конкретных областей действия, например, передавая конкретные области действия по кабельной связи во вторую машину и передачу конкретной области действия в соответствующий API в данной второй машине.

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

Отображение абстрактных областей действия на конкретные области действия является общим для всех приложений и конфигурируемым. Например, абстрактная область действия AbstractScope.Enterprise может отображаться, включая в себя обе конкретные области действия в Таблице 1.

Таблица 1   protocol=ConcreteScope.ADProtocol
address=”ldap://dev.corp.fabrikam.com”
path=null   protocol=ConcreteScope.UddiProtocol
address=”http://uddi. fabrikam.com/inquire.asmx”
path=null  

Фиг.7 является блок-схемой, иллюстрирующей иллюстративную взаимосвязь между конкретными областями действия и абстрактными областями действия. Конкретные области действия 730-750 обеспечивают описание домена, в котором будут выполняться запросы. Конкретные области действия 730-750 содержат подробности идентификации протокола и, как это требуется, определяют используемые хранилище или сервер, с возможностью дальнейшего определения области действия в указанных сервере или хранилище. В API 214 обнаружения службы это определено в свойствах Protocol, Address и Path, соответственно.

Абстрактные области действия 710-725 обеспечивают более высокий уровень иерархической абстракции над конкретными областями действия. Абстрактные области действия реализованы с возможностью включения конкретных или абстрактных областей действия, которые входят в их состав. Такое отображение области действия доступно для системных администраторов, которые имеют возможность выполнить конфигурацию в точности таким образом, как, например, должен быть разрешен AbstractScope.EnterpriseScope.

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

Абстрактные области действия позволяют разработчику прикладных программ 210 работать на относительно высоком уровне и использовать в коде определяющие область действия термы, такие как “AbstractScope.Enterprise”. В этом случае, например, от разработчика не требуется вносить основную специфику конкретного сервера UDDI в свой код. Эта абстракция предусмотрена для улучшения облегчения использования и переносимости кода. Одна и та же часть кода может быть использована в разном рабочем окружении без изменения или перекомпиляции. Между различными типами окружения будет меняться только конфигурация абстрактной области действия.

Может присутствовать множество иерархий отображений абстрактных областей действия в конкретные области действия. На Фиг.7 AbstractScope.LocalMachine не отображается в AbstractScope.All, даже если включены все его составляющие.

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

Результаты ServiceEntry

Разработчик приложения может выбрать подходящие описания «Область Действия» и «Фильтр», которые затем могут быть посланы в качестве свойств в объект обнаружения службы. Затем приложение может использовать методы FindOne или FindAll для выполнения запроса обнаружения. Метод FindAll возвращает все службы в соответствующие поддерживаемым критериям, тогда как метод FindOne возвращает единственную подходящую службу. Методы могут выполняться с использованием синхронного или асинхронного вызова.

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

Таблица 2 Свойство Комментарии Имя Идентифицирует экземпляр службы Определение Описывает экземпляр службы Конечные точки Набор конечных точек, в которых может быть получен доступ к экземпляру службы Ключ Идентификационный ключ экземпляра службы Область действия Области действия, которые сущность обнаружила или которые должны быть опубликованы Мандат Устанавливает мандаты, которые будут использованы при опубликовании данной службы Провайдер Указывает на “провайдера” (контейнер) службы, если таковой существует Истечение срока Момент времени, в который точка входа службы прекратит свое существование, основанное на времени жизни.

Публичная функция void Save() предоставляется для создания или обновления представления точки входа службы в областях действия, определенных набором областей действия.

Публичный метод void Delete() удаляет указанный объект ServiceEntry из областей действия, определенных свойством Scopes. В случае, если служба еще не опубликована, генерируется исключение.

Псевдокоды

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

Фиг.8 представляет собой псевдокод, иллюстрирующий использование языка программирования С# для обнаружения цветных принтеров, которые печатают 50 страниц в минуту, используя объект SimpleFilter протокола Active Directory.

Фиг.9 представляет собой псевдокод, иллюстрирующий использование языка программирования С# для обнаружения веб служб, которые реализуют интерфейс uddi-org:inquiry_v2 и имеют имя Fabrikam, используя объект RichFilter через протокол UDDI.

Фиг.10 представляет собой псевдокод, иллюстрирующий использование языка программирования С# для обнаружения служб, поддерживающих определенный интерфейс tModel, используя объект SimpleFilter и протокол UDDI.

Фиг.11 представляет собой псевдокод, иллюстрирующий использование Visual Basic.NET для обнаружения служб, поддерживающих определенный интерфейс tModel, используя объект SimpleFilter и протокол UDDI.

Фиг.12 представляет собой псевдокод, иллюстрирующий использование языка программирования С# для обнаружения принтера с именем, похожим на Office Printer, используя объект RichFilter с Active Directory.

Фиг.13 представляет собой псевдокод, иллюстрирующий использование Visual Basic.NET для обнаружения принтера с именем, похожим на Office Printer, используя объект RichFilter с Active Directory.

Фиг.14 представляет собой псевдокод, иллюстрирующий использование языка программирования С# для публикации службы определенного типа, идентифицированного определенным уникальным идентификатором, используя протокол SSDP.

Фиг.15 представляет собой псевдокод, иллюстрирующий использование Visual Basic.NET для публикации службы определенного типа, идентифицированного определенным уникальным идентификатором, используя протокол SSDP.

Фиг.16 представляет собой псевдокод, иллюстрирующий использование языка программирования С# для удаления службы из протокола SSDP.

Фиг.17 представляет собой псевдокод, иллюстрирующий использование Visual Basic.NET для удаления службы из протокола SSDP.

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

Фиг.19 представляет собой псевдокод, иллюстрирующий использование Visual Basic.NET для использования SimpleFilter для регистрации на извещения о событиях определенного типа с использованием протокола SSDP.

Иллюстративный синтаксис Opath

В Таблице 3 приведен иллюстративный синтаксис Opath для различных функций обнаружения.

Таблица 3 Opath Ссылается на Printer Найти все принтеры и очереди печати. Printer[name='Upstairs Printer'] Найти все принтеры с именем Upstairs Printer. Printer[printPagesPerMinute>20+5 and not(printmediaReady='A4')] Найти все принтеры, способные печатать более чем 25 страниц в минуту и в которых отсутствует бумага А4. Printer[ Properties.name like 'Pri' and printPagesPerMinute > 10 or printMediaReady = letter)] Найти все принтеры с именем, содержащим Pri, и либо со скоростью печати, превышающей 10 страниц в минуту, либо в которых присутствет бумага формата “Letter”. Printer[ supportsColor = true && (printerName like 'Home' or name like 'Work')] Найти все принтеры, которые поддерживают цветную печать с именем, начинающимся на Home или Work. Service[ServiceInterface= ServiceConnectionPoint] Найти все службы, которые являются объектами ServiceConnectionPoint. Service[ (serviceType = 'Printer' or serviceType= 'Computer' ) and name like Work] Найти все службы, которые являются либо принтерами, либо компьютерами и которые имеют имя, похожее на Work. Computer[ operatingSystemVersion like '%3790%] Найти все компьютеры, которые выполняют операционную систему с номером версии, содержащим 3790. Computer[ operatingSystem='Windows Server2003'] Найти все компьютеры, которые выполняют определенную операционную систему. Атрибут operatingSystem не включен в глобальный каталог.

Таблица 4 содержит примеры синтаксиса OPath, которые могут быть использованы в протоколе UDDI.

Таблица 4 OPath Ссылается на WebService [name='Fabrikam'] Найти все веб-службы с именем Fabrikam. WebService [name = 'UDDI%' && ServiceInterface ='uuid:ac104dcc-623-452f-88a7-f8acd94d9b2b] Найти все веб-службы с именем, начинающимся на UDDI и которые поддерживают идентифицированный интерфейс (т.е. tModel uddi-org:inquiry_v2).

Таблица 5 содержит примеры синтаксиса OPath, которые могут быть использованы в протоколе NetBT.

Таблица 5 OPath Ссылается на Workstation Найти все рабочие станции Service[ ServiceType ='PrintQueueServer'] Найти все службы типа PrintQueueServer. Computer[ servictInterface ='DomainController' and ServiceInterface='TerminalServer'] Найти все компьютеры контроллера домена, на которых выполняется терминальный сервер.

Служба обнаружения присутствия

Как кратко описывалось выше, служба 212 обнаружения присутствия управляет хранилищем данных присутствия для информации службы. Периодически или при заранее определенных событиях, таких как запуск, служба обнаружения присутствия регистрирует объявления ad-hoc устройств/служб. В качестве примера, если вводится новое UPnP устройство, оно генерирует объявление устройства, которое обрабатывается модулем протокола UPnP. Этот модуль затем выдает подробности этого события (устройства или службы) в службу обнаружения присутствия через API 214 обнаружения службы.

Используя свое хранилище данных присутствия, служба обнаружения присутствия затем определяет, является ли это новым устройством/службой или восстановленным устройством/службой. Если это новое устройство/служба, подробности данного устройства и его служб будут зарегистрированы в хранилище данных присутствия. Когда другой пользователь API 214 обнаружения службы затем попытается обнаружить службу, API 214 обнаружения службы будет иметь возможность вернуть службы для ad-hoc устройства/службы, даже если устройство в настоящее время не доступно. Для приведенного примера, в случае, если устройство/служба является доступным в настоящее время, в зависимости от определенной области действия, как модуль протокола UpnP, так и модуль хранилища данных присутствия могут вернуть результаты для данного устройства. В дополнение к UPnP эта функциональность применима к другим механизмам ad-hoc обнаружения.

Таким образом, служба 212 обнаружения присутствия, API 214 обнаружения службы и локальное хранилище 240 базы данных обеспечивают уровень абстракции над различными низкоуровневыми протоколами, используемыми для обнаружения устройства или службы. Такой дополнительный уровень абстракции устанавливает общую и улучшенную семантику поиска, которую разработчики прикладных программ могут использовать в разрабатываемых приложениях.

Дополнительно служба 212 обнаружения присутствия, API 214 обнаружения службы и локальное хранилище 240 базы данных обеспечивают консолидированную модель обнаружения служб и устройств на локальной машине, в домашней сети (сетях), в сети (сетях) предприятия и Интернете. Таким образом, разработчики приложений могут обнаруживать службы в различных местоположениях при помощи обращения к одному, совместимому API.

Заключение

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

Изобретение относится к цифровым вычислениям, а более точно к обнаружению службы в компьютерных устройствах и компьютерных сетях. Технический результат заключается в обеспечении совместимой, высокоуровневой абстракции служб и связанных операций, которая направлена на обнаружение и публикацию подробностей служб в широком спектре низкоуровневых API, протоколов, хранилищ и типов сетевого окружения. Прикладная программа генерирует запрос обнаружения службы, публикации службы и подписки к интерфейсу прикладного программирования обнаружения служб. Интерфейс прикладного программирования обнаружения служб запускает один или несколько низкоуровневых протоколов для выполнения запроса обнаружения, публикации и/или подписки. Информация о службе, полученная от низкоуровневых протоколов, форматируется в совместимой модели данных и возвращается клиентскому приложению. Дополнительно информация о службе может быть сохранена в хранилище данных присутствия, управляемом службой обнаружения присутствия, подсоединенной с возможностью обмена данными к API обнаружения службы. 5 н. и 13 з.п. ф-лы, 19 ил., 5 табл.

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

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

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

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

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

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

7. Способ по п.6, дополнительно содержащий сохранение информации о службе в хранилище данных присутствия.

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

9. Способ по п.8, дополнительно содержащий удаление информации о службе из хранилища данных присутствия.

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

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

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

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

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

15. Система по п.14, в которой первый интерфейс прикладного программирования обеспечивает интерфейс для, по меньшей мере, одного протокола, основанного на обнаружении, и, по меньшей мере, одного ad-hoc протокола.

16. Система по п.14, в которой первый интерфейс прикладного программирования обнаруживает службы, доступные в локальном компьютерном устройстве.

17. Система по п.14, в которой первый интерфейс прикладного программирования обнаруживает службы, доступные в удаленном компьютерном устройстве.

18. Система по п.14, в которой первый интерфейс прикладного программирования реализует отображение области действия и в которой отображение области действия является конфигурируемым системным администратором.