Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


Rambler's Top100

  

Слишком много справочников

Брюс Робертсон

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

Какое колесо? Самый очевидный ответ — службу справочника. Если распределенное приложение сравнить с автомобилем, то служба справочника — это, скорее, его рулевое колесо. Оно “направляет” приложение к тем ресурсам, какие ему необходимы. Однако среднестатистическая сеть имеет более одного “рулевого колеса”.

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

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

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

Справочники сетевых ОС и приложений

Во многих сетях применяются сетевые ОС: NetWare и Windows NT. Справочники этих ОС содержат имена и пароли пользователей. Соответствующие службы справочника обеспечивают аутентификацию пользователей и дают возможность присваивать им определяемые администратором права доступа к ресурсам. Такие развитые системы, как StreetTalk фирмы Banyan и NetWare Directory Services (NDS) фирмы Novell, содержат дополнительную информацию о каждом пользователе, например его номер телефона. Некоторые справочники включают данные о таких объектах, как, например, принтер (тип бумаги, местоположение принтера и т. д.).

При внесении в справочник данных о пользователях и сетевых ресурсах возникают проблемы его масштабируемости. Как и в случае со службами именования доменов DNS, службы справочника сетевых ОС должны быть распределены, чтобы выравнять нагрузку (на серверы. — Прим. ред.) и повысить надежность хранения данных. .Необходимо также, чтобы они имели иерархическую структуру. Конкретные подходы к выполнению этих требований могут сильно различаться. Кроме распределения информации требуется еще и ее тиражирование. Например, система StreetTalk фирмы Banyan распределяет элементы своей базы данных, но до недавнего времени она не тиражировала их. В результате, если сервер, на котором хранится бюджет пользователя, выходил из строя, то пользователь не мог войти в сеть, даже если на других серверах действовали службы, с которыми он мог бы работать. Тиражирование данных позволяет устранить проблему обеспечения доступа к сетевым ресурсам при отказе одного из серверов, поддерживающих службу справочника.

Часто средства, работающие со службой справочника сетевой ОС, поставляются производителем только этой ОС, хотя все производители ОС публикуют свои интерфейсы API, чтобы их могли использовать разработчики третьих фирм. В случае NetWare некоторые производители сетевых приложений действительно использовали API фирмы Novell, хотя, как правило, только для поддержки вспомогательных функций системного администрирования. Может быть, у новых интерфейсов Net2000 фирмы Novell будет иная судьба.

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

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

Я, лично, не могу запомнить необходимые в постоянной работе пароли для подключения к каждому из серверов SQL Server, к большой ЭВМ, к серверу удаленного доступа в сети главного офиса нашего журнала. Я регулярно беспокою обслуживающий персонал просьбой изменить мой пароль или напомнить мое ныне действующее (системное) имя пользователя.

Из всего вышесказанного складывается совершенно унылая картина. Кто знает, сколько различных компаний занималось и занимается изобретением “рулевого колеса”, то есть служб справочника? Разработчики приложений не хотят “нести потери” в битве сетевых ОС за господство на рынке и совершенно правильно сомневаются в том, что службы справочников этих ОС будут соответствовать всем их требованиям. Поэтому они создают их самостоятельно и не используют API справочников сетевых ОС. Каждая фирма идет собственным путем, реализуя управление распределенными базами данных и аутентификацию пользователей.

Сколько тратится сил! Неудивительно, что приобретение, поддержка и даже использование сетевых приложений обходятся недешево. Тяжело и фирмам в целом, и отдельным пользователям. Традиционно для решения подобных проблем использовался единственный метод: положить все яйца (сетевые объекты) в одну корзину, что в данном случае означает стандартизацию справочной системы. Корпорация Microsoft предлагает другое решение — использовать свой новый интерфейс ODSI (Open Directory Services Interface).

Устранение различий

Итак, первый метод очевиден — принятие стандарта. К сожалению, это проще сказать, чем сделать. Не существует единого мнения относительно того, каким должен быть стандарт на службу справочника. Если какую-либо из существующих систем и можно было бы принять в качестве стандартной, так это DCE (Distributed Computing Environment). Однако на практике DCE не получила широкого применения, поэтому производители ПО с неохотой создают программы для этого API.

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

