Принципы построения серверных программ

Содержание:

Введение

Развитие всемирной компьютерной сети Интернет в последние годы идет гигантскими темпами. В Сети появляются все новые и новые виды услуг - интернет-магазины, виртуальные биржевые площадки, аукционы, а такие приложения, как чаты, виртуальные доски объявлений, бесплатные сервисы электронной почты вообще стали чуть - ли не обязательными сервисами любого крупного интернет-портала.

Постоянное увеличение производительности автоматизированных рабочих мест обработки информации и рост возможностей современных программно-аппаратных средств информационного обмена заставляет по-новому взглянуть на проблему реализации современных информационных систем. Становится реальным совместное использование данных, хранящихся на нескольких ЭВМ одновременно. Указанная возможность обеспечивается ростом популярности глобальной сети Internet и технологии World-Wide-Web, к которым в последнее время проявляется повышенный интерес со стороны разработчиков информационных систем.

Тенденции заключаются в использовании Internet в качестве универсального транспорта при создании распределенных систем удаленного мониторинга, контроля и управления объектами различного назначения. Изначально WWW создавался только как средство, предоставляющее графический интерфейс в Internet и упрощающее доступ к информации, распределенной по миллионам компьютеров по всему миру. При этом основными компонентами являлись страницы, узлы, браузеры и серверы Web. Пользователям была предоставлена возможность навигации по Internet с использованием технологии гипертекста, поддерживаемой протоколом HTTP (Hypertext Transfer Protocol) и стандартом языка HTML (Hypertext Markup Language).

Появление CGI (Common Gateway Interface) решило проблему обмена информацией между сервером Web и такими программами, как базы данных, которые не могут непосредственно обмениваться данными с браузерами Web. В результате появилась возможность реализации интерактивного взаимодействия конечного пользователя с программами стороны Web сервера, которые обрабатывали информацию, введенную пользователем в браузере, и в качестве результата возвращали сформированную HTML-страницу. Многие из существующих решений доступа к базам данных в среде Internet основаны на данном подходе.

Средства протокола HTTP - одной из основ Web - позволяют организовывать передачу любых файлов, что в значительной мере снижает необходимость в использовании протокола передачи файлов FTP, а в ряде случаев позволяет заменить его. Кроме того, используя протокол HTTP и интерфейс CGI, с легкостью можно организовывать Web-форумы, сервис которых идентичен по своей сути сервису, предоставляемому протоколом NNTP (Network News Transfer Protocol). Те же технологии позволяют строить чаты, делая протокол IRC фактически ненужным.

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

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

Реализация поставленной цели предполагает необходимость решения следующих задач:

- проанализировать понятие и дать характеристику существующим Wed-технологиям;

- определить функциональные особенности Wed-технологий и сравнить их;

- рассмотреть принципы построения серверной части программного обеспечения;

- оценить применение дистанционных вызовов процедур для построения программ, функционирующих по принципу клиент/сервер.

Глава 1. Принципы построения и основные задачи, выполняемые серверными программами

Понятие и характеристика существующих Web-технологий

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

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

Формат запросов клиента и ответов сервера определяется протоколом. Спецификации открытых протоколов описываются открытыми стандартами, например протоколы Интернета определяются в документах RFC.

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

Значительные интернет-ресурсы могут быть созданы с применением технологии CGI. Платформенно-независимый интерфейс CGI (Common Gateway Interface – дословно – общий шлюзовой интерфейс) используется для исполнения программ совместно с Web-сервером. Такие программы называются CGI-приложениями [5], [6].

Допустим, набрав URL в строке адреса в браузере, посредством заполнения HTML-формы, или любым другим образом пользователь запрашивает следующий URL:

http://www.server.ru/some-path/cgi-script.ext

Иными словами, пользователь обращается к серверу www.server.ruпо протоколу HTTP, запрашивает из каталога/some-path/файлcgi-script.extи рассчитывает получить Web-документ, например, HTML-файл или файл другого формата, например, рисунок. Так и произойдет, если такой документ существует и находится в указанном каталоге Web-сервера. Отметим, что протокол HTTP не накладывает ограничений на тип запрашиваемого ресурса. Следовательно, файл cgi-script.ext может быть вовсе не изображением, не привычным HTML-документом, а программой – исполняемым файлом. В этом случае Web-сервер инициирует запуск этой программы на выполнение, а пользователю возвратит результат ее работы – все данные, выведенные программой через стандартный поток вывода STDOUT. В зависимости от решаемой задачи в CGI-программе может быть выбран любой из поддерживаемых протоколом HTTP форматов данных: текст, изображение, документ в HTML-формате с соответствующим форматированием, аудиофайл и прочее. Пользователь же не заметит никакой разницы, загрузил ли он существовавший документ с диска Web-сервера, или этот документ был создан для него CGI-программой «на лету».

