Сетевые взаимодействия вашего узла Web

Технический обзор

CGI в новом качестве способен придать новый импульс содержимому вашего узла

Как только ваш корпоративный сервер World Wide Web заработал и исправно “жужжит”, самое время подумать, не вдохнуть ли некоторую интерактивную жизнь в степенное поведение его HTML-документов.

CGI, или Common Gateway Interface (общий интерфейс шлюза), может вам помочь именно в этом. Разработанный несколько лет назад в CERN (European Center for Nuclear Research  -  Европейский центр по ядерным исследованиям) как стандартный интерфейс между программами просмотра Web и серверами Web, CGI использует стандартные или частные обращения к интерфейсу API, которые из “горячих” ссылок HTML-кода на ваших базовых страницах передаются серверу Web, чтобы тот предоставил, скажем, настроенные страницы Web, содержащие именно ту информацию, которую запросил Web-путешественник. Интерфейс CGI может одновременно выполнять учетную программу, фиксирующую сведения о том, кто останавливается на вашем узле, оформлять заказы на информацию о продуктах и наводить справки о продажах.

Для выполнения любой функции CGI-код вызывает внешние программы, выполняемые на сервере Web или других серверах  -  там, где содержатся данные, которые запросил посетитель. Программы выполняются и возвращают документы HTML в виде страниц Web.

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

Как все это работает

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

В ответ на запрос данных, указанных в строке URL, возвращаемой из программы просмотра серверу (или шлюзу  -  в понимании CGI), на этом сервере запускается рабочая программа. Она запоминает или получает требуемые данные и затем  -  вот где элемент гениальности!  -  создает в качестве результата HTML-документ. Он возвращается обратно к программе просмотра, которая и отображает данные в виде уже другой страницы Web.

Для вызова интерфейса CGI программа просмотра создает строку CGI либо из данных, введенных в форму-страницу Web, либо из гипертекстовой ссылки, на которой щелкнул пользователь.

Строка CGI, являющаяся просто теговой строкой текста, прикрепляется к URL и пересылается обратно на сервер. Затем содержимое строки CGI интерпретируется как аргументы для сервера, который запускает в соответствии с ними нужную программу и создает при этом другой документ HTML, показываемый браузером как страница Web.

Поскольку интерфейс CGI  -  стандарт CERN, практически все серверы Web его понимают. Он работает поразительно хорошо, за исключением одного момента: программирование для CGI может оказаться довольно сложным и трудоемким. Более того, в сложности стандарта может таиться угроза для безопасности сервера, которому доверено выполнение рабочих программ.

Использование CGI означает, что вы разрешаете пользователю программы просмотра Web предоставлять аргументы (включая и те, о которых вы могли и не подумать) программе, выполняемой на Web-узле. Остается только уповать на то, что программа для “плохих” или потенциально “злонамеренных” аргументов не будет выполняться.

Простейший способ обеспечения защиты состоит в том, чтобы поместить вызываемые из CGI-интерфейса программы в специальный каталог (обычно это /cgi-bin), доступ к которому разрешается только Web-мастеру. Это превентивная мера для того, чтобы хакеры не могли поместить свои собственные программы CGI на сервер Web.

“Заточение” сценариев и программ CGI в каталоге /cgi-bin также помогает Web-мастеру поддерживать список программ CGI, которые могут вызываться браузерами Web. Если несколько человек разрабатывают CGI-программы для одного и того же узла Web, желательно, чтобы Web-мастер знал, что все эти программы находятся в одном месте, а не раскиданы по всему дереву каталогов узла.

Чьи API?

Для того чтобы жизнь у Web-мастеров была проще, во многих Web-серверных программах предлагается использовать частные, более простые, но являющиеся собственностью конкретного разработчика интерфейсы API. “Подвох” заключается в том, что приложения, построенные с использованием частных интерфейсов API  -  или, коли на то пошло, даже CGI,  -  не обязательно будут переносимыми на другие серверные платформы Web.