Я видел работу программных средств, использующих одну службу справочника. Еще до появления набора приложений BackOffice корпорация Microsoft выпустила СУБД SQL Server, которая осуществляла аутентификацию при помощи справочника домена Windows NT. До этого администрировать SQL Server было так же тяжело, как и справочник Bindery сети NetWare 3.х. Каждый сервер имел собственную базу данных с именами и паролями пользователей. И что еще хуже — пароли передавались по сети в незакодированном виде. Теперь, зарегистрировавшись на сервере Windows NT, я получаю доступ к любому серверу SQL Server, не вводя каждый раз свое имя пользователя и пароль. Администраторам SQL Server больше не нужно размещать информацию о пользователях на каждом сервере. Имена пользователей извлекаются из справочника домена Windows NT. Новый продукт Exchange также будет поддерживать интегрированную систему информационной безопасности.

К сожалению, так взаимодействуют только сетевая ОС и приложения корпорации Microsoft. Очевидно, что этого недостаточно. Из-за большого неудобства работы с несколькими различными службами справочника многие пользователи должны “хранить верность” одной сетевой ОС и ее сетевым службам. Ориентация на использование службы справочника и приложений одного производителя сильно ограничивает свободу выбора программных средств. Вместо того, чтобы ждать появления продукта Godot (DCE) или более-менее сносных комплексных решений одного производителя, можно использовать еще один подход.

Маскировка различий

Новый лучик надежды связан с появлением интерфейса ODSI корпорации Microsoft. При помощи технологии WOSA (Windows Open Systems Architecture), которая используется этим интерфейсом для упрощения доступа к ODBC-совместимым базам данных, у нас появляется возможность работать с различными службами справочника, которые применяют общий интерфейс API.

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

Чтобы достичь настоящей ассимиляции служб справочника, интерфейс ODSI должен быть перенесен на компьютеры Macintosh и Unix-машины, а также на большие ЭВМ. Службы справочника должны взаимодействовать с интерфейсами API программы, предоставляющей услуги ODSI. Хотя фирма Banyan с энтузиазмом поддержала новый интерфейс API, непонятно, как к нему отнесутся фирма IBM и другие компании. Неясно так же, какова будет судьба справочников фирм Lotus, Oracle, Sybase и других производителей сетевых приложений. Совершенно очевидно, что должно пройти некоторое время, чтобы интерфейс ODSI приобрел популярность. Ведь он не начнет “приносить плоды”, пока производители не добавят в свои существующие приложения средства его поддержки. Интерфейсу ODSI предстоит еще много испытаний.

Интерфейс ODSI

Сегодня невозможно применять в информационной системе масштаба предприятия одну стандартную службу справочников, не ограничивая пользователей в выборе приложений. Еще не наступил тот час, когда какой-либо производитель служб справочников сможет объявить себя победителем. Однако если у вас нет возможности использовать единую службу, то наилучший выход — получить доступ ко всем имеющимся. Интерфейс прикладных программ ODSI (Open Directory Services Interface — открытый интерфейс службы справочников) фирмы Microsoft предлагает именно такие возможности: обеспечивая прозрачный доступ ко всем справочникам, он в то же время предоставляет пользователю видимость работы с единой службой.

Такая гибкость, обеспечивающая доступ ко всем службам справочников, достигается за счет создания единого интерфейса прикладных программ (API) клиентской стороны, который может применяться как пользователем, так и производителем таких служб. (Подобные возможности анонсированы фирмой Novell для интерфейсов прикладных программ продукта Net2000, но при этом используется несколько иная технология, подобная применению шлюзов). Подход, принятый в технологии ODSI, должен позволить разработчикам приложений использовать единый интерфейс API, подбирая поставщика услуг для конкретной задачи.

Однако пока все это из области мечтаний. При внимательном рассмотрении технологии ODSI видно, что у нее есть немало серьезных проблем. Для оценки ситуации придется подождать создания конкретных продуктов, поддерживающих ODSI. Заметим, что, скажем, фирма Banyan собирается поддерживать ODSI, в отличие от фирмы Novell, которая делать этого не собирается. Кроме того, подход, базирующийся на клиентском API, не может реально обеспечить интеграцию всего множества справочников серверной стороны и не дает гарантий защиты данных при взаимодействии служб. И, наконец, кто будет продвигать ODSI на платформы, отличные от Windows? Ведь мы уже были свидетелями того, как корпорация Microsoft прервала все деловые контакты с фирмами Digital и Software AG по вопросам переноса технологии связывания и внедрения объектов (OLE) на платформы Unix.

Начнется ли война вокруг интерфейса API служб справочников? Я думаю, что да. Однако события, связанные с ODSI, можно рассматривать только как одно из сражений. Гораздо важнее разрешить проблему служб справочников в целом, а не уладить частный конфликт.