CGI-программа может представлять собой любой исполняемый файл – будь то программа, написанная на языке С, Shell-скрипт или программа на Perl. Вообще приложениями CGI называются программы, которые, пользуясь этим интерфейсом, получают через протокол HTTP информацию от удаленного пользователя, обрабатывают ее, и возвращают результат обработки обратно в виде ссылки на уже существующий документ HTML или другой объект (например, графическое изображение) или в виде документа HTML, созданного динамически. Из-за того, что очень часто такие программы пишутся именно на языках-интерпретаторах (подобных Basic, Perl, PHP), их традиционно называют сценариями.

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

http://www.server.ru/some-path/cgi-script.ext?param1=value1&param2=value2...

Строка параметров отделяется от имени CGI-программы символом ?. Эта строка должна быть особым подготовлена – все символы с кодами больше 127 должны быть представлены комбинацией символов % и шестнадцатеричным представлением кода символа, например, символ с кодом 142 (русская буква «О») будет представлен как %8Е. Кроме того, все пробелы должны быть заменены символом+. Строка параметров передается программе через переменную окружения QUERY_STRING. Анализируя ее и выбирая из нее требуемые параметры, CGI-программа может выполнять определенные действия, и действовать соответствующим образом, например, по переданным в качестве параметров имени пользователя и паролю провести аутентификацию пользователя, в случае подтверждения подлинности пользователя предоставить ему определенный сервис, а в случае неуспешной аутентификации выдать предупреждающее сообщение.

Кроме перечисленного метода существуют еще два способа передачи параметров. Строка URL в некотором смысле подобна командной строке операционных систем. Как при запуске программ в ОС, CGI-программе можно передать параметры в командной строке. Тогда, например, при использовании для написания CGI-программы языка С или Perl, внутри программы такие параметры будут доступны через массив ARGV[]. Для передачи параметров таким образом строка параметров должна содержать список значений параметров, соединенных знаками +. Например, наш URL выглядел бы так:

http://www.server.ru/some-path/cgi-script.ext?value1+value2

В этом примере передача параметров осуществляется так же, как если бы мы запустили программу cgi-script.extв командной строке:

prompt> cgi-script.ext value1 value2

Третий способ осуществляется при использовании в HTTP-запросе метода POST. В этом случае строка параметров передается сценарию через стандартный поток ввода (STDIN). Однако, в этом случае так же сохраняется возможность передачи параметров через URL (соответственно, данные будут доступны в QUERY_STRING). Метод POST, как правило, используется при передаче на сервер данных из больших HTML-форм, или при передаче на сервер файлов.

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

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

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

PHP – язык, специально нацеленный на работу в сети Интернет, который позволяет встраивать программный код в HTML-документы. Синтаксис языка чрезвычайно ясный и читаемый, сочетает в себе все достоинства языков Perl и С.

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

Как правило, Web-документы, написанные на языке PHP, имеют расширение .php. Описание этого языка дано в [5]. Рассмотрим, как работает данная технология. PHP-«программа» представляет собой обычный HTML-файл, в который в требуемых местах встроен программный код, выполняющий заданные действия. Вставки кода оформляются парой тегов <?phpи?>, между которыми может находиться необходимое число операторов языка. При запросе такого документа пользователем Web-сервер вызывает специальный PHP-интерпретатор и передает ему этот документ. Интерпретатор просматривает его, пропуская все теги HTML и выполняя все операторы программной вставки. Сама программная вставка, ограниченная тегами<?phpи?>, удаляется из документа, а на ее место вставляется результат выполнения операторов этой вставки, в том случае, конечно, если в ней содержатся операторы вывода. При этом сам HTML-файл фактически выступает в роли статического шаблона, в котором изменяемые фрагменты реализуются программным кодом. Результат такой обработки отправляется пользователю. Пользователь же никогда не сможет узнать, какой конкретно фрагмент (и вообще имелись ли такие фрагменты) был сгенерирован динамически. Однако, если Web-сервер не имеет PHP-интерпретатора, но на нем была размещена страница с инструкциями на этом языке, то страница, вместе со всеми программными вставками будет передана пользователю. Так как вставки кода оформляются парой тегов<?phpи?>, они будут восприняты браузерами как комментарии, и отображены пользователю не будут. Хотя пользователь сможет увидеть их, запросив в браузере исходный код страницы.

Как следует из изложенного алгоритма, элементарная PHP-программа вообще может не содержать ни одной программной вставки. Тем не менее, такая «программа» будет вполне рабочей, и при ее интерпретации в интерпретаторе Web-сервера никакой ошибки не произойдет. Иными словами, PHP-сценарий вообще может не отличаться от HTML-документа.

