Эти API представляют собой набор функций в библиотеке /usr/lib/libwlm.a , позволяющих приложениям получать доступ ко всем задачам, которые администратор WLM может выполнить с помощью команд WLM. Поддерживаются следующие задачи:
Кроме того, функция wlm_set_tag позволяет приложению задавать тег приложения и режим наследования этого тега дочерними процессами при вызовах функций fork и exec. Эта библиотека поддерживает многонитевые 32- и 64-разрядные приложения.
Тег приложения - это строка символов, применяемая в качестве одного из критериев для классификации процессов (согласно файлу rules). Этот критерий может определяться приложением в дополнение к системным критериям, таким как пользователь (user), группа (group), приложение (application) и тип (type).
Если процесс изменяет тег приложения, то немедленно выполняется его повторная классификация в соответствии с действующими правилами классификации уровней суперкласса и подкласса текущей конфигурации WLM. При просмотре правил классификации учитываются все атрибуты процесса, включая новый тег.
Тег определяет класс процесса, если он указан хотя бы в одном правиле классификации. Формат и значение тегов должны быть подробно описаны в документации к приложению, чтобы администраторы WLM могли применять различные значения тегов в правилах классификации, различающих экземпляры одного приложения.
Поскольку у разных пользователей могут быть разные требования к набору характеристик процессов приложения, разработчикам приложений рекомендуется предусматривать возможности по настройке компонентов тега с помощью файлов конфигурации или атрибутов времени выполнения. Администратор приложения может задать формат тега приложения. Применяемые при этом атрибуты и формат тега WLM зависят от приложения и определяются его разработчиком.
Например, экземпляр сервера базы данных может сообщить информацию о текущей базе данных (db_name) и порте TCP, к которому подключен пользователь (port_num). Администраторы могут использовать эту информацию следующим образом:
Для того чтобы администратору были доступны все эти возможности, он должен иметь возможность задать содержимое и формат тега. В данном примере мы предполагаем, что формат тега может быть передан приложению в файле конфигурации или параметрах запуска, например в виде WLM_TAG=$db_name или WLM_TAG=$db_name_$port_num.
При задании тега приложение может также указать, должен ли этот тег наследоваться дочерними процессами; при этом дочерние процессы будут относиться к тому же классу, что и родительский процесс. Обычно наследование тегов включено.
Ниже приведен пример применения тегов приложения. В этом примере тег базы данных совпадает с ее именем. Два экземпляра сервера, работающие с разными базами данных, задают два разных тега, например, db1 и db2.
Системный администратор может создать два класса, dbserv1 и dbserv2, и настроить классификацию серверов баз данных и их дочерних процессов с помощью тегов. Затем с этими классами могут быть связаны различные параметры доступа к ресурсам.
Для реализации этой схемы можно задать следующие правила присвоения:
* класс resvd пользователь группа приложение тип тег * dbserv1 - - dbadm /usr/sbin/dbserv - db1 dbserv2 - - dbadm /usr/sbin/dbserv - db2
API WLM позволяет приложениям выполнять следующие действия:
Все изменения могут применяться только к файлам свойств указанной конфигурации WLM. Если в качестве имени конфигурации указана пустая строка, то изменения будут применены к классам, загруженным в память, что приведет к немедленному обновлению текущей конфигурации.
Для вызова указанных API требуются те же права доступа, что и для выполнения аналогичных действий с помощью командной строки или интерфейсов SMIT и Web-администратора системы:
Если управление WLM осуществляется одновременно администраторами WLM из командной строки и приложениями с помощью API, следует принять дополнительные меры предосторожности. Оба этих интерфейса работают в одном пространстве имен и объектов.
Кроме того, администраторы могут узнать об изменении базовых данных WLM с помощью API (например, о создании новых классов), только увидев эти классы в выводе команд wlmstat и аналогичных. Для того чтобы избежать ошибок в работающих приложениях, при ручном обновлении WLM системным администратором из командной строки классы, созданные с помощью API, но не определенные в файлах свойств WLM, не удаляются из памяти автоматически. Они продолжают существовать до явного удаления функцией wlm_delete_class или командой rmclass (вызванной из командной строки, интерфейса SMIT или Web-администратора системы).
API WLM позволяют приложениям выполнять следующие действия:
Для вызова указанных API требуются те же права доступа, что и для выполнения аналогичных действий командами wlmcntrl и wlmassign:
Функции API WLM и wlm_get_bio_stats предоставляют приложениям доступ ко всей статистической информации WLM, которую можно получить командой wlmstat.
Функция wlm_check позволяет пользователю просматривать определения классов и правила классификации указанной конфигурации WLM. Функция API wlm_classify (см. Присвоение процессов классам в WLM) позволяет приложению выяснить, какой класс был бы присвоен процессу с указанными атрибутами.
Для обеспечения двоичной совместимости с будущими версиями структур данных во всех вызовах API указывается номер версии библиотеки. Это позволит библиотеке определить формат структур данных, ожидаемый приложением.