Например, в сервере IIS (Internet Infornation Server) корпорации Microsoft, который работает совместно с Windows NT Server, используется либо CGI, либо интерфейс ISAPI (Internet Server API), разработанный Microsoft. Если вы построите вызовы в ваших приложениях на основе ISAPI, а позднее решите перенести эти приложения в среду Unix, где используется совершенно другое серверное ПО  -  скажем, Commerce Server корпорации Netscape Communications,  -  то другой сервер может не понять всего того, что запрограммировано на ISAPI.

Кроме того, функции CGI различаются для разных серверных платформ, так что даже CGI не является полностью переносимым интерфейсом. CGI  -  это интерфейс между клиентом Web и сервером Web, а не язык программирования. Но, поскольку многие программисты упоминают о “программах CGI”, подразумевая под ними программы, выполняемые на Web-сервере, CGI иногда рассматривается как язык программирования, так как цель его заключается все-таки в выполнении программ.

Однако некоторая переносимость возможна  -  для тех интерфейсов API, которые обладают межплатформными возможностями. Например, в продукте WebSite Pro фирмы O’Relly & Associates имеется WSAPI (т. е. WebSite API), собственный интерфейс API, который совместим с ISAPI корпорации Microsoft.

Суть дела заключается в том, что, выбирая программное обеспечение для Web-сервера, необходимо позаботиться об API, с которыми вы сами себя связываете, и заранее определить, какова будет (или должна быть) степень переносимости ваших Web-приложений. Знаете вы это или нет, но возможно, что к этому моменту вы уже строите некоторые из приложений с “труднопереносимым” наследием.

Пусть вас не сбивает с толку популярная концепция, заключающаяся в том, что фирменные функции API Web-сервера, типа ISAPI, являются еще одним проявлением синдрома Империи зла. Найдутся те, кто станет убеждать, будто функции API представляют собой способ “заключить” незадачливых Web-мастеров в рамки продуктов отдельных фирм-производителей, но ведь эти API служат полезной цели, особенно когда речь идет о противопоставлении подходу CGI.

Вызываем все CGI

Для разработки серверных приложений баз данных CGI не является единственной “рыбкой в море-океане”. Некоторые из частных API, созданных фирмами-разработчиками ПО для Web-сервера, прекрасно работают. Они предоставляют дополнительные возможности, улучшают защиту и управление задачами.

Программа CGI может быть “реальной” откомпилированной программой, написанной на какой-либо версии языка Си, такой как Си++ или AppleScript, на командном языке Unix, на Visual Basic или на Perl  -  главном любимчике программистов Web. Она может быть и простым файлом на языке сценариев или макрокоманд. Некоторые Web-серверные интерфейсы CGI способны выполнять даже пакетные файлы DOS.

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

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

Несмотря на привлекательность концепции универсальности CGI (“все в одном”), есть и оборотная сторона медали. Каждая клиентская программа, которая возвращает аргументы CGI, вложенные в URL, порождает новый CGI-процесс, открывающий новый канал расхода ресурсов процессора. Чем больше пользователей с клиентской стороны заполняют упомянутые формы и нажимают на клавишу “Submit” (представить), тем сильнее возрастает нагрузка на Web-сервер при их обработке.

Как и любому шлюзовому процессу, CGI, в качестве “компенсации” за его универсальность, присущи значительные издержки. То, что CGI уменьшает производительность, может сделать его непригодным для Web-узлов с высоким трафиком, для которых динамическое создание их внутреннего наполнения есть жизненная необходимость, а не изредка требуемая роскошь.

API не только подражают CGI

Несмотря на то, что сервер IIS корпорации Microsoft обеспечивает интерфейс CGI, он также предлагает ISAPI. Вообще говоря, интерфейс API более эффективен по сравнению с CGI. Функции API при вызове, в отличие от CGI, не порождают нового серверного процесса. Плюс к этому API могут иметь прямой доступ к специальным программам, работающим на сервере. Таким образом, функции API более компактны, работают быстрее и менее склонны “съедать” ресурсы процессора.

