Грядущее пришествие DSML и DEN

Язык разметки службы каталогов способен превратить совместимость каталогов в реальность.

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

Обеспечение надлежащего QoS для требующих гарантированной пропускной способности приложений, таких, как голос по IP (Voice over IP, VoIP), потоковое мультимедиа, VPN на базе IP и т. д., составляет главное препятствие на пути достижения удовлетворенности и, что более важно, доверия со стороны пользователей. Однако доверие пользователей неизбежно возрастет, если они смогут быстро и без труда выбирать необходимые им сервисы в реальном времени и настраивать их в соответствии со своими потребностями.

Несмотря на всю шумиху, предпосылки и цели упрощенного создания услуг достаточно весомы, хотя их реализация и сопряжена с трудностями. И только идя по этому пути, альтернативные операторы местной связи (Competitive Local Exchange Carrier, CLEC), независимые провайдеры связи (Independent Communications Provider, ICP) и операторы разнотипных систем (Multiple System Operator, MSO) могут с выгодой конкурировать с традиционными операторами местной связи (Incumbent Local Exchange Carrier, ILEC).

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

Одним словом, DEN редко совместимы со всеми продуктами, встречающимися в крупных частных или общедоступных сетях. Самим по себе каталогам не хватает общей схемы, своего рода индекса содержимого, хранимого по названиям категорий. Например, Active Directory компании Microsoft не понимает, скажем, реализацию Novell на уровне схемы, в результате обмен данными между «разномастными» каталогами оказывается невозможен. Реализация DEN ставит множество задач, но эту требуется решить в первую очередь (с остальными мы познакомимся чуть позже).

ЗНАКОМСТВО С DSML

Знакомьтесь — язык разметки службы каталогов (Directory Services Markup Language, DSML); с его возможностями, как считают авторы, о проблеме совместимости вскоре можно будет говорить в прошедшем времени. Детище DSML Working Group, членами которой являются ведущие разработчики каталогов Bowstreet, Microsoft, Novell, альянс Sun/Netscape, IBM и Oracle, — он был представлен в конце 1999 г. в попытке решить вопрос совместимости. Некоторые наблюдатели надеются, что он даст второй старт DEN. Вряд ли это так, но тем не менее иметь представление о DSML необходимо.

Спецификация DSML определяет открытый расширяемый стандартизованный формат для публикации схем каталогов и обмена их содержимым. Как можно догадаться, он базируется на расширяемом языке разметки (Extensible Markup Language, XML), именно благодаря этому он и является столь полезным.

Протокол «определяет синтаксис обмена на базе XML, или словарь — набор тегов разметки, который поддерживает» эти функции, как написано в недавнем докладе эксперта в области телекоммуникаций Джима Кобилуса из Burton Group. Синтаксис охватывает заданное пространство имен XML, структуру документов, теги определений записей каталога, теги определений схемы каталога и профили приложений и документов.

DSML работает со множеством протоколов Internet — в том числе с HTTP и SMTP, не говоря уже о LDAP3, при этом XML выступает в качестве универсального переводчика. Вследствие этого DSML может иметь доступ к каталогам и в тех случаях, когда брандмауэры Internet блокируют запросы LDAP. Кроме того, он может использоваться с не опирающимися на каталог приложениями, такими, как транзакции электронной коммерции.

Какие следствия все это имеет для администраторов сетей? «Главная цель этой первой спецификации состоит в создании формата, удовлетворяющего основным требованиям к инструментарию метакаталогов и ориентированных на каталог приложений, которым необходим доступ к информации каталога через XML. Благодаря DSML имеющимся XML-совместимым приложениям будет намного проще воспользоваться услугами каталога. Если приложение способно производить синтаксический разбор XML или создавать документы XML, то оно сможет без труда обработать обмен DSML — по сути стандартный XML, — не прибегая к переводу в промежуточный формат и обратно, например в LDAP Directory Interchange Format. Как таковой, DSML представляет собой небольшой, но важный шаг вперед в направлении создания более эффективного базиса для ориентированных на каталог приложений», — говорит Кобилус.

Помимо упрощения использования каталогов приложениями XML список преимуществ DSML будет, вероятно, включать ускорение интеграции функциональности метакаталога в корпоративные сети (Intranet и Extranet), а также упрощение внедрения метакалогов для объединения каталогов разных разработчиков. DSML может и должен изменить ситуацию на рынке, как только соответствующие продукты появятся в продаже.