Четыре компонента

Простейший компонент технологии ODSI включает интерфейс WinSock и интерфейс, поддерживающий вызовы удаленных процедур (RPC). Эти два интерфейса входят в набор средств разработчика Win32 SDK и позволяют программисту регистрировать приложения или ресурсы в сетях, в которых применяются различные системы наименования устройств. Точно также пользователи получают прозрачный (то есть независимый от конкретной службы имен) доступ к именам сетевых объектов и их правильную интерпретацию в адресном пространстве. Этот компонент ODSI обеспечивает наиболее простую функцию служб справочников работу с обычными именами устройств. Тем не менее, на сегодня службы справочников большинства сетей такие возможности не предоставляют (свидетельство тому — Domain Name Services).

Следующий компонент технологии ODSI — интерфейс Network Provider Interface, который уже сегодня успешно используется в Windows 95 и Windows NT. Сетевые ОС могут превратиться в поставщиков услуг, скрытых за этим интерфейсом, и потому неразличимых для пользователя. Для каждой сетевой ОС аутентификация может производиться независимо. Поэтому на одной машине с Windows легко можно иметь программы переадресации запросов различных сетевых ОС. На моем компьютере с Windows NT сосуществуют программы переадресации запросов фирм Microsoft и Novell. Каждая из них устанавливается отдельно, однако после этого работа с обеими сетевыми средами выглядит очень похоже.

Для того, чтобы обеспечить единый пароль при входе в систему, разработчики приложений могут переписать собственные службы справочников. Однако мне кажется более предпочтительным подход, когда разработчики приложений используют уже готовые службы справочников других фирм. Не надо изобретать колесо. Лучше обратить серьезное внимание на справочники конкретных сетевых ОС. Ведь даже пересмотр разработчиками архитектур уже созданных ими справочников не окажется достаточным. Разработчики должны отказаться от собственных справочников и использовать вместо них те, которые доступны не только их приложениям. Например, производители систем управления реляционными базами данных (СУРБД) часто вынуждают сетевых администраторов решать задачи управления каждым сервером такой системы в отдельном пространстве имен. А при развитии информационной системы число независимых пространств имен, этаких островков, постоянно увеличивается.

Теперь подошла очередь рассмотреть OLE DB — интерфейс OLE, который позволяет сделать запрос к любой базе данных, в том числе и к базе данных службы справочников. Этот интерфейс определяет способ доступа к любой информации базы данных, находящейся в его компетенции. Он напоминает интерфейс ODBC, но применяется для приложений, использующих объекты OLE, и не ограничен базами данных, поддерживающими язык SQL. Интерфейс OLE DB предоставляет только функции чтения, тем не менее он позволит более интеллектуально использовать справочники, обеспечивая задание большего числа атрибутов и процедур поиска для клиентских приложений.

И, наконец, последний компонент ODSI — интерфейс OLE DS — специально ориентирован на работу со службами справочников. При стандартизации объектов в справочниках возможно создание независимых (от конкретной службы) приложений для работы со справочниками. Пользователь будет иметь в своем распоряжении приложения с определенными атрибутами, независимыми от особенностей конкретного справочника. Поскольку этот интерфейс полностью еще не определен, он, возможно, будет поддерживать некоторые расширенные функции распределенного управления (скажем, выделение разделов баз данных) или только основные функции администрирования (например, добавление новых пользователей и групп, изменение атрибутов объектов). Несомненно, интерфейс OLE DS значительно облегчит написание приложений для синхронизации справочников существующих служб.

Разработчикам служб справочников придется писать программы для каждого интерфейса, чтобы охватить все необходимые области применения. Используемые в настоящее время системные имена пользователей и устройств, по-видимому, не противоречат требованиям интерфейсов Network Provider Interface и WinSock/RPC. В случае же с интерфейсами OLE DB и OLE DS дело обстоит сложнее.

Далеко ли можно уйти с одним клиентским API?

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

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

Что в имени тебе моем?

Хочется верить, что технология ODSI облегчит ситуации, подобные моей, когда приходится иметь дело с двумя программами переадресации запросов (для двух сетевых ОС) в среде Windows. Меня каждый раз ставит в тупик мой текущий пароль, замена которого производится еженедельно. Я постоянно забываю его, а система не желает работать с уже существующим набором паролей. Когда я однажды переформатировал диск, то в первый момент не смог получить доступ ни к одному сетевому ресурсу: просто не знал, какие имена и пароли необходимо вводить.

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