Синтаксис языка PHP обширен и функционален. Язык не требует ни объявления переменных, ни указания их типов. Все преобразования типов выполняются интерпретатором автоматически. Язык поддерживает множество управляющих структур – выбор, циклы, ветвления, поддерживаются функции. В языке реализованы некоторые принципы объектно-ориентированного программирования. К достоинствам языка относится богатый набор «встроенных» функций самого широчайшего назначения: файловых, сетевых, математических, строковых, функций для доступа к базам данных и многих других. PHP «изначально» ориентирован на поддержку CGI – при обработке форм в обрабатывающем сценарии становятся автоматически доступны все переменные, которые соответствуют элементам форм, что в значительной мере упрощает работу Web-программиста.

Область применения данной технологии, как и у технологии CGI – очень широка. PHP позволяет динамически создавать HTML-документы, работать с базами данных, сетевыми протоколами. Средства языка подходят для обработки HTML-форм. По сравнению с другими языками сценариев, выполняемыми на стороне сервера, PHP наилучшим образом подходит для решения задач, не предъявляющих высоких требований к производительности: гостевые книги, доски объявлений, системы регистрации, чаты – все это создается на PHP значительно с меньшими трудовыми затратами, нежели на других языках, например, на Perl [7].

Технология ASP компании Microsoft является аналогом рассмотренных серверных технологий. Более всего ASP функционально походит на CGI. ASP-страница – это HTML-документ, содержащий сценарии, которые позволяют работать с управляющими элементами ActiveX, в том числе, и элементами для доступа к базам данных. Особенностью этой технологии является то, что в качестве языков сценариев для написания динамических вставок как правило используются JavaScript и VBScript, хотя допустимо использование и других языков. Сценарий управляет объектами, результаты работы которых представляются в формате Dynamic HTML.

Технологию ASP используют Web-сервера на базе Windows – Internet Information Server и Personal Web Server. Таким образом, ASP в некоторой мере может служить заменой CGI на Windows-платформах.

Функциональные особенности Web-технологий и их сравнение

Перед рассмотрением используемых в Web технологий определимся с терминологией. В данной работе под Web-документом мы будем понимать любой отдельный объект информации, который может быть адресован с помощью URL и который может запросить пользователь по протоколу HTTP. Это может быть изображение, текстовый документ, HTML- или DHTML-страница, может быть и программа, запрос которой пользователем приводит к формированию документа перечисленных или иных типов.

Проведем некоторую классификацию Web-документов. Все Web-документы можно разделить на две категории. Первая категория – это статические документы. При запросе их пользователем содержимое документа на сервере не изменяется, он в исходном виде передается пользователю. На стороне клиента этот документ так же не позволяет реализовать с пользователем никакого интерактивного взаимодействия. К таким документам можно отнести, например, Web-страницу, реализованную с применением языка HTML без использования форм и дополнительных средств. Вторая категория – интерактивные Web-документы. Эти документы могут изменять свое содержимое в зависимости от определенных условий и действий пользователя. Все интерактивные документы можно, в свою очередь, разделить по принципу, на основе которого производится изменение их содержимого. В первую подкатегорию можно отнести документы, содержимое которых формируется на стороне Web-сервера. В таком случае сервер выполняет определенные действия, в результате которых по заданным условиям на основе заранее заданных шаблонов по определенному алгоритму формируется HTML- или иной документ (например, изображение счетчика или график курса валюты). Отметим, что формирование таких документов может осуществляться как в момент запроса этого документа пользователем, так и выполняться периодически по определенной временной сетке. В первом случае после создания документ сразу возвращается пользователю и не сохраняется на сервере. Во втором случае созданные документы помещаются в определенный подкаталог сервера, откуда они могут быть запрошены пользователем как обычные статические HTML-файлы. В обоих случаях пользователь получает статичный документ, как если бы он был заранее подготовлен и находился на жестком диске сервера. Более того, пользователь никаким образом не сможет определить, что этот документ только что был сделан специально для него. На стороне клиента этот документ выглядит как обычный статический документ, и его отображение в браузере не изменяется.

Ко второй подкатегории можно отнести Web-документы, интерактивное взаимодействие в которых происходит на стороне клиента. Это, прежде всего, Web-страницы, реализованные с применением технологии DHTML (Dynamic HTML). Помимо «чистого» HTML эти страницы имеют вставки программного кода на языках JavaScript или VBScript, а оформление их может быть выполнено с применением каскадных таблиц стилей. На стороне сервера никакой обработки этих документов не производится – при запросе они без изменения передаются пользователю. Программные вставки интерпретируются на стороне клиента браузером, используемым для просмотра документа, после загрузки документа. Этот подход, безусловно, обладает множеством достоинств, и позволяет создавать интерактивные страницы, содержимое которых меняется в зависимости от действий пользователя без перезагрузки документа из сети. Все происходит на стороне клиента.

В третью подкатегорию можно включить документы, совмещающие в себе два вышеперечисленных подхода. Например, это могут быть документы, определенная часть текста которых формируется на сервере (например, с использованием технологии PHP), и содержащие заранее подготовленные вставки на JavaScript, с помощью которых на стороне клиента будет реализовано меню и проверка вводимых пользователем данных.