Следует, однако, заметить, что пока какой-либо инструментарий для составления схемы DSML отсутствует: без предопределенной схемы создатель каталога вынужден будет писать определение схемы DSML вручную, а это весьма трудоемкая задача по кодированию всей спецификации DEN на DSML. Вероятно, разработчики каталогов пойдут навстречу и предоставят спецификации, если на них будет спрос, но до тех пор администраторам придется делать все самим.

DSML И ПЕРСПЕКТИВЫ DEN

Чтобы получить максимальную пользу от DSML, вам необходимо знать, что он собой представляет, что может и чего не может делать.

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

«Стандарт вполне годится для обмена схемами информационных моделей каталогов и их содержимым между каталогами, если те могут понимать и генерировать XML, — считает Кобилус. — Кроме того, он хорошо подходит на роль общего синтаксиса для схем и содержимого разнородных каталогов при реализации метакаталога».

«Однако он не очень хорошо подходит для реализации функций доступа к каталогу (таких, как операции LDAP) по HTTP через Internet. Это не протокол доступа, механизм запросов, интерфейс программирования или обязательный набор элементов и атрибутов схемы каталога», — объясняет он.

Марк Рой, менеджер по продуктам в Top Layer Networks, лидер рынка управления с помощью правил, соглашается с ним: «Хотя DSML предлагает стандартизованный метод доступа к данным, хранящимся в репозитарии LDAP, пока что ему не хватает возможностей для активного манипулирования этими данными. DSML не способен конструировать или конкретизировать запросы LDAP к каталогу, создавать/модифицировать объекты или атрибуты каталога, указывать источник записи в каталоге и т. д. — т. е. не умеет всего того, с чем традиционное приложение, использующее стандартные методы LDAP, справляется без труда».

«Например, может так случиться, что межсетевые устройства будут усовершенствованы настолько, что они смогут самостоятельно управлять правилами для пользователей. В этом случае устройство должно будет при обнаружении пользователя в сети записать в каталог определенные данные, скажем текущий порт коммутатора (идентифицируемый по IP-адресу коммутатора), к которому подключен пользователь. DSML 1.0 не предусматривает какого-либо способа, воспользовавшись которым приложение XML могло бы записать эти данные в каталог. Возможность изменять значения атрибутов с помощью форм на базе Web, открываемая XML и DSML, чрезвычайно важна», — говорит Рой.

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

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

Какова же конечная цель всего этого? «Главная задача состоит в том, чтобы исключить необходимость установки специализированных приложений и клиентов на рабочих станциях для управления инфраструктурой, — объясняет Рой. — В результате администратор сети сможет сесть за любую рабочую станцию и использовать браузер для выполнения диагностики, составления отчетов и управления конфигурацией в реальном времени».

ВРЕМЯ ДЛЯ МОДЕРНИЗАЦИИ?

Вторая версия DSML появится еще не скоро. Хотя Рабочая группа DSML и наметила, какие изменения предстоит внести в следующий проект стандарта, не было названо никаких определенных сроков и не было дано никаких твердых обещаний.

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

• перенесение функций LDAP в DSML для обеспечения доступа к каталогу, а также операций чтения и записи по HTTP для преодоления брандмауэров и поддержки работы приложений Web с каталогами;
• публикацию иерархической каталожной информации из DSML-совместимой службы каталогов;
• идентификацию и профилирование источника схем и записей каталога в формате DSML;
• преобразование элементов и атрибутов каталога из DSML в унаследованные форматы файлов;
• определение механизмов, с помощью которых DSML-совместимые каталоги могли бы динамически расширять свои схемы в ответ на поступление документов DSML с новыми каталожными элементами и атрибутами;
• определение средств управления доступом, применимых к элементам и атрибутам в экспортируемых схемах, элементах и атрибутах каталога;
• подпись и шифрование записанных в формате DSML схем и записей каталогов для предотвращения их несанкционированного изменения.

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

Что же все это дает нам с точки зрения DEN? Из сказанного должно быть ясно, что DSML — полезная разработка, но с ограниченной функциональностью. Для реализации DEN требуются более широкие возможности активного управления и работы с метакаталогом.

Что касается DSML, то он не ориентирован исключительно на DEN. Важно знать, как DSML связан с созданием сервисов, т. е. чем DSML может помочь в поддержке специфических усовершенствованных голосовых и информационных сервисов.

Чтобы выяснить это, я обратился в компанию Abatis System, так как она является, возможно, наиболее изощренным и искусным разработчиком средств для создания сервисов, особенно с использованием XML и каталогов.

