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

В сравнении с технологией Java технология ActiveX Controls имеет как не­достатки, так и преимущества.

Недостатки связаны прежде всего с более низким уровнем безопасности распределенной обработки информации. Программные компоненты ActiveX Controls, загруженные на клиентскую систему, могут обращаться к любой ее части подобно обычному приложению. Microsoft реализовала в рамках Ac­tiveX доверительную защиту на основе цифровых сертификатов, которые обеспечивают подтверждение подлинности загруженных с сети программ­ных компонентов. Однако подтверждение подлинности еще не означает подтверждение безопасности. Кроме того, схема доверительной защиты ActiveX может оказаться недейственной, когда пользователи загружают про­граммные компоненты ActiveX Controls из Internet, особенно из неизвест­ных или сомнительных источников.

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

Что же касается производительности, то поскольку Java является интерпре­тируемым языком, аплеты Java выполняются на виртуальной машине кли­ентской системы с меньшей скоростью, чем скомпилированные элементы ActiveX Controls. Но с другой стороны, аплеты Java очень компактны, по­этому загружаются быстро. Для загрузки же программ ActiveX Controls тре­буется большее время. Следует также учесть, что загруженные программы ActiveX Controls остаются в клиентской системе, тогда как все аплеты Java необходимо каждый раз загружать заново. Эта особенность с точки зрения безопасности является недостатком, так как нарушается централизация при­кладной системы. Но с точки зрения производительности достигается пре­имущество перед Java-аплетами.

По независимости от аппаратных и операционных платформ ActiveX уступает Java-технологии. Несмотря на заявление компании Microsoft, что ActiveX обеспечивает открытую многоплатформенную поддержку операционных сис­тем Macintosh, Windows и UNIX, технологии ActiveX лучше работают на платформах Microsoft Windows, поскольку разработаны преимущественно для использования функций, встроенных в эти операционные системы. Соответ­ственно в полной мере ActiveX может использоваться в сетях, работающих под управлением операционных систем Microsoft Windows.

1.2.3. Доступ к реляционным базам данных. В архитектуре "клиент-сервер", основанной на Web-технологии, Web-сервер выступает в качестве информационного концентратора, который доставляет информацию из разных источников, а потом однородным образом с помощью Web-навигатора предоставляет ее пользователю. Непосредственная интеграция разнородной информации выполняется при визуализации и интерпретации Web-документов, которую реализует Web-навигатор при взаимодействии с Web-сервером, а также другими серверами по предоставлению информацион­ных ресурсов.

Взаимодействие Web-навигатора с сервером системы управления базами дан­ных (сервером СУБД) может осуществляться двумя основными способами:

- доступ к серверу СУБД через Web-сервер;

- доступ к серверу СУБД напрямую.

Доступ к серверу СУБД через Web-сервер

Для доступа Web-навигатора к серверу СУБД через Web-сервер использует­ся система программных шлюзов (см. рис. 1.9). Программный шлюз, полу­чив запрос от Web-сервера, выступает в качестве посредника между серве­ром Web и сервером СУБД. Программные шлюзы разрабатываются в соответствии с определенными стандартами, определяющими способы вы­зова Web-сервером прикладных программ или функций динамических библиотек, а также способы обмена информацией с этими программными объ­ектами. Одними из наиболее распространенных стандартов данного типа являются интерфейс CGI (Common Gateway Interface — общий интерфейс шлюзов), а также его усовершенствованная спецификация, названная как FastCGI (ускоренный CGI).

Рис. 1.16. Схема доступа к СУБД через CGI-программу

1.2.3.1. Интерфейс CGI. Для доступа Web-навигатора к серверу СУБД через Web-сервер по стандарту CGI необходима соответствующая CGI-программа, выполняющая роль про­граммного шлюза между Web-сервером и сервером СУБД (рис. 1.16).

CGI-приложения работают независимо от Web-сервера, а их запуск осуще­ствляется по вызову с Web-документа при его обработке Web-навигатором. CGI-программа взаимодействует с Web-сервером посредством двусторонне­го обмена переменными среды через стандартные каналы ввода/вывода дан­ного приложения.