Место обработки динамической части Web-документа определяет некоторые функциональные возможности технологии. Так, из программного кода документов, исполнение которого производится на сервере, при наличии соответствующих полномочий возможно обращение к серверным базам данных, сетевым ресурсам, файлам сервера и прочей информации. Для интерпретируемых браузером клиента документов возможность доступа к серверным базам данных открывается при применении технологии ActiveX, которая, однако, нацелена на работу в среде Windows. Однако это вызывает повышенную нагрузку на сеть.

Технологии PHP, CGI и Parser, функционирующие на сервере, не позволяют выполнять с данными на стороне пользователя никаких действий. В том числе, невозможна и проверка введенных пользователем данных. Это означает, что, если при заполнении HTML-формы или при другом способе передачи параметров были введены неверные данные, эти данные будут переданы на сервер, и лишь там будет установлена их неправильность. Соответственно, в этом случае пользователю может быть выведено соответствующее сообщение об ошибке, а затем потребуется повторная передача данных. Это создает неоправданную нагрузку на сеть. Этого недостатка лишена технология DHTML: с использованием языков сценариев можно реализовать частичную проверку введенной информации на стороне клиента. Однако следует отметить, что применение технологии DHTML предусматривает передачу исходного текста всех используемых сценариев клиенту, в связи с чем и в этой технологии имеется значительная нагрузка на сеть. В свою очередь, технологии, работающие на сервере, этого недостатка лишены – пользователю передается подготовленный документ, в котором служебная информация отсутствует. В каком из приведенных примеров нагрузка на сеть значительнее – возможно оценить лишь рассматривая две одинаковые реализации Web-страниц с использованием обоих технологий.

Технология DHTML имеет один серьезный недостаток, о котором не упоминалось ранее. Дело в том, что все компоненты этой технологии, за исключением, пожалуй, только HTML, по разному интерпретируются не только разными браузерами, но даже разными версиями одного браузера. Язык VBScript поддерживается не всеми версиями браузеров. Возможности JavaScript так же различаются для разных версий браузеров, производимых разными поставщиками. Аналогичная картина и с объектными моделями документов и браузера. Все это заставляет программиста, по сути, писать в одном Web-документе несколько одинаковых по своим функциям сценариев, чтобы учесть особенности различных браузеров. Это сильно усложняет задачу Web-программиста и значительно увеличивает объем Web-документа.

К недостаткам технологии Parser, как упоминалось выше, могут быть отнесены сложность и «непрозрачность» исходного текста динамических вставок по сравнению с другими языками. Кроме того, это средство имеет ряд функциональных ограничений, упоминаемых в документации. Набор операторов и средств в этой технологии определяется версией интерпретатора инструкций Parser. Ранее было сказано, что данная технология может быть заменена технологией PHP. Учитывая это, в дальнейшем мы не будем касаться этой технологии, считая более целесообразным использование языка PHP.

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

Все перечисленные технологии относятся к технологиям создания интерактивных Web-документов. Технологии PHP, CGI, Parser и ASP относятся к выполняемым на сервере. PHP и Parser требуют для своего функционирования дополнительной программной надстройки к Web-серверу, которая будет интерпретировать и выполнять инструкции на соответствующем языке в теле документа. Выполнение CGI-сценариев возлагается на операционную систему. Только в случае, если сценарий написан на интерпретируемом языке, требует наличия в системе соответствующего интерпретатора. Если CGI-программа написана на компилируемом языке, то для ее работы не требуется никаких дополнительных средств. Технология ASP преимущественно ориентирована на Windows-платформы.

Обработка DHTML-документов производится на стороне клиента. Для этого браузер клиента должен иметь поддержку используемых в странице языков сценариев – JavaScript или VBScript.

Принципы построения серверной части программного обеспечения

Для структурирования информации и облегчения задач поиска в стандартах для Web в одних из первых в Интернет стал применяться гипертекст, по своей сути представляющий собой совокупность документов, связанных друг с другом ссылками. Такой способ организации информации делает процедуру перехода между отдельными документами какого-либо информационного массива наглядной, простой и понятной. В Web используется язык гипертекстовой разметки - Hypertext Markup Language, или HTML.

HTML - это упрощенная версия обобщенного языка SGML (Standard Generalized Markup Language), с помощью которого можно формально определить структуру документов. Язык HTML прост, но достаточно мощен для представления большинства документов, как общего назначения, так и специализированных, и представляет собой полнофункциональный язык разметки документа. Средства языка позволяют определить такие параметры оформления текстовой информации, как выделение различными шрифтами, различными размерами и начертаниями букв, выравнивание абзацев текста и отдельных текстовых фрагментов, центрирование, выделение заголовков, задание перечислений и списков, вставка гиперссылок, таблиц, рисунков и многое другое [1], [2].

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