Технология ODSI может указать правильный путь разработчикам приложений, ограничив их в создании собственных служб справочников. Однако сами разработчики хотели бы доверять сторонней службе, чтобы получать от нее необходимые для своих приложений услуги. Производители служб справочников для информационных систем масштаба предприятия (приверженцы среды распределенных вычислений — DCE и разработчики сетевых ОС, включая фирмы Novell, Banyan и Microsoft) должны убедить их, что они “нарастят мощные мышцы” своих служб на “скелете” интерфейсов API. Многие фирмы, создающие приложения и связующее ПО, используют достаточно сложные имена сетевых объектов, связанные со спецификой своих приложений, и даже специальные службы справочников. Они явно не хотят жертвовать этим в интересах соблюдения стандартов и обеспечения простоты обращения, так же как и покупатели их продуктов. Требования таких фирм должны быть учтены производителями служб справочников для информационных систем масштаба предприятия. Я глубоко убежден, что первые будут ставить много новых и неожиданных проблем перед последними. Если же эти проблемы будут решены, то технология ODSI может позволить разработчикам приложений усилить поддержку служб справочников, не связанных с конкретными приложениями.

Сейчас службы различных фирм должны взаимодействовать на уровне сервера, сосуществуя без конфликтов и перекрытия функций. Например, пользователь справочников фирмы Novell должен иметь возможность запросить ресурсы, первоначально определенные в справочниках продуктов фирм Banyan и Microsoft или среды DCE. Продукты и специалисты, в задачи которых входит синхронизация справочников разных производителей, должны стать ненужными. Иначе мы никогда не избавимся от постоянной головной боли при управлении копиями справочников.

Технология ODSI фирмы Microsoft является попыткой “оторвать” интерфейсы API служб справочников от собственно этих служб. Такая стратегия доказала свою эффективность на примере интерфейсов ODBC и MAPI. Однако ODSI не представляет собой универсального решения. Распутать клубок запутанных справочников информационной системы масштаба предприятий, опираясь только на клиентские интерфейсы API, невозможно. Тем не менее это первый полезный шаг в направлении полного решения данной проблемы.

Net2000

Наконец-то компания Novell приобретает привычный для всех облик. После нескольких лет интенсивного “поедания” таких “блюд”, как ОС и приложения для ПК, многим в Novell стало ясно, что компания заметно “прибавила в весе”. Но, несмотря на все старания Novell, корпорация Microsoft продолжает удерживать первенство на рынке ПО для ПК. Боб Франкенберг, возглавив Novell, затратил немало усилий, чтобы “посадить компанию на диету”, изменив ее рыночную политику. Novell за бесценок продала почти все, что скупила в течение последних нескольких лет (сейчас в кулуарах компании тот период, когда ею руководил Нурда, называют в шутку “эрой обжорства”). DOS корпорации Digital исчезла с горизонта, а у системы UnixWare (компании Novell) теперь другой хозяин. Более того, Novell избавилась от WordPerfect и Quattro Pro (Продав их фирме Cord. — Прим. ред.). Сейчас эта компания выглядит более стройной, чем когда-либо в прошлом, и такой “изящный облик” привлекает взгляды бизнесменов с Уолл-Стрит.

Все эти стратегические решения и “переход на строгую диету” убедили меня в том, что Novell снова хочет выглядеть сильной и целеустремленной компанией. Единственное, что меня удивляет, — это достаточно большой срок, который потребовался ей, чтобы вернуться на круги своя.

Действительно ли обновленная Novell выглядит так же эффектно, как и раньше? Совпадают ли ее благие намерения с реальными возможностями? Ответы на эти вопросы во многом определяются тем, как отнестись к новой “коллекции одежды” Novell от Франкенберга — набору интерфейсов API, получившему название Net2000. Можно ли назвать эту новую “коллекцию” достойной императора?

Сетевые службы и приложения

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

