Обнаружение и публикация службы

Обнаружение и публикация службы

Иллюстрации

Показать все

Реферат

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

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

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

Прикладные программы, которые выполняются в компьютерных устройствах и компьютерных сетях, могут требовать использования служб, обеспечиваемых другими физическими или логическими устройствами, подсоединенными к компьютерному устройству или сети. В настоящее время прикладные программы используют широкий спектр интерфейсов прикладного программирования (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.ADProtocoladdress=”ldap://dev.corp.fabrikam.com”path=null
protocol=ConcreteScope.UddiProtocoladdress=”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 возвращают один или набор объектов точки входа службы. Объект точки входа службы представляет собой абстракцию над различными представлениями служб, которые могут предоставить нижележащие протоколы. Каждый объект точки входа службы соответствует единичному экземпляру службы, и как таковой предоставляет дескриптивные и идентификационные свойства, включающие в себ