Сервис World Wide Web (WWW, или Web) представляет собой набор протоколов и программ прикладного уровня, представляющих информацию в гипертекстовом виде и позволяющих осуществлять обмен этой информацией через сеть. Традиционно в качестве транспортного протокола для передачи информации в Интернет применяется протокол TCP/IP, хотя протоколы Web по сути не привязаны к какому-либо конкретному транспортному протоколу. Web имеет клиент-серверную архитектуру: роль сервера выполняет специальная программа - Web-сервер, выполняющаяся на компьютере-сервере. Эта программа имеет доступ к соответствующему информационному массиву (наполнению, контенту), хранящемуся на жестком диске Web-сервера, и отвечает на запросы клиентов, отправляя им запрошенную информацию. На стороне клиента используется программа-клиент, называемаябраузером, позволяющая выводить принятую информацию в соответствии с ее форматом, а так же правилами разметки и отображения ее на устройстве вывода клиентского компьютера. Данная схема взаимодействия осуществляется с помощью протокола передачи гипертекстаHTTP(Hyper Text Transfer Protocol) [3], являющегося текст-ориентированным протоколом, реализующим модель запрос/ответ. HTTP определяет форматы методов-запросов информации и форматы ответов сервера. Для взаимодействия клиента и сервера по протоколу HTTP на сервере традиционно используется 80-й порт TCP/IP.

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

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

Адресация сетевых ресурсов в Интернет осуществляется с помощью указателей URL(Uniform Resource Locator). Для Web большинство URL в общем виде имеет следующий формат:

>,

где <хост>- доменное имя или IP-адрес компьютера-сервера,<порт>- IP-порт для соединения (если пропущено - используется порт по умолчанию - 80),<путь>- указывает расположение ресурса в структуре Web-сервера (часто совпадает с подкаталогом и именем файла в файловой системе сервера),<параметры>- используется для передачи параметров исполняемым сценариям (может отсутствовать).

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

Для передачи информации от пользователя к серверу язык HTML позволяет строить так называемые формы. Формы могут состоять из целого ряда интерфейсных управляемых элементов - списков выбора, из которых пользователь может выбрать одно или несколько значений, текстовых полей для ввода многострочных фрагментов текста, переключателей, предназначенных для выбора одного или нескольких вариантов из набора имеющихся, полей для ввода строк текста и других элементов. Каждый такой элемент имеет имя. Обязательным элементом формы является параметрaction, указывающий на Web-документ (обычно - CGI- или PHP-сценарий), вызываемый по окончании работы с формой - по завершении ввода данных или редактирования значений, а так же кнопка, при нажатии на которую на Web-сервере вызывается этот сценарий. В качестве параметров этому сценарию передаются парыимя_элемента=значение, формируемые для каждого интерфейсного элемента формы [4]. После обработки полученных данных сценарий выполняет заданные действия, а результат его работы передается пользователю.

Таким образом, передача пользовательской информации на Web-сервер с помощью HTML-формы производится как минимум в два этапа – на первом этапе выполняется заполнение формы, представляющей собой отдельный Web-документ, на втором этапе – выполняется передача информации на сервер сценарию, который будет обрабатывать ее.

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

Таким образом, при применении Web-сервера на базе ОС Unix для реализации интерактивных Web-документов на стороне сервера предпочтительным является использование языка PHP. В случае повышенных требований к быстродействию при обработке больших объемов информации рекомендуется использование интерфейса CGI со сценариями, написанными на компилируемых языках. На серверах на базе Windows предпочтительно применение технологии ASP. Для проверки больших объемов информации перед передачей их на сервер или для реализации обработки информации на стороне пользователя рекомендуется использовать компоненты DHTML.

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

Глава 2. Применение дистанционных вызовов процедур для построения программ, функционирующих по принципу клиент/сервер

Фирма Sun Microsystems построила NFS на базе концепции RPC (Remote Procedure Calls Дистанционный вызов процедур), которая позволяет программному обеспечению на разных машинах связываться между собой. Эта концепция состоит в том, что отдельные модули программного обеспечения, выполняющие разные функции, располагаются на компьютерах различных типов. Система NFS использует RPC для перенаправления файлов в компьютерной сети.

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

Что же программист должен делать, чтобы использовать RPC? Для этого он программирует отдельные модули, обычно на языке программирования С. каждый модуль предназначен для выполнения функции клиента или сервера. Модули сервера, как правило, являются программами заднего плана (вычисления, создание отчетов ил хранение временных записей базы данных), а модули клиента выполняются функции переднего плана (интерфейс пользователя). Затем составляется сценарий для RPC компилятора, где указываются модули-клиенты и модули-серверы. RPC компилятор генерирует Си-программу для склеивания отдельных модулей в единую систему, в рамках которой осуществляются сеансы связи между клиентами и серверами, расположенными на различных компьютерах. При этом, с точки зрения программистов, вызов модулей сервера осуществляется точно так же, как и любых других программ в программе клиента. то, что модули клиента и сервера находятся на различных компьютерах, остается совершенно невидимым для прикладной программы.