Поскольку CGI-программы работают независимо от Web-сервера и имеют простой общий интерфейс, разработчики Web-документов имеют возмож­ность создавать свои CGI-программы на любом языке, поддерживающем стандартные файловые операции ввода/вывода. Кроме того, при независи­мой разработке можно создавать такие приложения, которые легко перено­сятся с одного на другой Web-сервер. Существуют и стандартные CGI-программы, специально разработанные для взаимодействия Web-серверов с различными СУБД, например, программа WebDBC.

В качестве интерфейса между Web-навигатором и сервером СУБД в составе Web-документов применяют HTML-формы, которые позволяют формулировать запросы к базе данных. CGI-программа получает информацию от Web-сервера либо через переменные окружения, либо через стандартный ввод. Все зависит от метода доступа, который используется при обмене данными между Web-навигатором и Web-сервером. Далее CGI-программа через драйвер ODBC (Open DataBase Connectivity) обращается к серверу СУБД и возвращает Web-серверу ответ на запрос через стандартный вывод.

Драйвер ODBC обеспечивает унифицированный способ доступа к различ­ным СУБД посредством стандартного языка запросов SQL. Благодаря стан­дарту ODBC прикладные программы могут использовать единственный диалект SQL и взаимодействовать с разными СУБД. Можно обойтись и без драйвера ODBC, но в этом случае CGI-программа должна быть написана с ориентацией на конкретную СУБД, функционирующую на сервере.

Таким образом, разработчику CGI-приложения не надо ничего знать о том, как устроен Web-сервер. Более того, ему вовсе не обязательно использовать сложные языки типа C++. CGI-программа может быть написана и на ко­мандном языке, например Peri. Главное выдержать все соглашения, накла­дываемые стандартом CGI. Такой подход существенно облегчает разработку прикладного программного обеспечения для Web вообще и для сопряжения баз данных с Web-сервером в частности.

Стандарт CGI обладает и недостатком — снижение скорости обработки за­просов при увеличении интенсивности их поступления. При каждом вызове CGI-программы ее приходится загружать с диска (т. е. запускать новый процесс). По завершении работы программы требуется освободить исполь­зовавшиеся ею ресурсы. Такие операции создают заметную дополнительную нагрузку на сервер, что сказывается на его производительности. К тому же запуск нового процесса при каждом запросе снижает эффективность посто­янных процессов и доступность данных. Информацию, которая сгенериро­вана в ходе обработки одного запроса, невозможно использовать при обра­ботке другого.

1.2.3.2. Интерфейсы API и FastCGI. Для того чтобы обойти проблемы, связанные с быстродействием CGI, мно­гие поставщики Web-серверов, включая Microsoft и Netscape, разработали соответствующие интерфейсы прикладного программирования (API). Кор­порацией Microsoft был разработан интерфейс ISAPI (Internet Server API), a корпорацией Netscape — интерфейс NSAPI (Netscape Server API).

Эти интерфейсы тесно интегрированы с Web-сервером, позволяя сохранять доступность постоянно используемых процессов и данных. Программы с интерфейсом ISAPI компилируются в файлы динамически подключаемых библиотек DLL. Они загружаются в память во время первого обращения к ним и поэтому для повторного вызова этих программ не нужно порождать новый процесс. Функции интерфейса NSAPI загружаются в серверное пространство процессов. Соответственно при вызове этих функций также не порождаются дополнительные процессы. Благодаря API-интерфейсу ис­пользующая его программа может оставлять соединение с СУБД открытым, так что следующему запросу к базе данных не придется тратить время на открытие и закрытие соединения.

Однако API-интерфейсы Web-серверов — хоть и неплохое, но нестандарт­ное решение. Большинство приложений нельзя переносить с одного API на другой, и очень редко удается переносить приложения на другие платфор­мы. Кроме того, большинство приложений для Web-серверов все еще соз­даются для интерфейса CGI, поэтому переход к приложениям на базе API не представляется экономически оправданным.

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

Таким образом, приложения на базе FastCGI, подобно CGI-программам, работают независимо от Web-сервера и запускаются через стандартные ссылки в Web-документах. Но, как и программы на базе API, программы для FastCGI являются постоянно действующими. Когда программа заканчи­вает обработку очередного запроса, ее процесс остается открытым в ожида­нии нового запроса.

При доступе Web-навигатора к реляционной базе данных через интерфейс FastCGI получается схема, в которой фактически используются три сервера:

Web-сервер, FastCGI-программа и сервер базы данных. Web-сервер прини­мает запрос Web-навигатора и передает его FastCGI-программе, которая в свою очередь обращается к серверу баз данных. Результат возвращается по обратной цепочке.