С размахом рекламируя Net2000, Novell старается обратить внимание и фирм-разработчиков приложений, и покупателей на реальные проблемы интеграции сетевых служб. И это неплохо. Нам всем требуются приложения, которые смогли бы использовать существующие службы справочника и защиты данных. У большинства предприятий нет времени и людских ресурсов, чтобы поддерживать индивидуальную систему администрирования для каждого приложения. Это требует значительных затрат. На многих предприятиях предпочитают иметь одну среду аутентификации пользователей для всех приложений. Многие служащие попросту не в силах запомнить несколько имен и паролей для входа в систему. В результате часто в качестве паролей используются легко угадываемые слова или пароли записываются на листках бумаги, которые прикрепляются где-нибудь на видном месте. Все это существенно снижает эффективность системы информационной безопасности. Безусловно, сеть и сетевые приложения — это чрезвычайно важные ресурсы фирмы, чтобы оставить их без какой-либо защиты. Использование одной службы и для защиты данных, и для работы со справочником сетевых ресурсов может значительно упростить, а значит сделать возможными, внедрение и последующую поддержку сетевых приложений. Применение таких внешних служб намного облегчает и разработку приложений, поскольку сужается диапазон функций, выполняемых приложениями. Разработчики считают: лучше купить, чем писать самим.

Однако сетевые приложения обычно не поддерживают внешние службы справочника и защиты данных. Это хорошо видно на примере рыночной ситуации, сложившейся вокруг продуктов фирмы Banyan. Данная фирма выпустила солидный набор сетевых служб Enterprise Network Services (ENS) и глобальную службу справочника Universal StreetTalk, однако на эти продукты обратили внимание только пользователи сетей VINES. Мало просто иметь сетевые службы, нужны приложения, которые могли бы работать с ними.

Novell убеждает разработчиков сетевых приложений, что Net2000 представляет собой именно тот набор внешних сетевых служб, который способен решить все проблемы покупателей. В данном случае Novell выступает в качестве конкурента корпорации Microsoft, фирмы Banyan и, что более существенно, производителей программных средств, поддерживающих распределенную среду вычислений (Distributed Computing Environment — DCE). Тем не менее, поскольку по числу пользователей продуктов компании Novell значительно опережает любого из конкурентов, то, естественно, что для разработчиков сетевых приложений средства этой компании привлекательнее, чем продукты конкурентов. Таким образом, попытка Novell направить усилия разработчиков ПО на решение проблемы интеграции сетевых служб и приложений может оказаться успешной.

Новая “коллекция одежды” Novell

Набор интерфейсов Net2000 выглядит довольно полным и универсальным. Он будет включать интерфейсы API для работы со справочником сетевой ОС, для совместного использования файлов и принтеров, для передачи данных и их защиты, для администрирования системы и поддержки групповых работ, а также для обеспечения межпрограммной связи (средства middleware). Большая часть этих средств входит в существующие продукты компании Novell. В частности, для создания клиентских программ в качестве интерфейса API передачи данных по сети предполагается использовать уровень XTI/Streams системы NetWare, а для поддержки службы справочника и обеспечения защиты данных — интерфейсы API в составе NDS. В Net2000 также будут включены интерфейсы API системы NetWare, обеспечивающие совместное использование файлов и принтеров, API продукта GroupWise для поддержки рабочих групп и API системы Tuxedo для организации межпрограммной связи.

В Net2000 не будет службы баз данных. Система Tuxedo компании Novell ориентирована не на доступ к определенным данным, а на установление связи между программами. И поскольку Novell ушла с рынка СУБД, другие поставщики восполнят этот “пробел”.

Большое значение имеют планы Novell выпустить клиентские API для различных платформ сетевых рабочих станций. В отличие от набора интерфейсов WOSA корпорации Microsoft, предназначенных только для Windows (хотя наиболее популярные API, такие, как ODBC, могут быть перенесены на разные платформы другими производителями ПО), Novell намерена с помощью своих API поддерживать все наиболее распространенные платформы. Более того, в текущем году компания планирует выпустить эти интерфейсы в виде наборов средств разработчика ПО (SDK), и, возможно, это произойдет намного раньше, чем корпорация Microsoft завершит работу над основными интерфейсами ODSI (Open Directory Services Interface). Политика Novell достаточно агрессивна. Компания хотела бы, чтобы ее интерфейсы API могли работать везде.

Набор интерфейсов Net2000 компании Novell, в первую очередь, предназначен для ее собственных сетевых служб. К тому же эти интерфейсы являются собственностью Novell. И если корпорация Microsoft позволяет любому производителю ПО свободно использовать свои клиентские API, такие, как ODBC, MAPI и ODSI, на настольных системах в качестве поставщиков услуг, то Novell не допускает этого. Она предлагает использовать свои сетевые службы и интерфейсы API и с их помощью предоставляет возможность получить доступ к службам других производителей. Средства компании могут обеспечить связь между клиентскими и своими API (в частности, между MAPI и службами поддержки групповой работы в Net2000).