Компьютеры, составляющие сеть NFS, могут быть самых различных моделей и использовать совершенно различные способы внутреннего представления данных. Для учета этих различий в NFS применяется протокол XDR (External Data Representation Внешнее представление данных). С помощью этого протокола информация в пакетах сообщений преобразовывается в машинонезависимый формат.

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

Независимость от предыстории NFS позволяет избежать сложных процедур восстановления при сбоях в обмене данными между элементами клиента и сервера. В таких ситуациях клиент просто продолжает отправлять заново запросы к серверу до тех пор, пока не получит нужные ему данные. Фактически, клиент не видит разницы между медленным сервером и сервером, в котором произошел сбой. Аналогично, после перезапуска сервер продолжает, как ни в чем не бывало, отвечать на запросы клиентов без необходимости перезапуска каждого из клиентов. В NFS используется описанный выше протокол UDP (User Datagram Protocol Протокол пользовательских дата-грамм) для передачи/приема требований обслуживания файлов.

Идея вызова удаленных процедур состоит в расширении хорошо известного и понятного механизма передачи управления и данных внутри программы, выпол­няющейся на одной машине, на передачу управления и данных через сеть. Сред­ства удаленного вызова процедур предназначены для облегчения организации распределенных вычислений. Впервые механизм RPC реализовала компания Sun Microsystems, и он хорошо соответствует девизу «Сеть — это компьютер», взято­му этой компанией на вооружение, так как приближает сетевое программирование к локальному. Наибольшая эффективность RPC достигается в тех приложениях, в которых существует интерактивная связь между удаленными компонентами с небольшим временем ответов и относительно малым количеством передаваемыхданных. Такие приложения называются RFC-ориентированными.

Характерными чертами вызова локальных процедур являются:

- асимметричность — одна из взаимодействующих сторон является инициато­ром взаимодействия;

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

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

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

- при аварии вызывающей процедуры, удаленно вызванные процедуры стано­вятся «осиротевшими»;

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

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

Рассмотрим, каким образом технология RPC, лежащая в основе многих распре­деленных операционных систем, решает эти проблемы.

Чтобы понять работу RPC, рассмотрим сначала выполнение вызова локальной процедуры в автономном компьютере. Пусть это, например, будет процедура за­писи данных в файл:

m = my_write(fd, but, length)

Здесь fd — дескриптор файла, целое число, buf — указатель на массив символов, length— длина массива, целое число.

Чтобы осуществить вызов, вызывающая процедура помещает указанные пара­метры в стек в обратном порядке и передает управление вызываемой процедуреmy_write. Эта пользовательская процедура после некоторых манипуляций с дан­ными символьного массива buf выполняет системный вызов write для записи дан­ных в файл, передавая ему параметры тем же способом, то есть, помещая их в стек (при реализации системного вызова они копируются в стек системы, а при возврате из него результат помещается в пользовательский стек). После того как процедура my_write выполнена, она помещает возвращаемое значение m в регистр, перемещает адрес возврата и возвращает управление вызывающей процедуре, кото­рая выбирает параметры из стека, возвращая его в исходное состояние. Заметим, что в языке C параметры могут вызываться по ссылке (by name), представляю­щей собой адрес глобальной области памяти, в которой хранится параметр, или по значению (byvalue), в этом случае параметр копируется из исходной области памяти в локальную память процедуры, располагаемую обычно в стековом сег­менте. В первом случае вызываемая процедура работает с оригинальными значе­ниями параметров и их изменения сразу же видны вызывающей процедуре. Во втором случае вызываемая процедура работает с копиями значений параметров, и их изменения никак не влияют на значение оригиналов этих переменных в вы­зывающей процедуре. Эти обстоятельства весьма существенны для RPC.

Решение о том, какой механизм передачи параметров использовать, принима­ется разработчиками языка. Иногда это зависит от типа передаваемых данных. В языке C, например, целые и другие скалярные данные всегда передаются по значению, а массивы — по ссылке.

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

Механизм RPC достигает прозрачности следующим образом. Когда вызываемая процедура действительно является удаленной, в библиотеку процедур вместо локальной реализации оригинального кода процедуры помещается другая вер­ сия процедуры, называемая клиентским стабом (stub — заглушка). На удаленный компьютер, который выполняет роль сервера процедур, помещается оригиналь­ный код вызываемой процедуры, а также еще один стаб, называемый серверным стабом. Назначение клиентского и серверного стабов – организовать передачу параметров вызываемой процедуры и возврат значения процедуры через сети, при этом код оригинальной процедуры, помещенной на сервер, должен быть полностью сохранен. Стабы используют для передачи данных через сеть средства подсистемы обмена сообщениями, то есть существующие в ОС примитивы send иreceive. Иногда в подсистеме обмена сообщениями выделяется программный модуль, организующий связь стабов с примитивами передачи сообщений, называемый модулем RPCRuntime.

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

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