1.2.3.3. Доступ к серверу СУБД напрямую. Для доступа Web-навигатора к серверу СУБД напрямую могут использо­ваться как Java-аплеты (рис. 1.17) и программные компоненты ActiveX Con­trols (рис. 1.18), так и подключаемые к навигатору специализированные программные модули (plug-ins).

Для использования Java-аплетов по доступу к различным серверам СУБД раз­работан стандартный интерфейс JDBC (Java DataBase Connectivity) (рис. 1.17). Данный интерфейс ориентирован на обеспечение взаимодействия с сервером СУБД не только Java-аплетов, выполняющихся на клиентских станциях, но и Java-программ, запускаемых на сервере.

Рис. 1.17. Схема доступа к СУБД с помощью Java-аплета

Доступ Web-навигатора к серверу СУБД с помощью программных компонен­тов ActiveX Controls (рис. 1.18) предполагает, как и в случае Java-аплетов, за­прос и передачу соответствующей программы на рабочую станцию, а также ее дальнейшее выполнение на рабочей станции. В этом случае взаимодействие с сервером СУБД должно выполняться через интерфейс ODBC. Если учесть, что Java исполняется Web-навигатором в режиме интерпретации мобильного кода, то требования к аппаратуре рабочей станции по производительности и объему оперативной памяти существенно возрастают.

Рис. 1.18. Схема доступа к СУБД с помощью программного компонента ActiveX Controls

Использование для доступа Web-навигатора к серверу СУБД подключаемых к навигатору специализированных программных модулей (plug-ins) требует предварительной установки соответствующего программного дополнения на рабочей станции. После этого взаимодействие с сервером СУБД будет осу­ществлять установленное программное средство, получающее управление от Web-навигатора при обработке соответствующего вызова в Web-документе.

Для избежания несовместимости взаимодействие подключенных программ­ных модулей с сервером СУБД, как и в случае программных компонентов ActiveX Controls, должно выполняться через интерфейс ODBC.

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

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

- административная информация, включающая сведения о пользователях и сетевых ресурсах, которые не детализируют описания информацион­ных ресурсов на уровне отдельных файлов, например, файлов докумен­тов (Web-документов, обычных текстовых документов, документов Word, Excel и др.);

- детальные сведения об информационных ресурсах сети на уровне от­дельных файлов, отражающие их содержимое и адреса.

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

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

1.2.4.1. Задачи службы каталогов. Служба каталогов обеспечивает решение следующих важных задач:

- автоматический поиск сетевых ресурсов и зарегистрированных пользователей, а также прозрачный доступ к ресурсам сети;

- административный контроль и учет компьютерных ресурсов и пользова­телей;

- поддержка удобной системы именования сетевых ресурсов и пользова­телей;

- однократная регистрация пользователей и ресурсов сети.

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

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

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

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

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

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

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

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

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

В базе данных службы каталогов объектами являются порции информации, характеризующие ресурсы и пользователей сети. Объекты объединяются в поименованные каталоги по определенному признаку, например, по при­надлежности к подразделениям организации. Каждый каталог может содер­жать другие каталоги и объекты (рис. 1.20). Каталог, который не входит ни в какие другие каталоги, является корневым.

Рис. 1.19. Схема использования и организационная структура службы каталогов

Рис. 1.20. Древовидная структура корневого каталога базы данных службы каталогов

Таким образом, в древовидной структуре любого корневого каталога нелис­товыми вершинами (имеющими выходные дуги) являются каталоги, а лис­товыми (не имеющими выходных дуг) - объекты. Для отдельных операци­онных систем, например, для Windows NT, база данных службы каталогов может включать несколько корневых каталогов, объединенных определен­ными типами отношений. В этом случае полное дерево корневого каталога называют доменом.

Объект в каталоге базы данных представляет собой ее запись, соответст­вующую реальному объекту или субъекту сети, например, принтеру или пользователю. Каждый объект каталога содержит информацию в виде набо­ра свойств (атрибутов) и их значений. Например, сетевой принтер характе­ризуется в базе данных объектом Printer, для которого определены такие свойства, как имя, описание, местоположение и сетевой адрес. Одни и те же типы объектов обладают одинаковыми свойствами, в то время как у раз­ных типов объектов свойства могут отличаться. Для каждого типа объектов определяются обязательные свойства, без указания значений которых объ­ект данного типа не сможет быть создан. Например, обязательным свойст­вом объектов всех типов является имя.

