proNovell

Уважаемые коллеги, требуется совет знатоков тонкостей Дерева.

Суть в следующем: пишется программный комплекс ( относительно сложный) , который планируется опереть на данные из Дерева.

Комплекс разворачивается на вин2003сервере, Дерево, естественно, на NW-серверах. (При необходимости можно вести речи о покупке Дерева для вин-сервера и об установке реплики и на вин-сервере, но это - на край)

Комплекс запускается и в начале своей работы считывает данные из Дерева. И с ними и работает. Предполагается - круглосуточно и постоянно.

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

ВОПРОС: существует ли возможность оперативно отражать в программном комплексе изменения, произведенные в атрибутах и объектах Дерева?
Т.е. что то типа механизма событий в винде: в Дереве произошло некое событие (изменилось значение некого атрибута) и информация об этом событии ( или его суть, что одно и тоже) оперативно передалось бы внешней (по отношению к Дереву), программе.

Постоянное сканирование Дерева из программы решением не считается.

Спасибо.

Мне почему-то кажется, что, возможно, в решении задачи мог бы помочь IDM ( и даже его Starter Pack ). Ведь он как раз и умеет по событию ( event based ) - типа изменение атрибута в дереве - выполнять некие действия - типа синхронизация этого атрибута на приемнике ( другое дерево, БД, по ЛДАП и пр. - вплоть до самописных драйверов, что тоже, кстати, вариант ) и более хитрых операций.

Так что ежели ваш относительно сложный комплекс умеет все необходимое проделывать с АД ( или его легко этому научить ), то можно подумать об использовании этого самого IDM Starter Pack ( bundled edition ) для слива требуемых объектов ( пользователей ? групп ? ) из еДира в АД.

А просто лазить за каждым атрибутом каждый раз в дерево (без слива=кеширования информации в комплекс) не получится? Слишком медлено? Netware, например, так и делает.

2 Ковалев Артем

А просто лазить...

Не, не просто. Т.е. прочесть - не проблема. Проблема - когда это делать.

Дело в том, что программка НЕ ЗНАЕТ, что я ВОТ В ЭТОТ МОМЕНТ ВРЕМЕНИ что то в Дереве поменял.

И ей надо сказать : "В Дереве вот прямо сейчас произедены изменения. Полезь и перечитай данные по новому".

Проблема в том, что Дерево ( или кто-то/что-то другое) должно дать отмашку программе на перечитывание Дерева.

2 Андрей Тр. aka RH

Ведь он как раз и умеет по событию ( event based ) - ... - выполнять некие действия

Андрей! Чуть подробнее,пожл.

Музалёв Николай писал(а):2 Ковалев Артем

А просто лазить...

Не, не просто. Т.е. прочесть - не проблема. Проблема - когда это делать.

Дело в том, что программка НЕ ЗНАЕТ, что я ВОТ В ЭТОТ МОМЕНТ ВРЕМЕНИ что то в Дереве поменял.

И ей надо сказать : "В Дереве вот прямо сейчас произедены изменения. Полезь и перечитай данные по новому".

Проблема в том, что Дерево ( или кто-то/что-то другое) должно дать отмашку программе на перечитывание Дерева.

Еще раз. По вашей схеме программа кеширует данные из дерева один раз где-то у себя. И вы хотите этот кеш периодически по "отмашке" дерева обновлять. Вот я и спрашиваю - обойтись без кеша нельзя? Хранить данные в дереве и брать их только оттуда?

Музалёв Николай писал(а):И ей надо сказать : "В Дереве вот прямо сейчас произедены изменения. Полезь и перечитай данные по новому".
Андрей Тр. aka RH

Ведь он как раз и умеет по событию ( event based ) - ... - выполнять некие действия

Андрей! Чуть подробнее,пожл.

Ну например : у меня есть два дерева - еДир1 и еДир2, и еще АД, и еще сиквельная БД ( или две ). Все они представлены в IDM в виде неких драйверов ( упрощенно говоря - драйвер для такой connected system умеет работать только с ней, знает про операции с ней, форматы данных и т.п. ).

И между этими драйверами в IDM установлены взаимоотношения и написаны политики, которые применяются к потокам данных между этими connected system. Ими регулируется, что именно, в каком направлении и по какому критерию передается ( и как по пути трансформируется ).

Например, в еДир1 кто-то ( или что-то ) поменяло атрибут title у пользователя Вася - на "менеджер". По этому событию пошли данные по трубам ( в политике написано - следить за title и в случае чего делать то-то и то-то ) - в еДир2 у Васи этот атрибут тоже сменился, плюс его добавили в существующую там группу "менеджеры", а в АД - в отдельную группу "менеджеры отдела продаж", подсмотрев в каком отделе Вася живет в одном из его атрибутов. А если такой группы в АД до этого не было, то ее создали, по заданному правилу. В БД Васю занесли в таблицу с менеджерами, плюс записали в адресную книгу менеджеров Васин номер телефона. Через несколько секунд ( минут ) всё устаканилось до следующего события.

Короче, сценариев может быть немеряно. Аналогично со сменой паролев - Вася сменил себе пароль в еДир1, и его пароли сразу же сменились в еДир2 и в АД.

Самое интересное, что эти самые драйверы - теоретически - можно писать и самому - для своих приложений. Просматривается некая аналогия с драйверами для устройств. Надо только знать, как писать ..