Клиент узнает место расположения сервера, кото­рому необходимо послать сообщение-вызов. Процедура, устанавливающая соот­ветствие между клиентом и сервером RPC, носит название связывание (binding). Методы связывания, применяемые в различных реализациях RPC, отличаются:

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

- способом обнаружения сетевого адреса (места расположения) требуемого сер­вера процессом связывания;

- стадией, на которой происходит связывание.

Метод связывания тесно связан с принятым методом именования сервера. В наи­более простом случае имя или адрес сервера RPC задается в явной форме, в ка­честве аргумента клиентского стаба или программы-сервера, реализующей ин­терфейс определенного типа. Например, можно использовать в качестве такого аргумента IP-адрес компьютера, на котором работает некоторый RPC-сервер, и номер TCP/UDP порта, через который он принимает сообщения-вызовы своих процедур. Основной недостаток такого подхода — отсутствие гибкости и про­зрачности. При перемещении сервера или при существовании нескольких серве­ров клиентская программа не может автоматически выбрать новый сервер или тот сервер, который в данный момент наименее загружен. Тем не менее, во мно­гих случаях такой способ вполне приемлем, и ввиду своей простоты часто ис­пользуется на практике. Необходимый сервер часто выбирает пользователь, на­пример, путем просмотра списка или графического представления имеющихся в сети разделяемых файловых систем (набор этих файловых систем может быть собран операционной системой клиентского компьютера за счет прослушивания широковещательных объявлений, которые периодически делают серверы). Кро­ме того, пользователь может задать имя требуемого сервера на основании зара­нее известной ему информации об адресе или имени сервера.

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

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

- типа интерфейса;

- экземпляра интерфейса.

Тип интерфейса определяет все характеристики интерфейса, кроме его место­расположения. Это те же характеристики, который имеются в описании для IDL-компилятора, например файловая служба определенной версии, включающая процедуры open, close, read, write, и т. п. Часть, описывающая экземпляр интер­фейса, должна точно задавать сетевой адрес сервера, который поддерживает дан­ный интерфейс. Если клиенту безразлично, какой сервер его будет обслуживать, то вторая часть имени-интерфейса опускается.

Динамическое связывание иногда называют импортом/экспортом интерфейса: клиент импортирует интерфейс, а сервер его экспортирует.

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

- с использованием широковещания;

- с использованием централизованного агента связывания.

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

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

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

Агент связывания может работать в составе общей централизованной справоч­ной службы сети, такой как NDS, X.500 или LDAP (справочные службы более подробно рассматриваются в следующей главе).

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

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

Необходимо отметить, что и в тех случаях, когда используется статическое свя­зывание, такая часть адреса, как порт сервера интерфейса (то есть идентифи­катор процесса, обслуживающего данный интерфейс), определяется клиентом динамически. Эту процедуру поддерживает специальный модуль RPC Runtime, называемый в ОСUNIX модулем отображения портов (portmapper), а в ОС се­мейства Windows - локатором RFC (RPC Locator). Этот модуль работает на каждом сетевом узле, поддерживающем механизм RPC, и доступен по хорошо известному порту TCP/UDP. Каждый сервер RPC, обслуживающий определен­ный интерфейс, при старте обращается к такому модулю с запросом о выделении ему для работы номера порта из динамически распределяемой области, есть с номером, большим 1023). Модуль отображения портов выделяет серверу некото­рый свободный номер порта и запоминает это отображение в своей таблице, свя­зывая порт с типом интерфейса, поддерживаемым сервером. Клиент RPC, выяс­нив каким-либо образом сетевой адрес узла, на котором имеется сервер RPC с нужным интерфейсом, предварительно соединяется с модулем отображения портов по хорошо известному порту и запрашивает номер порта искомого серве­ра. Получив ответ, клиент использует данный номер для отправки сообщений-вызовов удаленных процедур. Механизм очень похож на механизм, лежащий в основе работы агента связывания, но только область его действия ограничивает­ся портом одного компьютера.

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

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

Существует немало средств для построения надежной системы. Дисковые массивы RAID, например, позволяют не прерывать обработку запросов к информации, хранящейся на дисках, при выходе из строя одного или нескольких элементов массива. Резервные блоки питания в ряде случаев позволят в какой-то степени застраховаться на случай отказа других компонентов. Источники бесперебойного питания поддержат работоспособность системы в случае сбоев в сети энергоснабжения. Многопроцессорные системные платы обеспечат функционирование сервера в случае отказа одного процессора. Однако ни один из этих вариантов не спасет, если из строя выйдет вся вычислительная система целиком. Вот тут на помощь приходит кластеризация. Пожалуй, первым шагом к созданию кластеров можно считать широко распространенные в пору расцвета мини-компьютеров системы "горячего" резерва. Одна или две такие системы, входящие в сеть из нескольких серверов, не выполняют никакой полезной работы, но готовы начать функционировать, как только выйдет из строя какая-либо из основных систем. Таким образом, серверы дублируют друг друга на случай отказа или поломки одного из них. Но при объединении компьютеров желательно, чтобы они не просто дублировали друг друга, но и выполняли другую полезную работу, распределяя нагрузку между собой. Для этого во многих случаях как нельзя лучше подходят кластеры.

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

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