В настоящее время решается проблема создания мультиплексора поставщиков услуг SPM (service provider multiplexer), который позволил бы программам других фирм (не Novell) обрабатывать вызовы к интерфейсам Net2000. Однако компания Novell по сравнению с Microsoft или IETF не имеет достаточного опыта в создании API, независимых от программных средств других производителей ПО. Найдется ли разработчик ПО, который будет писать программы, использующие частные API компании Novell и конкурирующие со службами этой компании? Учитывая тот факт, что фирма Banyan объявила о намерениях поддерживать интерфейс ODSI корпорации Microsoft, маловероятно, что она поведет себя аналогичным образом и в отношении Net2000.

Ориентированный на клиентские станции подход корпорации Microsoft подразумевает для поддержки приложений различных производителей размещать на каждом ПК по несколько поставщиков услуг. Например, применение интерфейса ODBC требует установки на всех клиентских станциях нескольких сетевых программ, каждая из которых предназначена для работы с определенной реляционной СУБД. Со своей стороны, специалисты компании Novell считают, что такой подход плохо масштабируется.

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

В настоящее время Novell старается распространить данный подход на другие сетевые службы. Новый продукт NetWare Application Server Manager, выпуск которого запланирован на этот год, предназначен для интеграции сред серверов приложений, таких, как Windows NT и Unix, в единую среду Net2000 (при этом должна осуществляться синхронизация их пространств имен с NDS). Дальнейшие планы Novell предусматривают поддержку стандарта Х.500 и среды DCE, хотя пока непонятно, как будет решаться проблема интеграции систем защиты данных.

Есть мнение, что серверы приложений и их клиентские программы, написанные для интерфейсов API, не входящих в набор Net2000, можно будет согласовать (либо с помощью связующих программ, либо как-то иначе) с интерфейсами Net2000. Как это можно сделать неясно, но, по-видимому, предполагается, что приложения (например, из набора Microsoft BackOffice, такие, как SQL Server и Exchange) будут в силу тех или иных причин четко функционировать в сетях, управляемых с помощью NDS. Однако это представляется маловероятным. Возможно, гораздо легче переписать приложения так, чтобы они напрямую поддерживали интерфейсы Net2000, но это означает, что вместо Novell придется ждать производителей приложений.

Что, вам не нравится ждать? Вы сомневаетесь, сможет ли компания Novell в этом году выпустить все, что она пообещала? Часть этих обещаний, по-видимому, станет реальностью не раньше 1997 г. Пока перспективы вполне обнадеживающие, даже если сейчас они кажутся туманными. “Изящная фигура” Novell вселяет в меня надежду, что хотя бы часть намеченного будет выполнена в обещанные сроки.

Этюд в багровых тонах

Итак, новая “коллекция одежды” Novell пока выдержана только в красных тонах прежнего логотипа фирмы. Несмотря на то, что сетевые службы компании Novell имеют реальный шанс быть принятыми крупными корпорациями, маловероятно, что занимающиеся разработкой стандартов организации, такие, как IETF, узаконят их. Это вряд ли случится, даже если принять во внимание тот факт, что для Internet больше подходит NDS, чем DNS (Domain Name Services). Novell создала свою собственную “всемирную сеть” под названием NetWare Connect Services, которая целиком в ее власти. В этой сети NDS должна быть стандартом.

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

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


распечатать статью




  
3 '1996
СОДЕРЖАНИЕ

колонка редактора

• Как заработать миллион

локальные сети

• Слишком много справочников

• Жесткие диски большой емкости для серверов

• Проблема сертификации кабелей

• Виртуальные ЛВС: мифы и реальность

• NDS - совместимое клиентское ПО для Windows 95

корпоративные сети

• Технология АТМ

• Сетевые технологии XXI века

• Суперсервер в сети NetWare

• Программные средства удаленного доступа

• Задержки при передаче файлов

услуги сетей связи

• Спутниковая сеть ТЕЛЕПОРТ-ТП: технология DAMA на российском рынке

• Компьютерная телефония снова в пути

• Спутниковая система передачи данных ROMANTIS DATA

приложения клиент-сервер

• Системы обмена электронными сообщениями

интернет и интрасети

• Windows 95: окно в Internet

• Парад программ просмотра

защита данных

• Защита от электронного шпионажа

• Защищайтесь, а не то ...

новые продукты

• Новая версия Back Offise, Система хранения данных SPANStor-Mag, IWare облегчает работу по TCP/IP в сети NetWare, Концентраторы TigerStack



 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх