Журнал "Windows 2000 Magazine", #03/2000
С самой первой версии операционная система Windows NT включала в себя встроенные средства мониторинга производительности и системных событий. Прикладные программы и сама система обычно выдают сообщения об ошибках и диагностические сообщения с помощью Event Manager. Встроенная в Windows NT утилита Event Viewer позволяет администраторам просматривать события, произошедшие как на локальном компьютере, так и на других машинах в сети. Подобным образом Performance API позволяет прикладным программам и подсистемам собирать статистику по производительности, которую администраторы затем могут просмотреть через Performance Monitor.
Хотя средства NT для сбора статистики о событиях в системе и производительности отвечают большинству требований, они все же имеют ряд ограничений. Например, интерфейсы программирования этих средств отличаются друг от друга, что увеличивает сложность прикладных программ сбора данных, контролирующих и события и производительность. Эффективность Performance API может быть низкой, особенно в сети, так как этот интерфейс может предоставить "все или ничего": у приложения нет возможности запросить информацию о производительности отдельных компонентов. Вероятно, самый существенный недостаток современных средств контроля состоит в том, что они имеют очень небольшую расширяемость, и ни одно не обеспечивает возможность двухстороннего взаимодействия с API управления, которое так необходимо. Обычно прикладные программы предоставляют данные в определенных форматах для регистрации событий или сбора других данных. Performance API не дает приложению никакой возможности для получения уведомлений о событиях, связанных с производительностью, и прикладные программы, которые запрашивают у Event Manager уведомления о событиях, не могут ограничить извещение отдельными типами событий или данных. Наконец, клиенты или средства сбора информации не имеют возможности связываться с источником событий или рабочих данных через Event Manager или Performance API. Создание интерфейса Windows Management Interface (WMI) - следующий шаг к реализации усовершенствованной поддержки управления средствами Windows. WMI разработан специалистами Microsoft на базе технологии управления предприятием через Web - Web-Based Enterprise Management (WBEM). WBEM - это стандарт, определенный консорциумом Distributed Management Task Force (DMTF). WBEM определяет структуру расширяемого набора данных о предприятии и возможности администрирования, необходимые для управления локальными и удаленными системами, включающими произвольные компоненты. Разработчики Microsoft реализовали WMI в Windows 98 и в Win95 OSR2, сделали его доступным для NT 4.0, начиная с Service Pack 4 (SP4), и, наконец, интегрировали в Windows 2000. Тем не менее в большей степени WMI предназначен для использования в Windows 2000. Так как независимые производители уже начали поставлять инструментальные средства управления, основанные на WMI, администраторы получат возможность удаленно управлять всеми компонентами своих систем (Windows 2000, NT или 9x). В этой статье мы заглянем внутрь WMI. То, что здесь будет рассказано о WMI, применимо ко всем платформам Windows, но при обсуждении подробностей выполнения я буду делать акцент на Windows 2000.
Архитектура WMI состоит из четырех сегментов, показанных на Рисунке 1: управляющие программы (management applications), ядро WMI (WMI infrastructure), провайдеры (providers), или поставщики, и управляемые объекты (managed objects). Управляющие программы - это приложения Windows, которые обращаются к данным и отображают или обрабатывают данные, полученные от управляемых объектов. Простой пример управляющей программы - использование технологии WMI (вместо API) в Performance Monitor. Более сложный пример - инструмент управления предприятием, который позволяет администраторам автоматически отслеживать конфигурации программного обеспечения и оборудования каждого компьютера на предприятии.
РИСУНОК 1. Архитектура WMI
Обычно разработчики настраивают свои управляющие программы на специфические объекты, чтобы собрать данные о них и управлять ими. Объект может представлять собой один компонент, такой, как сетевой адаптер, или множество компонентов, таких, например, как компьютер (объект "компьютер" может содержать объект "сетевой адаптер"). Провайдеры задают и экспортируют представления объектов, которыми управляют приложения. Например, если продавец сетевого адаптера хочет, чтобы адаптер был WMI-совместимым, он должен разработать "поставщика услуг", который служит интерфейсом к адаптеру: запрашивает и устанавливает состояние и поведение его атрибутов, как того требуют управляющие приложения. В некоторых случаях (например, при использовании драйвера устройств) Microsoft поставляет такого поставщика услуг, который имеет собственный API, для упрощения разработки дополнений (plugins) и кодирования.
Инфраструктура WMI связывает приложения управления и провайдеров, а также играет роль хранилища классов-объектов и, во многих случаях, менеджера памяти для устойчивых объектных свойств. WMI осуществляет хранение (работает как репозитарий), подобно базе данных на жестком диске. WMI, как часть своей инфраструктуры, поддерживает несколько API, с помощью которых приложения управления обращаются к объектным данным, а провайдеры поставляют данные и определения класса.
Программы Win32 используют WMI COM API - главный API управления - для прямого взаимодействия с WMI. Другой уровень API - на вершине COM API - включает ODBC-адаптер для доступа к базе данных Microsoft Access. Разработчик базы данных использует WMI ODBC-адаптер, чтобы внедрить ссылки на объектные данные в своей базе данных. Затем разработчик может без труда составлять отчеты с помощью запросов к базе данных, которые содержат WMI-данные. Компоненты WMI ActiveX поддерживают API другого уровня. Разработчики Web используют средства управления ActiveX для создания сетевых интерфейсов к WMI-данным. Другой способ управления предполагает применение сценарного API WMI, для использования в сценариях и приложениях Visual Basic. Средства создания сценариев WMI существуют для VBScript, JScript, Active Server Pages (ASP) и HTML.
WMI-интерфейсы COM, которые используются управляющими приложениями, представляют собой основной интерфейс API для провайдеров. Однако, в отличие от приложений управления, которые являются COM-клиентами, провайдеры - это COM- или DCOM-серверы (т. е. провайдеры дополняют COM-объекты, взаимодействующие с WMI). Провайдер WMI может быть реализован в виде DLL, которые загружаются в процесс администратора WMI, в виде автономных приложений Win32 или сервисов Win32. Microsoft поставляет ряд встроенных провайдеров, которые предоставляют данные из известных источников, таких, как Performance API, системный реестр и журнал событий. Средства WMI SDK позволяют создавать независимым разработчикам собственные продукты с функциональностью WMI-провайдеров.
В основе WBEM лежит спроектированная в DMTF спецификация Common Information Model (CIM). CIM определяет, КАК системы управления представляют структуру компьютера, приложения или устройства. Разработчики провайдера используют CIM для представления управляемых компонентов, составляющих приложение. Для удобства реализации компонентов в стандарте CIM разработчики применяют язык Managed Object Format (MOF).
Помимо определения объектов провайдер должен связать с ними WMI. WMI классифицирует провайдеров согласно свойствам, которые те обеспечивают. В Таблице 1 перечислены спецификации WMI-провайдера. Стоит отметить, что провайдер может выполнять не одну функцию; поэтому провайдером может быть, например, и класс, и источник событий. Чтобы прояснить определения свойств в Таблице 1, приведу пример провайдера, который наделен большинством этих свойств. Источник (провайдер) событий EventLog определяет несколько объектов, включая EventLog Computer, EventLog Record, EventLog File. Провайдер EventLog Computer - поставщик классов, поскольку он определяет объекты, используя классы, и должен предоставлять описания этих классов WMI. Данный провайдер является также поставщиком экземпляров, так как он может предоставить несколько экземпляров для каждого из своих классов. Один из таких классов - EventLog File. Провайдер EventLog предоставляет экземпляры для каждого из журналов системных событий (system's event logs) (например, журналы системных событий, прикладных событий, событий в системе безопасности).
Провайдер EventLog определяет экземпляр данных и предоставляет управляющим приложениям возможность нумеровать записи, а также запрашивать определенные свойства записей журнала событий. Это свойство позволяет классифицировать провайдера EventLog как поставщика свойств. Чтобы обеспечить управляющим программам возможность использовать WMI для архивирования и восстановления журналов событий, провайдер EventLog дополняет объекты класса Event Log File методами Backup и Restore. Это позволяет отнести провайдера EventLog к числу поставщиков методов. Наконец, управляющая программа может зарегистрироваться для получения сообщений о появлении новых записей в одном из журналов. Таким образом, провайдер EventLog, использующий WMI для уведомления о появлении новых записей в журнале событий, является поставщиком событий.
CIM подобен объектно-ориентированным языкам программирования C++ и Java, в которых проектировщик создает представления в виде классов. Использование классов дает разработчику возможность задействовать всю мощь технологии моделирования наследования и композиции. Подклассы могут наследовать определенные атрибуты родительских классов и добавлять собственные свойства или переопределять свойства, унаследованные от родительских классов. Класс, который наследует свойства другого класса, является наследником родительского класса. Классы также могут иметь сложное наследование: разработчик может построить класс, являющийся производным от нескольких родительских классов.
DMTF предоставляет несколько классов как часть WBEM-стандарта. Эти классы - основа CIM; они обеспечивают интерфейс ко всем областям управления и являются частью модели ядра CIM. Примером такого класса может служить CIM_ManagedSystemElement. Этот класс содержит несколько основных свойств, которые идентифицируют физические компоненты, такие, как устройства, и логические компоненты, такие, как файлы. Свойства включают заголовок, описание, дату установки и статус. Таким образом, классы CIM_LogicalElement и CIM_PhysicalElement наследуют атрибуты класса CIM_ManagedSystemElement. Оба эти класса также являются частью модели ядра CIM. Стандарт WBEM называет их абстрактными, так как они существуют исключительно как родительские для других классов (т. е. не может существовать экземпляра абстрактного класса). Поэтому абстрактные классы можно представлять как шаблоны, определяющие свойства для использования в других классах.
Другая категория классов представляет объекты, которые являются специфическими для задач управления, но не зависят от конкретной реализации. Эти классы составляют общую модель и рассматриваются как расширение основной модели. Примером класса общей модели может служить класс CIM_FileSystem, наследующий свойства класса CIM_LogicalElement. Поскольку фактически каждая операционная система, будь то Windows 2000, Linux или другие версии UNIX, использует файловую систему как основную структуру хранения информации, класс CIM_FileSystem является естественной составляющей общей модели.
Последняя категория классов включает специфические для каждой технологии дополнения к обычному классу. Windows 2000 определяет большое число таких классов для представления объектов, специфических для среды Win32. Поскольку все операционные системы хранят данные в файлах, общая модель CIM включает класс CIM_LogicalFile. Класс CIM_DataFile является наследником класса CIM_LogicalFile, и Win32 добавляет классы Win32_ PageFile и Win32_ShortCutFile для соответствующих типов файлов операционной системы Win32.
Провайдер EventLog широко использует наследование. На Экране 1 показан вид WMI CIM Studio - браузера для просмотра классов, поставляемого с WMI SDK (Microsoft поставляет WMI SDK с MSDN). Он позволяет увидеть, где провайдер EventLog использует наследование в классе Win32_NTEventlogFile, который и образуется от CIM_DataFile. Файлы EventLog являются файлами данных, имеющими специфические атрибуты, такие, как имя файла журнала и количество содержащихся в нем записей. По дереву, которое показывает браузер, видно, что класс Win32_ NTEventlogFile имеет сложное наследование, в котором класс CIM_ DataFile - наследник CIM_LogicalElement, а CIM_LogicalElement - наследник CIM_ManagedSystemElement.
ЭКРАН 1. Просмотр наследования классов с помощью браузера классов CIM Studio.
Как я упоминал вначале, разработчики провайдеров WMI-классов пишут свои классы на языке MOF. Экран 2 показывает определение класса Win32_NTEventlogFile, который был выбран на Экране 1. Отметим корреляцию между первыми шестью свойствами в правой панели списка на Экране 1 и определениями этих же свойств MOF-файла на Экране 2. CIM Studio использует желтые стрелки, чтобы показать наследование подобных свойств от родительского класса. Поэтому мы не видим определений этих свойств в определении класса Win32_ NTEventlogFile. Один из терминов, который в связи с этим стоит рассмотреть, - динамический (DYNAMIC) провайдер. Он является описательным указателем (характеристикой) для класса Win32_ NTEventlogFile, показанного в MOF-файле на Экране 2. Этот термин означает, что инфраструктура WMI запрашивает WMI-провайдера о значениях свойств, ассоциированных с классом, тогда, когда управляющее приложение запрашивает эти свойства. СТАТИЧЕСКИМ является тот класс, для которого провайдер сохраняет свойства в репозитарии WMI; инфраструктура WMI ссылается на репозитарий для получения значений, а не опрашивает для этого провайдера. Поскольку модифицирование репозитария - операция относительно дорогая, динамические провайдеры более эффективны для объектов, у которых изменение свойств происходит часто.
ЭКРАН 2. Определение класса Win32_NTEventlogFile.
После создания классов в MOF разработчики WMI могут вставить определения класса в WMI несколькими путями. Первый путь предполагает компиляцию MOF-файла в бинарный MOF(BMF)-файл - более компактное бинарное представление, чем MOF-файл, - и размещение BMF-файла в инфраструктуре WMI. Другой путь для провайдера - это компилировать MOF и использовать WMI API COM, чтобы предоставить определения классов WMI-инфраструктуре. Наконец, провайдер может использовать инструмент mofcomp, чтобы непосредственно дать WMI-инфраструктуре откомпилированное представление класса.
Классы определяют свойства объектов, и экземпляры класса представляют объекты в системе. WMI использует пространство имен, содержащее несколько подпространств, которые WMI упорядочивает иерархически, чтобы организовать экземпляры объектов. Прежде, чем управляющее приложение сможет обращаться к объектам в пределах пространства имен, оно должно подключиться к нему.
WMI называет пространство имен корневого каталога root. Все варианты установки WMI имеют четыре предопределенных пространства имен, которые постоянно находятся ниже корня: CIMV2, Default, Security и WMI. Некоторые из этих пространств имен имеют внутри себя другие пространства. Например, CIMV2 включает пространства имен Applications и ms_409, как подпространства имен. Провайдеры иногда определяют свои собственные пространства имен; встречаются пространства имен WMI (которые определяет провайдер WMI драйверов устройств Windows) ниже корня Windows 2000. В отличие от пространства имен файловой системы, которая включает иерархию каталогов и файлов, у пространства имен WMI - только один уровень в глубину. Вместо использования имен для идентификации объектов, как это делается в файловой системе, WMI задействует свойства объектов, которые определены как ключи. Управляющие приложения определяют имена класса с ключевыми названиями, чтобы указать определенные объекты в пределах пространства имен. Таким образом, каждый экземпляр класса должен быть уникально идентифицирован по своим ключевым параметрам. Например, провайдер EventLog использует класс Win32_NTLogEvent для представления записей в журнале событий. У этого класса два ключа: LogFile и RecordNumber, тип обоих - строка. Управляющие приложения, которые делают запрос WMI на экземпляры записей в журнале событий, получают от провайдера ключевые пары, идентифицирующие запись. Приложение ссылается на запись, используя синтаксис, который показан в примере: \\MARKLAPTOP\CIMV2: Win32_ NTLogEvent .Logfile="Application", RecordNumber="1".
Первый компонент в имени идентификатора - компьютер, на котором объект расположен, а второй - пространство имен, в котором объект постоянно находится. Имя класса следует за двоеточием, а ключевые названия и их связанные значения следуют за точкой. Запятая отделяет ключевые значения.
ЭКРАН 3. Просмотр зависимости классов.
Многие типы объектов так или иначе связаны с друг другом. Например, объект "компьютер" имеет процессор, программное обеспечение, операционную систему, активные процессы и т. д. WMI позволяет провайдерам создавать классы зависимости, чтобы задать логическую взаимосвязь между двумя различными классами. Классы зависимости сопоставляют один класс с другим, поэтому имеют только два свойства. Поскольку свойства - это ссылки на классы, они состоят из имени класса и модификатора Ref. На Экране 3 показана зависимость, в которой MOF-файл провайдера EventLog ассоциирует класс Win32_ NTLogEvent с классомWin32_ComputerSystem. Получая объект, приложение управления может сделать запрос ассоциированным объектам. Таким образом провайдер создает иерархию объектов.
На Экране 4 показан WMI-браузер объектов Object Browser (еще одно средство разработки, включенное в SDK) с корнем пространства имен CIMV2. Системные компоненты Win32 обычно размещают свои объекты в пределах пространства имен CIMV2. Object Browser сначала выводит экземпляр объекта Win32_ComputerSystem MARKLAPTOP, который соответствует компьютеру. Затем он получает объекты, связанные с Win32_ComputerSystem, и отображает их ниже MARKLAPTOP. Интерфейс пользователя Object Browser обозначает связанные объекты значком "папка с двойной стрелкой". Связанные с типом класса объекты отображаются ниже папки.
ЭКРАН 4. Применение браузера объектов Object Browser для просмотра корня пространства имен.
Object Browser показывает, что зависимый класс провайдера файла регистрации событий Win32_NTLogEventComputer расположен ниже MARKLAPTOP и что существуют многочисленные образцы класса Win32_NTLogEvent. На Экране 3 видно, как MOF-файл определяет класс Win32_NTLogEventComputer, чтобы сопоставить класс Win32_ ComputerSystem с классом Win32_ NTLogEvent. Указание экземпляра события Win32_NTLogEvent в Object Browser позволяет увидеть свойства класса в правой области окна. Microsoft Object Browser, по замыслу его создателей, должен был помогать WMI-разработчикам исследовать объекты, хотя приложение управления выполнило бы те же самые действия и представило информацию более понятным способом.
Инфраструктура WMI представлена прежде всего исполняемым файлом \winnt\system32\wbem\winmgmt.exe. Это служба Windows 2000, которая запускается при старте управляющего приложения через Service Control Manager или при первом обращении провайдера WMI к WMI API. Большинство компонентов WMI постоянно находятся в \winnt\system32 и \winnt\system32\wbem, включая MOF-файлы Win32, встроенный провайдер DLL и управляющее приложение WMI DLL. В каталоге \winnt\system32\wbem можно найти ntevt.mof - MOF-файл провайдера журнала событий EventLog, а также ntevt.dll, библиотеку DLL провайдера EventLog, которую загружает winmgmt.exe.
Каталоги ниже \winnt\system32 \wbem вмещают репозитарий, файлы журналов и MOF-файлы. WMI реализует репозитарий, называемый Object Management CIM (CIMOM) репозитарием, как файл \winnt\system32\wbem\repository\cim.rep. Служба WinMgmt выбирает многочисленные параметры настройки, связанные с репозитарием (включая различные параметры, такие, как расположение резервной копии CIMOM и интервалы копирования), из раздела системного реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WBEM\CIMOM.
Разработчики Microsoft хотели расширить возможности управления всеми аспектами Windows 2000, так что пришлось создать механизм взаимодействия драйверов устройств с WMI. Драйверы устройств используют несколько новых интерфейсов для предоставления данных WMI и исполнения команд, получаемых от WMI. Команды WMI System Control commands названы в Microsoft командами управления системой. Разработчики присвоили название провайдера Windows Driver Model (WDM) провайдеру драйверов устройств, потому что одинаковые интерфейсы WMI в драйверах Windows 2000 существуют и для Win98-драйверов. Поскольку это кросс-платформенные интерфейсы, они включены в зону ответственности WDM, кросс-платформенную архитектуру драйверов устройств. Windows 2000 размещает объекты WDM в пространстве имен \root\wmi.
WMI осуществляет защиту на уровне пространства имен. Если приложение управления успешно соединяется с пространством имен, то оно имеет право просматривать свойства всех объектов и обращаться к ним в этом пространстве. Администратор может использовать приложение управления WMI для контроля доступа пользователей к пространству имен. Чтобы запустить приложение управления WMI, следует выбрать Start/Administrative Tools/Computer Management. Затем нужно открыть Services and Applications, щелкнуть правой кнопкой мыши на WMI Control и выбрать Properties, чтобы открыть диалоговое окно WMI Control (Local) Properties, показанное на Экране 5. Чтобы настроить защиту для пространства имен, на закладке Security следует выбрать нужное пространство имен и нажать Security. Другие закладки в диалоговом окне позволяют изменять функции и резервировать параметры настройки, хранимые в системном реестре.
ЭКРАН 5. Настройка системы безопасности пространства имен.
Хотя в довольно короткой статье был охвачен целый ряд аспектов, функциональные возможности WMI на самом деле гораздо шире. Гибкость WMI и универсальность его применения в Windows 2000 делают этот механизм мощной технологией программного обеспечения среднего уровня, которой с успехом могут пользоваться поставщики инструментальных средств для управления предприятием.
Марк Русинович
доктор философии в области вычислительной техники Университета Карнеги-Меллон и один из соавторов многих популярных утилит для Windows NT, включая NTFSDOS, Filemon, Regmon и Recover. С ним можно связаться по электронной почте по адресу: mark@sysinternals.com, или через Web-узел http://www.sysinternals.com.
Таблица 1. Спецификации провайдера.
| Провайдер | Описание |
|---|---|
| Класс | Может вызывать, изменять, удалять, просматривать класс, специфичный для провайдера. Также поддерживает выполнение запросов. |
| Экземпляр | Может вызывать, изменять, удалять, просматривать экземпляры системы и классы, специфичные для провайдера. Также поддерживает выполнение запросов. |
| Свойство | Может вызывать и изменять значения индивидуальных свойств. |
| Метод | Вызывает методы, специфичные для класса провайдера. |
| Событие | Формирует уведомления о событии. |
| Потребитель | события Ставит в соответствие физического потребителя событий логическому для передачи уведомлений о событиях. |