Термин «кластер» имеет множество определений. Одни во главу угла ставят отказоустойчивость, другие - масштабируемость, третьи - управляемость. Классическое определение кластера звучит примерно так: «кластер - параллельная или распределенная система, состоящая из нескольких связанных между собой компьютеров и при этом используемая как единый, унифицированный компьютерный ресурс». Таким образом, кластер представляет собой объединение нескольких компьютеров, которые на определенном уровне абстракции управляются и используются как единое целое. На каждом узле кластера (по сути, узел в данном случае - компьютер, входящий в состав кластера) находится своя собственная копия ОС. Впрочем, узлом кластера может быть как однопроцессорный, так и многопроцессорный компьютер, причем в пределах одного кластера компьютеры могут иметь различную конфигурацию (разное количество процессоров, разные объемы ОЗУ и дисков). Узлы кластера соединяются между собой либо с помощью обычных сетевых соединений (Ethernet, FDDI, Fibre Channel), либо посредством нестандартных специальных технологий. Такие внутрикластерные, или межузловые соединения позволяют узлам взаимодействовать между собой независимо от внешней сетевой среды. По внутрикластерным каналам узлы не только обмениваются информацией, но и контролируют работоспособность друг друга.

Заключение

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

Компьютеры пользователей системы объединены в сеть, при этом на каждом из них (на клиентском месте) запущены копии одной и той же программы (СУБД), которые обращаются за данными к серверу – специальному компьютеру, который хранит файлы, одновременно доступные всем пользователям (как правило это БД).

Сервер – обладает повышенной надежностью, высоким быстродействием, большим объемом памяти, на нем установлена специальная версия ОС.

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

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

Клиентский уровень занимает браузер, на уровне сервера находится сервер БД, а на промежуточном уровне располагаются Web-сервер и программа расширения сервера. Такое архитектурное решение позволяет уменьшить сетевой трафик, делает компоненты взаимозаменяемыми и повышает уровень безопасности. Однако такая архитектура также затрудняет обработку транзакций БД ввиду природы протокола HTTP, не запоминающего состояния (этот протокол использует для передачи данных между браузером и сервером БД). Браузер посылает Web-серверу запросы на доставку Web-страниц или данных. Web-сервер обслуживает заявки на Web-страницы, а запросы отправляет программе-расширению серверной части. Последняя принимает передаваемые ей запросы, преобразует их в форму, понятную серверу БД, и передает их серверу БД. Затем сервер БД выполняет работу по обслуживанию запроса и возвращает результат программе-расширению серверной части. Наконец та преобразует результаты в формат, приемлемый для браузера, и передает их Web-серверу, а тот в свою очередь – браузеру.

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

Список использованной литературы

1. Агальцов В.П. Базы данных. Распределенные и удаленные базы данных. Том 2-ой. – М.: Инфра-М, 2015. - 272 с.;
2. Ахтырченко К.В. Распределенные объектные технологии в информационных системах / К.В. Ахтырченко, В.В. Леонтьев. – М.: Мир, 2013. – 560 с.;
3. Карпова Т.С. Базы данных: модели, разработка, реализация [Электронный ресурс]. – Режим доступа:

http://www.intuit.ru/department/database/dbmdi/10/;

1. Петров В.Н. Информационные системы: Учеб. пособие для вузов / В.Н. Петров. – СПб: ПИТЕР, 2013. – 688 с.
2. Свистунов А.И. Построение распределенных систем на Java. – М.: Интернет-Универ, 2015. – 279 с.;
3. Распределенные системы. Принципы и парадигмы/ Э. Таненбаум, М. ван Стеен. — СПб.: Питер, 2003. - 877 с.;
4. Разработка Web-приложений на РНР и MySQL: Пер. с англ. / Лаура Томсон, Люк Веллинг. - 2-е изд., испр. – СПб: ООО «ДиаСофтЮП», 2003. – 672 с.
5. Телков А.Ю. Распределенные системы обработки информации. Учебно-методическое пособие для вузов. – Воронеж: Воронежский государственный университет, 2007. – 26 с.;
6. Хомоненко А. Д., Базы данных / Под ред. проф. Хомоненко А.Д. – 6-е изд. – М: БИНОМ-Пресс; Спб., КОРОНА, 2013. – 736 с.;
7. Храпский С.Ф. Распределенная обработка информации : учебное пособие / С. Ф. Храпский ; Федеральное агентство по образованию, Омский гос. ин-т сервиса, Каф. высш. математики и информатики. - Омск : Омский гос. ин-т сервиса, 2006. - 108 с.