Программы, в которых используются вызовы функций ISAPI, верные своему происхождению из Windows, компилируются в файлы динамически подключаемых библиотек DLL. Они загружаются в память во время первого обращения к ним, поэтому для их повторного выполнения не нужно порождать процесс. Интерфейс ISAPI поддерживает также фильтры (filters), с помощью которых можно отслеживать определенный уровень трафика и регистрировать запросы аутентификации или попытки установить соединение с защищенным портом.

Интерфейс WSAPI фирмы O’Relly & Associates лучше ISAPI: он полностью совместим с ISAPI, так что программы с интерфейсом ISAPI, разработанные для сервера IIS корпорации Microsoft, будут работать и на сервере WebSite.

Подобно другим API-интерфейсам, функции интерфейса NSAPI корпорации Netscape (Netscape Server API) загружаются в серверное пространство процессов. Это означает, что при их вызове не порождаются дополнительные серверные процессы. Полностью интегрированный с серверами Web корпорации Netscape, интерфейс NSAPI предоставляет функции, которых не имеет CGI, такие, как обработка ошибок и аутентификация.

Одним из наиболее широко используемых инструментов разработки приложений стал язык Visual Basic корпорации Microsoft. Еще для одного API-интерфейса  -  WinCGI  -  было заявлено, что он объединяет преимущества фирменных API корпорации Microsoft и существующей “базы программ” на Visual Basic. Интерфейс WinCGI содержит в себе идею взять достоинства всех этих программ, разработанных на языке Visual Basic, встроить их в узлы Web и вызывать из строк CGI, передаваемых через локаторы URL.

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

Недостаток WinCGI заключается в том, что для работы он должен вызывать интерпретатор языка Visual Basic. Тем не менее снижение производительности  -  не самое главное, а принимая во внимание муки и страдания, от которых Visual Basic вас избавляет, он стоит вложенных в него средств.

Java вновь ввязывается в драку

Для обращения к данным в CGI и Java применяются совершенно противоположные подходы, но, учитывая глубокий интерес к Java, заслуживает рассмотрения и интерфейс JDBC API (открытый интерфейс связи Java и СУБД) фирмы SunSoft.

JDBC API служит стандартным интерфейсом между апплетами Java и набором основных реляционных СУБД, в частности, со встроенным языком SQL. Модель Java основана на том, что апплеты Java загружаются на клиентскую станцию с сервера, а выполняются на клиенте (при помощи браузера Web, который “знает” Java).

JDBC можно применить несколькими способами, один из них  -  традиционный режим, когда сервер вызывает Java-апплет. Возможен и другой подход. Например, вместо того чтобы к СУБД обращался сервер, это делает апплет, выполняющийся на клиентской стороне, с аргументами, представленными CGI-строкой клиента.

Преимущество такого JDBC-подхода состоит в том, что он перемещает бремя выполнения программы на клиент (который, по-видимому, и должен “съедать” процессорное время), а не на сервер Web.

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

Куда же дальше?

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

Они добавят свои собственные фирменные расширения API (кое-кто для защиты интересов рынка), но, по всей вероятности, мы увидим гораздо больший наплыв межплатформных решений, когда функции API, разработанные для сервера Web одним производителем, смогут работать и на серверных Web-платформах других.

В то же время многое говорит в пользу того, чтобы рекомендовать подход с интерфейсом WinCGI: например, когда происходит вызов уже установленных приложений Visual Basic. Вероятно, Visual Basic  -  наиболее широко используемый генератор приложений со времен широкого применения языка Basic.

Подход WinCGI мог бы помочь, если бы интерфейс WinCGI работал быстрее, но Web-мастерам нравится идея быстрой и простой разработки приложений, а комбинация двойного выигрыша при переходе “CGI в Visual Basic”  -  самая мощная комбинация.

Уильям Датчер

Уильям Датчер (шт. Вашингтон) ведет семинары по сетевым технологиям и взаимодействиям в Internet. С ним можно связаться по адресу: dutcherb@nic.ddn.mil.