ADAM: возвращение в Эдем

19 февраль, 2004 - 00:00Георгий Вишня
Как известно, служба Active Directory в Windows Server 2003 претерпела целый ряд изменений и доработок по сравнению с прежней версией ("Компьютерное Обозрение", # 17, 2003). И хотя большинство усовершенствований коснулось администрирования и обслуживания Active Directory, в ней появились и некоторые новые возможности, интересные разработчикам приложений.

Любая идея, чарующая нас, совершенно бесполезна до тех пор, пока мы не решим ею воспользоваться.
Ричард Бах

Действительно, в службе Active Directory из Windows Server 2003 реализованы новые идеи и инструменты, способные заинтересовать не только системных администраторов, но и разработчиков ПО на платформах Microsoft. Так, в ней появилась инфраструктура, аналогичная репозиторию интерфейсов в архитектуре CORBA (реестр, построенный на базе публикаций сервисов и точек подсоединения к ним), а также существенно улучшилась поддержка расширенных возможностей семейства протоколов LDAP.

Однако наиболее значительным нововведением, несомненно, является технология и отдельный продукт Active Directory Application Mode (ADAM). Как мы увидим в дальнейшем, появление ADAM знаменует собой качественное изменение статуса Active Directory -- глобальное централизованное вместилище корпоративной информации трансформировалось в гибкую распределенную технологию хранения структурированных данных.

Это открывает совершенно новые возможности для эффективной организации информационной инфраструктуры в относительно независимых подразделениях больших компаний и даже отдельных коллективах (в том числе, и разработчиков), а стало быть, и дополнительные пути для продвижения в корпоративную среду решений, использующих технологии Active Directory.


Сущность ADAM

ADAM возвращение в Эдем
Рис. 1
Что же представляет собой ADAM? Фактически это реализация каталога Active Directory в виде отдельного приложения. В отличие от стандартной службы Active Directory, интегрированной с операционной системой, ADAM является обычной прикладной программой, для развертывания которой не требуются ни домен, ни контроллер домена, ни даже сервер (рис. 1). Благодаря этому ADAM совершенно легко инсталлируется и деинсталлируется, запускается и останавливается на любом ПК под управлением Windows Server 2003 и Windows XP. Кроме того, на одном и том же физическом компьютере могут одновременно выполняться сразу несколько экземпляров ADAM (при этом каждый из них должен быть настроен на использование уникального TCP/IP-порта для доступа к нему). Администрирование ADAM также практически ничем не отличается от обслуживания обычной службы Active Directory, для чего применяется один и тот же набор утилит.

Таким образом, важнейшим достоинством ADAM с точки зрения разработчиков является преодоление наиболее серьезного концептуального ограничения Active Directory в Windows 2000 Server, а именно: пересмотр априорного предположения о том, что вся информация, хранящаяся в каталоге, представляет интерес абсолютно для всех пользователей и приложений сети. Отказ от такого глобального подхода позволяет разработчикам более полно реализовать потенциал Active Directory как единой технологии хранения разнородных (разрозненных) данных в своих решениях. При этом их продукты станут еще жизнеспособнее благодаря широкому спектру потенциальных сценариев применения ADAM.


Применение

ADAM возвращение в Эдем
Рис. 2
Остановимся вкратце на использовании ADAM при создании и развертывании корпоративных приложений. Хотя некоторые из них представляют наибольшую ценность для системных администраторов, большая часть все же пригодится и разработчикам, взявшим на вооружение технологию Active Directory, ведь для корпоративной среды простота и единообразие управления и администрирования -- важный фактор.

Частные каталоги отдельных приложений. ADAM позволяет создавать и поддерживать частные экземпляры каталогов для отдельных приложений, причем не связанные с центральным каталогом Windows Server 2003 (более того, его присутствие в сети даже не является обязательным условием для развертывания ADAM). Это и есть наглядная иллюстрация "деглобализации" хранения корпоративной информации. Таким образом, данные, актуальные только для конкретного приложения, не публикуются в центральном каталоге, а находятся в отдельном пространстве, что упрощает администрирование, а также позволяет избежать многих проблем применения Active Directory, характерных для Windows 2000 Server. В частности, в каждом конкретном случае может использоваться собственная схема каталога -- без необходимости корректировки структуры центрального хранилища (если таковое имеется).

Многообразие подходов к IT-менеджменту в организации. Развертывание множества каталогов на базе ADAM, адаптированных под потребности различных приложений, способствует децентрализации администрирования IT-инфраструктуры предприятия. Это может оказаться эффективным для центральных офисов крупных организаций, в которых есть большое число департаментов. Например, экземпляры ADAM для "локальных" приложений, обслуживающих специфические потребности отдельных подразделений, устанавливаются именно и только на их серверах. По идее, с обслуживанием ADAM сможет справиться выделенный или невыделенный администратор из числа сотрудников данного подразделения, в результате чего снизится нагрузка на IT-персонал центрального офиса.

Безусловно, при построении такой децентрализованной инфраструктуры функция ведения учетных записей пользователей все равно должна остаться за центральным каталогом (и его администраторами), к которому "локальные" экземпляры ADAM будут обращаться по вопросам аутентификации.

Кстати, с появлением ADAM может измениться и привычная модель администрирования. Скажем, на центральных серверах компании развертываются экземпляры ADAM для всех критичных приложений, и для каждого из них настраиваются соответствующие политики (разбивка на разделы, частота архивирования, необходимость в синхронизации с центральным каталогом и т. д.). При этом удельный вес работ по поддержке центрального каталога Active Directory заметно снизится, а надежность всей инфраструктуры вырастет.

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

Стоит также отметить, что подобные подходы к организации информационной инфраструктуры будут становиться все более привычными и оправданными с популяризацией приложений, взаимодействующих с каталогом Active Directory.

Интеграция с доменами Windows NT 4.0. Благодаря умению ADAM связываться с серверами Windows NT 4.0 Server для аутентификации пользователей, приложения, интегрированные с каталогом Active Directory, смогут работать не только в сетях под управлением Windows Server 2000/2003, но и в более "пожилых" доменах Windows NT 4.0 Server. Это, в свою очередь, позволит организациям, еще не осуществившим миграцию на новейшие серверные платформы, обойтись без этой процедуры (которая при любом сценарии связана со значительными временными затратами и чревата неожиданными проблемами, в том числе недокументированными либо уже описанными в Microsoft Knowledge Base, но не имеющими прямого решения) и в ближайшем будущем.

Интеграция с унаследованными системами. Для предприятий, давно применяющих компьютерные технологии с целью автоматизации своей деятельности, типична ситуация, когда у них уже развернуты одна или несколько важных для бизнеса систем (например, реестр служащих или клиентов наподобие Siemens EAD, хранилище истории контактов с клиентами и т. д.), использующих каталоги того или иного формата (к примеру, X.500 или LDAP). С появлением новых платформ и приложений эти системы не могут быть выведены из эксплуатации, поскольку выполняют достаточно критичные для жизнедеятельности компании операции.

В этой связи возникает необходимость интеграции существующих структур с новыми информационными компонентами. Здесь и придет на помощь ADAM -- благодаря хорошо отлаженным механизмам обмена данными с разнообразными системами каталогов (прежде всего по протоколу LDAP) этот продукт способен выступить в качестве своеобразного middleware, предоставляющего новейшим решениям на базе Windows и .NET доступ к данным унаследованных систем. При этом программистам не придется тратить время на изучение специализированных middleware-продуктов (вроде Attachmate myEXTRA Enterprise и др.), а конечным пользователям -- лицензировать их для обеспечения работы новых интегрированных решений. Подобным же образом ADAM может использоваться для переноса информации в Active Directory.

Хотя описанная ситуация более характерна для крупных западных корпораций, данные возможности окажутся полезными и отечественным компаниям, занимающимся заказными разработками для рынков Северной Америки и Западной Европы.

Web-порталы и системы доступа в extranet. В последнее время в корпоративной среде получили большое распространение Web-порталы, частным случаем которых являются extranet-шлюзы, обеспечивающие авторизированный доступ удаленных пользователей к Web-приложениям в корпоративной сети (например, OpenNetworks DirectorySmart, Netegrity SiteMinder или Microsoft Mobile Information Server). Как правило, системы подобного рода должны поддерживать свой собственный каталог учетных записей и ACL, описывающих их права на различные ресурсы. ADAM вполне может стать технологической платформой для решения подобной задачи (рис. 2), предоставляя механизмы аутентификации и авторизации на основе стандартных средств протокола LDAP. При этом отпадает необходимость в трудоемкой процедуре развертывания полноценной службы Active Directory для нужд Web-портала.

Централизованные адресные книги. Одним из очевидных и практических примеров применения ADAM может стать создание общей адресной книги контактов, независимой от почтового сервера (или в дополнение к нему), что в некоторых случаях позволит отказаться от использования дорогостоящего ПО. С таким каталогом умеют работать программы Outlook, Outlook Express и другие почтовые клиенты и PIM, поддерживающие LDAP-протоколы. Кстати, данный сценарий вполне подходит и для совсем небольших компаний.

Приложения "ускоренного развертывания". Инсталляцию ADAM разрешается включать непосредственно в дистрибутивы приложений. При этом благодаря наличию развитого программного интерфейса ходом установки и конфигурированием ADAM способны управлять VBScript- и JScript-сценарии для Windows Scripting Host, подготовленные самими разработчиками в соответствии с потребностями их программ. Тем самым конечный пользователь (который, как говорилось выше, может и не быть профессиональным администратором) будет избавлен от активного участия в процессе развертывания.


Преимущества

До сих пор при создании приложений под Windows 2000 Server разработчики предпочитали не пользоваться инфраструктурой Active Directory -- как максимум, некоторые программы применяли ADSI для получения информации об учетных записях при аутентификации и авторизации, оставляя в стороне прочие возможности объектного хранилища. Исключения из этого правила столь немногочисленны, что их следует воспринимать как "заморские диковинки". Даже среди программных решений самой Microsoft на сегодняшний день в полной мере интегрируются с Active Directory лишь два продукта -- Exchange 2000/2003 и Mobile Information Server 2002.

Такая ситуация вполне объяснима -- вспомним еще раз о роли глобального хранилища информации, которую Active Directory играет в Windows 2000 Server. Это усложняет администрирование хранилища, резервное копирование данных и синхронизацию реплик -- причем две последние операции производятся сразу со всем содержимым каталога (нетрудно представить, какой сетевой трафик создала бы процедура ежечасного резервирования быстро обновляемых данных, складируемых в каталог некоей системой автоматизации торговой деятельности или CRM-системой). Кроме того, изменение схемы объектного хранилища под нужды нового приложения может негативно сказаться на функционировании прежних. Наконец, далеко не каждая организация даже сегодня имеет желание и готова разворачивать у себя Active Directory.

Благодаря тому что ADAM действует как отдельное приложение, разработчики получают ту же технологию Active Directory, но без старых ее недостатков. Теперь они могут прямо на своих машинах поддерживать несколько каталогов с различными схемами, работающими к тому же совершенно изолированно друг от друга. Соответственно и для развертывания готового приложения у заказчика не потребуется вмешательства в существующую информационную среду или задействования дорогостоящих серверов.

Еще одним преимуществом для разработчиков, использующих ADAM, как ни странно, станет снижение затрат на администрирование в их собственной компании, ведь отпадет также и потребность в организации и поддержке отдельных доменов для программистских отделов. При этом каждый разработчик будет иметь полное IT-окружение создаваемого приложения локально, у себя на машине -- что называется, под рукой.

Пример использования ADAM

'подключение к экземпляру ADAM
'порт 389 используется по умолчанию
Set objADAM = GetObject("LDAP://localhost:389/dc=fabrikam,dc=com")

'создание нового подразделения в оргструктуре каталога - Treasure
Set objOU = objADAM.Create("organizationalUnit", "ou=Treasure")
objOU.SetInfo

'создание 2 учетных записей пользователей,
'принадлежащих новому подразделению
Set objUser = objOU.Create("user", "cn=vladd")
objUser.Put "displayName", "Vladimir Didenko"
objUser.SetInfo

Set objUser = objOU.Create("user", "cn=ivanm")
objUser.Put "displayName", "Ivan Maryanenko"
objUser.SetInfo

'отображение в консоли всех учетных записей
'для подразделения Treasure
Set objDeprt = _
GetObject("LDAP://localhost:389/ou=Treasure,dc=fabrikam,dc=com")
objDeprt.Filter = Array("user")
For Each objUser In objDeprt
Wscript.Echo objUser.Name
Next


Простота программирования

Безусловным плюсом технологии ADAM является простота программного доступа к каталогу, который обеспечивается тем же API, что используется при работе с глобальной службой Active Directory и наверняка уже знаком многим создателям серверного ПО для платформы Windows. Впрочем, данный API заслуживает отдельного рассмотрения и даже небольшого исторического экскурса.

Те, кто в 1996--1997 гг. трудился над интеграцией своих Win32-приложений с моделью безопасности доменов Windows NT 4.0 Server, конечно, помнят всю нетривиальность решения этой задачи и радостные чувства, связанные с реализацией компанией Microsoft в мае 1998 г. технологии ADSI 1.1 (Active Directory Service Interface), ставшей логическим завершением исследовательского проекта по разработке OLE Directory Services Interface (1995--1997 гг.). Данный интерфейс значительно упростил интеграцию Win32- и Web-приложений под IIS 4.0 c доменами Windows NT 4.0 Server особенно благодаря наличию библиотек ADSI с готовыми ActiveX-объектами, позволившими программировать высокоуровневые обращения к каталогу на любом языке, поддерживающем COM-технологии.

В первые релизы ADSI был включен и провайдер доступа к LDAP-каталогам. Постепенно этот компонент приобрел более стабильные очертания (ADSI 2.5 в 2000 г.), став основным средством организации запросов пользовательских приложений к Active Directory в Windows 2000 Server (см. "Компьютерное обозрение", # 22, 2000). Это совпало по времени с общим усилением интереса Microsoft к промышленным стандартам LDAP.

Теперь ADSI обеспечивает и доступ к ADAM, причем принципиальных отличий по сравнению с применением глобального каталога Active Directory просто не существует (не считая изменений в формате адреса каталога, в котором, кроме стандартного имени домена, теперь требуется также указывать имя сервера, где развернута копия ADAM, и номер порта). В листинге приведен простейший WSH-сценарий на VBScript, иллюстрирующий подключение к ADAM, создание в каталоге новых объектов и запрос на получение данных о них.

В силу отмеченного отсутствия существенной разницы в обращении к ADAM и к глобальному каталогу Active Directory программы, написанные с расчетом на одно из этих хранилищ, легко адаптируются и для использования другого.


ADAM vs. MSDE: ничья

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

Однако нельзя сказать, что ADAM сможет стать заменой MSDE при развертывании прикладного ПО в экономичных конфигурациях. Как показывает сравнительная таблица, оба продукта имеют свои уникальные ниши и, скорее всего, будут и дальше использоваться разработчиками для платформ Windows.

Сравнение ADAM и MSDE 
Характеристика  ADAM  MSDE 
Лицензирование для конечных пользователей  Бесплатно для пользователей Windows XP и Windows Server 2003  Необходима лицензия на один из продуктов, содержащих MSDE (например, Microsoft Office 2000/XP Professional) 
Производительность  Ограничена лишь возможностями аппаратного обеспечения и ОС  Резко падает при числе одновременных подключений свыше 5 
Технологии доступа  ADSI, LDAP поверх TCP/IP, DSML  Стандартные технологии доступа к реляционным БД из приложений на платформе Windows 
Область применения  Приложения, работающие со структурированными данными, организованными в виде иерархических деревьев (наподобие структуры компании, штатного расписания и т. д.)  Приложения, работающие с данными, которые можно представить в терминах реляционной модели 
Возможность включения в инсталляционные пакеты  Да (для партнеров Microsoft)  Да (для партнеров Microsoft) 


Надежда на возвращение в рай?

Технология ADAM, безусловно, открывает новые горизонты для разработчиков относительно применения Active Directory в своих продуктах. Учитывая простоту развертывания и администрирования решений, базирующихся на ADAM, конечными пользователями, легкость программирования и удобство организации среды разработки, можно спрогнозировать повышение спроса на данные технологии в сфере прикладного ПО. Не исключено, что появление ADAM приблизит решение проблемы "философского камня разработки" -- так называемой единой регистрации (single sign-on) для доступа к разнообразным ресурсам в корпоративной IT-среде.

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