История изменений

Сопоставимые чтение и запись из иерархического реестра объектов - это странно, но возможно: скорее всего, в каталог отправляется любая информация о клиенте оператора сотовой связи. Например, информация об изменении баланса после отправки СМС-сообщения.

Я бы так делать не стал: с моей точки зрения нужно подобные вещи хранить в оптимизированных на запись СУБД, при этом ссылаясь на каталог в какой-нибудь таблице people с полями uid и dn (первое-идентификатор внутри СУБД, второе - ссылка на объект в LDAP, являющийся «паспортом пользователя»).

Но здесь есть ещё один тонкий момент: до тех пор, пока с тем же каталогом LDAP работает всего одна программа - его действительно можно использовать после надлежащей оптимизации как просто «древовидную СУБД».

А LDAP-каталог - это авторитетный реестр объектов, предназначенный для совместного использования приложениями информационной системы.

LDAP-каталоги разрабатывались для того, чтобы служить объектным «скелетом» информационной модели, хранящим свойства объектов, но не их методы, то есть не их собственную программную логику.

Кости скелета не должны ничего «знать» о взаимодействии нейронов головного мозга или работе клапанов сердца. И LDAP-каталог не должен содержать сведений, которые интересны только одному конкретному приложению. Иначе получается, что приложение хранит данные своих собственных «внутренних» объектов, касающиеся того или иного объекта общей информационной модели, в самом объекте информационной модели.

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

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

Сопоставимые чтение и запись из иерархического реестра объектов - это странно, но возможно: скорее всего, в каталог отправляется любая информация о клиенте оператора сотовой связи. Например, информация об изменении баланса после отправки СМС-сообщения.

Я бы так делать не стал: с моей точки зрения нужно подобные вещи хранить в оптимизированных на запись СУБД, при этом ссылаясь на каталог в какой-нибудь таблице people с полями uid и dn (первое-идентификатор внутри СУБД, второе - ссылка на объект в LDAP, являющийся «паспортом пользователя»).

Но здесь есть ещё один тонкий момент: до тех пор, пока с тем же каталогом LDAP работает всего одна программа - его действительно можно использовать после надлежащей оптимизации как просто «древовидную СУБД».

А LDAP-каталог - это авторитетный реестр объектов, предназначенный для совместного использования приложениями информационной системы.

LDAP-каталоги разрабатывались для того, чтобы служить объектным «скелетом» информационной модели, хранящим свойства объектов, но не их методы, то есть не их собственную программную логику.

Кости скелета не должны ничего «знать» о взаимодействии нейронов головного мозга или работе клапанов сердца. И LDAP-каталог не должен содержать сведений, которые интересны только одному конкретному приложению. Иначе получается, что приложение хранит данные своих собственных «внутренних» объектов, касающиеся того или иного объекта общей информационной модели, в самом объекте информационной модели.

Безусловно, в каких-то случаях можно копировать данные приложения в объект информационной модели, чтобы другие приложения могли ими воспользоваться , но вот хранить их прямо в каталоге - это, конечно, противоречит задаче Каталогов. И задача эта максимально кратко и ёмко формулируется одним словом - интеграция. Задача LDAP-каталога - это интеграция приложений, реализующих логику информационной системы на основе единой информационной модели, костяком которой каталог и является, поскольку предоставляет авторитетный/авторитативный реест объектов информационной модели.

Сопоставимые чтение и запись из иерархического реестра объектов - это странно, но возможно: скорее всего, в каталог отправляется любая информация о клиенте оператора сотовой связи. Например, информация об изменении баланса после отправки СМС-сообщения.

Я бы так делать не стал: с моей точки зрения нужно подобные вещи хранить в оптимизированных на запись СУБД, при этом ссылаясь на каталог в какой-нибудь таблице people с полями uid и dn (первое-идентификатор внутри СУБД, второе - ссылка на объект в LDAP, являющийся «паспортом пользователя»).

Но здесь есть ещё один тонкий момент: до тех пор, пока с тем же каталогом LDAP работает всего одна программа - его действительно можно использовать после надлежащей оптимизации как просто «древовидную СУБД».

А LDAP-каталог - это авторитетный реестр объектов, предназначенный для совместного использования приложениями информационной системы.

LDAP-каталоги разрабатывались для того, чтобы служить объектным «скелетом» информационной модели, хранящим свойства объектов, но не их свойства. Методы могут быть реализованы, например, в модели JNDI, в рамках Java-приложения.

Кости скелета не должны ничего «знать» о взаимодействии нейронов головного мозга или работе клапанов сердца. И LDAP-каталог не должен содержать сведений, которые интересны только одному конкретному приложению. Иначе получается, что приложение хранит данные своих собственных «внутренних» объектов, касающиеся того или иного объекта общей информационной модели, в самом объекте информационной модели.

Безусловно, в каких-то случаях можно копировать данные приложения в объект информационной модели, чтобы другие приложения могли ими воспользоваться , но вот хранить их прямо в каталоге - это, конечно, противоречит задаче Каталогов. И задача эта максимально кратко и ёмко формулируется одним словом - интеграция. Задача LDAP-каталога - это интеграция приложений, реализующих логику информационной системы на основе единой информационной модели, костяком которой каталог и является, поскольку предоставляет авторитетный/авторитативный реест объектов информационной модели.

Сопоставимые чтение и запись из иерархического реестра объектов - это странно, но возможно: скорее всего, в каталог отправляется любая информация о клиенте оператора сотовой связи. Например, информация об изменении баланса после отправки СМС-сообщения.

Я бы так делать не стал: с моей точки зрения нужно подобные вещи хранить в оптимизированных на запись СУБД, при этом ссылаясь на каталог в какой-нибудь таблице people с полями uid и dn (первое-идентификатор внутри СУБД, второе - ссылка на объект в LDAP, являющийся «паспортом пользователя»).

Но здесь есть ещё один тонкий момент: до тех пор, пока с тем же каталогом LDAP работает всего одна программа - его действительно можно использовать после надлежащей оптимизации как просто «древовидную СУБД».

Только вот LDAP-каталог - это как раз авторитетный реестр объектов, сведения ориентированы на совместное использование любыми приложениями. LDAP-каталоги разрабатывались для того, чтобы служить объектным скелетом информационной модели. Как кости не должны ничего «знать» о взаимодействии нейронов головного мозга или работе клапанов сердца, так и LDAP-каталог не должен содержать сведений, которые интересны только одному конкретному приложению. Иначе получается, что приложение хранит данные своих собственных «внутренних» объектов, касающиеся того или иного объекта общей информационной модели, в самом объекте информационной модели.

Безусловно, в каких-то случаях можно копировать данные приложения в объект информационной модели, чтобы другие приложения могли ими воспользоваться , но вот хранить их прямо в каталоге - это, конечно, противоречит задаче Каталогов. И задача эта максимально кратко и ёмко формулируется одним словом - интеграция. Задача LDAP-каталога - это интеграция приложений, реализующих логику информационной системы на основе единой информационной модели, костяком которой каталог и является, поскольку предоставляет авторитетный/авторитативный реест объектов информационной модели.