В предыдущей главе нами были рассмотрены сильносвязанные многопроцессорные системы с общей памятью, общими структурами данных ядра и общим пулом, из которого процессы вызываются на выполнение. Часто, однако, бывает желательно в целях обеспечения совместного использования ресурсов распределять процессоры таким образом, чтобы они были автономны от операционной среды и условий эксплуатации. Пусть, например, пользователю персональной ЭВМ нужно обратиться к файлам, находящимся на более крупной машине, но сохранить при этом контроль над персональной ЭВМ. Несмотря на то, что отдельные программы, такие как uucp, поддерживают передачу файлов по сети и другие сетевые функции, их использование не будет скрыто от пользователя, поскольку пользователь знает о том, что он работает в сети. Кроме того, надо заметить, что программы, подобные текстовым редакторам, с удаленными файлами, как с обычными, не работают. Пользователи должны располагать стандартным набором функций системы UNIX и, за исключением возможной потери в быстродействии, не должны ощущать пересечения машинных границ. Так, например, работа системных функций open и read с файлами на удаленных машинах не должна отличаться от их работы с файлами, принадлежащими локальным системам.
Архитектура распределенной системы представлена на Рисунке 13.1. Каждый компьютер, показанный на рисунке, является автономным модулем, состоящим из ЦП, памяти и периферийных устройств. Соответствие модели не нарушается даже несмотря на то, что компьютер не располагает локальной файловой системой: он должен иметь периферийные устройства для связи с другими машинами, а все принадлежащие ему файлы могут располагаться и на ином компьютере. Физическая память, доступная каждой машине, не зависит от процессов, выполняемых на других машинах. Этой особенностью распределенные системы отличаются от сильносвязанных многопроцессорных систем, рассмотренных в предыдущей главе. Соответственно, и ядро системы на каждой машине функционирует независимо от внешних условий эксплуатации распределенной среды.
Рисунок 13.1. Модель системы с распределенной архитектурой
Распределенные системы, хорошо описанные в литературе, традиционно делятся на следующие категории:
Периферийные системы, представляющие собой группы машин, отличающихся ярковыраженной общностью и связанных с одной (обычно более крупной) машиной. Периферийные процессоры делят свою нагрузку с центральным процессором и переадресовывают ему все обращения к операционной системе. Цель периферийной системы состоит в увеличении общей производительности сети и в предоставлении возможности выделения процессора одному процессу в операционной среде UNIX. Система запускается как отдельный модуль; в отличие от других моделей распределенных систем, периферийные системы не обладают реальной автономией, за исключением случаев, связанных с диспетчеризацией процессов и распределением локальной памяти.
Распределенные системы типа "Newcastle", позволяющие осуществлять дистанционную связь по именам удаленных файлов в библиотеке (название взято из статьи "The Newcastle Connection" - см. ). Удаленные файлы имеют спецификацию (составное имя), которая в указании пути поиска содержит специальные символы или дополнительную компоненту имени, предшествующую корню файловой системы. Реализация этого метода не предполагает внесения изменений в ядро системы, вследствие этого он более прост, чем другие методы, рассматриваемые в этой главе, но менее гибок.
Абсолютно "прозрачные" распределенные системы, в которых для обращения к файлам, расположенным на других машинах, достаточно указания их стандартных составных имен; распознавание этих файлов как удаленных входит в обязанности ядра. Маршруты поиска файлов, указанные в их составных именах, пересекают машинные границы в точках монтирования, сколько бы таких точек ни было сформировано при монтировании файловых систем на дисках.
В настоящей главе мы рассмотрим архитектуру каждой модели; все приводимые сведения базируются не на результатах конкретных разработок, а на информации, публиковавшейся в различных технических статьях. При этом предполагается, что забота об адресации, маршрутизации, управлении потоками, обнаружении и исправлении ошибок возлагается на модули протоколов и драйверы устройств, другими словами, что каждая модель не зависит от используемой сети. Примеры использования системных функций, приводимые в следующем разделе для периферийных систем, работают аналогичным образом и для систем типа Newcastle и для абсолютно "прозрачных" систем, о которых пойдет речь позже; поэтому в деталях мы их рассмотрим один раз, а в разделах, посвященных другим типам систем, остановимся в основном на особенностях, отличающих эти модели от всех остальных.
13.1 ПЕРИФЕРИЙНЫЕ ПРОЦЕССОРЫ
Архитектура периферийной системы показана на Рисунке 13.2. Цель такой конфигурации состоит в повышении общей производительности сети за счет перераспределения выполняемых процессов между центральным и периферийными процессорами. У каждого из периферийных процессоров нет в распоряжении других локальных периферийных устройств, кроме тех, которые ему нужны для связи с центральным процессором. Файловая система и все устройства находятся в распоряжении центрального процессора. Предположим, что все пользовательские процессы исполняются на периферийном процессоре и между периферийными процессорами не перемещаются; будучи однажды переданы процессору, они пребывают на нем до момента завершения. Периферийный процессор содержит облегченный вариант операционной системы, предназначенный для обработки локальных обращений к системе, управления прерываниями, распределения памяти, работы с сетевыми протоколами и с драйвером устройства связи с центральным процессором.
При инициализации системы на центральном процессоре ядро по линиям связи загружает на каждом из периферийных процессоров локальную операционную систему. Любой выполняемый на периферии процесс связан с процессом-спутником, принадлежащим центральному процессору (см. ); когда процесс, протекающий на периферийном процессоре, вызывает системную функцию, которая нуждается в услугах исключительно центрального процессора, периферийный процесс связывается со своим спутником и запрос поступает на обработку на центральный процессор. Процесс-спутник исполняет системную функцию и посылает результаты обратно на периферийный процессор. Взаимоотношения периферийного процесса со своим спутником похожи на отношения клиента и сервера, подробно рассмотренные нами в главе 11: периферийный процесс выступает клиентом своего спутника, поддерживающего функции работы с файловой системой. При этом удаленный процесс-сервер имеет только одного клиента. В разделе 13.4 мы рассмотрим процессы-серверы, имеющие несколько клиентов.
Рисунок 13.2. Конфигурация периферийной системы
Рисунок 13.3. Форматы сообщений
Когда периферийный процесс вызывает системную функцию, которую можно обработать локально, ядру нет надобности посылать запрос процессу-спутнику. Так, например, в целях получения дополнительной памяти процесс может вызвать для локального исполнения функцию sbrk. Однако, если требуются услуги центрального процессора, например, чтобы открыть файл, ядро кодирует информацию о передаваемых вызванной функции параметрах и условиях выполнения процесса в некое сообщение, посылаемое процессу-спутнику (Рисунок 13.3). Сообщение включает в себя признак, из которого следует, что системная функция выполняется процессом-спутником от имени клиента, передаваемые функции параметры и данные о среде выполнения процесса (например, пользовательский и групповой коды идентификации), которые для разных функций различны. Оставшаяся часть сообщения представляет собой данные переменной длины (например, составное имя файла или данные, предназначенные для записи функцией write).
Процесс-спутник ждет поступления запросов от периферийного процесса; при получении запроса он декодирует сообщение, определяет тип системной функции, исполняет ее и преобразует результаты в ответ, посылаемый периферийному процессу. Ответ, помимо результатов выполнения системной функции, включает в себя сообщение об ошибке (если она имела место), номер сигнала и массив данных переменной длины, содержащий, например, информацию, прочитанную из файла. Периферийный процесс приостанавливается до получения ответа, получив его, производит расшифровку и передает результаты пользователю. Такова общая схема обработки обращений к операционной системе; теперь перейдем к более детальному рассмотрению отдельных функций.
Для того, чтобы объяснить, каким образом работает периферийная система, рассмотрим ряд функций: getppid, open, write, fork, exit и signal. Функция getppid довольно проста, поскольку она связана с простыми формами запроса и ответа, которыми обмениваются периферийный и центральный процессоры. Ядро на периферийном процессоре формирует сообщение, имеющее признак, из которого следует, что запрашиваемой функцией является функция getppid, и посылает запрос центральному процессору. Процесс-спутник на центральном процессоре читает сообщение с периферийного процессора, расшифровывает тип системной функции, исполняет ее и получает идентификатор своего родителя. Затем он формирует ответ и передает его периферийному процессу, находящемуся в состоянии ожидания на другом конце линии связи. Когда периферийный процессор получает ответ, он передает его процессу, вызвавшему системную функцию getppid. Если же периферийный процесс хранит данные (такие, как идентификатор процесса-родителя) в локальной памяти, ему вообще не придется связываться со своим спутником.
Если производится обращение к системной функции open, периферийный процесс посылает своему спутнику соответствующее сообщение, которое включает имя файла и другие параметры. В случае успеха процесс-спутник выделяет индекс и точку входа в таблицу файлов, отводит запись в таблице пользовательских дескрипторов файла в своем пространстве и возвращает дескриптор файла периферийному процессу. Все это время на другом конце линии связи периферийный процесс ждет ответа. У него в распоряжении нет никаких структур, которые хранили бы информацию об открываемом файле; возвращаемый функцией open дескриптор представляет собой указатель на запись в таблице пользовательских дескрипторов файла, принадлежащей процессу-спутнику. Результаты выполнения функции показаны на Рисунке 13.4.
Рисунок 13.4. Вызов функции open из периферийного процесса
Если производится обращение к системной функции write, периферийный процессор формирует сообщение, состоящее из признака функции write, дескриптора файла и объема записываемых данных. Затем из пространства периферийного процесса он по линии связи копирует данные процессу-спутнику. Процесс-спутник расшифровывает полученное сообщение, читает данные из линии связи и записывает их в соответствующий файл (в качестве указателя на индекс которого и запись о котором в таблице файлов используется содержащийся в сообщении дескриптор); все указанные действия выполняются на центральном процессоре. По окончании работы процесс-спутник передает периферийному процессу посылку, подтверждающую прием сообщения и содержащую количество байт данных, успешно переписанных в файл. Операция read выполняется аналогично; спутник информирует периферийный процесс о количестве реально прочитанных байт (в случае чтения данных с терминала или из канала это количество не всегда совпадает с количеством, указанным в запросе). Для выполнения как той, так и другой функции может потребоваться многократная пересылка информационных сообщений по сети, что определяется объемом пересылаемых данных и размерами сетевых пакетов.
Единственной функцией, требующей внесения изменений при работе на центральном процессоре, является системная функция fork. Когда процесс исполняет эту функцию на ЦП, ядро выбирает для него периферийный процессор и посылает сообщение специальному процессу - серверу, информируя последний о том, что собирается приступить к выгрузке текущего процесса. Предполагая, что сервер принял запрос, ядро с помощью функции fork создает новый периферийный процесс, выделяя запись в таблице процессов и адресное пространство. Центральный процессор выгружает копию процесса, вызвавшего функцию fork, на периферийный процессор, затирая только что выделенное адресное пространство, порождает локальный спутник для связи с новым периферийным процессом и посылает на периферию сообщение о необходимости инициализации счетчика команд для нового процесса. Процесс-спутник (на ЦП) является потомком процесса, вызвавшего функцию fork; периферийный процесс с технической точки зрения выступает потомком процесса-сервера, но по логике он является потомком процесса, вызвавшего функцию fork. Процесс-сервер не имеет логической связи с потомком по завершении функции fork; единственная задача сервера состоит в оказании помощи при выгрузке потомка. Из-за сильной связи между компонентами системы (периферийные процессоры не располагают автономией) периферийный процесс и процесс-спутник имеют один и тот же код идентификации. Взаимосвязь между процессами показана на Рисунке 13.5: непрерывной линией показана связь типа "родитель-потомок", пунктиром - связь между равноправными партнерами.
Рисунок 13.5. Выполнение функции fork на центральном процессоре
Когда процесс исполняет функцию fork на периферийном процессоре, он посылает сообщение своему спутнику на ЦП, который и исполняет после этого всю вышеописанную последовательность действий. Спутник выбирает новый периферийный процессор и делает необходимые приготовления к выгрузке образа старого процесса: посылает периферийному процессу-родителю запрос на чтение его образа, в ответ на который на другом конце канала связи начинается передача запрашиваемых данных. Спутник считывает передаваемый образ и переписывает его периферийному потомку. Когда выгрузка образа заканчивается, процесс-спутник исполняет функцию fork, создавая своего потомка на ЦП, и передает значение счетчика команд периферийному потомку, чтобы последний знал, с какого адреса начинать выполнение. Очевидно, было бы лучше, если бы потомок процесса-спутника назначался периферийному потомку в качестве родителя, однако в нашем случае порожденные процессы получают возможность выполняться и на других периферийных процессорах, а не только на том, на котором они созданы. Взаимосвязь между процессами по завершении функции fork показана на Рисунке 13.6. Когда периферийный процесс завершает свою работу, он посылает соответствующее сообщение процессу-спутнику и тот тоже завершается. От процесса-спутника инициатива завершения работы исходить не может.
Рисунок 13.6. Выполнение функции fork на периферийном процессоре
И в многопроцессорной, и в однопроцессорной системах процесс должен реагировать на сигналы одинаково: процесс либо завершает выполнение системной функции до проверки сигналов, либо, напротив, получив сигнал, незамедлительно выходит из состояния приостанова и резко прерывает работу системной функции, если это согласуется с приоритетом, с которым он был приостановлен. Поскольку процесс-спутник выполняет системные функции от имени периферийного процесса, он должен реагировать на сигналы, согласуя свои действия с последним. Если в однопроцессорной системе сигнал заставляет процесс завершить выполнение функции аварийно, процессу-спутнику в многопроцессорной системе следует вести себя тем же образом. То же самое можно сказать и о том случае, когда сигнал побуждает процесс к завершению своей работы с помощью функции exit: периферийный процесс завершается и посылает соответствующее сообщение процессу-спутнику, который, разумеется, тоже завершается.
Когда периферийный процесс вызывает системную функцию signal, он сохраняет текущую информацию в локальных таблицах и посылает сообщение своему спутнику, информируя его о том, следует ли указанный сигнал принимать или же игнорировать. Процессу-спутнику безразлично, выполнять ли перехват сигнала или действие по умолчанию. Реакция процесса на сигнал зависит от трех факторов (Рисунок 13.7): поступает ли сигнал во время выполнения процессом системной функции, сделано ли с помощью функции signal указание об игнорировании сигнала, возникает ли сигнал на этом же периферийном процессоре или на каком-то другом. Перейдем к рассмотрению различных возможностей.
алгоритм sighandle /* алгоритм обработки сигналов */
if (текущий процесс является чьим-то спутником или имеет прототипа)
if (сигнал игнорируется)
if (сигнал поступил во время выполнения системной функции)
поставить сигнал перед процессом-спутником;
послать сообщение о сигнале периферийному процессу;
else { /* периферийный процесс */
/* поступил ли сигнал во время выполнения системной функции или нет */
послать сигнал процессу-спутнику;
алгоритм satellite_end_of_syscall /* завершение системной функции, вызванной периферийным процессом */
входная информация: отсутствует
выходная информация: отсутствует
if (во время выполнения системной функции поступило прерывание)
послать периферийному процессу сообщение о прерывании, сигнал;
else /* выполнение системной функции не прерывалось */
послать ответ: включить флаг, показывающий поступление сигнала;
Рисунок 13.7. Обработка сигналов в периферийной системе
Допустим, что периферийный процесс приостановил свою работу на то время, пока процесс-спутник исполняет системную функцию от его имени. Если сигнал возникает в другом месте, процесс-спутник обнаруживает его раньше, чем периферийный процесс. Возможны три случая.
1. Если в ожидании некоторого события процесс-спутник не переходил в состояние приостанова, из которого он вышел бы по получении сигнала, он выполняет системную функцию до конца, посылает результаты выполнения периферийному процессу и показывает, какой из сигналов им был получен.
2. Если процесс сделал указание об игнорировании сигнала данного типа, спутник продолжает следовать алгоритму выполнения системной функции, не выходя из состояния приостанова по longjmp. В ответе, посылаемом периферийному процессу, сообщение о получении сигнала будет отсутствовать.
3. Если по получении сигнала процесс-спутник прерывает выполнение системной функции (по longjmp), он информирует об этом периферийный процесс и сообщает ему номер сигнала.
Периферийный процесс ищет в поступившем ответе сведения о получении сигналов и в случае обнаружения таковых производит обработку сигналов перед выходом из системной функции. Таким образом, поведение процесса в многопроцессорной системе в точности соответствует его поведению в однопроцессорной системе: он или завершает свою работу, не выходя из режима ядра, или обращается к пользовательской функции обработки сигнала, или игнорирует сигнал и успешно завершает выполнение системной функции.
Рисунок 13.8. Прерывание во время выполнения системной функции
Предположим, например, что периферийный процесс вызывает функцию чтения с терминала, связанного с центральным процессором, и приостанавливает свою работу на время выполнения функции процессом-спутником (Рисунок 13.8). Если пользователь нажимает клавишу прерывания (break), ядро ЦП посылает процессу-спутнику соответствующий сигнал. Если спутник находился в состоянии приостанова в ожидании ввода с терминала порции данных, он немедленно выходит из этого состояния и прекращает выполнение функции read. В своем ответе на запрос периферийного процесса спутник сообщает код ошибки и номер сигнала, соответствующий прерыванию. Периферийный процесс анализирует ответ и, поскольку в сообщении говорится о поступлении сигнала прерывания, отправляет сигнал самому себе. Перед выходом из функции read периферийное ядро осуществляет проверку поступления сигналов, обнаруживает сигнал прерывания, поступивший от процесса-спутника, и обрабатывает его обычным порядком. Если в результате получения сигнала прерывания периферийный процесс завершает свою работу с помощью функции exit, данная функция берет на себя заботу об уничтожении процесса-спутника. Если периферийный процесс перехватывает сигналы о прерывании, он вызывает пользовательскую функцию обработки сигналов и по выходе из функции read возвращает пользователю код ошибки. С другой стороны, если спутник исполняет от имени периферийного процесса системную функцию stat, он не будет прерывать ее выполнение при получении сигнала (функции stat гарантирован выход из любого приостанова, поскольку для нее время ожидания ресурса ограничено). Спутник доводит выполнение функции до конца и возвращает периферийному процессу номер сигнала. Периферийный процесс посылает сигнал самому себе и получает его на выходе из системной функции.
Если сигнал возник на периферийном процессоре во время выполнения системной функции, периферийный процесс будет находиться в неведении относительно того, вернется ли к нему вскоре управление от процесса-спутника или же последний перейдет в состояние приостанова на неопределенное время. Периферийный процесс посылает спутнику специальное сообщение, информируя его о возникновении сигнала. Ядро на ЦП расшифровывает сообщение и посылает сигнал спутнику, реакция которого на получение сигнала описана в предыдущих параграфах (аварийное завершение выполнения функции или доведение его до конца). Периферийный процесс не может послать сообщение спутнику непосредственно, поскольку спутник занят исполнением системной функции и не считывает данные из линии связи.
Если обратиться к примеру с функцией read, следует отметить, что периферийный процесс не имеет представления о том, ждет ли его спутник ввода данных с терминала или же выполняет другие действия. Периферийный процесс посылает спутнику сообщение о сигнале: если спутник находится в состоянии приостанова с приоритетом, допускающим прерывания, он немедленно выходит из этого состояния и прекращает выполнение системной функции; в противном случае выполнение функции доводится до успешного завершения.
Рассмотрим, наконец, случай поступления сигнала во время, не связанное с выполнением системной функции. Если сигнал возник на другом процессоре, спутник получает его первым и посылает сообщение о сигнале периферийному процессу, независимо от того, касается ли этот сигнал периферийного процесса или нет. Периферийное ядро расшифровывает сообщение и посылает сигнал процессу, который реагирует на него обычным порядком. Если сигнал возник на периферийном процессоре, процесс выполняет стандартные действия, не прибегая к услугам своего спутника.
Когда периферийный процесс посылает сигнал другим периферийным процессам, он кодирует сообщение о вызове функции kill и посылает его процессу-спутнику, который исполняет вызываемую функцию локально. Если часть процессов, для которых предназначен сигнал, имеет местонахождение на других периферийных процессорах, сигнал получат (и прореагируют на его получение вышеописанным образом) их спутники.
13.2 СВЯЗЬ ТИПА NEWCASTLЕ
В предыдущем разделе мы рассмотрели тип сильносвязанной системы, для которого характерна посылка всех возникающих на периферийном процессоре обращений к функциям подсистемы управления файлами на удаленный (центральный) процессор. Теперь перейдем к рассмотрению систем с менее сильной связью, которые состоят из машин, производящих обращение к файлам, находящимся на других машинах. В сети, состоящей из персональных компьютеров и рабочих станций, например, пользователи часто обращаются к файлам, расположенным на большой машине. В последующих двух разделах мы рассмотрим такие конфигурации систем, в которых все системные функции выполняются в локальных подсистемах, но при этом имеется возможность обращения к файлам (через функции подсистемы управления файлами), расположенным на других машинах.
Для идентифицирования удаленных файлов в этих системах используется один из следующих двух путей. В одних системах в составное имя файла добавляется специальный символ: компонента имени, предшествующая этому символу, идентифицирует машину, остальная часть имени - файл, находящийся на этой машине. Так, например, составное имя
"sftig!/fs1/mjb/rje"
идентифицирует файл "/fs1/mjb/rje", находящийся на машине "sftig". Такая схема идентифицирования файла соответствует соглашению, установленному программой uucp относительно передачи файлов между системами типа UNIX. В другой схеме удаленные файлы идентифицируются добавлением к имени специального префикса, например:
/../sftig/fs1/mjb/rje
где "/../" - префикс, свидетельствующий о том, что файл удаленный; вторая компонента имени файла является именем удаленной машины. В данной схеме используется привычный синтаксис имен файлов в системе UNIX, поэтому в отличие от первой схемы здесь пользовательским программам нет необходимости приноравливаться к использованию имен, имеющих необычную конструкцию (см. ).
Рисунок 13.9. Формулирование запросов к файловому серверу (процессору)
Всю оставшуюся часть раздела мы посвятим рассмотрению модели системы, использующей связь типа Newcastle, в которой ядро не занимается распознаванием удаленных файлов; эта функция полностью возлагается на подпрограммы из стандартной Си-библиотеки, выполняющие в данном случае роль системного интерфейса. Эти подпрограммы анализируют первую компоненту имени файла, в обоих описанных способах идентифицирования содержащую признак удаленности файла. В этом состоит отступление от заведенного порядка, при котором библиотечные подпрограммы не занимаются синтаксическим разбором имен файлов. На Рисунке 13.9 показано, каким образом формулируются запросы к файловому серверу. Если файл локальный, ядро локальной системы обрабатывает запрос обычным способом. Рассмотрим обратный случай:
open("/../sftig/fs1/mjb/rje/file", O_RDONLY);
Подпрограмма open из Си-библиотеки анализирует первые две компоненты составного имени файла и узнает, что файл следует искать на удаленной машине "sftig". Чтобы иметь информацию о том, была ли ранее у процесса связь с данной машиной, подпрограмма заводит специальную структуру, в которой запоминает этот факт, и в случае отрицательного ответа устанавливает связь с файловым сервером, работающим на удаленной машине. Когда процесс формулирует свой первый запрос на дистанционную обработку, удаленный сервер подтверждает запрос, в случае необходимости ведет запись в поля пользовательского и группового кодов идентификации и создает процессспутник, который будет выступать от имени процесса-клиента.
Чтобы выполнять запросы клиента, спутник должен иметь на удаленной машине те же права доступа к файлам, что и клиент. Другими словами, пользователь "mjb" должен иметь и к удаленным, и к локальным файлам одинаковые права доступа. К сожалению, не исключена возможность того, что код идентификации клиента "mjb" может совпасть с кодом идентификации другого клиента удаленной машины. Таким образом, администраторам систем на работающих в сети машинах следует либо следить за назначением каждому пользователю кода идентификации, уникального для всей сети, либо в момент формулирования запроса на сетевое обслуживание выполнять преобразование кодов. Если это не будет сделано, процесс-спутник будет иметь на удаленной машине права другого клиента.
Более деликатным вопросом является получение в отношении работы с удаленными файлами прав суперпользователя. С одной стороны, клиент-суперпользователь не должен иметь те же права в отношении удаленной системы, чтобы не вводить в заблуждение средства защиты удаленной системы. С другой стороны, некоторые из программ, если им не предоставить права суперпользователя, просто не смогут работать. Примером такой программы является программа mkdir (см. главу 7), создающая новый каталог. Удаленная система не разрешила бы клиенту создавать новый каталог, поскольку на удалении права суперпользователя не действуют. Проблема создания удаленных каталогов служит серьезным основанием для пересмотра системной функции mkdir в сторону расширения ее возможностей в автоматическом установлении всех необходимых пользователю связей. Тем не менее, получение setuid-программами (к которым относится и программа mkdir) прав суперпользователя по отношению к удаленным файлам все еще остается общей проблемой, требующей своего решения. Возможно, что наилучшим решением этой проблемы было бы установление для файлов дополнительных характеристик, описывающих доступ к ним со стороны удаленных суперпользователей; к сожалению, это потребовало бы внесения изменений в структуру дискового индекса (в части добавления новых полей) и породило бы слишком большой беспорядок в существующих системах.
Если подпрограмма open завершается успешно, локальная библиотека оставляет об этом соответствующую отметку в доступной для пользователя структуре, содержащей адрес сетевого узла, идентификатор процесса-спутника, дескриптор файла и другую аналогичную информацию. Библиотечные подпрограммы read и write устанавливают, исходя из дескриптора, является ли файл удаленным, и в случае положительного ответа посылают спутнику сообщение. Процесс-клиент взаимодействует со своим спутником во всех случаях обращения к системным функциям, нуждающимся в услугах удаленной машины. Если процесс обращается к двум файлам, расположенным на одной и той же удаленной машине, он пользуется одним спутником, но если файлы расположены на разных машинах, используются уже два спутника: по одному на каждой машине. Два спутника используются и в том случае, когда к файлу на удаленной машине обращаются два процесса. Вызывая системную функцию через спутника, процесс формирует сообщение, включающее в себя номер функции, имя пути поиска и другую необходимую информацию, аналогичную той, которая входит в структуру сообщения в системе с периферийными процессорами.
Механизм выполнения операций над текущим каталогом более сложен. Когда процесс выбирает в качестве текущего удаленный каталог, библиотечная подпрограмма посылает соответствующее сообщение спутнику, который изменяет текущий каталог, при этом подпрограмма запоминает, что каталог удаленный. Во всех случаях, когда имя пути поиска начинается с символа, отличного от наклонной черты (/), подпрограмма посылает это имя на удаленную машину, где процесс-спутник прокладывает маршрут, начиная с текущего каталога. Если текущий каталог - локальный, подпрограмма просто передает имя пути поиска ядру локальной системы. Системная функция chroot в отношении удаленного каталога выполняется похоже, но при этом ее выполнение для ядра локальной системы проходит незамеченным; строго говоря, процесс может оставить эту операцию без внимания, поскольку только библиотека фиксирует ее выполнение.
Когда процесс вызывает функцию fork, соответствующая библиотечная подпрограмма посылает сообщения каждому спутнику. Процессы - спутники выполняют операцию ветвления и посылают идентификаторы своих потомков клиенту-родителю. Процесс-клиент запускает системную функцию fork, которая передает управление порождаемому потомку; локальный потомок ведет диалог с удаленным потомком-спутником, адреса которого сохранила библиотечная подпрограмма. Такая трактовка функции fork облегчает процессам-спутникам контроль над открытыми файлами и текущими каталогами. Когда процесс, работающий с удаленными файлами, завершается (вызывая функцию exit), подпрограмма посылает сообщения всем его удаленным спутникам, чтобы они по получении сообщения проделали то же самое. Отдельные моменты реализации системных функций exec и exit затрагиваются в упражнениях.
Преимущество связи типа Newcastle состоит в том, что обращение процесса к удаленным файлам становится "прозрачным" (незаметным для пользователя), при этом в ядро системы никаких изменений вносить не нужно. Однако, данной разработке присущ и ряд недостатков. Прежде всего, при ее реализации возможно снижение производительности системы. В связи с использованием расширенной Си-библиотеки размер используемой каждым процессом памяти увеличивается, даже если процесс не обращается к удаленным файлам; библиотека дублирует функции ядра и требует для себя больше места в памяти. Увеличение размера процессов приводит к удлинению продолжительности периода запуска и может вызвать большую конкуренцию за ресурсы памяти, создавая условия для более частой выгрузки и подкачки задач. Локальные запросы будут исполняться медленнее из-за увеличения продолжительности каждого обращения к ядру, замедление может грозить и обработке удаленных запросов, затраты по пересылке которых по сети увеличиваются. Дополнительная обработка удаленных запросов на пользовательском уровне увеличивает количество переключений контекста, операций по выгрузке и подкачке процессов. Наконец, для того, чтобы обращаться к удаленным файлам, программы должны быть перекомпилированы с использованием новых библиотек; старые программы и поставленные объектные модули без этого работать с удаленными файлами не смогут. Все эти недостатки отсутствуют в системе, описываемой в следующем разделе.
13.3 "ПРОЗРАЧНЫЕ" РАСПРЕДЕЛЕННЫЕ ФАЙЛОВЫЕ СИСТЕМЫ
Термин "прозрачное распределение" означает, что пользователи, работающие на одной машине, могут обращаться к файлам, находящимся на другой машине, не осознавая того, что тем самым они пересекают машинные границы, подобно тому, как на своей машине они при переходе от одной файловой системе к другой пересекают точки монтирования. Имена, по которым процессы обращаются к файлам, находящимся на удаленных машинах, похожи на имена локальных файлов: отличительные символы в них отсутствуют. В конфигурации, показанной на Рисунке 13.10, каталог "/usr/src", принадлежащий машине B, "вмонтирован" в каталог "/usr/src", принадлежащий машине A. Такая конфигурация представляется удобной в том случае, если в разных системах предполагается использовать один и тот же исходный код системы, традиционно находящийся в каталоге "/usr/src". Пользователи, работающие на машине A, могут обращаться к файлам, расположенным на машине B, используя привычный синтаксис написания имен файлов (например: "/usr/src/cmd/login.c"), и ядро уже само решает вопрос, является файл удаленным или же локальным. Пользователи, работающие на машине B, имеют доступ к своим локальным файлам (не подозревая о том, что к этим же файлам могут обращаться и пользователи машины A), но, в свою очередь, не имеют доступа к файлам, находящимся на машине A. Конечно, возможны и другие варианты, в частности, такие, в которых все удаленные системы монтируются в корне локальной системы, благодаря чему пользователи получают доступ ко всем файлам во всех системах.
Рисунок 13.10. Файловые системы после удаленного монтирования
Наличие сходства между монтированием локальных файловых систем и открытием доступа к удаленным файловым системам послужило поводом для адаптации функции mount применительно к удаленным файловым системам. В данном случае ядро получает в свое распоряжение таблицу монтирования расширенного формата. Выполняя функцию mount, ядро организует сетевую связь с удаленной машиной и сохраняет в таблице монтирования информацию, характеризующую данную связь.
Интересная проблема связана с именами путей, включающих "..". Если процесс делает текущим каталог из удаленной файловой системы, последующее использование в имени символов ".." скорее вернет процесс в локальную файловую систему, чем позволит обращаться к файлам, расположенным выше текущего каталога. Возвращаясь вновь к Рисунку 13.10, отметим, что когда процесс, принадлежащий машине A, выбрав предварительно в качестве текущего каталог "/usr/src/cmd", расположенный в удаленной файловой системе, исполнит команду
текущим каталогом станет корневой каталог, принадлежащий машине A, а не машине B. Алгоритм namei, работающий в ядре удаленной системы, получив последовательность символов "..", проверяет, является ли вызывающий процесс агентом процесса-клиента, и в случае положительного ответа устанавливает, трактует ли клиент текущий рабочий каталог в качестве корня удаленной файловой системы.
Связь с удаленной машиной принимает одну из двух форм: вызов удаленной процедуры или вызов удаленной системной функции. В первой форме каждая процедура ядра, имеющая дело с индексами, проверяет, указывает ли индекс на удаленный файл, и если это так, посылает на удаленную машину запрос на выполнение указанной операции. Данная схема естественным образом вписывается в абстрактную структуру поддержки файловых систем различных типов, описанную в заключительной части главы 5. Таким образом, обращение к удаленному файлу может инициировать пересылку по сети нескольких сообщений, количество которых определяется количеством подразумеваемых операций над файлом, с соответствующим увеличением времени ответа на запрос с учетом принятого в сети времени ожидания. Каждый набор удаленных операций включает в себя, по крайней мере, действия по блокированию индекса, подсчету ссылок и т. п. В целях усовершенствования модели предлагались различные оптимизационные решения, связанные с объединением нескольких операций в один запрос (сообщение) и с буферизацией наиболее важных данных (см. ).
Рисунок 13.11. Открытие удаленного файла
Рассмотрим процесс, который открывает удаленный файл "/usr/src/cmd/login.c", где "src" - точка монтирования. Выполняя синтаксический разбор имени файла (по схеме namei-iget), ядро обнаруживает, что файл удаленный, и посылает на машину, где он находится, запрос на получение заблокированного индекса. Получив желаемый ответ, локальное ядро создает в памяти копию индекса, корреспондирующую с удаленным файлом. Затем ядро производит проверку наличия необходимых прав доступа к файлу (на чтение, например), послав на удаленную машину еще одно сообщение. Выполнение алгоритма open продолжается в полном соответствии с планом, приведенным в главе 5, с посылкой сообщений на удаленную машину по мере необходимости, до полного окончания алгоритма и освобождения индекса. Взаимосвязь между структурами данных ядра по завершении алгоритма open показана на Рисунке 13.11.
Если клиент вызывает системную функцию read, ядро клиента блокирует локальный индекс, посылает запрос на блокирование удаленного индекса, запрос на чтение данных, копирует данные в локальную память, посылает запрос на освобождение удаленного индекса и освобождает локальный индекс. Такая схема соответствует семантике существующего однопроцессорного ядра, но частота использования сети (несколько обращений на каждую системную функцию) снижает производительность всей системы. Однако, чтобы уменьшить поток сообщений в сети, в один запрос можно объединять несколько операций. В примере с функцией read клиент может послать серверу один общий запрос на "чтение", а уж сервер при его выполнении сам принимает решение на захват и освобождение индекса. Сокращения сетевого трафика можно добиться и путем использования удаленных буферов (о чем мы уже говорили выше), но при этом нужно позаботиться о том, чтобы системные функции работы с файлами, использующие эти буферы, выполнялись надлежащим образом.
При второй форме связи с удаленной машиной (вызов удаленной системной функции) локальное ядро обнаруживает, что системная функция имеет отношение к удаленному файлу, и посылает указанные в ее вызове параметры на удаленную систему, которая исполняет функцию и возвращает результаты клиенту. Машина клиента получает результаты выполнения функции и выходит из состояния вызова. Большинство системных функций может быть выполнено с использованием только одного сетевого запроса с получением ответа через достаточно приемлемое время, но в такую модель вписываются не все функции. Так, например, по получении некоторых сигналов ядро создает для процесса файл с именем "core" (глава 7). Создание этого файла не связано с конкретной системной функцией, а завершает выполнение нескольких операций, таких как создание файла, проверка прав доступа и выполнение ряда операций записи.
В случае с системной функцией open запрос на исполнение функции, посылаемый на удаленную машину, включает в себя часть имени файла, оставшуюся после исключения компонент имени пути поиска, отличающих удаленный файл, а также различные флаги. В рассмотренном ранее примере с открытием файла "/usr/src/cmd/login.c" ядро посылает на удаленную машину имя "cmd/login.c". Сообщение также включает в себя опознавательные данные, такие как пользовательский и групповой коды идентификации, необходимые для проверки прав доступа к файлам на удаленной машине. Если с удаленной машины поступает ответ, свидетельствующий об успешном выполнении функции open, локальное ядро выбирает свободный индекс в памяти локальной машины и помечает его как индекс удаленного файла, сохраняет информацию об удаленной машине и удаленном индексе и по заведенному порядку выделяет новую запись в таблице файлов. В сравнении с реальным индексом на удаленной машине индекс, принадлежащий локальной машине, является формальным, не нарушающим конфигурацию модели, которая в целом совпадает с конфигурацией, используемой при вызове удаленной процедуры (Рисунок 13.11). Если вызываемая процессом функция обращается к удаленному файлу по его дескриптору, локальное ядро узнает из индекса (локального) о том, что файл удаленный, формулирует запрос, включающий в себя вызываемую функцию, и посылает его на удаленную машину. В запросе содержится указатель на удаленный индекс, по которому процесс-спутник сможет идентифицировать сам удаленный файл.
Получив результат выполнения любой системной функции, ядро может для его обработки прибегнуть к услугам специальной программы (по завершении которой ядро закончит работу с функцией), ибо не всегда локальная обработка результатов, применяемая в однопроцессорной системе, подходит для системы с несколькими процессорами. Вследствие этого возможны изменения в семантике системных алгоритмов, направленные на обеспечение поддержки выполнения удаленных системных функций. Однако, при этом в сети циркулирует минимальный поток сообщений, обеспечивающий минимальное время реакции системы на поступающие запросы.
13.4 РАСПРЕДЕЛЕННАЯ МОДЕЛЬ БЕЗ ПЕРЕДАТОЧНЫХ ПРОЦЕССОВ
Использование передаточных процессов (процессов-спутников) в "прозрачной" распределенной системе облегчает слежение за удаленными файлами, однако при этом таблица процессов удаленной системы перегружается процессами-спутниками, бездействующими большую часть времени. В других схемах для обработки удаленных запросов используются специальные процессы-серверы (см. и ). Удаленная система располагает набором (пулом) процессов-серверов, время от времени назначаемых ею для обработки поступающих удаленных запросов. После обработки запроса процесс-сервер возвращается в пул и переходит в состояние готовности к выполнению обработки других запросов. Сервер не сохраняет пользовательский контекст между двумя обращениями, ибо он может обрабатывать запросы сразу нескольких процессов. Следовательно, каждое поступающее от процесса-клиента сообщение должно включать в себя информацию о среде его выполнения, а именно: коды идентификации пользователя, текущий каталог, сигналы и т. д. Процессы-спутники получают эти данные в момент своего появления или во время выполнения системной функции.
Когда процесс открывает удаленный файл, ядро удаленной системы назначает индекс для последующих ссылок на файл. Локальная машина располагает таблицей пользовательских дескрипторов файла, таблицей файлов и таблицей индексов с обычным набором записей, причем запись в таблице индексов идентифицирует удаленную машину и удаленный индекс. В тех случаях, когда системная функция (например, read) использует дескриптор файла, ядро посылает сообщение, указывающее на ранее назначенный удаленный индекс, и передает связанную с процессом информацию: код идентификации пользователя, максимально-допустимый размер файла и т. п. Если удаленная машина имеет в своем распоряжении процесс-сервер, взаимодействие с клиентом принимает вид, описанный ранее, однако связь между клиентом и сервером устанавливается только на время выполнения системной функции.
Если вместо процессов-спутников воспользоваться услугами серверов, управление потоком данных, сигналами и удаленными устройствами может усложниться. Поступающие в большом количестве запросы к удаленной машине при отсутствии достаточного числа серверов должны выстраиваться в очередь. Для этого нужен протокол более высокого уровня, чем тот, который используется в основной сети. В модели, использующей спутник, с другой стороны, перенасыщенность запросами исключается, ибо все запросы клиента обрабатываются синхронно. Клиент может иметь не более одного запроса, ожидающего обработки.
Обработка сигналов, прерывающих выполнение системной функции, при использовании серверов также усложняется, поскольку удаленной машине приходится при этом искать соответствующий сервер, обслуживающий выполнение функции. Не исключается даже и такая возможность, что в связи с занятостью всех серверов запрос на выполнение системной функции находится в состоянии ожидания обработки. Условия для возникновения конкуренции складываются и тогда, когда сервер возвращает результат выполнения системной функции вызывающему процессу и ответ сервера заключает в себе посылку через сеть соответствующего сигнального сообщения. Каждое сообщение должно быть помечено таким образом, чтобы удаленная система могла распознать его и в случае необходимости прервать работу процессов-серверов. При использовании спутников тот процесс, который обслуживает выполнение запроса клиента, идентифицируется автоматически, и в случае поступления сигнала проверка того, закончена ли обработка запроса или нет, не составляет особого труда.
Наконец, если вызываемая клиентом системная функция заставляет сервер приостановиться на неопределенное время (например, при чтении данных с удаленного терминала), сервер не может вести обработку других запросов, чтобы освободить тем самым серверный пул. Если к удаленным устройствам обращаются сразу несколько процессов и если при этом количество серверов ограничено сверху, имеет место вполне ощутимое узкое место. При использовании спутников этого не происходит, поскольку спутник выделяется каждому процессу-клиенту. Еще одна проблема, связанная с использованием серверов для удаленных устройств, будет рассмотрена в упражнении 13.14.
Несмотря на преимущества, которые предоставляет использование процессов-спутников, потребность в свободных записях таблицы процессов на практике становится настолько острой, что в большинстве случаев для обработки удаленных запросов все-таки прибегают к услугам процессов-серверов.
Рисунок 13.12. Концептуальная схема взаимодействия с удаленными файлами на уровне ядра
13.5 ВЫВОДЫ
В данной главе нами были рассмотрены три схемы работы с расположенными на удаленных машинах файлами, трактующие удаленные файловые системы как расширение локальной. Архитектурные различия между этими схемами показаны на Рисунке 13.12. Все они в свою очередь отличаются от многопроцессорных систем, описанных в предыдущей главе, тем, что здесь процессоры не используют физическую память совместно. Система с периферийными процессорами состоит из сильносвязанного набора процессоров, совместно использующих файловые ресурсы центрального процессора. Связь типа Newcastle обеспечивает скрытый ("прозрачный") доступ к удаленным файлам, но не средствами ядра операционной системы, а благодаря использованию специальной Си-библиотеки. По этой причине все программы, предполагающие использовать связь данного типа, должны быть перекомпилированы, что в общем-то является серьезным недостатком этой схемы. Удаленность файла обозначается с помощью специальной последовательности символов, описывающих машину, на которой расположен файл, и это является еще одним фактором, ограничивающим мобильность программ.
В "прозрачных" распределенных системах для доступа к удаленным файлам используется модификация системной функции mount. Индексы в локальной системе содержат отметку о том, что они относятся к удаленным файлам, и локальное ядро посылает на удаленную систему сообщение, описывающее запрашиваемую системную функцию, ее параметры и удаленный индекс. Связь в "прозрачной" распределенной системе поддерживается в двух формах: в форме вызова удаленной процедуры (на удаленную машину посылается сообщение, содержащее перечень операций, связанных с индексом) и в форме вызова удаленной системной функции (сообщение описывает запрашиваемую функцию). В заключительной части главы рассмотрены вопросы, имеющие отношение к обработке дистанционных запросов с помощью процессов-спутников и серверов.
13.6 УПРАЖНЕНИЯ
*1. Опишите реализацию системной функции exit в системе с периферийными процессорами. В чем разница между этим случаем и тем, когда процесс завершает свою работу по получении неперехваченного сигнала? Каким образом ядру следует сохранить дамп содержимого памяти?
2. Процессы не могут игнорировать сигналы типа SIGKILL; объясните, что происходит в периферийной системе, когда процесс получает такой сигнал.
*3. Опишите реализацию системной функции exec в системе с периферийными процессорами.
*4. Каким образом центральному процессору следует производить распределение процессов между периферийными процессорами с тем, чтобы сбалансировать общую нагрузку?
*5. Что произойдет в том случае, если у периферийного процессора не окажется достаточно памяти для размещения всех выгруженных на него процессов? Каким образом должны производиться выгрузка и подкачка процессов в сети?
6. Рассмотрим систему, в которой запросы к удаленному файловому серверу посылаются в случае обнаружения в имени файла специального префикса. Пусть процесс вызывает функцию execl("/../sftig/bin/sh", "sh", 0); Исполняемый модуль находится на удаленной машине, но должен выполняться в локальной системе. Объясните, каким образом удаленный модуль переносится в локальную систему.
7. Если администратору нужно добавить в существующую систему со связью типа Newcastle новые машины, то как об этом лучше всего проинформировать модули Си-библиотеки?
*8. Во время выполнения функции exec ядро затирает адресное пространство процесса, включая и библиотечные таблицы, используемые связью типа Newcastle для слежения за ссылками на удаленные файлы. После выполнения функции процесс должен сохранить возможность обращения к этим файлам по их старым дескрипторам. Опишите реализацию этого момента.
*9. Как показано в разделе 13.2, вызов системной функции exit в системах со связью типа Newcastle приводит к посылке сообщения процессу-спутнику, заставляющего последний завершить свою работу. Это делается на уровне библиотечных подпрограмм. Что происходит, когда локальный процесс получает сигнал, побуждающий его завершить свою работу в режиме ядра?
*10. Каким образом в системе со связью типа Newcastle, где удаленные файлы идентифицируются добавлением к имени специального префикса, пользователь может, указав в качестве компоненты имени файла ".." (родительский каталог), пересечь удаленную точку монтирования?
11. Из главы 7 нам известно о том, что различные сигналы побуждают процесс сбрасывать дамп содержимого памяти в текущий каталог. Что должно произойти в том случае, если текущим является каталог из удаленной файловой системы? Какой ответ вы дадите в том случае, если в системе используется связь типа Newcastle?
*12. Какие последствия для локальных процессов имело бы удаление из системы всех процессов-спутников или серверов?
*13. Подумайте над тем, как в "прозрачной" распределенной системе следует реализовать алгоритм link, параметрами которого могут быть два имени удаленных файлов, а также алгоритм exec, связанный с выполнением нескольких внутренних операций чтения. Рассмотрите две формы связи: вызов удаленной процедуры и вызов удаленной системной функции.
*14. При обращении к устройству процесс-сервер может перейти в состояние приостанова, из которого он будет выведен драйвером устройства. Естественно, если число серверов ограничено, система не сможет больше удовлетворять запросы локальной машины. Придумайте надежную схему, по которой в ожидании завершения ввода-вывода, связанного с устройством, приостанавливались бы не все процессы-серверы. Системная функция не прекратит свое выполнение, пока все серверы будут заняты.
Рисунок 13.13. Конфигурация с терминальным сервером
*15. Когда пользователь регистрируется в системе, дисциплина терминальной линии сохраняет информацию о том, что терминал является операторским, ведущим группу процессов. По этой причине, когда пользователь на клавиатуре терминала нажимает клавишу "break", сигнал прерывания получают все процессы группы. Рассмотрим конфигурацию системы, в которой все терминалы физически подключаются к одной машине, но регистрация пользователей логически реализуется на других машинах (Рисунок 13.13). В каждом отдельном случае система создает для удаленного терминала getty-процесс. Если запросы к удаленной системе обрабатываются с помощью набора процессов-серверов, следует отметить, что при выполнении процедуры открытия сервер останавливается в ожидании подключения. Когда выполнение функции open завершается, сервер возвращается обратно в серверный пул, разрывая свою связь с терминалом. Каким образом осуществляется рассылка сигнала о прерывании, вызываемого нажатием клавиши "break", по адресам процессов, входящих в одну группу?
*16. Разделение памяти - это особенность, присущая локальным машинам. С логической точки зрения, выделение общей области физической памяти (локальной или удаленной) можно осуществить и для процессов, принадлежащих разным машинам. Опишите реализацию этого момента.
*17. Рассмотренные в главе 9 алгоритмы выгрузки процессов и подкачки страниц по обращению предполагают использование локального устройства выгрузки. Какие изменения следует внести в эти алгоритмы для того, чтобы создать возможность поддержки удаленных устройств выгрузки?
*18. Предположим, что на удаленной машине (или в сети) случился фатальный сбой и локальный протокол сетевого уровня зафиксировал этот факт. Разработайте схему восстановления локальной системы, обращающейся к удаленному серверу с запросами. Кроме того, разработайте схему восстановления серверной системы, утратившей связь с клиентами.
*19. Когда процесс обращается к удаленному файлу, не исключена возможность того, что в поисках файла процесс обойдет несколько машин. В качестве примера возьмем имя "/usr/src/uts/3b2/os", где "/usr" - каталог, принадлежащий машине A, "/usr/src" - точка монтирования корня машины B, "/usr/src/uts/3b2" - точка монтирования корня машины C. Проход через несколько машин к месту конечного назначения называется "мультискачком" (multihop). Однако, если между машинами A и C существует непосредственная сетевая связь, пересылка данных через машину B была бы неэффективной. Опишите особенности реализации "мультискачка" в системе со связью Newcastle и в "прозрачной" распределенной системе.
В настоящее время все разрабатываемые в коммерческих целях ИС имеют распределенную архитектуру, которая подразумевает использование глобальных и/или локальных сетей.
Исторически первыми получила широкое распространение файл-серверная архитектура, поскольку ее логика проста и перевести на такую архитектуру уже находящиеся в эксплуатации ИС –проще всего. Затем она была трансформирована в архитектуру сервер-клиент, которую можно трактовать как ее логическое продолжение. Современные системы, используемые в глобальной сети INTERNET в основном относятся к архитектуре распределенных объектов (см. Рис. III ‑15 )
ИС можно представить состоящую из следующих составных частей (Рис. III‑16)
III.03.2. a Файл-серверные приложения.
Это исторически первая распределенная архитектура (Рис. III‑17). Организуется она предельно просто: на сервере находятся только данные, а все остальное относится к клиентской машине. Поскольку локальные сети достаточно дешевы, и в силу того, что при такой архитектуре прикладное ПО автономно, такая архитектура достаточно часто используется и сейчас. Можно сказать, что это вариант клиент-серверной архитектуры, при которой на сервере находятся только файлы данных. Разные персональные компьютеры взаимодействуют только по средствам общего хранилища данных, поэтому программы, написанные в расчете на один компьютер проще всего адаптировать под такую архитектуру.
Плюсы:
Плюсы файл-серверной архитектуры:
Простота организации;
Не противоречит необходимым требованиям к БД к поддержанию целостности и надежности.
Перегрузка сети;
Непредсказуемость реакции на запрос.
Эти недостатки объясняются тем, что любой запрос к БД приводит к перекачке по сети к значительным объемам информации. Например, для выборки из таблиц одной или нескольких строк перекачивается вся таблица на клиентскую машину и уже там СУБД производит выборку. Значительный сетевой трафик особенно чреват при организации удаленного доступа к БД.
III.03.2. b Клиент-серверные приложения.
В данном случае имеет место распределение обязанностей между сервером и клиентом. В зависимости от того, как они разделены различают толстого и тонкого клиента .
В модели «тонкий клиент” вся работа приложения и управление данными выполняются на сервере. Пользовательский интерфейс в этих системах "переселяется" на персональный компьютер, а само программное приложение выполняет функции сервера, т.е. выполняет все процессы приложения и управляет данными. Модель тонкого клиента можно также реализовать там, где клиенты компьютеры или рабочие станции. Сетевые устройства запускают Internet-броузер и пользовательский интерфейс, реализованный внутри системы.
Главный недостаток модели тонкого клиента - большая загруженность сервера и сети. Все вычисления выполняются а сервере, а это может привести к значительному сетевое трафику между клиентом и сервером. В современных компьютерах достаточно вычислительной мощности, но она практически не используется в модель/тонкого клиента банка
Напротив, модель толстого клиента использует вычислительную мощность локальных машин: само приложение помещаются на клиентский компьютер. Примером архитектуры такого типа могут служить системы банкоматов, в которых банкомат является клиентом, а сервер -центральным компьютером, обслуживающим базу данных по расчетам с клиентами
III.03.2. c Двух- и трехуровневые архитектура клиент-сервер.
Все рассмотренные выше архитектуры являются двухуровневыми. В них различается уровень клиента и уровень сервера. Строго говоря, ИС состоит из трех логических уровней:
· Уровень пользователя;
· Уровень приложения:
· Уровень данных.
Поэтому в двухуровневой модели, где задействованы только два уровня, возникает проблема с масштабируемостью и производительностью, если выбрана модель тонкий клиент, либо проблемы связанные с управлением системы, если взята модель толстый клиент. Избежать этих проблем можно, если применять модель, состоящую из трех уровней, где два из них сервера(Рис. III‑21).
| Сервер данных |
Фактически сервер приложения и сервер данных могут располагаться на одной машине, но выполнять функции друг друга они не могут. Трехуровневая модель хороша тем, что в ней логически разделены выполнение приложения и управление данными.
Таблица III‑5 Применение разных типов архитектур
| Архитектура | Приложение |
| Двухуровневая тонкий клиент | 1 Наследуемые системы, в которых не целесообразно разделять выполнение приложения и управление данными. 2 Приложения с интенсивными вычислениями, но малыми объемами управления данными. 3 Приложения с большими объемами данных, но малым количеством вычислений. |
| Двухуровневый толстый клиент | 1 Приложения, где пользователю требуется интенсивная обработка данных, то есть визуализация данных. 2 Приложения с относительно постоянным набором функций пользователя, применяемых к среде с хорошо отлаженным системным управлением. |
| Трехуровневый сервер-клиент | 1 Большие приложения с сотами и тысячами клиентов 2 Приложения, в которых часто меняются и данные и методы их обработки. 3 Приложения, в которых выполняются интеграции данных из многих источников. |
Такая модель подходит многим типам приложений, но ограничивает разработчиков ИС, которые должна решать, где предоставить сервисы, обеспечивать поддержку масштабируемости, разрабатывать средства для подключения новых клиентов.
III.03.2. d Архитектура распределенных объектов.
Более общий подход обеспечивает архитектура распределенных объектов, основными компонентами которой являются объекты. Они предоставляют набор услуг через свои интерфейсы. Другие объекты посылают запросы, при этом не делается различий между клиентом и сервером. Объекты могут располагаться на разных компьютерах в сети и взаимодействовать по средствам промежуточного ПО, по аналогии системной шины, которая позволяет подключать различные устройства и поддерживать взаимодействие между аппаратными устройствами.
| … |
| Диспетчер драйвер ODBC |
| Драйвер 1 |
| Драйвер К |
| БД 1 |
| БД К |
| Работа с SQL |
| … |
Архитектура ODBC включает компоненты:
1. Приложение (например, ИС). Оно выполняет задачи: запрашивает соединение с источником данных, посылает SQL – запросы к источнику данных, описывает область хранения и формат для SQL – запросов, обрабатывает ошибки и оповещает о них пользователя, осуществляет фиксацию или откат транзакций, запрашивает соединение с источником данных.
2. Диспетчер устройств. Он загружает драйвера по требованию приложений, предлагает единый интерфейс всем приложениям, причем интерфейс администратора ODBC одинаков и независим то того, с какой СУБД приложение будет взаимодействовать. Диспетчер драйверов, поставляемый Microsoft, является динамически загружаемой библиотекой DLL.
3. Драйвер зависит от СУБД. Драйвер ODBC – это динамическая библиотека DLL, которая реализует функции ODBC и взаимодействует с источником данных. Драйвер – это программа, которая обрабатывает запрос какой-то функции специфично для СУБД (может модифицировать запросы в соответствии с СУБД) и возвращает результат приложению. Каждая СУБД, поддерживающая технологию ODBC, должна предоставить разработчикам приложений драйвер для этой СУБД.
4. Источник данных содержит управляющую информацию, задаваемую пользователем, информацию об источнике данных и используется для доступа к конкретной СУБД. При этом используются средства ОС и сетевой платформы.
Динамическая модель
Эта модель предполагает много аспектов, для представления которых на языке UML используется как минимум 5 диаграмм см. пп. 2.04.2- 2.04.5.
Рассмотрим аспект управления. Модель управления дополняет структурные модели.
Каким бы образом не была описана структура системы, она состоит из набора структурных единиц (функций или объектов). Чтобы они функционировали как единое целое, ими надо управлять, а информация по управлению отсутствует в статических диаграммах. В моделях управления проектируется поток управления между системами.
Можно выделить два основных типа управления в программных системах.
1. Централизованное управление.
2. Управление, основанное на событиях.
Централизованное управление может быть:
· Иерархическим - по принципу «вызов-возврат» (именно так чаще всего работает учебные программы)
· Модель диспетчера , которая применяется для параллельных систем.
В модели диспетчера предполагается, что один из компонентов системы – диспетчер. Он управляет как запуском, так и завершением систем и координацией остальных процессов системы. Процессы могут работать параллельно друг другу. Под процессом понимается программа, подсистема или процедура, которая работает на данный момент. Эта модель может применяться также в последовательных системах, где управляющая программа вызывает отдельные подсистемы в зависимости от каких-то переменных состояния (через оператор case ).
Управление событиями предполагает отсутствие какой-либо подпрограммы ответственной за управление. Управление осуществляется внешними событиями: нажатие клавиши мыши, нажатие клавиатуры, изменения показания датчиков, изменения показания таймера ит.д. Каждое внешнее событие кодируется и помещается в очередь событий. Если реакция на событие в очереди предусмотрена, то вызывается та процедура (подпрограмма), которая и осуществляет реакцию на это событие. События, на которые реагирует система, могут происходить либо в других подсистемах, либо во внешнем окружении системы.
Примером такого управления является организация приложений в ОС Windows.
Все описанные ранее структурной модели можно реализовать с помощью централизованного управления или управления, основанного на событиях.
Пользовательский интерфейс
При разработки модели интерфейса следует учитывать не только задачи проектируемого ПО, но и особенности мозга, связанные с восприятием информации.
III.03.4. a Психофизические особенности человека, связанные с восприятием и обработкой информации.
Часть мозга, которую условно можно назвать процессором восприятия, постоянно, без участия сознания, перерабатывает поступающую информацию, сравнивает ее с прошлым опытом и помещает ее в хранилище.
Когда зрительный образ привлекает наше внимание, тогда интересующая нас информация поступает краткосрочную память. Если же наше внимание не было привлечено, то информация в хранилище пропадает, замещаясь следующими порциями.
В каждый момент времени фокус внимания может фиксироваться в одной точке, поэтому если возникает необходимость одновременного отслеживания нескольких ситуаций, то фокус перемещается с одного отслеживаемого объекта на другой. При этом внимание рассредоточивается, и какие-то детали могут быть упущены. Существенно и то, что восприятие во многом основано на мотивации.
При смене кадра мозг на некоторое время блокируется: он осваивает новую картинку, выделяя наиболее существенные детали. Это значит, что если необходима быстрая реакция пользователя, то резко менять картинки не стоит.
Краткосрочная память - самое узкое место в системе обработки информации человека. Ее емкость равна 7±2 несвязанных объекта. Невостребованная информация хранится в ней не более 30 секунд. Чтобы не забыть какую-нибудь важную для нас информацию, мы обычно повторяем ее про себя, обновляя информацию в краткосрочной памяти. Таким образом, при проектировании интерфейсов следует иметь в виду, что подавляющему большинству сложно, например, запомнить и ввести на другом экране числа, содержащие более пяти цифр.
Несмотря на то, что емкость и время хранения долгосрочной памяти неограниченны, доступ к информации весьма непрост. Механизм извлечения информации из долгосрочной памяти имеет ассоциативный характер. Для улучшения запоминания информации ее привязывают тем данным, которые память уже хранит и позволяет легко получить. Поскольку доступ к долгосрочной памяти затруднен, целесообразно рассчитывать не на то, что пользователь вспомнит информацию, а на то, что пользователь узнает ее.
III.03.4. b Основные критерии оценки интерфейсов
Многочисленные опросы и обследования, проводимые ведущими фирмами по разработке программного обеспечения, показали, что пользователи ценят в интерфейсе:
1)простоту освоения и запоминания - конкретно оценивают время освоения и продолжительность сохранения информации и памяти;
2)скорость достижения результатов при использовании системы, которая определяется количеством вводимых или выбираемых мышью команд и настроек;
3)субъективную удовлетворенность при эксплуатации системы (удобство работы, утомляемость и т. д.).
Причем для пользователей-профессионалов, постоянно работающих с одним и тем же пакетом, на первое место достаточно быстро выходят второй и третий критерии, а для пользователей-непрофессионалов, работающих с программным обеспечением периодически и выполняющих сравнительно несложные задачи - первый и третий.
С этой точки зрения на сегодняшний день наилучшими характеристиками для пользователей-профессионалов обладают интерфейсы со свободной навигацией, а для пользователей-непрофессионалов - интерфейсы прямого манипулирования. Давно замечено, что при выполнении операции копирования файлов при прочих равных условиях большинство профессионалов используют оболочки типа Far, а непрофессионалы - «перетаскивание объектов» Windows.
III.03.4. c Типы интерфейсов пользователя
Различают следующие типы пользовательских интерфейсов:
Примитивные
Со свободной навигацией
Прямого манипулирования.
Интерфейс примитивный
Примитивным называется интерфейс, который организует взаимодействие с пользователем и используется в консольном режиме. Единственное отклонение от последовательного процесса, который обеспечивается данными, заключается в организации цикла для обработки нескольких наборов данных.
Интерфейс Меню.
В отличие от примитивного интерфейса, позволяет пользователю выбирать операцию из специального списка, выводимого ему программой. Эти интерфейсы предполагают реализацию множества сценариев работы, последовательность действий в которых определяется пользователями. Древовидная организация меню предполагает, что поиск пункта более чем двух уровневого меню оказывается довольно сложной задачей.
n1.doc
11. Архитектура распределенных систем
Цели
Цель настоящей главы – изучение архитектуры распределенных программных систем. Прочитав эту главу, вы должны:
знать основные преимущества и недостатки распределенных систем;
иметь представление о различных подходах, используемых при разработке архитектур клиент/сервер;
понимать различия между архитектурой клиент/сервер и архитектурой распределенных объектов;
знать концепцию брокера запросов к объектам и принципы, реализованные в стандартах CORBA.
В настоящее время практически все большие программные системы являются распределенными. Распределенной называется такая система, в которой обработка информации сосредоточена не на одной вычислительной машине, а распределена между несколькими компьютерами. При проектировании распределенных систем, которое имеет много общего с проектированием любого другого ПО, все же следует учитывать ряд специфических особенностей. Некоторые из них уже упоминалось во введении к главе 10 при рассмотрении архитектуры клиент/сервер, здесь они обсуждаются более подробно.
Поскольку в наши дни распределенные системы получили широкое распространение, разработчики ПО должны быть знакомы с особенностями их проектирования. До недавнего времени все большие системы в основном являлись централизованными, которые запускались на одной главной вычислительной машине (мэйнфрейме) с подключенными к ней терминалами. Терминалы практически не занимались обработкой информации – все вычисления выполнялись на главной машине. Разработчикам таких систем не приходилось задумываться о проблемах распределенных вычислений.
Все современные программные системы можно разделить на три больших класса.
1. Прикладные программные системы, предназначенные для работы только на одном персональном компьютере или рабочей станции. К ним относятся текстовые процессоры, электронные таблицы, графические системы и т.п.
2. Встроенные системы, предназначенные для работы на одном процессоре либо на интегрированной группе процессоров. К ним относятся системы управления бытовыми устройствами, различными приборами и др.
3. Распределенные системы, в которых программное обеспечение выполняется на слабо интегрированной группе параллельно работающих процессоров, связанных через сеть. К ним относятся системы банкоматов, принадлежащих какому-либо банку, издательские системы, системы ПО коллективного пользования и др.
В настоящее время между перечисленными классами программных систем существуют четкие границы, которые в дальнейшем будут все более стираться. Со временем, когда высокоскоростные беспроводные сети станут широкодоступными, появится возможность динамически интегрировать устройства со встроенными программными системами, например электронные органайзеры с более общими системами.
В книге выделено шесть основных характеристик распределенных систем.
1. Совместное использование ресурсов.
Распределенные системы допускают совместное использование аппаратных и программных ресурсов, например жестких дисков, принтеров, файлов, компиляторов и т.п., связанных посредством сети. Очевидно, что разделение ресурсов возможно также в многопользовательских системах, однако в этом случае за предоставление ресурсов и их управление должен отвечать центральный компьютер.
2. Открытость. Это возможность расширять систему путем добавления новых ресурсов. Распределенные системы – это открытые системы, к которым подключают аппаратное и программное обеспечение от разных производителей.
3. Параллельность. В распределенных системах несколько процессов могут одновременно выполняться на разных компьютерах в сети. Эти процессы могут (но не обязательно) взаимодействовать друг с другом во время их выполнения.
4. Масштабируемость. В принципе все распределенные системы являются масштабируемыми: чтобы система соответствовала новым требованиям, ее можно наращивать посредством добавления новых вычислительных ресурсов. Но на практике наращивание может ограничиваться сетью, объединяющей отдельные компьютеры системы. Если подключить много новых машин, пропускная способность сети может оказаться недостаточной.
5. Отказоустойчивость. Наличие нескольких компьютеров и возможность дублирования информации означает, что распределенные системы устойчивы к определенным аппаратным и программным ошибкам (см. главу 18). Большинство распределенных систем в случае ошибки, как правило, могут поддерживать хотя бы частичную функциональность. Полный сбой в работе системы происходит только в случае сетевых ошибок.
6. Прозрачность.
Это свойство означает, что пользователям предоставлен полностью прозрачный доступ к ресурсам и в то же время от них скрыта информация о распределении ресурсов в системе. Однако во многих случаях конкретные знания об организации системы помогают пользователю лучше использовать ресурсы.
Разумеется, распределенным системам присущ ряд недостатков.
Сложность. Распределенные системы сложнее централизованных. Намного труднее понять и оценить свойства распределенных систем в целом, а также тестировать эти системы. Например, здесь производительность системы зависит не от скорости работы одного процессора, а от полосы пропускания сети и скорости работы разных процессоров. Перемещая ресурсы из одной части системы в другую, можно радикально повлиять на производительность системы.
Безопасность. Обычно доступ к системе можно получить с нескольких разных машин, сообщения в сети могут просматриваться или перехватываться. Поэтому, в распределенной системе намного сложнее поддерживать безопасность.
Управляемость. Система может состоять из разнотипных компьютеров, на которых могут быть установлены разные версии операционных систем. Ошибки на одной машине могут распространиться на другие машины с непредсказуемыми последствиями. Поэтому требуется значительно больше усилий, чтобы управлять и поддерживать систему в рабочем состоянии.
Непредсказуемость.
Как известно всем пользователям Web-сети, реакция распределенных систем на определенные события непредсказуема и зависит от полной загрузки системы, ее организации и сетевой нагрузки. Так как все эти параметры могут постоянно меняться, время, затраченное на выполнение запроса пользователя, в тот или иной момент может существенно различаться.
При обсуждении преимуществ и недостатков распределенных систем в книге определяется ряд критических проблем проектирования таких систем (табл. 11.1). В этой главе основное внимание уделяется архитектуре распределенного ПО, так как я полагаю, что при разработке программных продуктов наиболее значимым является именно этот момент. Если вас интересуют другие темы, обратитесь к специализированным книгам по распределенным системам.
Таблица 11.1. Проблемы проектирования распределенных систем
| Проблема проектирования | Описание |
| Идентификация ресурсов | Ресурсы в распределенной системе располагаются на разных компьютерах, поэтому систему имен ресурсов следует продумать так, чтобы пользователи могли без труда открывать необходимые им ресурсы и ссылаться на них. Примером может служить система унифицированного указателя ресурсов URL, которая определяет адреса Web-страниц. Без легковоспринимаемой и универсальной системы идентификации большая часть ресурсов окажется недоступной пользователям системы |
| Коммуникации | Универсальная работоспособность Internet и эффективная реализация протоколов TCP/IP в Internet для большинства распределенных систем служат примером наиболее эффективного способа организации взаимодействия между компьютерами. Однако там, где на производительность, надежность и прочее накладываются специальные требования, можно воспользоваться альтернативными способами системных коммуникаций |
| Качество системного сервиса | Качество сервиса, предлагаемое системой, отражает ее производительность, работоспособность и надежность. На качество сервиса влияет целый ряд факторов: распределение системных процессов, распределение ресурсов, системные и сетевые аппаратные средства и возможности адаптации системы |
| Архитектура программного обеспечения | Архитектура программного обеспечения описывает распределение системных функций по компонентам системы, а также распределение этих компонентов по процессорам. Если необходимо поддерживать высокое качество системного сервиса, выбор правильной архитектуры оказывается решающим фактором |
Задача разработчиков распределенных систем – спроектировать программное или аппаратное обеспечение так, чтобы предоставить все необходимые характеристики распределенной системы. А для этого требуется знать преимущества и недостатки различных архитектур распределенных систем. Здесь выделяется два родственных типа архитектур распределенных систем.
1. Архитектура клиент/сервер.
В этой модели систему можно представить как набор сервисов, предоставляемых серверами клиентам. В таких системах серверы и клиенты значительно отличаются друг от друга.
2. Архитектура распределенных объектов.
В этом случае между серверами и клиентами нет различий и систему можно представить как набор взаимодействующих объектов, местоположение которых не имеет особого значения. Между поставщиком сервисов и их пользователями не существует различий.
В распределенной системе разные системные компоненты могут быть реализованы на разных языках программирования и выполняться на разных типах процессоров. Модели данных, представление информации и протоколы взаимодействия – все это не обязательно будет однотипным в распределенной системе. Следовательно, для распределенных систем необходимо такое программное обеспечение, которое могло бы управлять этими разнотипными частями и гарантировать взаимодействие и обмен данными между ними. Промежуточное программное обеспечение
относится именно к такому классу ПО. Оно находится как бы посередине между разными частями распределенных компонентов системы.
В статье описаны различные типы промежуточного ПО, которое может поддерживать распределенные вычисления. Как правило, такое ПО составляется из готовых компонентов и не требует от разработчиков специальных доработок. В качестве примеров промежуточного ПО можно привести программы управления взаимодействием с базами данных, менеджеры транзакций, преобразователи данных, коммуникационные инспекторы и др. Далее в главе будет описана структура распределенных систем как класс промежуточного ПО.
Распределенные системы обычно разрабатываются на основе объектно-ориентированного подхода. Эти системы создаются из слабо интегрированных частей, каждая из которых может непосредственно взаимодействовать как с пользователем, так и с другими частями системы. Эти части по возможности должны реагировать на независимые события. Программные объекты, построенные на основе таких принципов, являются естественными компонентами распределенных систем. Если вы еще не знакомы с концепцией объектов, рекомендую сначала прочитать главу 12, а затем вновь вернуться к данной главе.
11.1. Многопроцессорная архитектура
Самой простой распределенной системой является многопроцессорная система. Она состоит из множества различных процессов, которые могут (но не обязательно) выполняться на разных процессорах. Данная модель часто используется в больших системах реального времени. Как вы узнаете из главы 13, эти системы собирают информацию, принимают на ее основе решения и отправляют сигналы исполнительному механизму, который изменяет системное окружение. В принципе все процессы, связанные со сбором информации, принятием решений и управлением исполнительным механизмом, могут выполняться на одном процессоре под управлением планировщика заданий. Использование нескольких процессоров повышает производительность системы и ее способность к восстановлению. Распределение процессов между процессорами может переопределяться (присуще критическим системам) или же находиться под управлением диспетчера процессов.
На рис. 11.1 показан пример системы такого типа. Это упрощенная модель системы управления транспортным потоком. Группа распределенных датчиков собирает информацию о величине потока. Собранные данные перед отправкой в диспетчерскую обрабатываются на месте. На основании полученной информации операторы принимают решения и управляют светофорами. В этом примере для управления датчиками, диспетчерской и светофорами имеются отдельные логические процессы. Это могут быть как отдельные процессы, так и группа процессов. В нашем примере они выполняются на разных процессорах.
Рис. 11.1. Многопроцессорная система управления движением транспорта
Системы ПО, одновременно выполняющие множество процессов, не обязательно являются распределенными. Если в системе более одного процессора, реализовать распределение процессов не представляет труда. Однако при создании многопроцессорных программных систем не обязательно отталкиваться только от распределенных систем. При проектировании систем такого типа, по существу, используется тот же подход, что и при проектировании систем реального времени, которые рассматриваются в главе 13.
11.2. Архитектура клиент/сервер
В главе 10 уже рассматривалась концепция клиент/сервер. В архитектуре клиент/сервер программное приложение моделируется как набор сервисов, предоставляемых серверами, и множество клиентов, использующих эти сервисы . Клиенты должны знать о доступных (имеющихся) серверах, хотя могут и не иметь представления о существовании других клиентов. Как видно из рис. 11.2, на котором представлена схема распределенной архитектуры клиент/сервер, клиенты и серверы представляют разные процессы.
Рис. 11.2. Система клиент/сервер
В системе между процессами и процессорами не обязательно должно соблюдаться отношение "один к одному". На рис. 11.3 показана физическая архитектура системы, которая состоит из шести клиентских машин и двух серверов. На них запускаются клиентские и серверные процессы, изображенные на рис. 11.2. В общем случае, говоря о клиентах и серверах, я подразумеваю скорее логические процессы, чем физические машины, на которых выполняются эти процессы.
Архитектура системы клиент/сервер должна отражать логическую структуру разрабатываемого программного приложения. На рис. 11.4 предлагается еще один взгляд на программное приложение, структурированное в виде трех уровней. Уровень представления обеспечивает информацию для пользователей и взаимодействие с ними. Уровень выполнения приложения реализует логику работы приложения. На уровне управления данными выполняются все операции с базами данных. В централизованных системах между этими уровнями нет четкого разделения. Однако при проектировании распределенных систем необходимо разделять эти уровни, чтобы затем расположить каждый уровень на разных компьютерах.
Самой простой архитектурой клиент/сервер является двухуровневая, в которой приложение состоит из сервера (или множества идентичных серверов) и группы клиентов. Существует два вида такой архитектуры (рис. 11.5).
1. Модель тонкого клиента.
В этой модели вся работа приложения и управление данными выполняются на сервере. На клиентской машине запускается только ПО уровня представления.
2. Модель толстого клиента.
В этой модели сервер только управляет данными. На клиентской машине реализована работа приложения и взаимодействие с пользователем системы.
Рис. 11.3. Компьютеры в сети клиент/сервер
Рис. 11.4. Уровни программного приложения
Тонкий клиент двухуровневой архитектуры – самый простой способ перевода существующих централизованных систем (см. главу 26) в архитектуру клиент/сервер. Пользовательский интерфейс в этих системах "переселяется" на персональный компьютер, а само программное приложение выполняет функции сервера, т.е. выполняет все процессы приложения и управляет данными. Модель тонкого клиента можно также реализовать там, где клиенты представляют собой обычные сетевые устройства, а не персональные компьютеры или рабочие станции. Сетевые устройства запускают Internet-броузер и пользовательский интерфейс, реализованный внутри системы.
Рис. 11.5. Модели тонкого и толстого клиентов
Главный недостаток модели тонкого клиента – большая загруженность сервера и сети. Все вычисления выполняются на сервере, а это может привести к значительному сетевому трафику между клиентом и сервером. В современных компьютерах достаточно вычислительной мощности, но она практически не используется в модели тонкого клиента банка.
Напротив, модель толстого клиента использует вычислительную мощность локальных машин: и уровень выполнения приложения, и уровень представления помещаются на клиентский компьютер. Сервер здесь, по существу, является сервером транзакций, который управляет всеми транзакциями баз данных. Примером архитектуры такого типа могут служить системы банкоматов, в которых банкомат является клиентом, а сервер – центральным компьютером, обслуживающим базу данных по расчетам с клиентами.
На рис. 11.6 показана сетевая система банкоматов. Заметим, что банкоматы связаны с базой данных расчетов не напрямую, а через монитор телеобработки. Этот монитор является промежуточным звеном, которое взаимодействует с удаленными клиентами и организует запросы клиентов в последовательность транзакций для работы с базой данных. Использование последовательных транзакций при возникновении сбоев позволяет системе восстановиться без потери данных.
Рис. 11.6. Система клиент/сервер для сети банкоматов
Поскольку в модели толстого клиента выполнение программного приложения организовано более эффективно, чем в модели тонкого клиента, управлять такой системой сложнее. Здесь функции приложения распределены между множеством разных машин. Необходимость замены приложения приводит к его повторной инсталляции на всех клиентских компьютерах, что требует больших расходов, если в системе сотни клиентов.
Появление языка Java и загружаемых аплетов позволили разрабатывать модели клиент/сервер, которые находятся где-то посередине между моделями тонкого и толстого клиента. Часть программ, составляющих приложение, можно загружать на клиентской машине как аплеты Java и тем самым разгрузить сервер. Интерфейс пользователя строится посредством Web-броузера, который запускает аплеты Java. Однако Web-броузеры от различных производителей и даже различные версии Web-броузеров от одного производителя не всегда выполняются одинаково. Более ранние версии броузеров на старых машинах не всегда могут запустить аплеты Java. Следовательно, такой подход можно использовать только тогда, когда вы уверены, что у всех пользователей системы установлены броузеры, совместимые с Java.
В двухуровневой модели клиент/сервер существенной проблемой является размещение на двух компьютерных системах трех логических уровней – представления, выполнения приложения и управления данными. Поэтому в данной модели часто возникают либо проблемы с масштабируемостью и производительностью, если выбрана модель тонкого клиента, либо проблемы, связанные с управлением системой, если используется модель толстого клиента. Чтобы избежать этих проблем, необходимо применить альтернативный подход – трехуровневую модель архитектуры клиент/сервер (рис. 11.7). В этой архитектуре уровням представления, выполнения приложения и управления данными соответствуют отдельные процессы.
Рис. 11.7. Трехуровневая архитектура клиент/сервер
Архитектура ПО, построенная по трехуровневой модели клиент/сервер, не требует, чтобы в сеть были объединены три компьютерных системы. На одном компьютере-сервере можно запустить и выполнение приложения, и управление данными как отдельные логические серверы. В то же время, если требования к системе возрастут, можно будет относительно просто разделить выполнение приложения и управление данными и выполнять их на разных процессорах.
Банковскую систему, использующую Internet-сервисы, можно реализовать с помощью трехуровневой архитектуры клиент/сервер. База данных расчетов (обычно расположенная на главном компьютере) предоставляет сервисы управления данными, Web-сервер поддерживает сервисы приложения, например средства перевода денег, генерацию отчетов, оплату счетов и др. А компьютер пользователя с Internet-броузером является клиентом. Как показано на рис. 11.8, эта система масштабируема, так как в нее относительно просто добавить новые Web-серверы при увеличении количества клиентов.
Использование трехуровневой архитектуры в этом примере позволило оптимизировать передачу данных между Web-сервером и сервером базы данных. Взаимодействие между этими системами не обязательно строить на стандартах Internet, можно использовать более быстрые коммуникационные протоколы низкого уровня. Обычно информацию от базы данных обрабатывает эффективное промежуточное ПО, которое поддерживает запросы к базе данных на языке структурированных запросов SQL.
В некоторых случаях трехуровневую модель клиент/сервер можно перевести в многоуровневую, добавив в систему дополнительные серверы. Многоуровневые системы можно использовать и там, где приложениям необходимо иметь доступ к информации, находящейся в разных базах данных. В этом случае объединяющий сервер располагается между сервером, на котором выполняется приложение, и серверами баз данных. Объединяющий сервер собирает распределенные данные и представляет их в приложении таким образом, будто они находятся в одной базе данных.
Рис. 11.8. Распределенная архитектура банковской системы с использованием
Internet
-сервисов
Разработчики архитектур клиент/сервер, выбирая наиболее подходящую, должны учитывать ряд факторов. В табл. 11.2 перечислены различные случаи применения архитектуры клиент/сервер.
Таблица 11.2. Применение разных типов архитектуры клиент/сервер
| Архитектура | Приложения |
| Двухуровневая архитектура тонкого клиента | Наследуемые системы, в которых нецелесообразно разделять выполнение приложения и управления данными. |
| Приложения с интенсивными вычислениями, например компиляторы, но с незначительным объемом управления данными. |
|
| Приложения, в которых обрабатываются большие массивы данных (запросы), но с небольшим объемом вычислений в самом приложении |
|
| Двухуровневая архитектура толстого клиента | Приложения, где пользователю требуется интенсивная обработка данных (например, визуализация данных или большие объемы вычисления). |
| Приложения с относительно постоянным набором функций на стороне пользователя, применяемых в среде с хорошо отлаженным системным управлением |
11.3. Архитектура распределенных объектов
В модели клиент/сервер распределенной системы между клиентами и серверами существуют различия. Клиент запрашивает сервисы только у сервера, hq не у других клиентов; серверы могут функционировать как клиенты и запрашивать сервисы у других серверов, но не у клиентов; клиенты должны знать о сервисах, предоставляемых определенными серверами, и о том, как взаимодействуют эти серверы. Такая модель отлично подходит ко многим типам приложений, но в то же время ограничивает разработчиков системы, которые вынуждены решать, где предоставлять сервисы. Они также должны обеспечить поддержку масштабируемости и разработать средства включения клиентов в систему на распределенных серверах.
Более общим подходом, применяемым в проектировании распределенных систем, является стирание различий между клиентом и сервером и проектирование архитектуры системы как архитектуры распределенных объектов. В этой архитектуре (рис. 11.9) основными компонентами системы являются объекты, предоставляющие набор сервисов через свои интерфейсы. Другие объекты вызывают эти сервисы, не делая различий между клиентом (пользователем сервиса) и сервером (поставщиком сервиса).
Рис. 11.9. Архитектура распределенных объектов
Объекты могут располагаться на разных компьютерах в сети и взаимодействовать посредством промежуточного ПО. По аналогии с системной шиной, которая позволяет подключать различные устройства и поддерживать взаимодействие между аппаратными средствами, промежуточное ПО можно рассматривать как шину программного обеспечения. Она предоставляет набор сервисов, позволяющий объектам взаимодействовать друг с другом, добавлять или удалять их из системы. Промежуточное ПО называют брокером запросов к объектам. Его задача – обеспечивать интерфейс между объектами. Брокеры запросов к объектам рассматриваются в разделе 11.4.
Ниже перечислены основные преимущества модели архитектуры распределенных объектов.
Разработчики системы могут не спешить с принятием решений относительно того, где и как будут предоставляться сервисы. Объекты, предоставляющие сервисы, могут выполняться в любом месте (узле) сети. Следовательно, различие между моделями толстого и тонкого клиентов становятся несущественными, так как нет необходимости заранее планировать размещение объектов для выполнения приложения.
Системная архитектура достаточно открыта, что позволяет при необходимости добавлять в систему новые ресурсы. В следующем разделе отмечается, что стандарты программной шины постоянно совершенствуются, что позволяет объектам, написанным на разных языках программирования, взаимодействовать и предоставлять сервисы друг другу.
Гибкость и масштабируемость системы. Для того чтобы справиться с системными нагрузками, можно создавать экземпляры системы с одинаковыми сервисами, которые будут предоставляться разными объектами или разными экземплярами (копиями) объектов. При увеличении нагрузки в систему можно добавить новые объекты, не прерывая при этом работу других ее объектов.
Существует возможность динамически переконфигурировать систему посредством объектов, мигрирующих в сети по запросам. Объекты, предоставляющие сервисы, могут мигрировать на тот же процессор, что и объекты, запрашивающие сервисы, тем самым повышая производительность системы.
В процессе проектирования систем архитектуру распределенных объектов можно использовать двояко.
1. В виде логической модели, которая позволяет разработчикам структурировать и спланировать систему. В этом случае функциональность приложения описывается только в терминах и комбинациях сервисов. Затем разрабатываются способы предоставления сервисов с помощью нескольких распределенных объектов. На этом уровне, как правило, проектируют крупномодульные объекты, которые предоставляют сервисы, отражающие специфику конкретной области приложения. Например, в программу учета розничной торговли можно включить объекты, которые бы вели учет состояния запасов, отслеживали взаимодействие с клиентами, классифицировали товары и др.
2. Как гибкий подход к реализации систем клиент/сервер. В этом случае логическая модель системы – это модель клиент/сервер, в которой клиенты и серверы реализованы как распределенные объекты, взаимодействующие посредством программной шины. При таком подходе легко заменить систему, например двухуровневую на многоуровневую. В этом случае ни сервер, ни клиент не могут быть реализованы в одном объекте, однако могут состоять из множества небольших объектов, каждый из которых предоставляет определенный сервис.
Примером системы, которой подходит архитектура распределенных объектов, может служить система обработки данных, хранящихся в разных базах данных (рис. 11.10). В этом примере любую базу данных можно представить как объект с интерфейсом, предоставляющим доступ к данным "только чтение". Каждый из объектов-интеграторов занимается определенными типами зависимостей между данными, собирая информацию из баз данных, чтобы попытаться проследить эти зависимости.
Объекты-визуализаторы взаимодействуют с объектами-интеграторами для представления данных в графическом виде либо для составления отчетов по анализируемым данным. Способы представление графической информации рассматриваются в главе 15.
Рис. 11.10. Архитектура распределенной системы обработки данных
Для такого типа приложений архитектура распределенных объектов подходит больше, чем архитектура клиент/сервер, по трем причинам.
1. В этих системах (в отличие, например, от системы банкоматов) нет одного поставщика сервиса, на котором были бы сосредоточены все сервисы управления данными.
2. Можно увеличивать количество доступных баз данных, не прерывая работу системы, поскольку каждая база данных представляет собой просто объект. Эти объекты поддерживают упрощенный интерфейс, который управляет доступом к данным. Доступные базы данных можно разместить на разных машинах.
3. Посредством добавления новых объектов-интеграторов можно отслеживать новые типы зависимостей между данными.
Главным недостатком архитектур распределенных объектов является то, что их сложнее проектировать, чем системы клиент/сервер. Оказывается, что системы клиент/сервер предоставляют более естественный подход к созданию распределенных систем. В нем отражаются взаимоотношения между людьми, при которых одни люди пользуются услугами других людей, специализирующихся на предоставлении конкретных услуг. Намного труднее разработать систему в соответствии с архитектурой распределенных объектов, поскольку индустрия создания ПО пока еще не накопила достаточного опыта в проектировании и разработке крупномодульных объектов.
11.4. CORBA
Как уже отмечалось в предыдущем разделе, при реализации архитектуры распределенных объектов необходимо промежуточное программное обеспечение (брокеры запросов к объектам), организующее взаимодействие между распределенными объектами. Здесь могут возникнуть определенные проблемы, поскольку объекты в системе могут быть реализованы на разных языках программирования, могут запускаться на разных платформах и их имена не должны быть известны всем другим объектам системы. Поэтому промежуточное ПО должно выполнять большую работу для того, чтобы поддерживалось постоянное взаимодействие объектов.
В настоящий момент для поддержки распределенных объектных вычислений существует два основных стандарта промежуточного ПО.
1. CORBA (Common Object Request Broker Architecture– архитектура брокеров запросов к общим объектам). Это набор стандартов для промежуточного ПО, разработанный группой OMG (Object Management Group – группа по управлению объектами). OMG является консорциумом фирм-производителей программного и аппаратного обеспечения, в числе которых такие компании, как Sun, Hewlett-Packard и IBM. Стандарты CORBA определяют общий машинонезависимый подход к распределенным объектным вычислениям. Разными производителями разработано множество реализаций этого стандарта. Стандарты CORBA поддерживаются операционной системой Unix и операционными системами от Microsoft.
2. DCOM (Distributed Component Object Model – объектная модель распределенных компонентов). DCOM представляет собой стандарт, разработанный и реализованный компанией Microsoft и интегрированный в ее операционные системы. Данная модель распределенных вычислений менее универсальна, чем CORBA и предлагает более ограниченные возможности сетевых взаимодействий. В настоящий момент использование DCOM ограничивается операционными системами Microsoft.
Здесь я решил уделить внимание технологии CORBA, поскольку она более универсальна. Кроме того, я считаю, что, вероятно, CORBA, DCOM и другие технологии, например RMI (Remote Method Invocation – вызов удаленного метода, технология построения распределенных приложений на языке Java), будут постепенно сближаться друг с другом и это сближение будет базироваться на стандартах CORBA. Поэтому нет необходимости в еще одном стандарте. Различные стандарты будут только помехой в дальнейшем развитии.
Стандарты CORBA определены группой OMG, которая объединяет более 500 компаний, поддерживающих объектно-ориентированные разработки. Роль OMG – создание стандартов для объектно-ориентированных разработок, а не обеспечение конкретных реализаций этих стандартов. Эти стандарты находятся в свободном доступе на Web-узле OMG. Группа занимается не только стандартами CORBA, но также определяет широкий диапазон других стандартов, включая язык моделирования UML.
Представление распределенных приложений в рамках CORBA показано на рис. 11.11. Это упрощенная схема архитектуры управления объектами, взятая из статьи . Предполагается, что распределенное приложение должно состоять из перечисленных ниже компонентов.
1. Объекты приложения, которые созданы и разработаны для данного программного продукта.
2. Стандартные объекты, которые определены группой OMG для специфических задач. Во время написания книги множество специалистов занимались разработкой стандартов объектов в области финансирования, страхования, электронной коммерции, здравоохранения и многих других.
3. Основные сервисы CORBA, поддерживающие базовые сервисы распределенных вычислений, например каталоги, управление защитой и др.
4. Горизонтальные средства CORBA, например пользовательские интерфейсы, средства управления системой и т.п. Под горизонтальными подразумеваются средства, общие для многих приложений.
Рис. 11.11. Структура распределенного приложения, основанного на стандартах
CORBA
Стандарты CORBA описывают четыре основных элемента.
1. Модель объектов, в которой объект CORBA инкапсулирует состояния посредством четкого описания на языке IDL (Interface Definition Language – язык описания интерфейсов).
2. Брокер запросов к объектам (Object Request Broker– ORB), который управляет запросами к сервисам объектов. ORB размещает объекты, предоставляющие сервисы, подготавливает их к получению запросов, передает запрос к сервису и возвращает результаты объекту, сделавшему запрос.
3. Совокупность сервисов объектов, которые являются основными сервисами, и необходимы во многих распределенных приложениях. Примерами могут быть службы каталогов, сервисы транзакций и сервисы поддержки временных объектов.
4. Совокупность общих компонентов, построенных на верхнем уровне основных сервисов. Они могут быть как вертикальными, отражающими специфику конкретной области, так и горизонтальными универсальными компонентами, используемыми во многих программных приложениях. Эти компоненты рассматриваются в главе 14.
В модели CORBA объект инкапсулирует атрибуты и сервисы как обычный объект. Вместе с тем в объектах CORBA еще должно содержаться определение различных интерфейсов, описывающих глобальные атрибуты и операции объекта. Интерфейсы объектов CORBA определяются на стандартном универсальном языке описания интерфейсов IDL. Если один объект запрашивает сервисы, предоставляемые другими объектами, он получает доступ к этим сервисам через IDL-интерфейс. Объекты CORBA имеют уникальный идентификатор, называемый IOR (Interoperable Object Reference – ссылка на взаимодействующий объект). Когда один объект отправляет запросы к сервису, предоставляемому другим объектом, используется идентификатор IOR.
Брокеру запросов к объектам известны объекты, запрашивающие сервисы и их интерфейсы. Он организует взаимодействие между объектами. Взаимодействующим объектам не требуется что-либо знать о размещении других объектов, а также об их реализации. Так как интерфейс IDL отделяет объекты от брокера, реализацию объектов можно изменять, не затрагивая другие компоненты системы.
На рис. 11.12 показано, как объекты ol и о2 взаимодействуют посредством брокера запросов к объектам. Вызывающий объект (ol) связан с заглушкой (stub) IDL, которая определяет интерфейс объекта, предоставляющего сервис. Конструктор объекта ol при запросе к сервису внедряет вызовы в заглушку своей реализации объекта. Язык IDL является расширением C++, поэтому, если вы программируете на языках C++, С или Java, получить доступ к заглушке совсем просто. Перевод описания интерфейса объекта на IDL также возможен и для других языков, например Ada или COBOL. Но в этих случаях необходима соответствующая инструментальная поддержка.
Рис. 11.12. Взаимодействие объектов посредством брокера запросов к объектам
Объект, предоставляющий сервис, связан с остовом (skeleton) IDL, который связывает интерфейс с реализацией сервисов. Иными словами, когда сервис вызывается через интерфейс, остов IDL транслирует вызов к сервису независимо от того, какой язык использовался в реализации. После завершения метода или процедуры остов транслирует результаты в язык IDL, так что они становятся доступными вызывающему объекту. Если объект одновременно предоставляет сервисы другим объектам или использует сервисы, которые предоставлены еще где-то, ему требуются и остов IDL, и заглушка IDL. Последняя необходима всем используемым объектам.
Брокер запросов к объектам обычно реализуется не в виде отдельных процессов, а как каркас (см. главу 14), который связан с реализацией объектов. Поэтому в распределенной системе каждый компьютер, на котором работают объекты, должен иметь собственный брокер запросов к объектам, который будет обрабатывать все локальные вызовы объектов. Но если запрос сделан к сервису, который предоставлен удаленным объектом, требуется взаимодействие между брокерами.
Такая ситуация проиллюстрирована на рис. 11.13. В данном примере, если объект ol или о2 отправляет запросы к сервисам, предоставляемым объектами о3 или о4, то необходимо взаимодействие связанных с этими объектами брокеров. Стандарты CORBA поддерживают взаимодействие "брокер-брокер", которое обеспечивает брокерам доступ к описаниям интерфейсов IDL, и предлагают разработанный группой OMG стандарт обобщенного протокола взаимодействия брокеров GIOP (Generic Inter-ORB Protocol). Данный протокол определяет стандартные сообщения, которыми могут обмениваться брокеры при выполнении вызовов удаленного объекта и передаче информации. В сочетании с протоколом Internet низкого уровня TCP/IP этот протокол позволяет брокерам взаимодействовать через Internet.
Первые варианты CORBA были разработаны еще в 1980-х годах. Ранние версии CORBA просто были связаны с поддержкой распределенных объектов. Однако со временем стандарты развивались, становились более расширенными. Подобно механизмам взаимодействия распределенных объектов, стандарты CORBA сейчас определяют некоторые стандартные сервисы, которые можно использовать для поддержки объектно-ориентированных приложений.
Рис. 11.13. Взаимодействие между брокерами запросов к объектам
Сервисы CORBA являются средствами, которые необходимы во многих распределенных системах. Эти стандарты определяют примерно 15 общих служб (сервисов). Вот некоторые из них.
1. Служба имен, которая позволяет объектам находить другие объекты в сети и ссылаться на них. Служба имен является сервисом каталогов, который присваивает имена объектам. При необходимости объекты через эту службу могут находить идентификаторы IOR других объектов.
2. Служба регистрации, которая позволяет объектам регистрировать другие объекты после совершения некоторых событий. С помощью этой службы объекты можно регистрировать по их участию в определенном событии, а когда данное событие уже произошло, оно автоматически регистрируется сервисом.
3. Служба транзакций, которая поддерживает элементарные транзакции и откат назад в случае ошибок или сбоев. Эта служба является отказоустойчивым средством (см. главу 18), обеспечивающим восстановление в случае ошибок во время операции обновления. Если действия по обновлению объекта приведут к ошибкам или сбою системы, данный объект всегда можно вернуть назад к тому состоянию, которое было перед началом обновления.
Считается, что стандарты CORBA должны содержать определения интерфейсов для широкого диапазона компонентов, которые могут использоваться при построении распределенных приложений. Эти компоненты могут быть вертикальными или горизонтальными. Вертикальные компоненты разрабатываются специально для конкретных приложений. Как уже отмечалось, разработкой определений этих компонентов занято множество специалистов из различных сфер деятельности. Горизонтальные компоненты универсальны, например компоненты пользовательского интерфейса.
Во время написания этой книги спецификации компонентов были уже разработаны, но еще не согласованы. С моей точки зрения, вероятно, именно здесь наиболее слабое место стандартов CORBA, и, возможно, потребуется несколько лет, чтобы достичь того, что в наличии будут и спецификации, и реализации компонентов.
КЛЮЧЕВЫЕ ПОНЯТИЯ
Все большие системы в
той или иной степени являются распределенными, в которых программные компоненты выполняются на интегрированной в сеть группе процессоров.
Распределенным системам присущи следующие черты: использование ресурсов, открытость, параллельность, масштабируемость, устойчивость к ошибкам и прозрачность.
Системы клиент/сервер являются распределенными. Такие системы моделируются как набор сервисов, предоставляемых сервером клиентским процессам.
В системе клиент/сервер интерфейс пользователя на стороне клиента, а управление данными всегда поддерживается на разделяемом сервере. Функции приложения могут быть реализованы на клиентском компьютере или на сервере.
В архитектуре распределенных объектов нет различий между клиентами и серверами. Объекты предоставляют основные сервисы, которые могут вызывать другие объекты. Такой же подход можно использовать в реализации систем клиент/сервер.
В системах распределенных объектов должно быть промежуточное программное обеспечение, предназначенное для обработки взаимодействий между объектами, а также добавления или удаления объектов из системы. Концептуально промежуточное ПО можно представить как программную шину, к которой подключены объекты.
Стандарты CORBA представляют собой набор стандартов для промежуточного ПО, поддерживающего архитектуру распределенных объектов. К ним относятся определения модели объектов, брокера запросов к объектам и общих сервисов. В настоящее время существует несколько реализаций стандартов CORBA.
Упражнения
11.1.
Объясните, почему распределенные системы всегда более масштабируемы, чем централизованные. Какой вероятный предел масштабируемости программных систем?
11.2. В чем основное отличие между моделями толстого и тонкого клиента в разработке систем клиент/сервер? Объясните, почему использование Java как языка реализации сглаживает различия между этими моделями?
11.3. На основе модели приложения, изображенной на рис. 11.4, рассмотрите возможные проблемы, которые могут возникнуть при преобразовании системы 1980-х годов, реализованной на мейнфрейме и предназначенной для работы в сфере здравоохранения, в систему архитектуры клиент/сервер.
11.4. Распределенные системы, базирующиеся на модели клиент/сервер, разрабатывались с 1980-х годов, но только недавно такие системы, основанные на распределенных объектах, были реализованы. Приведите три причины, почему так получилось.
11.5. Объясните, почему использование распределенных объектов совместно с брокером запросов к объектам упрощает реализацию масштабируемых систем клиент/сервер. Проиллюстрируйте свой ответ примером.
11.6. Каким образом используется язык IDL для поддержки взаимодействия между объектами, реализованными на разных языках программирования? Объясните, почему такой подход может вызвать проблемы, связанные с производительностью, если между языками, которые используются при реализации объектов, имеются радикальные различия.
11.7. Какие базовые средства должен предоставлять брокер запросов к объектам?
11.8. Можно показать, что разработка стандартов CORBA для горизонтальных и вертикальных компонентов ограничивает конкуренцию. Если они уже созданы и адаптированы, это препятствует разработке лучших компонентов более мелкими компаниями. Обсудите роль стандартизации в поддержке или ограничении конкуренции на рынке программного обеспечения.
По утверждению известного специалиста в области информатики Э. Таненбаума, не существует общепринятого и в то же время строгого определения распределенной системы. Некоторые остряки утверждают, что распределенной является такая вычислительная система , в которой неисправность компьютера, о существовании которого пользователи ранее даже не подозревали, приводит к остановке всей их работы. Значительная часть распределенных вычислительных систем, к сожалению, удовлетворяют такому определению, однако формально оно относится только к системам с уникальной точкой уязвимости (single point of failure ).Часто при определении распределенной системы во главу угла ставят разделение ее функций между несколькими компьютерами. При таком подходе распределенной является любая вычислительная система , где обработка данных разделена между двумя и более компьютерами. Основываясь на определении Э. Таненбаума, несколько более узко распределенную систему можно определить как набор соединенных каналами связи независимых компьютеров, которые с точки зрения пользователя некоторого программного обеспечения выглядят единым целым.
Такой подход к определению распределенной системы имеет свои недостатки. Например, все используемое в такой распределенной системе программное обеспечение могло бы работать и на одном единственном компьютере, однако с точки зрения приведенного выше определения такая система уже перестанет быть распределенной. Поэтому понятие распределенной системы, вероятно, должно основываться на анализе образующего такую систему программного обеспечения.
Как основу описания взаимодействия двух сущностей рассмотрим общую модель взаимодействия клиент- сервер , в которой одна из сторон (клиент) инициирует обмен данными, посылая запрос другой стороне (серверу). Сервер обрабатывает запрос и при необходимости посылает ответ клиенту (рис. 1.1).
Рис.
1.1.
Взаимодействие в рамках модели клиент сервер может быть как синхронным, когда клиент ожидает завершения обработки своего запроса сервером, так и асинхронным, при котором клиент посылает серверу запрос и продолжает свое выполнение без ожидания ответа сервера. Модель клиента и сервера может использоваться как основа описания различных взаимодействий. Для данного курса важно взаимодействие составных частей программного обеспечения, образующего распределенную систему.
Рис. 1.2.
Рассмотрим некое типичное приложение , которое в соответствии с современными представлениями может быть разделено на следующие логические уровни (рис. 1.2): пользовательский интерфейс (ИП), логика приложения (ЛП) и доступ к данным (ДД), работающий с базой данных ( БД ). Пользователь системы взаимодействует с ней через интерфейс пользователя, база данных хранит данные, описывающие предметную область приложения, а уровень логики приложения реализует все алгоритмы, относящиеся к предметной области .
Поскольку на практике разных пользователей системы обычно интересует доступ к одним и тем же данным, наиболее простым разнесением функций такой системы между несколькими компьютерами будет разделение логических уровней приложения между одной серверной частью приложения, отвечающим за доступ к данным, и находящимися на нескольких компьютерах клиентскими частями, реализующими интерфейс пользователя. Логика приложения может быть отнесена к серверу, клиентам, или разделена между ними (рис. 1.3).
Рис. 1.3.
Архитектуру построенных по такому принципу приложений называют клиент серверной или двухзвенной. На практике подобные системы часто не относят к классу распределенных, но формально они могут считаться простейшими представителями распределенных систем.
Развитием архитектуры клиент- сервер является трехзвенная архитектура , в которой интерфейс пользователя, логика приложения и доступ к данным выделены в самостоятельные составляющие системы, которые могут работать на независимых компьютерах (рис. 1.4).
Рис. 1.4.
Запрос пользователя в подобных системах последовательно обрабатывается клиентской частью системы, сервером логики приложения и сервером баз данных. Однако обычно под распределенной системой понимают системы с более сложной архитектурой, чем трехзвенная.
(Материал сайта http://se.math.spbu.ru)
Введение.
В настоящее время практически все большие программные системы являются распределенными. Распределенная система - система, в которой обработка информации сосредоточена не на одной вычислительной машине, а распределена между несколькими компьютерами. При проектировании распределенных систем, которое имеет много общего с проектированием ПО в общем, все же следует учитывать некоторые специфические особенности.
Существует шесть основных характеристик распределенных систем.
- Совместное использование ресурсов. Распределенные системы допускают совместное использование как аппаратных (жестких дисков, принтеров), так и программных (файлов, компиляторов) ресурсов.
- Открытость. Это возможность расширения системы путем добавления новых ресурсов.
- Параллельность. В распределенных системах несколько процессов могут одновременно выполнятся на разных компьютерах в сети. Эти процессы могут взаимодействовать во время их выполнения.
- Масштабируемость . Под масштабируемостью понимается возможность добавления новых свойств и методов.
- Отказоустойчивость. Наличие нескольких компьютеров позволяет дублирование информации и устойчивость к некоторым аппаратным и программным ошибкам. Распределенные системы в случае ошибки могут поддерживать частичную функциональность. Полный сбой в работе системы происходит только при сетевых ошибках.
- Прозрачность. Пользователям предоставляется полный доступ к ресурсам в системе, в то же время от них скрыта информация о распределении ресурсов по системе.
Распределенные системы обладают и рядом недостатков.
- Сложность . Намного труднее понять и оценить свойства распределенных систем в целом, их сложнее проектировать, тестировать и обслуживать. Также производительность системы зависит от скорости работы сети, а не отдельных процессоров. Перераспределение ресурсов может существенно изменить скорость работы системы.
- Безопасность . Обычно доступ к системе можно получить с нескольких разных машин, сообщения в сети могут просматриваться и перехватываться. Поэтому в распределенной системе намного труднее поддерживать безопасность.
- Управляемость . Система может состоять из разнотипных компьютеров, на которых могут быть установлены различные версии операционных систем. Ошибки на одной машине могут распространиться непредсказуемым образом на другие машины.
- Непредсказуемость . Реакция распределенных систем на некоторые события непредсказуема и зависит от полной загрузки системы, ее организации и сетевой нагрузки. Так как эти параметры могут постоянно изменятся , поэтому время ответа на запрос может существенно отличаться от времени.
Из этих недостатков можно увидеть, что при проектировании распределенных систем возникает ряд проблем, которые надо учитывать разработчикам.
- Идентификация ресурсов . Ресурсы в распределенных системах располагаются на разных компьютерах, поэтому систему имен ресурсов следует продумать так, чтобы пользователи могли без труда открывать необходимые им ресурсы и ссылаться на них. Примером может служить система URL(унифицированный указатель ресурсов), которая определяет имена Web-страниц.
- Коммуникация . Универсальная работоспособность Internet и эффективная реализация протоколов TCP/IP в Internet для большинства распределенных систем служат примером наиболее эффективного способа организации взаимодействия между компьютерами. Однако в некоторых случаях, когда требуется особая производительность или надежность, возможно использование специализированных средств.
- Качество системного сервиса . Этот параметр отражает производительность, работоспособность и надежность. На качество сервиса влияет ряд факторов: распределение процессов, ресурсов, аппаратные средства и возможности адаптации системы.
- Архитектура программного обеспечения . Архитектура ПО описывает распределение системных функций по компонентам системы, а также распределение этих компонентов по процессорам. Если необходимо поддерживать высокое качество системного сервиса, выбор правильной архитектуры является решающим фактором.
Задача разработчиков распределенных систем - спроектировать программное и аппаратное обеспечение так, чтобы предоставить все необходимые характеристики распределенной системы. А для этого требуется знать преимущества и недостатки различных архитектур распределенных систем. Выделяется три типа архитектур распределенных систем.
- Архитектура клиент/сервер . В этой модели систему можно представить как набор сервисов, предоставляемых серверами клиентам. В таких системах серверы и клиенты значительно отличаются друг от друга.
- Трехзвенная архитектура . В этой модели сервер предоставляет клиентам сервисы не напрямую, а посредством сервера бизнес-логики .
Про первые две модели было сказано уже не раз, остановимся подробнее на третьей.
- Архитектура распределенных объектов . В этом случае между серверами и клиентами нет различий и систему можно представить как набор взаимодействующих объектов, местоположение которых не имеет особого значения. Между поставщиком сервисов и их пользователями не существует различий.
Эта архитектура широко применяется в настоящее время и носит также название архитектуры веб-сервисов . Веб-сервис - это приложение, доступное через Internet и предоставляющее некоторые услуги, форма которых не зависит от поставщика (так как используется универсальный формат данных - XML) и платформы функционирования. В данное время существует три различные технологии, поддерживающие концепцию распределенных объектных систем. Это технологии EJB, CORBA и DCOM.
Для начала несколько слов о том, что такое XML вообще. XML - универсальный формат данных, который используется для предоставления Web-сервисов. В основе Web-сервисов лежат открытые стандарты и протоколы: SOAP, UDDI и WSDL.
- SOAP (Simple Object Access Protocol ), разработанный консорциумом W3C, определяет формат запросов к Web-сервисам. Сообщения между Web-сервисом и его пользователем пакуются в так называемые SOAP-конверты (SOAP envelopes , иногда их ещё называют XML-конвертами). Само сообщение может содержать либо запрос на осуществление какого-либо действия, либо ответ - результат выполнения этого действия.
- WSDL (Web Service Description Language). Интерфейс Web-сервиса описывается в WSDL-документах (а WSDL - это подмножество XML). Перед развертыванием службы разработчик составляет ее описание на языке WSDL, указывает адрес Web-сервиса, поддерживаемые протоколы, перечень допустимых операций, форматы запросов и ответов.
- UDDI (Universal Description, Discovery and Integration) - протокол поиска Web- сервисов в Internet (http://www.uddi.org/ ). Представляет собой бизнес-реестр, в котором провайдеры Web-сервисов регистрируют службы, а разработчики находят необходимые сервисы для включения в свои приложения.
Из доклада может показаться, что Web-сервисы - наилучшее и безальтернативное решение, и вопрос только в выборе средств разработки. Однако это не так. Альтернатива Web-службам существует, это семантический Web (Semantic Web ), о необходимости создания которого уже пять лет назад говорил создатель WWW Тим Бернерс-Ли .
Если задача Web-сервисов - облегчить коммуникацию между приложениями, то семантический Web призван решить гораздо более сложную проблему - с помощью механизмов метаданных повысить эффективность ценность информации, которую можно найти в Сети. Сделать это можно, отказавшись от документно-ориентированного подхода в пользу объектно-ориентированного.
Список литературы
- Соммервилл И. Инженерия программного обеспечения.
- Драница А. Java против.NET. - "Компьютерра ", #516.
- Ресурсы интернет.