2 Андрей
Спасибо. Посомтрю-подумаю...
Только вопрос: у меня 51 системы. С ними это чудо работать будет? или как?
И не подскажите ссылки для самОбразования меня?
Спасибо.

2 Артем

...спрашиваю - обойтись без кеша нельзя?

Предполагается, что нет.
Поясню и чуть детализирую задачу. И приведу маль. пример.

Относится задача к пресловутому документОбороту.
в ДО Есть понятие "должность" и есть понятие "работник" . (Как можно видеть - строго соответсвует нашим ORGAN Role & User.)
Предполагается создать в Дереве множество РОЛЕЙ (которые в нашей системе строго соответствовали бы ДОЛЖНОСТЯМ) и заполнять их пользователями в соотв. с реальностями.
И при необходимости - менять пользователей на должностях, меняя атрибут окупант в соотв. ORG Role.
Тут понятно, надеюсь.

В начале работы комплекса он считывает эту информацию из Дерева к себе в память.
На базе этой информации формирует у себя некий справочник должностей и полномочий...
Эти данные используются практически в каждой транзакции. И очень интенсивно.

Итак.
В системе есть "должность" ГЛАВНЫЙ, ее на тек. момент занимает пользователь Василий Пупкин.
Было это прописано в Дереве: окупантом ОРГ_роли я указал Васю. И система в начале работы это прочитала и приняла к сведению.

Внутри нашей задачи должность ГЛАВНЫЙ (например, Главный инженер конторы) должена подписывать, согласовывать, отвергать и тд массу электронных документов.

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

Так, если нужна формальная подпись на вынос мусора из конторы - ее даст любой, кто ноне ГЛАВНЫЙ, а если нужна толковая консультация, как инженера, то документ надо послать именно Васе.

Теперь представьте, что Вася отбывает, а по приказу его должен замещать ДругойТоварищ.
В Дереве я тут же выдергиваю Васю из окупантов соответствующей ORG Role и вставляю туда другого товарища (ДТ).

Теперь надо заставить как-то принудительно обновиться справочник должностей и полномочий нашей системы, чтобы все видели, что ГЛАВНЫЙ теперь - ДТ, а Васи вообще нету и нескоро будет.

Если ничего не делать, то изменения вступят в дело после завтрашней перезагрузки, а это не дело.

Поскольку интенсивность обновлений Дерева НА ДВА-ТРИ порядка меньше, чем интенсивность обмена документами, то очевидно, что каждый раз, как куда-кому-какой документ посылать приходиться, проводить перечитывание данных Дерева - это плохое решение.

Итак.
Первое решение - от Андрея.
А еще кто что подскажет?

Если будете писать на языке C, то используйте функции ldap_monitor_events() или ldap_monitor_events_filtered(), описанные в LDAP Libraries for C. Обе требуют eDirecory v 8.7 или старше! LDAP SDK бесплатно скачивается с http://developer.novell.com

Музалёв Николай писал(а):у меня 51 системы. С ними это чудо работать будет? или как?
И не подскажите ссылки для самОбразования меня?

Поясню и чуть детализирую задачу. И приведу маль. пример.
Относится задача к пресловутому документОбороту.

Насчет 5.1 - ИМХО скорее или как. Я уже не помню, что из линейки DirXML - IDM поддерживало 5.1 .. по-моему, текущая версия требует 6.5 Но ! Ведь можно же это все завести и на Венде ( а она у вас есть, раз ваш комплекс на 2003 ). Заодно поставите на нее еДир с репликой.

Хотя, прочитав изложенные подробности вашей задачи, у меня закралась мысль, что, может, вами и писать ничего не надо .. Вы для начала почитайте поподробнее про возможности IDM ^

IDM - Features & Benefits
Product Info ( ряд документов )

и Workflow-based Provisioning from the Provisioning Module, в частности.

When a provisioning request requires permission from one or more individuals in an organization, the request starts a workflow. The workflow coordinates the approvals needed to fulfill the request. Some provisioning requests require approval from a single individual; others require approval from several individuals. In some instances, a request can be fulfilled without any approvals.

Там есть и про ДО, и про подписи, и про товарищей, временно замещающих. Правда, оно все стоит денег - так что писать подобный комплекс самим - это тоже вариант.

Музалёв Николай писал(а):Дело в том, что программка НЕ ЗНАЕТ, что я ВОТ В ЭТОТ МОМЕНТ ВРЕМЕНИ что то в Дереве поменял.

И ей надо сказать : "В Дереве вот прямо сейчас произедены изменения. Полезь и перечитай данные по новому".

Проблема в том, что Дерево ( или кто-то/что-то другое) должно дать отмашку программе на перечитывание Дерева.

(На правах размышлений)

В Дереве постоянно что-то меняется.

Интересно, насколько затратно перечитывать всё дерево с шагом, например, в минуту?

В свое время ковырялся в АМ 3.0 Там под событием понимается простой шедулер, по событиям которого DirXML реплицирует те или иные данные...

Николай! К сожалению в функции ldap_parse_ds_event() обнаружена утечка памяти, по крайней мере на платформах Linux и NetWare. Утечка небольшая - от 40 до 60 байт в зависимости от платформы, но при большом потоке событий или длительном мониторинге становится проблемой. Пока не исправят, остается старый добрый NWDSERegisterForEvent() на платформе NetWare.