Введение

Все файлы к данному курсу Вы можете скачать здесь.

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

Информационные системы окружают нас повсюду, область их применения постоянно расширяется, а сами они становятся все более и более сложными. Некоторые системы вырастают и усложняются настолько, что приобретают глобальный характер, и от их правильного и надежного функционирования начинает зависеть деятельность десятков или даже сотен тысяч людей. В силу своей "глобальности" (нужно обеспечить доступ к системе из территориально разнесенных между собой точек), а также в силу ряда других причин такие системы часто имеют очень сложную архитектуру, предполагающую их функционирование в виде набора компонентов, каждый из которых выполняется на отдельном узле. Поскольку число таких систем постоянно возрастает, требования, предъявляемые к ним, достаточно серьезны, сложность проектирования и разработки таких систем высока, а методы и средства, применяемые при реализации таких проектов, отличны от принятых при разработке "монолитных" систем - существует необходимость в специализированных курсах. Следует отметить, что на распределенные системы и обработку распределенной информации направлено значительное внимание в последние несколько лет, и почти каждый университет предлагает по крайней мере один курс по разработке распределенных алгоритмов. Существует большое число книг о принципах построения распределенных систем, в том числе считающийся классическим учебник [1].

Далее, используя термин "распределенная система", мы будем подразумевать взаимосвязанный набор автономных компьютеров, процессов или процессоров. Компьютеры, процессы или процессоры будут упоминаться как узлы распределенной системы. Будучи определенными как автономные, узлы должны быть, по крайней мере, оборудованы своим собственным блоком управления. Таким образом, параллельный компьютер с одним потоком управления и несколькими потоками данных ( SIMD ) не подпадает под определение распределенной системы. Чтобы быть определенными как взаимосвязанные, узлы должны иметь возможность обмениваться информацией.

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

Более ограничивающие определения распределенных систем могут быть также найдены в литературе. Tanenbaum [1], например, называет систему распределенной, только если существуют автономные узлы, прозрачные для пользователей системы. Распределенная система в этом смысле ведет себя как виртуальная самостоятельная компьютерная система, но реализация этой прозрачности требует разработки замысловатых алгоритмов распределенного управления.

Экскурс в историю

Не следует думать, что распределенные системы - изобретение последних лет.

Два-три десятилетия назад при построении информационных систем популярной была модель "хост-компьютер + терминалы", реализованная на базе мэйнфреймов (например, IBM-360/370 или их отечественных аналогов - компьютеров серии ЕС ЭВМ), либо на базе так называемых мини- ЭВМ (например, PDP-11, также имевших отечественный аналог - СМ-4 ). Характерной особенностью такой системы была полная "неинтеллектуальность" терминалов, используемых в качестве рабочих мест, - их работой управлял все тот же хост-компьютер.

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

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

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

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

Концепция слоев (уровней, layers ) - одна из общеупотребительных моделей, используемых разработчиками программного обеспечения для разделения сложных систем на более простые части. В архитектурах компьютерных систем, например, различают слои кода на языке программирования, функций операционной системы, драйверов устройств, наборов инструкций центрального процессора и внутренней логики чипов. В среде сетевого взаимодействия протокол FTP работает на основе протокола TCP, который, в свою очередь, функционирует "поверх" протокола IP, расположенного "над" протоколом Ethernet.

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

Расчленение системы на слои предоставляет целый ряд преимуществ.

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

Схема расслоения обладает и определенными недостатками.

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

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

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

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

С появлением Web всем внезапно захотелось иметь системы "клиент/сервер", где в роли клиента выступал бы Web -браузер. Появившиеся инструментальные средства конструирования Web -страниц были в меньшей степени связаны с SQL и потому более подходили для реализации третьего уровня.

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