Различают следующие типы объектов базы данных службы каталогов:

- объект рабочая станция, содержащий описание рабочей станции сети;

- объект сервер, описывающий сервер сети;

- объект тома, характеризующий логический том на дисковом носителе информации;

- объект принтер, содержащий описание принтера;

- объект очередь, описывающий очередь заданий на печать;

- объект пользователь, содержащий учетную запись пользователя (иденти­фикатор, фамилия и имя, пароль, полномочия, адрес электронной поч­ты, сценарий регистрации и др.);

- объект группа, описывающий группу пользователей;

- объект профиль, описывающий задаваемые для пользователей параметры конфигурации;

- объект схема каталога, характеризующий каталог;

- другие объекты, зависящие от конкретной службы каталогов.

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

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

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

Современные службы каталогов соответствуют стандартам Х.500 и LDAP (Lightweight Directory Access Protocol — облегченный протокол доступа к ка­талогам). Наиболее распространенным является стандарт LDAP, который представляет собой подмножество протокола Directory Access Protocol (DAP), используемого для построения каталогов Х.500. Однако DAP работает только в стеках протоколов модели OSI (Open System Interconnection) и требует серь­езных вычислительных мощностей. Протокол LDAP, как и DAP, предназна­чен для извлечения информации из иерархических каталогов, но в отличие от него, имеет ограничение по числу ответов на запрос к каталогу Х.500, что снижает загрузку сети. Преимуществом LDAP является также его программ­ный интерфейс, более дружественный и легкий для использования, чем ин­терфейс Х.500 или DAP. Кроме того, LDAP проще реализуется, чем выше­упомянутые протоколы, поскольку в нем используются для кодирования обычные текстовые строки без дополнительного форматирования.

В сетевых операционных системах Novell NetWare используется служба ката­логов Novell Directory Services (NDS). Microsoft Windows NT Server 4.0 вклю­чает службу каталогов Windows NT Directory Service (NTDS). Для пятой вер­сии данной операционной системы разработана новая служба каталогов Active Directory (AD). Службы каталогов NDS и AD соответствуют протоколу LDAP.

1.2.4.3. Управление детальными сведениями об информационных ресурсах. Для управления детальными сведениями об информационных ресурсах сети на уровне отдельных файлов используются специализированные информа­ционно-поисковые системы. Эти системы ориентированы на выполнение следующих функций:

- периодического сканирования файлов, хранящихся в узлах компьютер­ной сети с целью определения их содержимого;

- систематизации полученной при сканировании информации и занесе­ние ее в базу данных об информационных ресурсах сети;

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

Функцию поиска и выдачи необходимых сведений по запросам пользователей и профамм реализует специализированная СУБД на основе сведений об информационных ресурсах сети, хранящихся в базе данных информационно-поисковой системы (рис. 1.21 и 1.22). Результатом поиска является список ука­зателей на удовлетворяющие запросу файлы вместе с их описаниями.

Рис. 1.21. Схема использования и организационная структура информационно-поисковой системы, основанной на построении каталогов

Рис. 1.22. Схема использования и организационная структура информационно-поисковой системы, основанной на построении индексов

В зависимости от автоматизации способа накопления сведений в базе дан­ных об информационных ресурсах, а также ее структуры различают два типа информационно-поисковых систем:

- системы, основанные на построении каталогов, которые обеспечивают как поиск путем навигации по тематическим каталогам, так и поиск по ключевым словам;

- системы, основанные на построении индексов, которые обеспечивают только поиск по ключевым словам.

Существуют также комбинированные информационно-поисковые системы.

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

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

Наиболее популярной моделью поискового образа файла является вектор­ная модель, в которой каждому файлу приписывается список терминов, адекватно отражающих его описание. Если быть более точным, то файлу приписывается вектор размерности, равный числу терминов, которыми можно воспользоваться при поиске. При булевой векторной модели элемент вектора равен 1 или 0, в зависимости от наличия или отсутствия термина в поисковом образе. В более сложных моделях термины взвешиваются — элемент вектора равен не 1 или 0, а некоторому числу (весу), отражающему соответствие данного термина документу. Именно последняя модель стала наиболее популярной.

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