«По моему мнению, в его нынешнем виде DSML способен поддерживать приложения и каталоги с относительно простыми схемами и выполнять такие функции DEN, как поиск пользователя по имени, поиск по DNS и т. п.», — полагает Амар Шэн, директор по новой продукции в Abatis.

«Но схемы DEN весьма сложны и требуют хранения методов (поведения), взаимосвязей между объектами (ассоциаций) и ряда других возможностей представления схемы, не поддерживаемых в настоящее время DSML».

Шэн указывает на то, что объектно-ориентированная информационная модель, вроде той, что используется в DEN, не всегда хранится в каталоге. Например, данные MIB, доступ к которым осуществляется с помощью SNMP, являются объектно-ориентированными, но могут храниться где угодно. Аналогично, DEN позволяет осуществлять альтернативное преобразование данных для хранения в каталоге или другом хранилище, например в базе данных, а не только в каталоге LDAP.

Таким образом, DSML будет способен извлекать всю находящуюся в каталоге информацию DEN, но это только подмножество всей информации DEN в логической модели. (Некоторые производители, в частности Cisco Systems, обходят эту проблему посредством публикации альтернативного API для доступа к DEN, но такое решение является нестандартным.)

ВСЕ ДОРОГИ ВЕДУТ К XML

Из всего сказанного следует, что DSML наиболее эффективен, когда от него не требуют выполнять всю работу для DEN в одиночку. На самом деле, модель на базе XML выглядит весьма многообещающе, но ей требуется гораздо более широкая функциональность, чем в состоянии предоставить DSML.

Именно в этом направлении и предпринимают усилия многие разработчики в области как управления с помощью правил, так и создания сервисов. «Хотя, вероятно, мы смогли бы обойтись и XML, но тогда [без DSML] мы были бы вынуждены иметь дело с причудами каждого каталога в отдельности», — говорит Рой.

«И каждое из различных приложений, которым может потребоваться доступ к одним и тем же данным в каталоге, не смогло бы поделиться известными ему знаниями с другими приложениями XML, возлагая дополнительную нагрузку на сервер каталогов. Таким образом, XML и DSML имеют фундаментально различные и в то же время общие цели». Оба — и XML и DSML — будут использоваться для манипулирования данными в рамках схем каталогов.

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

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

Другим хорошим примером объединения возможностей XML и DEN может служить предоставление ресурсов для конкретного приложения в определенное время дня. Эффективное управление требует для реализации правил предоставления ресурсов «сверху вниз» и возможности определения состояния сети до, в момент и после задания правил.

«Скажем, у вас есть приложение XML, знающее о функционировании и состоянии сети. Это приложение XML может иметь информацию о местонахождении важных данных, необходимых DEN-совместимому элементу управления для принятия решения, — объясняет Рой. — Приложение XML может проверить/записать данные в каталог и затем передать управляемому элементу высокоуровневый указатель на структуру каталога. Затем устройство запросит и найдет указатель и все данные, на которые он ссылается, и выполнит действия в зависимости от того, что найдет».

Что касается создания сервисов, то здесь я опять обращаюсь к помощи Abatis. Ее Services Directory составляет основу Business Services Architecture (см. Рисунок 2). Каталог интегрирует системы обеспечения функционирования и сетевые элементы, предоставляя в стандартном виде информацию о сети, пользователях и сервисах (на третьем уровне и выше). Активный агент публикации/подписки позволяет системам запрашивать и получать извещения о значительных «событиях».

Для доступа к каталогу Abatis предложила свой нестандартный XML/Services — словарь на базе XML для обмена касающейся сервисов информацией, а также интерфейс для запроса заказчиком сервиса. Этот протокол имеет двоякое преимущество: во-первых, определения сервисов абстрагируются от нижележащей транспортной технологии (аналогично модели программного коммутатора), и, во-вторых, доступ к информации оказывается проще, чем в случае LDAP.

Почему это решение столь привлекательно? Оно является, вероятно, наиболее полным (и имеющим реальный практический смысл), когда речь идет об установлении связи между сетью или провайдерами приложений (Application Service Provider, ASP) профилями подписчиков (т. е. информацией о пользователях, такой, как правила, распределение пропускной способности, характеристики пакетной передачи и т. д.) и определениями сервисов, а также поведением пользователей и биллинговой информацией. Разве это не то же самое, что и DEN?

Abatis видит место и для DSML, но она более заинтересована в другом стандарте для определения своего языка XML/Services: Консорциум World Wide Web (W3C) опубликовал новый язык для составления схем XML/Schema. Он весьма популярен, имеет сильную поддержку и доступен для использования. Кроме того, он постоянно совершенствуется. Не ограничиваясь каталогами, XML/Schema позволяет представлять более разнообразные типы схем, чем DSML.

Еще важнее то, что, как утверждает Шэн, «следующая редакция XML/Schema позволит непосредственно представлять объектно-ориентированную информационную модель, в результате она будет подходить для определения схем DEN и получит благодаря этому значительное преимущество над DSML».

«Попросту говоря, она имеет более богатые возможности определения схемы. Я надеюсь, что определение информационной модели DEN на XML/Schema будет вскоре опубликовано. Вместе с тем, DSML будет, вероятно, проще для изучения и извлечения информации из каталогов. Насколько этого достаточно для его широкого распространения — покажет время».

Как упоминалось ранее, некоторые подвергают сомнению стратегическую ценность DSML и DEN. «Я считаю, что DSML нацелен на формализацию взаимосвязей между оборудованием и каталогами, но этот вопрос не столь важен для пользователей, как взаимосвязь между сервисами и каталогами», — говорит Том Нолле, президент CIMI.

«Я не думаю, что стандарты многое решают с точки зрения рынка. Однако я также не думаю, что ощущается «нехватка стандартов». Как и политиков, их уже слишком много!»

Это одна из причин, почему подход, связывающий каталоги с определениями и шаблонами сервисов, как в модели Abatis, более привлекателен для провайдеров услуг, внедряющих такое обеспечивающее оборудование, чем решение проблем QoS на первом и втором уровнях.

До сих пор мы оставляли без внимания вопрос целесообразности реализации DEN на предприятии. При строгом анализе расходов не исключено, что развертывание оборудования DEN может оказаться дороже, чем простое увеличение пропускной способности, в особенности с учетом рабочего времени, затрачиваемого на внесении изменений в каталог.

«Без сомнения, цена решения является серьезной проблемой, — говорит Шэн. — Как показали исследования, стоимость установки сервера правил для управления пропускной способностью составляет для предприятия от 150 до 600 долларов на пользователя в зависимости от выбранного решения. Оптимизация использования пропускной способности глобальной сети влетит в копеечку! Говоря другими словами, за те же деньги вы могли бы просто приобрести дополнительные каналы».

Однако в случае провайдеров услуг калькуляция оказывается совершенно иной. «Оператор получает огромную выгоду от централизации сервисной информации, разделяемой рядом систем обеспечения функционирования, — говорит Шэн. — Это позволяет избежать дублирования данных и упростить интеграцию систем».

Администраторы корпоративных сетей могут добиться экономии с помощью интеллектуального агрегатного устройства, принадлежащего провайдеру и управляемого им, вместо того чтобы полагаться на более дорогие каталоги и серверы правил DEN. Кроме того, обращение к услугам общедоступных сетей имеет и другое преимущество: распутывать гордиев узел каталогов придется не вам, а провайдеру услуг.

«Заказчики получают выгоду от значимой модели сервиса и, в меньшей мере, от того, как эта модель воплощается на уровне устройств, за что, в соответствии с современными взглядами на проблему, должны отвечать DEN, — полагает Нолле. — Переход на общедоступные сети почти полностью изолирует пользователей от вопросов, которые ставит DSML, за исключением тех, у кого имеются собственные крупные локальные сети».

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

«Нам необходим автоматизированный метод для осуществления процесса управления, если мы хотим, чтобы сети были в состоянии обеспечить требования электронной коммерции, — говорит Рой. — Если DSML может помочь в разработке такого рода систем, то он даст огромные преимущества и будет быстро взят на вооружение. Однако DSML 1.0 — это только первое слово. Он оставляет нерешенными слишком много второстепенных задач, чтобы можно было возлагать надежды на DSML 2.0».

НАПОСЛЕДОК

Так что же сказать в заключение о DSML? Если не требовать большего, чем он может дать — и учитывая цели, с которыми он создавался, — DSML является эффективным, удобным средством для обеспечения совместимости каталогов. Проблемы возникают, лишь когда DSML пытаются использовать для достижения более широких целей. Так что, возможно, мы ожидаем чересчур много от нового протокола.

Однако мы вполне можем надеяться, что дальнейшие разработки для XML приведут к эволюции каталогов в направлении более тесной интеграции между сервисами (в противовес сетевым устройствам) и пользователями. «DSML представляет ценность только как метод получения полного доступа к данным, — говорит Рой. — DSML 1.0 является только малым фрагментом того, что действительно необходимо, и я не вижу места DSML в управлении сетями, пока его возможности не расширятся».

Ресурсы Internet