close

Вход

Забыли?

вход по аккаунту

?

KuchinMolchanov

код для вставкиСкачать
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ
Федеральное государственное автономное
образовательное учреждение высшего образования
САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ
АЭРОКОСМИЧЕСКОГО ПРИБОРОСТРОЕНИЯ
Н. В. Кучин, А. Ю. Молчанов
МНОГОУРОВНЕВЫЕ СИСТЕМЫ
И ОБЛАЧНЫЕ ВЫЧИСЛЕНИЯ
Учебное пособие
УДК 004.771
ББК 32.973
К95
Рецензенты:
кандидат технических наук, доцент М. А. Волохов;
кандидат технических наук, доцент Б. А. Кац
Утверждено
редакционно-издательским советом университета
в качестве учебного пособия
Кучин, Н. В.
К95 Многоуровневые системы и облачные вычисления: учеб. пособие / Н. В. Кучин, А. Ю. Молчанов. – СПб.: ГУАП, 2018. – 135 с.
ISBN 978-5-8088-1250-5
Содержит описание принципов организации распределенных
вычислений и простейших методов их реализации в вычислительных системах. Подробно рассматриваются вопросы использования
различных технологий при проектировании распределенного программного обеспечения в локальных и глобальных вычислительных
сетях. Особо выделены вопросы, связанные с описанием различных
технологий, используемых при организации облачных вычислений.
Для каждой приведенной в пособии технологии дается подробный
анализ ее достоинств и недостатков.
Предназначено для студентов, обучающихся по направлению
«Информатика и вычислительная техника».
УДК 004.771
ББК 32.973
ISBN 978-5-8088-1250-5
©
©
Кучин Н. В., Молчанов А. Ю., 2018
Санкт-Петербургский государственный
университет аэрокосмического
приборостроения, 2018
ВВЕДЕНИЕ
С развитием рынка информационных технологий появился новый термин – облачные вычисления.
Он часто употребляется и в специализированной литературе,
и во многих популярных статьях, рассчитанных на неискушенного читателя. При этом авторы различных статей и публикаций не
всегда должным образом информируют своих читателей о том, что
представляют собой облачные вычисления или «IT-облака».
Следует отметить, что по своей сути облачные вычисления – это
всего лишь множество специализированных способов предоставления вычислительных ресурсов, а не какая-то принципиально
новая технология. Тем не менее, нельзя не сказать, что они вызвали заметные и достаточно радикальные преобразования в методах
предоставления информации и услуг. Но эти преобразования, как и
любые другие, возникли не на пустом месте и имеют в своей основе
различные технологические решения, а в их составе, в том числе,
и довольно «старые» компоненты, на базе которых они построены.
Проблема заключается в том, что смысл реальных инновационных преобразований теряется в разговорах о моде, когда желание
компаний и их маркетологов поскорее продвинуть на рынок и популяризовать новые термины и технологии имеет результатом «запутывание слушателей». В итоге серьезные обсуждения предлагаемых
инноваций подменяются красивыми, но ничем не обоснованными
«проповедями и заклинаниями». Как следствие, нововведения из
области реалий переходят в область мифологии, а реальные трудности и проблемы (и обсуждение возможностей их преодоления)
отступают на задний план или просто теряются в красивых маркетинговых слоганах.
Поэтому задача пособия в том, чтобы с точки зрения специалиста
дать, по возможности, максимально полную информацию о том, что
представляют собой облачные вычисления и на каких технологических и организационно-технических принципах они основаны.
Но прежде чем перейти к этому вопросу, необходимо детально рассмотреть те технологии и вычислительные структуры, которые, с
одной стороны, стали предтечей появления облачных вычислений,
а с другой стороны, лежат в самой основе их существования.
Рассматривая эти технологии и вычислительные структуры, необходимо обращать внимание как на их положительные стороны,
так и на возникающие те или иные проблемы и возможные пути их
решения или обхода. Это необходимо, чтобы дать максимально пол3
ное представление о новых идеях со всех сторон и во всех аспектах.
Только тогда можно добиться того, чтобы новые идеи и технологии
действительно помогали в деле применения вычислительной техники для повышения эффективности бизнеса и качества жизни.
4
1. ОРГАНИЗАЦИЯ РАСПРЕДЕЛЕННЫХ ВЫЧИСЛЕНИЙ
1.1. Предпосылки появления облачных вычислений
Прежде, чем перейти к рассмотрению самих облачных вычислений и различных организационно-технических решений на их
основе, необходимо разобраться, благодаря каким принципам и
технологиям стало возможным их появление на рынке вычислительных систем и услуг. Ведь облачные вычисления появились и
распространились на этом рынке только тогда, когда сложились все
необходимые условия их существования, появились и стали широкодоступными соответствующие технологии. Без их появления
и выхода в информационную среду само существование облачных
вычислений было бы невозможным.
В основе организации распределенных вычислений, и облачных
вычислений в том числе, лежат два базисных принципа:
– возможность разделения решаемых задач между несколькими
доступными вычислителями;
– возможность разместить вычислители, участвующие в решении задач, в местах, физически отдаленных друг от друга на значительные расстояния.
И хотя второй принцип не является строго обязательным и возможны ситуации, когда он на практике не имеет места быть, без
самой возможности его реализации облачные вычисления принципиально не могут существовать. Таким образом, облачные вычисления всегда предполагают распределение вычислений между
несколькими вычислителями и возможность пространственного
разнесения этих вычислителей. Решение этих задач невозможно
без использования вычислительных сетей. Следовательно, первой
и основной предпосылкой для выхода в свет облачных вычислений
стало появление и развитие вычислительных сетей.
Надо сказать, что первые вычислительные сети появились ненамного позже первых компьютеров (тогда еще – ЭВМ), однако широкое и поистине всемирное распространение они получили только с
появлением и развитием глобальных вычислительных сетей, прежде всего – всемирной сети Интернет. Именно появление, развитие
и широкое распространение сети Интернет стало определяющим
фактором для развития облачных вычислений. До этого момента
технические решения и технологии, лежащие в основе облачных
вычислений, хотя и существовали, но имели узкоспециализированное и внутрикорпоративное применение. Только общедоступность и
5
распространенность Интернета сделала их новым фактором на рынке вычислительных систем и услуг и, что называется, вывела в свет.
Однако одно только развитие вычислительных сетей и связанных с ними технологий не могло стать основой для возникновения
облачных вычислений. Вторым фактором, позволяющим выполнять разделение решаемых задач между несколькими вычислителями, стало появление распределенных вычислений. Именно появление технологий, связанных с распределенными вычислениями,
позволило разделять решаемую задачу на части и разносить эти части по различным вычислителям. Без наличия такой возможности
даже самые развитые и производительные вычислительные сети не
могли бы обеспечить этот процесс, столь необходимый для существования облачных вычислений.
Важной предпосылкой для появления распределенных вычислений стал тот факт, что прикладные программы стали представлять
собой не единый программный модуль, а набор взаимосвязанных
компонентов. В свою очередь, это стало возможным благодаря постепенному согласованному развитию операционных системы и
систем программирования, которые смогли обеспечить поддержку этих структур на технологическом уровне. Именно развитие и
распространение динамически загружаемых библиотек, ресурсов
пользовательского интерфейса и других подобных технологий привело к ситуации, когда прикладные программы стали представлять
собой сложные структуры из взаимосвязанных компонентов. Такое
положение вещей стало возможным только с появлением средств и
систем, поддерживающих такие технологические решения на всех
этапах жизненного цикла программных продуктов, включая их
проектирование, разработку, отладку и эксплуатацию.
Разделение единого программного продукта на части сделало
возможным то, что не все компоненты, входящие в его состав, создавались одними и теми же разработчиками. Некоторые из них входили в состав ОС, другие поставлялись сторонними разработчиками,
которые очень часто могли быть никак не связаны с разработчиками самой прикладной программы. Это привело к тому, что на рынке
вычислительных систем стали появляться не только полноценные
программные продукты, но их отдельные компоненты, выполняющие ту или иную роль, а также технологии, обеспечивающие взаимодействие различных компонент программного обеспечения.
Поэтому для того, чтобы иметь представление об облачных вычислениях, абсолютно необходимо детально познакомиться с их
фундаментальной основой – распределенными вычислениями, а
6
также теми технологиями, которые обеспечивают различные варианты организации распределенных вычислений.
1.2. Понятие о распределенных вычислениях
Как было сказано выше, облачные вычисления не могут существовать без распределения одной или нескольких решаемых задач между различными вычислительными системами. В том случае, когда возникает потребность разделить вычислительный процесс (и решаемые им задачи) между несколькими вычислителями,
можно говорить о распределении вычислений. Любая организация
распределенных вычислений подразумевает разделение решаемой
задачи на части и то или иное распределение имеющихся вычислительных ресурсов для решения каждой из выделенных частей. Далее встают вопросы о том, как разделить на части решаемую задачу
и как распределить имеющиеся вычислительные ресурсы.
Однако не любое распределение вычислений между несколькими вычислителями трактуется именно как «распределенные вычисления» и в этом есть некоторая терминологическая путаница.
Поэтому прежде, чем говорить о распределенных вычислениях,
необходимо разобраться с тем, что, по сути, обозначает сам термин
«распределенные вычисления». Какие вычисления можно считать
распределенными, а какие – нет?
Пока на рынке вычислительных систем доминировали однопроцессорные, никак не связанные между собой вычислительные машины, вопрос о распределенных вычислениях не возникал. Только
с появлением многопроцессорных систем встала задача о распределении вычислительной нагрузки между имеющимися вычислителями. Это отдельная и достаточно интересная тема, но она выходит
далеко за рамки данного учебного пособия. Дело в том, что такие вычислительные системы в большинстве своем не подпадают под определение распределенных вычислений. Связано это с тем, что в многопроцессорных (а также и в многоядерных) вычислительных системах скорость обмена информацией между вычислителями сопоставима со скоростью выполнения самих вычислений. Основываясь на
этой точки зрения, такие системы нельзя называть распределенными, и поэтому их рассмотрение выходит за рамки данной работы.
По-настоящему понятие распределенных вычислений сформировалось только с появлением компьютерных сетей, как локальных,
так и глобальных. Характерной особенностью таких структур явля7
ется то, что скорость обмена данными между различными вычислителями в них существенно ниже, чем скорость выполнения вычислений и обмена информацией между составными элементами в пределах одного вычислителя. При этом вычислителями в таких сетях
могут быть и персональные компьютеры различной структуры, и
многопользовательские вычислительные машины («мейнфреймы»),
и сложные многопроцессорные вычислительные системы.
С момента появления первых компьютерных сетей и до настоящего времени их надежность и производительность существенно
изменились. Типовая пропускная способность вычислительных сетей за это время радикально возросла, увеличившись в разы (как
минимум, на два порядка). Но развитие внутренней структуры отдельных вычислительных систем всё это время также не стояло на
месте, и в результате производительность отдельных вычислителей
возрастала не меньшими (по крайней мере, сопоставимыми) темпами. Поэтому основная характерная особенность вычислительных
сетей осталась неизменной: скорость обмена данными между вычислителями в рамках сети существенно ниже, чем скорость выполнения вычислений и обмена информацией в пределах одного
вычислителя. И следует ожидать, что в ближайшей обозримой перспективе такая тенденция сохранится.
Поэтому суть распределенных вычислений можно определить
следующим образом: задача организации распределенных вычислений возникает тогда, когда скорость обмена данными между различными взаимосвязанными вычислителями (вычислительными
системами) существенно ниже, чем выполнение вычислений и обмен информацией между элементами в пределах одного вычислителя. При этом сами такие вычислители могут представлять собой
сложно организованные структуры со своими внутренними взаимосвязями.
Как уже было сказано выше, распределение вычислительных
ресурсов в пределах одного вычислителя – это непростая и достаточно интересная задача, но ее рассмотрение выходит за рамки данного учебного пособия. Далее здесь будут рассматриваться только
технологии, связанные с вопросами распределения ресурсов и задач между вычислителями в рамках сети именно тогда, когда речь
заходит о распределенных вычислениях в том понимании, как это
было определено выше.
Конечно, проведенная здесь граница термина «распределенные
вычисления» достаточно условна. Возможны ситуации, когда применение высокопроизводительных вычислительных сетей нивелирует
8
разницу между скоростью обмена данными между различными вычислителями в сети и скоростью обмена данными между составными
элементами в пределах одного вычислителя. И наоборот: возможно,
что усложнение структуры и количества составных элементов в рамках одного вычислителя сделает для него актуальными те проблемы,
которые возникают обычно в пределах вычислительных сетей. Тем
не менее, такие ситуации не отменяют базисный принцип, лежащий
в основе рассмотренных здесь методов организации распределенных
вычислений, тем более, что эти методы получили широкое распространение и технологическую поддержку на уровне операционных
систем и средств разработки. Это никак не отменяет возможности
иных способов организации распределенных вычислений, однако их
рассмотрение не входит в предмет данного учебного пособия.
Здесь и далее термин «распределенные вычисления» будет трактоваться именно в том понимании, как это было указано выше.
1.3. Принципы организации распределенных вычислений
Чтобы организовать распределенные вычисления, необходимо так
или иначе уметь разделять решаемую задачу на части. Причем такая
необходимость возникает в любом случае, вне зависимости от того,
как именно организовано распределение вычислений между имеющимися вычислителями. Если решается не одна, а несколько задач,
то проблема еще больше усложняется, так как можно не только разделять задачи на части, но и объединять однотипные части нескольких задач в рамках тех вычислительных элементов, которые наилучшим образом подходят для их наиболее эффективного решения.
Способов разделения решаемой задачи на части, а также принципов, лежащих в основе каждого такого разделения, достаточно
много. С теоретической точки зрения их количество может быть
бесконечно велико и каждый раз для каждой решаемой задачи
можно предложить новый оригинальный способ ее разделения на
части. Но при выборе каждого такого способа необходимо учитывать два разумных ограничения: во-первых, трудозатраты на разделение задачи на части должны быть незначительными на фоне
общих трудозатрат, потраченных на ее решение. А во-вторых, вычислительные затраты, требуемые для организации и поддержки
взаимодействия выделенных частей единой задачи, также не должны быть существенными по сравнению с вычислительными затратами на решение самой задачи. Любой способ разделения задачи на
9
части, выполненный без соблюдения двух указанных ограничений,
будет, конечно, иметь право на существование, но его практическое
применение будет связано с существенными трудностями.
Очевидно, что чем более распространенным является тот или
иной способ разделения задачи, тем больше имеется информации,
соответствующих средств и технологий, его поддерживающих. Эти
факторы, в свою очередь, снижают трудозатраты на применение
данного способа, а также помогают оценить и по возможности снизить вычислительные затраты на его реализацию. Поэтому каждый
новый способ разделения задач на части, появляющийся в сфере
информационных технологий, поначалу будет требовать больших
затрат, которые будут постепенно снижаться до некоторого стабильного уровня по мере его внедрения и распространения на рынке.
К настоящему моменту развитие технологий, связанных с распределенными вычислениями, прошло уже значительный путь. И хотя
перечень доступных и достаточно распространенных способов разделения задач на части всё еще нельзя назвать устоявшимся, среди
них можно выделить тот базисный перечень, который лежит в основе самых распространенных технологических решений.
Поэтому для дальнейшего рассмотрения здесь возьмем самые
простые и наиболее распространенные способы, применяемые для
одной задачи, которую решает одна исполняемая программа (далее такую программу будем называть прикладной программой или
приложением). Этого будет достаточно, чтобы выделить основные
применяемые принципы и технологии, наиболее распространенные
на рынке вычислительных систем в настоящее время.
Принцип, который будет здесь использован для разделения прикладной программы на части, основан на разделении по уровням
обработки данных (как иногда говорят, по слоям). При этом в самом
общем виде любую прикладную программу (приложение) можно условно разделить на четыре основных уровня (слоя) обработки данных:
– пользовательский интерфейс, отвечающий за отображение
данных, представление их человеку (пользователю) и взаимодействие с ним;
– бизнес-логика, реализующая специализированную логику обработки и преобразования данных, характерную для данной прикладной программы;
– операции со структурами данных, отвечающие за типовые действия для получения, хранения, защиты и архивации данных, разделение доступа к ним;
10
– файловые операции, обеспечивающие работу прикладной программы с файловой системой, которую обычно реализует операционная система (ОС).
Конечно, предложенное разбиение достаточно условно и не является единственно возможным, но оно в целом достаточно полно отражает все функциональные составляющие большинства прикладных программ. Каждый из этих уровней представляет собой логически цельную составляющую единого приложения (прикладной
программы). При соответствующей организации распределенных
вычислений и самой прикладной программы каждая составляющая может выполняться отдельно (при условии сохранения взаимосвязи между всеми составляющими).
Как уже было сказано, предложенный выше вариант разделения прикладной программы на части по слоям обработки данных
не является единственно возможным, но это разбиение является
минимальным. Разделение на более крупные части не существует
(а если оно и существовало, то технологической поддержки на рынке вычислительных систем не получило). Тем не менее, возможно
более детальное разбиение на большее количество уровней. В этом
случае один или несколько из предложенных выше уровней можно
далее разбить на подуровни и получить больше составляющих, общее число которых ничем принципиально не ограничено. Особенно
это касается уровня бизнес-логики, который существенно зависит
от сложности прикладной программы и решаемой ею задачи.
Однако с точки зрения рассмотрения общих принципов технологий, лежащих в основе организации распределенных вычислений, предложенное выше разделение решаемой задачи на 4 части
(уровня) является вполне достаточным. Более подробные разбиения
могут потребоваться в тех случаях, когда речь пойдет о деталях
реализации тех или иных технологических решений, но в данном
учебном пособии эти вопросы не рассматриваются (там, где это необходимо, соответствующие возможности будут далее упомянуты).
Необходимо отметить, что кроме рассмотренной выше возможности разделения решаемой задачи на части распространение распределенных вычислений предоставило разработчиком программных
продуктов еще одно немаловажное преимущество. Это преимущество – возможность использовать для реализации новых приложений те составные части, которые уже были ранее созданы и использованы для ранее созданных приложений (и ранее решенных задач). Причем здесь идет речь не только об использовании отдельных
готовых элементов на уровне исходного кода (что давно предлагают
11
многие технологии разработки и поддерживают системы программирования), а об использовании готовых составных частей на уровне внешних программных интерфейсов взаимодействия. Это дает
возможность применять при разработке уже готовые составные части, полученные из общедоступных источников или от сторонних
разработчиков, что может существенно сократить трудозатраты и
уменьшить сложность разработки прикладных программ.
Данное немаловажное технологическое преимущество предопределило распространение технологий, связанных с распределенными вычислениями, не в меньшей степени, чем описанная ранее
возможность разделять решаемую задачу между несколькими вычислителями.
Далее здесь будут рассмотрены основные технологии, используемые в настоящее время для организации распределенных вычислений, предоставляемые ими возможности, а также основные положительные и отрицательные моменты для каждого из возможных
технических решений. Только после этого можно будет говорить о
том, как указанные технические решения применяются для организации облачных вычислений.
Контрольные вопросы
1. Какие основополагающие принципы лежат в основе возможности организации распределенных вычислений?
2. К возникновению каких новых парадигм разработки программного обеспечения привело появление возможности разделять
программные продукты на части?
3. Без каких необходимых условий не могут существовать облачные вычисления?
4. Что понимается под термином «распределенные вычисления»?
5. Что подразумевается под термином «приложение»?
6. Какой принцип заложен в основу предлагаемого в данной главе разделения программ на составные части?
7. Какие составные части можно выделить в каждом приложении?
8. Какое дополнительное преимущество разработчикам дает возможность разделения прикладных программ на части?
9. Какие положительные эффекты предопределили распространение на рынке технологий разработки, ориентированных на поддержку распределенных вычислений?
12
2. ПРОСТЕЙШИЕ МЕТОДЫ ОРГАНИЗАЦИИ
РАСПРЕДЕЛЕННЫХ ВЫЧИСЛЕНИЙ
2.1. Какие методы обозначены как «простейшие»
Указанное выше понятие «Простейшие методы организации
распределенных вычислений» довольно условно. Само слово «Простейшие» здесь никак не относится ни к самим вычислениям, ни
к используемым технологиям, ни к решаемым этими методами задачам. Оно связано даже не столько с самими методами организации распределенных вычислений, сколько с теми технологиями и
средствами разработки, которые необходимы для того, чтобы организовать распределенные вычисления с использованием одного из
рассмотренных далее методов.
В этом разделе рассматриваются такие методы организации
распределенных вычислений, которые не требуют никаких специализированных средств разработки при создании приложений
(прикладных программ). Теоретически эти методы организации
распределенных вычислений могут быть применены к любой прикладной программе (хотя на практике могут возникать различные
ограничения, о которых сказано ниже применительно к каждому
конкретному методу).
Соответственно, эти методы не налагают никаких принципиальных ограничений и не предъявляют никаких требований к используемым системам программирования, хотя отдельные ограничения
для конкретных прикладных программ, в принципе, возможны. То
есть любая система программирования (среда разработки) может
быть использована для создания прикладных программ, использующих распределенные вычисления на основе любого из описанных
далее методов.
Однако отсутствие требований к поддержке на уровне систем
программирования не отменяет тот факт, что для реализации этих
«простейших» методов всё же требуются определенные программные средства. В данном случае эти программные средства входят в
состав операционных систем (ОС) или же поставляются сторонними
разработчиками. Поскольку задача организации распределенных
вычислений возникла не одновременно с появлением операционных систем, можно сказать, что не все операционные системы поддерживают те методы организации распределенных вычислений, о
которых далее пойдет речь. Однако большинство современных ОС
так или иначе поддерживает наиболее распространенные из «про13
стейших» методов организации распределенных вычислений. О существующих ограничениях будет сказано далее применительно к
каждому конкретному методу.
Как уже было сказано выше, то, что описанные далее «простейшие» методы не требуют применения специализированных средств
разработки, вовсе не означает, что они могут быть применены для
любого приложений без каких-либо ограничений. Каждый из этих
методов имеет свою определенную специфику, что может ограничить
или сделать полностью невозможным его применение в случае конкретной прикладной программы. Такие ограничения возможны, но
в целом технологии, лежащие в основе описанных далее «простейших» методов организации распределенных вычислений, рассчитаны на их широкое использование для приложений различных типов.
2.2. Технология «файл-сервер»
Наиболее простая и очевидная схема организации распределенных вычислений основана на том, чтобы выделить в приложении на
отдельный вычислитель самый нижний уровень (слой) обработки
данных – файловые операции. Тогда идея заключается в том, чтобы
выделить отдельный компьютер (или несколько компьютеров) для
выполнения файловых операций. В этом случае все файлы, обрабатываемые прикладной программой (или несколькими прикладными программами), будут располагаться на выделенном для этой
цели компьютере. Прикладная программа для получения доступа
к файлам и для выполнения любых операций с ними должна будет
через сеть обратиться к этому компьютеру и к файлам, расположенным на нем.
Если подобных прикладных программ много и/или они используются несколькими пользователями, то все обрабатываемые ими
файлы можно разместить на одном компьютере. В таком варианте
этот компьютер можно оптимизировать с точки зрения максимально
эффективного выполнения на нем именно файловых операций – он
должен иметь хорошо организованное эффективное хранилище данных достаточного объема, оперативную память, достаточную для оптимального выполнения файловых операций, возможно, несколько
процессоров, чтобы обеспечить одновременную обработку данных.
При этом производительность процессоров этого компьютера не так
важна, так как для файловых операций наиболее критичным является именно быстрый доступ к хранилищу данных. Остальные ком14
пьютеры в составе вычислительной сети в этом случае могут иметь
файловое хранилище минимального объема (достаточного для хранения локальных файлов ОС и прикладных программ), но более
производительные процессоры (чтобы выполнять остальные уровни
распределенных вычислений – операции с данными, бизнес-логику
приложений и операции с интерфейсом пользователя).
Такой компьютер, выделенный в составе сети для хранения файлов и выполнения операций над ними, получил название «файлсервер» (или «файловый сервер»). В свою очередь, такая технология организации распределенных вычислений получила название
«файл-серверная архитектура» или «архитектура файл-сервер».
Компьютеры, осуществляющие доступ к данным, расположенным
на файловом сервере, называются клиентскими компьютерами.
Общая структура организации распределенных вычислений по
технологии «файл-сервер» представлена на рис. 1.
Кроме того, что весь объем хранения информации при использовании архитектуры «файл-сервер» можно сосредоточить в одном
месте, данная архитектура предоставляет пользователям очевидное
преимущество в работе со своими данными. Каждый пользователь
в такой системе может работать со своими данными, расположенными в файлах на файловом сервере, с любого компьютера, входящего в состав сети.
При такой организации распределенных вычислений доступ к
данным файл-сервера осуществлялся на уровне файлов, а разделение доступа к файлам обеспечивается средствами ОС. Сервер в этой
архитектуре выполняет только примитивные процедуры доступа
к файлам, хранения файлов, копирования и защиты файлов от несанкционированного доступа.
ПО «Клиент-1»
ПО «Клиент-2»
Разделение доступа средствами ОС
Данные
Рис. 1. Схема организации распределенных вычислений
по технологии «файл-сервер»
15
Использование архитектуры «файл-сервер» не требует от разработчиков приложений применения каких-либо специальных
средств разработки. Однако для реализации этой технологии необходимы средства, которые бы обеспечивали для прикладных программ доступ к файлам, расположенных на других компьютерах в
составе сети. На ранних этапах развития данной технологии такие
средства предоставляли сторонние разработчики – с их помощью
каталоги файловой системы, расположенные на файловых серверах
(выделенных компьютерах в составе сети), можно было представить
в ОС в качестве логических дисков с соответствующими обозначениями. Но по мере того, как технология развивалась и получала популярность, ее поддержка становилась все более и более широкой и
перешла на уровень ОС. В настоящее время все современные операционные системы поддерживают технологию «файл-сервер» и предоставляют возможность унифицированной работы с файлами, как
расположенными на локальных устройствах, так и на компьютерах
в составе вычислительной сети.
Удаленный доступ к файлам в ОС – это отдельная и довольно интересная тема, выходящая за рамки данной книги. С ней лучше ознакомится в специализированной литературе [3, 9, 13, 14].
Для разработчиков прикладных программ технология «файлсервер» не предъявляет никаких дополнительных требований – для
них операции работы с файлами остаются унифицированными и
«прозрачными» вне зависимости от того, где реально расположены
эти файлы: на локальных носителях или на других компьютерах в
составе сети. Эту технологию организации распределенных вычислений может использовать любая прикладная программа, работающая с файловой системой на уровне ОС (а все современные ОС обеспечивают унифицированный доступ к локальным и сетевым файлам). Даже если приложение создано на основе устаревших средств
разработки, не поддерживающих доступ к файлам в распределенной сети, доступ к файловому серверу для него можно обеспечить
средствами ОС в форме создания логических дисков, привязанных
к сетевым ресурсам на файловом сервере. Ограничения могут возникнуть только в том случае, если приложение осуществляет доступ к файловой системе на более низком уровне – в этом случае ресурсы файлового сервера могут оказаться для него недоступными.
Также следует учитывать, что если приложение обрабатывает на
уровне файловых операций значительные объемы информации, это
может создать существенную нагрузку на вычислительную сеть.
При недостаточной пропускной способности сети выполнение таких
16
операций может существенно замедлить или сделать вовсе невозможной работу данного приложения, а также негативно сказаться
на работе других приложений, передающих данные через сеть. Это
один из существенных недостатков архитектуры «файл-сервер», о
котором еще будет сказано далее.
За исключением двух указанных выше ограничений архитектура «файл-сервер» не налагает никаких иных требований на прикладные программы.
Преимущества архитектуры «файл-сервер».
Основные преимущества организации распределенных вычислений на основе технологии «файл-сервер» заключаются в следующем:
– широкая доступность технологии, так как практически любое
приложение может быть использовано для организации распределенных вычислений на ее основе (ограничения на применимость
технологии «файл-сервер» указаны выше, на большинство приложений они не влияют);
– простота организации и отсутствие дополнительных затрат,
поскольку все современные ОС поддерживают возможность организации распределенных вычислений на основе данной технологии.
Недостатки архитектуры «файл-сервер».
Главными недостатками организации распределенных вычислений на основе технологии «файл-сервер» являются:
– высокая нагрузка на клиентскую часть, и как следствие, высокие требования к вычислительным ресурсам клиентской части
(клиентских компьютеров);
– невозможность эффективно разделить доступ к данным при их
одновременном использовании несколькими пользователями;
– невозможность организовать защиту данных иначе, как на
уровне доступа ОС;
– высокая нагрузка на сеть для передачи файлов, если файловый
сервер и клиентское приложение работают на разных компьютерах
в составе сети.
Последний недостаток является определяющим в ограничении
распространения данной архитектуры. Действительно, если программе, работающей в архитектуре «файл-сервер», например, необходимо выполнить изменение нескольких байт в файле, имеющем
объем несколько мегабайт, это приведет к значительной нагрузке
на сеть. В этом случае программа должна будет получить доступ к
файлу – открыть его на запись, после чего переместить внутренний
указатель файла к нужному месту, выполнить необходимые изменения и закрыть файл.
17
Фактически, выполнение такой операции в архитектуре «файлсервер» потребует копирования всех данных файла с файлового
сервера на локальный компьютер, где выполняется программа. На
локальном компьютере программа выполнит необходимые изменения, после чего данные файла будут скопированы обратно на файловый сервер и записаны в файл. В результате, необходимость изменения нескольких байт в файле вызовет выполнение копирования по
сети мегабайт информации, причем два раза в разных направлениях: сначала с файл-сервера на локальный компьютер и затем обратно. При этом всё время, пока данная программа будет обрабатывать
файл на своем компьютере, он будет закрыт на файл-сервере для доступа на запись для всех других программ.
Тем не менее, несмотря на указанные недостатки, технология
«файл-сервер» получила очень широкое распространение благодаря своей простоте и доступности. Большинство компаний имеют
выделенные корпоративные файловые сервера, а зачастую эта технология используется и для доступа к файлам, хранящимся на компьютерах, не являющихся выделенными файловыми серверами. По
этой технологии чаще всего осуществляется доступ к данным небольшого объема, не требующим одновременного доступа большого
количества пользователей (офисные документы, таблицы, тексты и
т. п.), а также к объемным редко изменяемым файлам, данные которых не могут быть структурированы (видеозаписи, изображения,
чертежи и т. п.).
2.3. Графические серверы
Еще одна простая схема организации распределенных вычислений основана на том, чтобы выделить в приложении на отдельный
вычислитель самый верхний уровень (слой) обработки данных –
операции взаимодействия с пользователем (пользовательский интерфейс). Эта идея заключается в том, чтобы выделить отдельный
компьютер для выполнения взаимодействия с пользователем. Тогда
все остальные компьютеры будут выполнять другие задачи распределенных вычислений – файловые операции, обработку данных и
бизнес-логику, а для взаимодействия с пользователями будут обращаться к серверному компьютеру.
Такая необычная схема организации распределенных вычислений несколько меняет традиционные представления: сервером становится тот компьютер, который взаимодействует с пользователем,
18
а клиентами становятся компьютеры, которые только выполняют
различные операции, но с пользователями напрямую не взаимодействуют. Поскольку на сервере в данном случае организуется именно
графический интерфейс с пользователем, то его можно назвать «графический сервер», а саму технологию организации распределенных
вычислений – технология на основе графического сервера.
Эта идея была реализована в графической среде «X-Window»,
которая является основной и самой распространенной средой для
организации графического интерфейса с пользователем в операционных системах типа UNIX и Linux. Общая схема организации
распределенных вычислений по технологии на основе графического
сервера представлена на рис. 2.
В этой схеме организации распределенных вычислений обмен
данными между клиентами и графическим сервером происходит через сеть на основе специализированного протокола, который получил название «X-Протокол» («X-Protocol»). Графический сервер (который в «X-Window» реализации называется «X-Сервер») обеспечивает прием по этому протоколу от клиентских программ команд на
отображение графической информации (окон, кнопок, меню и др.),
а обратно передает им информацию о действиях пользователя (ввод
с клавиатуры, операции с графическим манипулятором («мышь»)
или с сенсорным экраном). Любая клиентская программа, которая
поддерживает обмен данными по «X-Протоколу», может обмениваться данными с «X-Сервером» и быть клиентским приложением в
такой схеме организации распределенных вычислений. При этом не
имеет значения, в какой вычислительной среде и под управлением
какой ОС выполняются клиентская программа и «X-Сервер».
Графический сервер
приложений
Разделение доступа средствами ОС (X-Window)
Сеть
ПО «Клиент-1»
X-Протокол
ПО «Клиент-2»
Рис. 2. Схема организации распределенных вычислений
по технологии на основе графического сервера
19
Технология организации распределенных вычислений на основе
графического сервера появилась в то время, когда самыми распространенными устройствами взаимодействия компьютера с пользователем были терминалы с текстовым дисплеем. Качественные графические дисплеи в этот период времени были дороги и доступ к ним
был ограничен, поэтому и встала задача обеспечить возможность разделения доступа к графическому дисплею. Но базисные принципы,
лежащие в основе этой технологии, были заложены во все средства
организации графического интерфейса с пользователем в ОС типа
UNIX и Linux. Поэтому даже в настоящее время, когда не только
каждый персональный компьютер, но и каждое мобильное устройство оснащены графическим дисплеем, в подавляющем большинстве
приложений, имеющих графический интерфейс под управлением ОС
типа UNIX и Linux, для организации этого интерфейса используется
система «X-Window». Просто в этом случае и графический сервер, и
клиентские программы выполняются на одном и том же компьютере
и взаимодействуют между собой через внутренний (локальный) сетевой интерфейс (localhost). Но при необходимости графический интерфейс практически любой программы, выполняющейся под управлением ОС типа UNIX и Linux (при условии, что программа поддерживает «X-Протокол»), может быть вынесен на любой компьютер в
составе сети, где имеется «X-Сервер» (подавляющее большинство
программ, имеющих графический интерфейс под управлением этих
ОС, соответствуют указанным здесь требованиям).
Преимущества архитектуры на основе графического сервера.
Основные преимущества организации распределенных вычислений на основе технологии с использованием графического сервера
заключаются в следующем:
– простота и универсальность технологии, практически любая
программа, имеющая графический интерфейс под управлением ОС
типа UNIX и Linux, может использовать данную технологию.
Недостатки архитектуры на основе графического сервера.
Главными недостатками организации распределенных вычислений на основе технологии с использованием графического сервера
являются:
– ограниченная поддержка технологии, связанная с тем, что
производители других ОС, отличных от UNIX и Linux, не развивают эту технологию и не поддерживают ее (однако есть возможность
использовать сторонние программные продукты для ее поддержки);
– относительно высокая ресурсоемкость, так как в среднем применение данной технологии для взаимодействия с локальным гра20
фическим сервером требует более высоких затрат вычислительных
ресурсов, чем локальные средства графического ввода/вывода;
– отсутствие реальной потребности для широкого развития технологии, поскольку в настоящее время локальные средства обеспечения взаимодействия с пользователем с использованием графического интерфейса относительно дешевы и доступны (нет необходимости использовать удаленные графические серверы).
Технология организации распределенных вычислений на основе графического сервера достаточно специфична и имеет довольно
узкое применение. Большинство пользователей, использующих ОС
отличные от UNIX и Linux, даже и не знают о ее существовании,
да и пользователи, работающие в ОС типа UNIX и Linux, далеко не
всегда задумываются о том, что графический интерфейс их компьютера построен на основе такой технологии, имеющей достаточно широкие возможности. Главным образом это связано с тем, что
различные средства графического интерфейса с пользователем в
настоящее время широко распространены и доступны, из-за чего
потребность в использовании удаленных графических серверов на
практике возникает исключительно редко.
2.4. Терминальные серверы
Еще одним простейшим средством организации распределенных
вычислений, является использование терминального доступа. При
использовании терминального доступа пользователь удаленного
компьютера (компьютера-терминала) получает доступ к серверу, который в этом случае называется «терминальный сервер», и работает
на нем таким образом, как будто его устройства ввода и отображения данных подключены непосредственно к этому серверу. В таком
варианте пользователь работает на терминальном сервере, как если
бы он сидел за терминалом, подключенным к этому серверу – отсюда и происходит название «терминальный доступ», восходящее
к эпохе больших ЭВМ, к которым подключались многочисленные
терминалы. Технология организации распределенных вычислений,
построенная с использованием терминального сервера, называется
«технология терминального доступа» или «технология на основе
терминального сервера».
При такой технологии организации распределенных вычислений
на клиентских компьютерах выполняются только операции, обеспечивающие взаимодействие с пользователями (интерфейс поль21
зователя), а все остальные действия – бизнес-логика, операции с
данными и файловые операции выполняются на терминальном сервере. В этом случае компьютер-терминал (клиент) обеспечивает всю
логику пользовательского интерфейса приложения, и фактически
на нем происходит взаимодействие приложения с пользователем.
А терминальный сервер выполняет все функции прикладной логики приложения, обработку данных и файловые операции. Структура организации распределенных вычислений для простейшего приложения на основе терминального доступа представлена на рис. 3.
Терминальный доступ может быть использован для организации
работы любых приложений. Так же как использование архитектуры «файл-сервер», использование терминального доступа не требует от разработчиков приложений применения каких-либо специальных средств разработки. Организация терминального сервера и
поддержка удаленного доступа к нему целиком и полностью возложены на ОС. Именно ОС должна обеспечить отображение элементов пользовательского интерфейса с терминального сервера на компьютере-терминале и передачу команд и действий пользователя с
компьютера-терминала на терминальный сервер. И если ОС поддерживает терминальный доступ, любое приложение, использующее
стандартные функции ОС для организации интерфейса с пользователем, может быть выполнено в режиме терминального доступа.
Большинство современных ОС так или иначе поддерживают организацию распределенных вычислений с помощью терминального
Терминальные
компьютеры
пользователей
приложения
Сеть
Разделение доступа средствами ОС
Терминальный сервер
Приложение Приложение
(копия 1)
(копия 2)
Рис. 3. Схема организации распределенных вычислений
на основе технологии терминального доступа
22
доступа. Одним из наиболее распространенных протоколов для реализации этой технологии является протокол RDP (Remote Desktop
Protocol – протокол удаленного рабочего стола), кроме того, есть программные средства от сторонних производителей, с помощью которых также можно организовать терминальный сервер. Однако эта
технология появилась на рынке немного позже, чем рассмотренная
выше технология на основе файлового сервера, поэтому выбор доступных средств здесь меньше, а в состав ОС она вошла несколько позже.
Возможные ограничения по использованию терминального доступа могут возникнуть для тех приложений, которые осуществляют доступ к аппаратуре компьютера, минуя функции ОС – для таких
приложений невозможно организовать распределенные вычисления
на основе терминального доступа. Кроме того, при использовании
этой технологии могут возникать не только технические, но и организационные ограничения, так как многие производители ОС, а также производители сторонних программных продуктов, предназначенных для организации терминального доступа, требуют приобретения лицензий на его использование. И количество таких лицензий
обычно зависит от количества возможных подключений к терминальному серверу. Поэтому использование терминального доступа
может увеличить стоимость используемого программного обеспечения за счет стоимости лицензий на терминальные подключения.
Кроме того, хотя терминальный доступ не налагает каких-либо
явных ограничений и не предъявляет дополнительных требований
к приложениям, при его использовании могут возникнуть нюансы,
зависящие от каждого конкретного приложения. Так, если приложение использует файлы конфигурации или настройки, хранящиеся в его локальном каталоге, то это не имеет значения, пока оно
исполняется на отдельно стоящем компьютере. Но если то же самое
приложение будет выполняться на терминальном сервере, к которому могут подключаться различные пользователи, то файлы, расположенные в локальном каталоге, могут стать так или иначе доступны всем этим пользователям, что может привести к конфликтам
конфигураций и настроек. Поэтому при использовании терминального доступа для работы с приложениями необходимо обеспечивать
разделение локальных файлов и хранилищ данных. Могут возникать и другие подобные нюансы.
Терминальный доступ прошел долгий путь развития. Основные
его идеи были перенесены с терминальных классов больших ЭВМ на
компьютерные сети. Более подробно об особенностях его организации можно узнать в специализированной литературе по ОС [3, 9, 14].
23
Преимущества терминального доступа.
Основные преимущества организации распределенных вычислений на основе технологии терминального доступа заключаются
в следующем:
– доступность технологии, так как практически любое приложение может быть использовано для организации распределенных
вычислений на ее основе и все современные ОС поддерживают эту
технологию (ограничения на применимость технологии терминального доступа указаны выше);
– упрощение процесса администрирования и обновления приложений, поскольку все используемые приложения установлены в
одном месте – на терминальном сервере – а пользовательские компьютеры являются только терминалами.
Недостатки терминального доступа.
Главными недостатками организации распределенных вычислений на основе технологии терминального доступа являются:
– неэффективное использование вычислительных ресурсов терминального сервера, поскольку каждый экземпляр приложения,
запущенного на терминальном сервере, выполняется в своем адресном пространстве;
– возможные конфликты доступа к локальным данным при их
одновременном использовании несколькими пользователями;
– дополнительные затраты на лицензирование терминальных
подключений.
Главным недостатком терминального доступа следует признать неэффективное использование вычислительных ресурсов
терминального сервера. Так происходит, потому что данные пользователей терминального сервера полностью разделены и каждый
пользователь на терминальном сервере работает в своем адресном
пространстве. Поэтому для одного и того же приложения (и всех используемых им библиотек) на терминальном сервере будет выполняться столько его копий, сколько компьютеров-терминалов осуществили запуск этого приложения на выполнение. Причем каждая такая копия приложения будет выполняться в своем адресном
пространстве и разделять процессорное время с другими копиями
(и другими приложениями) на основе общих принципов ОС. И если
приложение не использует никаких иных средств организации распределенных вычислений, то все запущенные на выполнение его
копии будут выполняться независимо друг от друга.
Сочетая простейшие методы организации распределенных вычислений, такие, как файловый сервер и терминальный сервер, мож24
но построить довольно сложную распределенную систему. Однако
такой системе будут присущи все указанные выше недостатки «простейших» технологий организации распределенных вычислений.
Поэтому «простейшие» технологии организации распределенных
вычислений находят свое применение в первую очередь для тех приложений, которые изначально создавались без учета возможности
распределенных вычислений. Для более эффективного использования ресурсов серверов и вычислительной сети были предложены
другие решения, которые предусматривают создание приложений,
специально ориентированных на распределенные вычисления. Эти
решения и связанные с ними технологии будут рассмотрены далее.
Контрольные вопросы
1. Какие методы организации распределенных вычислений относятся к простейшим и почему?
2. Могут ли простейшие методы организации распределенных
вычислений быть применены к любому приложению?
3. В чем состоит суть технологии организации распределенных
вычислений «файл-сервер»?
4. Какие операции выполняет серверная часть приложения в технологии организации распределенных вычислений «файл-сервер»?
5. Какие преимущества имеет технология организации распределенных вычислений «файл-сервер»?
6. Какие недостатки присущи технологии организации распределенных вычислений «файл-сервер»?
7. Какие предпосылки привели к появлению технологии организации распределенных вычислений «графический сервер»? Существуют ли эти предпосылки на современном рынке IT-технологий?
8. Какие операции выполняет серверная часть приложения в
технологии организации распределенных вычислений «графический сервер»?
9. Какие элементы технологии организации распределенных вычислений «графический сервер» используются в современных ОС
типа UNIX и Linux и для каких целей?
10. В чем состоит суть технологии организации распределенных
вычислений с использованием терминального сервера?
11. Какие преимущества дает разработчикам технология организации распределенных вычислений на основе терминального сервера?
12. Какие проблемы связаны с технологией организации распределенных вычислений на основе терминального сервера?
25
3. ОРГАНИЗАЦИЯ РАСПРЕДЕЛЕННЫХ ВЫЧИСЛЕНИЙ
В ЛОКАЛЬНЫХ СЕТЯХ
3.1. Принципы организации
распределенных вычислений в ЛВС
Далее речь пойдет о таких технологиях организации распределенных вычислений, которые предполагают использование приложений, целенаправленно разработанных и ориентированных на
функционирование с применением соответствующих технологий.
То есть, если каждый из «простейших» способов организации распределенных вычислений можно было применить практически к
любому приложению (с учетом тех ограничений, о которых шла
речь выше), то дальше будут рассмотрены такие способы организации распределенных вычислений, которые предусматривают не
только определенные технологии организации вычислений, но и соответствующие им технологии разработки приложений.
И в первую очередь будут рассмотрены технологии организации
распределенных вычислений, ориентированные на использование в
локальных вычислительных сетях (ЛВС).
В связи с этим встает вопрос о том, как разделить вычислительные сети на локальные и глобальные?
На взгляд авторов, современная разница между локальными и
глобальными вычислительными сетями достаточна условна. Граница между ними столь же нечеткая, как ранее проведенная граница между «распределенными» и «нераспределенными» вычислениями. Можно делить вычислительные сети на локальные и глобальные по разным критериям: по количеству компьютеров, входящих
в сеть; по размеру охватываемой сетью территории; по объему передаваемой через сеть информации и др. Однако любое такое разделение не будет единственно возможным и общепринятым.
Предлагаемое здесь разделение вычислительных сетей на локальные и глобальные будет столь же условным, но оно будет построено на основе двух критериев, которые являются принципиально важными для рассматриваемых технологий организации распределенных вычислений. Первый из этих критериев – это скорость
реакции приложений на воздействие пользователя.
Конечно, предлагаемый критерий очень субъективен и зависит
не только от пропускной способности сети, но и от многих других
факторов – производительности и загруженности серверов, возможностей клиентских компьютеров и даже от быстроты реакции
26
пользователя. Однако именно такой критерий чаще всего является одним из определяющих факторов, позиционирующих программные продукты на рынке. Если приложение не реагирует на
воздействие пользователя за адекватное время, оно просто не будет
использоваться. И тогда его поставщики должны или обеспечивать
необходимую производительность среды (пропускную способность
сети, мощность серверов и клиентских компьютеров), или применять иные технологии организации распределенных вычислений,
в том числе ориентированные на менее производительные глобальные сети или полное отсутствие сетей. Далее при прочих равных
условиях будем считать, что все необходимые условия, связанные с
производительностью среды, обеспечены на нужном уровне.
Второй критерий – это возможность пользователя напрямую или
опосредовано контролировать вычислительные системы, входящие
в состав сети. В локальных вычислительных сетях пользователи
этих сетей так или иначе имеют информацию о составе вычислительных систем, входящих в состав сети, а зачастую могут также
и предъявлять какие-то требования к этим системам. Даже если
пользователь взаимодействует только с одним компонентом распределенного приложения, выполняющегося в такой сети, он так или
иначе знает о составе других его компонентов, с которыми осуществляется взаимодействие. В этом случае и разработчики, создавая
приложение для выполнения распределенных вычислений в сети,
могут предъявлять те или иные требования к вычислительным системам, под управлением которых будут выполняться компоненты,
входящие в состав приложения.
Конечно, этот критерий также не является строго однозначным.
Иногда пользователи локальных сетей не имеют возможности или
по каким-то другим причинам не могут получать информацию о
компонентах, входящих в состав распределенного приложения.
Также может оказаться, что для разработчиков распределенного приложения требования к вычислительной среде выполнения
какого-то из его компонентов будут не принципиальными. Однако
этот критерий является практически обязательным при использовании глобальных сетей – при работе в них нельзя заранее сказать,
какие вычислительные системы будут использованы для всех без
исключения компонент распределенного приложения.
Следовательно, можно сказать, что если пропускная способность
сети является достаточной для того, чтобы обеспечить должное
время реакции приложений на воздействия пользователя при используемой технологии организации распределенных вычислений
27
и при этом пользователь располагает информацией обо всех взаимодействующих через сеть компонентах приложения, то такая сеть
может быть признана локальной сетью – ЛВС.
Поскольку граница между локальными и глобальными вычислительными сетями весьма условна, нет и никаких жестких ограничений, которые бы запрещали использование рассмотренных далее технологий, ориентированных на локальные вычислительные
сети, в глобальных сетях. Более того, это вполне возможно, если
обеспечены все необходимые условия. Авторам известно немало
примеров, когда при наличии высокопроизводительной глобальной
сети в ней применялись методы и технологии, ориентированные на
ЛВС. Однако всё же главной областью применения рассмотренных
далее технологий организации распределенных вычислений являются именно локальные вычислительные сети, обеспечивающие
достаточно оперативную реакцию взаимодействующих по сети частей приложения на воздействия пользователя.
3.2. Технология «клиент-сервер»
Технология организации распределенных вычислений, называемая «клиент-сервер» (или «клиент-серверная технология»), как и
многие технологии, рассмотренные выше, подразумевает, что приложение разделяется на две составные части – клиентскую и серверную. Клиентскую часть обычно так и называют «клиент», а чтобы не путать с другими типами клиентских частей, используемых
в других технологиях организации распределенных вычислений –
«толстый клиент», а серверную часть называют «сервер данных».
Примечание: Само наименование данной технологии «клиентсервер» следует признать не очень удачным, поскольку практически
любые технологии, используемые для организации распределенных вычислений (в том числе и все, рассмотренные выше) подразумевают наличие серверов (компьютеров, которые оказывают те или
иные услуги по запросу) и клиентов (компьютеров, которые запрашивают те или иные услуги). Поэтому термин «клиент-сервер» формально можно применить к любой такой технологии. Но поскольку
рассматриваемая в данном разделе технология организации распределенных вычислений получила наибольшее распространение
(по крайней мере, в известный период времени), то и наименование
«клиент-сервер» закрепилось именно за ней, без уточнения того, о
каких типах серверных и клиентских компьютеров идет речь.
28
В данной технологии организации распределенных вычислений
сервер данных выполняет два нижних уровня (слоя) операций из
четырех – файловые операции и операции с данными. Тогда как
клиентская часть выполняет два оставшихся типа операций (два
верхних уровня) – бизнес-логику приложения и взаимодействие с
пользователем. Взаимодействие между этими составными частями
может осуществляться через вычислительную сеть (как правило,
локальную).
Иногда рассмотренную выше технологию организации распределенных вычислений «файл-сервер» рассматривают как тривиальный вариант реализации технологии «клиент-сервер». При таком
подходе файл-сервер, реализующий только файловые операции,
рассматривается как примитивный вариант сервера данных. На
самом деле, это не совсем правильно, так как технология «файлсервер» предполагает иной уровень распределения вычислений по
сравнению с технологией «клиент-сервер» и может применяться
для практически любых приложений, чего нельзя сказать о технологии «клиент-сервер» (хотя с терминологической точки зрения
технологию «файл-сервер» тоже можно назвать «клиент-серверной», так как она предполагает наличие и сервера, и клиентов). Однако существуют упрощенные варианты реализации технологии
«клиент-сервер», сочетающие в себе элементы обеих технологий – о
них еще будет сказано далее.
Появление технологии организации распределенных вычислений «клиент-сервер» сразу поставило вопросы о том, как организовать клиентскую и серверную части приложения и каким образом
обеспечить взаимодействие между ними. В данном случае серверный уровень невозможно было реализовать на уровне ОС, так как
соответствующие инструменты в операционных системах отсутствуют. На самых ранних этапах развития технологии предлагались различные решения для этих вопросов, но со временем устоялось одно общепринятое решение, по которому серверный уровень
реализуется на основе систем управления базами данных (СУБД).
Можно сказать, что развитие СУБД шло параллельно с развитием технологии «клиент-сервер» и в итоге сложилась схема организации приложений, построенных по такой технологии, представленная на рис. 4. В этой схеме сервер данных построен на основе СУБД и
реализует два нижних слоя операций приложения – файловые операции и операции с данными. Клиентские компьютеры («толстые
клиенты»), которых может быть любое количество, реализуют два
других слоя – бизнес-логику приложения и взаимодействие с поль29
ПО «Клиент-1»
ПО «Клиент-2»
Клиентская часть СУБД
Клиентская часть СУБД
Сеть
СУБД
Данные
Рис. 4. Схема организации распределенных вычислений
на основе технологии «клиент-сервер»
зователями. При этом обмен данными между клиентами и сервером
данных организован на уровне команд: клиенты передают на сервер
те или иные команды на обработку данных, а сервер возвращает им
результаты выполнения этих команд.
Конечно, можно представить ситуацию, когда при создании приложения на основе технологии «клиент-сервер» разработчики создают обе его части – и серверную, и клиентскую – и в принципе, такие
ситуации бывают на практике, но в очень специфичных случаях. Но
наиболее типичной является ситуация, когда при создании приложения разработчики создают только клиентскую часть, а в качестве
серверной части используют одну из множества СУБД, доступных
на рынке. Кроме того, большинство СУБД, чтобы упростить разработку клиентской части приложений, взаимодействующих с этой
СУБД, предлагают разработчикам приложений соответствующие
библиотеки, поддерживающие такое взаимодействие. Таким образом, разработчики приложений, построенных по технологии «клиент-сервер» не только используют готовую серверную часть, но и
могут воспользоваться библиотеками клиентской части для взаимодействия с СУБД. Но даже в том случае, когда для взаимодействия с
СУБД, в приложении используется одна из доступных неспециализированных технологий (о них речь пойдет далее), на клиентском рабочем месте всё равно должна присутствовать системная библиотека
(драйвер), обеспечивающая взаимодействие с СУБД заданного типа.
30
Как уже было сказано выше, развитие технологии «клиент-сервер» шло параллельно с развитием СУБД – именно реализация этой
технологии организации распределенных вычислений положила
начало развитию систем управления базами данных. Однако первые
СУБД были довольно примитивными и содержали в себе ограничения, присущие технологии организации распределенных вычислений «файл-сервер». И хотя в них обмен данными между клиентской
и серверной частью был организован уже на уровне команд управления данными, реальное разграничение доступа к данным в таких
СУБД осуществлялось по-прежнему на уровне файлов. В настоящее
время всё еще существуют простейшие СУБД, использующие такую технологию – как правило, это дешевые СУБД, которые часто
называют «настольными» или «локальными». Примерами таких
СУБД являются СУБД Paradox производства компании Borland и
СУБД Microsoft Access производства компании Microsoft.
Приложения, работающие с такими СУБД, могут не использовать средства доступа к файлам, а применять полноценные механизмы работы с БД (которые более подробно рассмотрены далее). При
этом СУБД реализует не только файловые операции, но и другую
составляющую распределенных вычислений – логику работы с данными. Однако в этом случае логика работы с данными реализуется
хотя и с помощью СУБД, но на том же компьютере, где выполняется
остальные вычисления, а по сети распределяются только файловые
операции. Единственным преимуществом для разработчика прикладной программы является только то, что выполнение распределенных файловых операций организует не он сам, а средства СУБД,
к которым он обращается. В остальном логика работы такого приложения остается такой же, как и при явном использовании распределенного доступа к файлам в технологии «файл-сервер».
В настоящее время такие «настольные» СУБД используются в
устаревших приложениях, а также в упрощенных версиях современных приложений – в тех случаях, когда количество пользователей приложения невелико и для его работы нет необходимости
использовать полномасштабную СУБД, может быть использована
настольная СУБД. При этом разработчики приложений, которые
создают только клиентскую часть, могут использовать одни и те
же средства взаимодействия с серверной частью вне зависимости от
того, какой тип СУБД будет использован. Кроме того, если заранее
известно, что создаваемое приложение не будет широко использоваться в распределенной вычислительной среде, его разработчики
могут целенаправленно ориентировать его на одну из «настольных»
31
СУБД, поскольку использование такой локальной СУБД зачастую
обходится дешевле или может быть полностью бесплатным. В этом
случае преимуществом является тот факт, что разработчики получают уже готовую серверную часть приложения.
Со временем, по мере развития технологии организации распределенных вычислений «клиент-сервер» на рынке появились более
сложные полномасштабные СУБД, которые полностью реализуют
весь потенциал, заложенный в этой технологии. В них обмен данными через сеть осуществлялся уже только на уровне команд и
результатов их выполнения, а разделения доступа к данным шло
на уровне тех структур данных, которыми оперирует та или иная
СУБД (в реляционных СУБД такими структурами являются таблицы, представления и хранимые процедуры). Такой подход освобождает клиентские рабочие места от реализации функций обработки
данных и файловых операций и тем самым снижает требования к
ним. Клиентское приложение не работает непосредственно с файлами и данными, оно обращается к СУБД с запросами на получение
(просмотр) данных, их добавление, модификацию и удаление. При
работе сервера данных и клиентского приложения на разных компьютерах в составе сети через сеть будут передаваться не все данные из БД, а только запросы клиента и ответы СУБД на них. Таким
образом, в архитектуре клиент-сервер снижается нагрузка на сеть
при обмене данными.
Для работы компонентов серверной части в этой технологии организации распределенных вычислений зачастую требуется высокопроизводительная вычислительная система, особенно в том случае,
когда с одним сервером данных работает значительное количество
клиентов. Клиентская часть приложения, получая данные от сервера данных, обеспечивает их обработку и отображение в интерфейсе
пользователя. Требования к вычислительным ресурсам, необходимым для выполнения клиентской части приложения, обычно существенно ниже, чем для серверной части, поскольку каждая клиентская часть обслуживает только одного пользователя.
Технология организации распределенных вычислений «клиентсервер» развивалась достаточно быстро, и можно сказать, что к началу XXI в. приложения, построенные на основе этой технологии,
стали доминирующими на рынке программных средств. Появился
и широкий выбор различных СУБД, доступных разработчикам таких приложений. Среди них можно назвать достаточно известные
СУБД типа DB2 (компания IBM), Interbase (компания Borland),
Oracle Database (компания Oracle), Microsoft SQL Server (компа32
ния Microsoft). При этом доминирующие позиции заняли именно
реляционные СУБД.
В настоящее время технология организации распределенных вычислений «клиент-сервер» хотя и не является доминирующей, но
продолжает широко использоваться. По-прежнему на рынке наличествует достаточный выбор доступных СУБД, при этом многие из
их производителей стали предлагать бесплатные лицензии (хотя,
как правило, и с некоторыми ограничениями использования). Кроме того, появились СУБД, построенные по принципу открытого кода
и распространяемые без явных лицензионных ограничений такие,
например, как MySQL и PostgreSQL. При этом реляционные СУБД
продолжают занимать доминирующее положение на рынке, но постепенно появляются и развиваются типы СУБД, построенные на основе иных принципов, прежде всего на основе технологии «NoSQL».
Но какой бы тип СУБД не выбрали и не использовали разработчики приложений, построенных на основе технологии «клиент-сервер», основные принципы, заложенные в основе этой технологии, от
этого не меняются.
Выше уже было отмечено, что технология организации распределенных вычислений «клиент-сервер» может быть использована только для тех приложений, которые специально разработаны
именно для использования этой технологии. Поэтому ее развитие
и распространение требовало не только появления на рынке достаточного количества различных типов СУБД, но и развития средств
разработки (систем программирования), которые должны были обеспечить возможность создания приложений, ориентированных на
использование данной технологии. При этом в подавляющем большинстве случаев разработчики приложения, функционирующего
на основе технологии «клиент-сервер» должны разработать именно
клиентскую часть приложения, а серверная часть (сервер данных)
выбирается из числа имеющихся на рынке предложений. При этом
по выбору разработчиков клиентской части в качестве сервера данных может использоваться или строго определенное программное
обеспечение от конкретного производителя, или любое программное обеспечение, поддерживающее выбранную технологию взаимодействия клиентской и серверной частей (о плюсах и минусах каждого из этих вариантов будет еще сказано далее).
В принципе, создание приложения (а конкретно его клиентской
части), ориентированного на использование технологии «клиентсервер», возможно с помощью любой системы программирования.
При этом достаточно иметь библиотеки, обеспечивающие взаимо33
действие клиентской части с сервером данных, и иметь возможность вызывать функции из этих библиотек. Однако такая разработка может быть достаточно трудоемкой.
По этой причине на рынке средств разработки очень быстро стали
появляться системы программирования, которые содержали в своем составе инструменты, специально ориентированные на создание
приложений на основе технологии «клиент-сервер». Это могли быть
различные компоненты, библиотеки классов, визуальные элементы пользовательского интерфейса, специально ориентированные на
взаимодействие с серверами данных, а также средства проектирования БД и команд взаимодействия с ними. Наличие таких инструментов позволяло существенно снизить трудозатраты на создание
клиентской части приложений по технологии «клиент-сервер» в той
или иной системе программирования. Это, в свою очередь, повышало конкурентоспособность соответствующей системы программирования и улучшало ее позиции на рынке средств разработки. В результате возникла ситуация, когда практически все системы программирования, существующие на рынке средств разработки, стали
гарантированно поддерживать создание клиентских приложений на
основе технологии «клиент-сервер». Такая ситуация еще более ускорила повсеместное распространение данной технологии.
Далее будут более детально рассмотрены технологии, используемые для создания клиентских приложений на основе «клиентсерверной» схемы и то, как они поддерживаются на уровне средств
разработки. Но сначала необходимо окончательно определиться с
тем, какие преимущества предоставляет технология организации
распределенных вычислений «клиент-сервер» и какие недостатки
она в себе содержит.
Преимущества технологии «клиент-сервер».
Основные преимущества организации распределенных вычислений на основе технологии «клиент-сервер» заключаются в следующем:
– существенное снижение нагрузки на сеть, так как по сети от
клиентских компьютеров к серверу данных передаются только команды, а обратно – только те результаты их выполнения, которые
необходимы клиенту (нет необходимости передавать по сети все
данные с сервера);
– расширенные возможности по разделению доступа к данным,
так как это разделение идет уже не на уровне файлов, а на уровне
структур данных, поддерживаемых СУБД;
– упрощение процесса разработки приложений, так как разработчики приложений в этой архитектуре избавлены от необходи34
мости самостоятельно создавать средства для хранения данных,
разделения доступа к ним, защиты и резервного копирования данных – все эти функции берет на себя СУБД;
– снижение требований к вычислительным ресурсам клиентских компьютеров, так как часть выполняемых ими типовых операций с данными вынесена на сервер данных;
– упрощение процесса масштабирования системы, так как в
большинстве случаев для увеличения количества пользователей,
использующих приложение, построенное на основе технологии
«клиент-сервер», достаточно добавить в сеть новые клиентские места и пропорционально увеличить мощность сервера данных.
Недостатки технологии «клиент-сервер».
Главными недостатками организации распределенных вычислений на основе технологии «клиент-сервер» являются:
– необходимость структурировать обрабатываемые данные (при
отсутствии структурирования данных теряются основные преимущества, присущие данной технологии);
– достаточно высокие требования к вычислительным ресурсам
клиентских компьютеров, так как они продолжают выполнять операции бизнес-логики приложения, которая может содержать в себе
многие достаточно ресурсоемкие операции;
– сложность управления и администрирования, так как замену
и обновление приложений в случае развития или изменения бизнеслогики приходится выполнять на всех рабочих местах, где установлены клиентские части приложения;
– если необходимо изменить только внешний вид интерфейса
пользователя (отображение данных), но оставить неизменной логику обработки данных, то при этом чаще всего требуется заново
создать и установить на рабочем месте новый вариант клиентской
части системы.
Необходимость структурирования обрабатываемых данных является одним из главных условий применимости распределенных
вычислений на основе технологии «клиент-сервер». Поскольку ни
одна СУБД не умеет эффективно работать с данными, представленными в виде файлов неопределенной структуры, требования к созданию структуры данных в архитектуре «клиент-сервер» является
определяющим. В тех случаях, когда структурирование данных
выполнить не удается или оно в принципе невозможно, эта технология остается применимой, но основные ее преимущества теряются
(например, при обработке таких плохо структурируемых данных
как изображения и видеозаписи). Если такие данные являются ос35
новными в приложении, то имеет смысл задуматься о применении
более простых технологий организации распределенных вычислений, где предварительное структурирование данных не требуется
(например, «файл-сервер»).
Неверно утверждать, что клиенты (клиентские части приложения) в архитектуре «клиент-сервер» совсем не используют файловых
операций и не работают с файлами. На самом деле это не так – клиентские приложения в этой архитектуре могут обращаться к файлам,
как и любые другие. Во-первых, любое приложение может сочетать
в себе несколько технологий разработки, в том числе, технология
«клиент-сервер» может использоваться в сочетании с технологией
«файл-сервер». Во-вторых, файловые операции могут использоваться
для вспомогательных функций приложения. При этом если утверждается, что приложение построено на основе технологии «клиент-сервер», то основные его данные должны храниться и обрабатываться на
сервере данных – иначе архитектура «клиент-сервер» теряет смысл.
Если вернуться к примеру, связанным с изменением нескольких
байт в файле объемом в несколько мегабайт, который был рассмотрен
выше для архитектуры «файл-сервер», то в архитектуре приложения
«клиент-сервер» решение этой задачи будет происходить по-другому.
Прежде всего, данные в архитектуре «клиент-сервер» должны быть
структурированы и размещены на сервере данных (чаще всего – в
БД). Для изменения данных клиент должен сформировать запрос
к серверу на модификацию этих данных. Этот запрос передается по
сети на сервер, обрабатывается и выполняется там (обычно с помощью СУБД), а результат его выполнения сообщается клиенту.
Очевидно, что при таком решении нет необходимости пересылать по сети с сервера на клиент и обратно на сервер весь объемный
файл – по сети передается только запрос и результат его выполнения. При этом объем запроса и его результата ограничены именно
теми данными, которые необходимо изменить, и не зависят от общего объема данных на сервере (хотя скорость обработки запроса
сервером, конечно, будет зависеть от общего объема данных). Кроме
того, клиент не обращается непосредственно к данным сервера, а
потому не блокирует их для других клиентов на время обработки.
За разграничение данных между клиентами отвечает СУБД на сервере, что делает доступ к данным более гибким.
Приложение, работающее на клиенте в архитектуре «клиентсервер», не должно самостоятельно выполнять операции логики
работы с данными и файловые операции. Это снижает нагрузку на
клиентский компьютер и уменьшает трудоемкость создания кли36
ентской части приложения. Поэтому требования к вычислительным ресурсам клиентских приложений, работающих в архитектуре «клиент-сервер», могут быть ниже, чем требования аналогичных
приложений, не использующих распределенных вычислений.
Снижение требований к вычислительным ресурсам клиентов
влечет за собой перенос части выполняемых ими функций на сервер данных – и, как следствие, увеличение требований к вычислительным ресурсам сервера. Эти ресурсы необходимы для выполнения функций СУБД на сервере, и они тем более значительны, чем
больше клиентов обращаются к этому серверу одновременно. Увеличение вычислительных ресурсов сервера и с практической, и с
экономической точки зрения окупается за счет снижения этих же
ресурсов на клиентах. Но надо помнить, что существует разумный
предел количества клиентов в системе, после достижения которого, требования к вычислительным ресурсам сервера возрастают настолько, что его использование становится неоправданным.
Конкретный предел количества клиентов в системе зависит от
функций приложений, от их распределения между клиентами и
сервером, а также от интенсивности работы клиентов. В реальных
системах, построенных по архитектуре «клиент-сервер», как правило, количество клиентов ограничено в диапазоне от сотни до нескольких сотен (системы, содержащие более тысячи клиентов, на
практике встречаются редко). При достижении этого предела необходимо подумать либо о разбиении системы на части, в каждой
из которых может быть свой сервер, либо об использовании других
технологий (о некоторых из них сказано далее).
Недостатки организации распределенных вычислений на основе
технологии «клиент-сервер» являются не столь существенными, однако они начинают сказываться, когда речь заходит о масштабных
системах, построенных на основе этой технологии, включающих в
себя сотни и даже тысячи рабочих мест (и соответствующее количество клиентских приложений). Есть средства, позволяющие снизить
влияние этих недостатков, и далее о них еще будет сказано отдельно.
3.2.1. Взаимодействие с сервером данных
Как уже было отмечено, в подавляющем большинстве случаев
сервер данных для приложений, функционирующих на основе технологии «клиент-сервер», создается на основе системы управления
базами данных – СУБД. В настоящее время наиболее распространенным типом СУБД являются реляционные СУБД [5]. Поэтому на
37
рынке программного обеспечения для серверов данных доминируют программные продукты, так или иначе построенные на основе
реляционных СУБД.
Главным фактором, определяющим взаимодействие клиентской
части приложения и сервера данных, построенного на основе реляционной СУБД, стал механизм запросов, с которыми клиентское приложение обращается к серверу. Этот механизм должен предоставить
клиенту средства, которые давали бы ему возможность определить,
какие данные он хочет получить от сервера и какие операции с ними
выполнить. Для этой цели был предложен специальный язык описания запросов – SQL (Structured Query Language, язык структурированных запросов). По мере развития языка SQL он был признан всеми разработчиками серверов данных, построенных на основе реляционных СУБД, и со временем появились международные стандарты
этого языка структурированных запросов (аббревиатура «SQL» на
английский манер часто читается как «сиквэл», либо как «эскюэль»).
SQL предназначен для построения запросов и манипуляции данными и структурами данных на сервере. У него нет ни переменных,
ни меток, ни циклов, ни всего прочего, с чем привык работать программист, создающий программы для наиболее распространенных
компилируемых языков. Надо также четко представлять себе, что
SQL оговаривает способ передачи данных в клиентскую программу,
но никак не оговаривает то, как эти данные должны в клиентской
программе обрабатываться и представляться пользователю.
Элегантность и независимость от специфики используемых технологий, а также поддержка лидерами промышленности в области
технологий СУБД, сделали SQL (и, вероятно, в течение обозримого
будущего оставит его) основным стандартным языком манипулирования с данными (для реляционных СУБД он является практически
единственным таким языком). По этой причине большинство разработчиков приложений для архитектуры «клиент-сервер» должны знать SQL. Стандарт SQL определяется ANSI (Американским
Национальным Институтом Стандартов) и в данное время также
принимается ISO (Международной Организацией по Стандартизации). Одним из наиболее известных и употребительных стандартов
этого языка на данный момент является стандарт SQL 92, который
в настоящее время поддерживается всеми серверами данных от известных производителей, но развитие языка SQL и связанных с ним
стандартов продолжается.
Язык SQL предназначен для манипулирования данными в реляционных СУБД, определения структуры БД и для управления пра38
вами доступа к данным на сервере данных. Поэтому, в язык SQL в
качестве составных частей входят:
– язык определения данных;
– язык управления данными;
– язык манипулирования данными.
Это не отдельные языки, а различные группы команд одного
языка. Деление, приведенное здесь, выполнено с точки зрения различного функционального назначения команд языка, входящих в
эти группы.
Язык определения данных используется для создания и изменения структуры БД и ее составных частей – таблиц, индексов, представлений (виртуальных таблиц), а также триггеров и сохраненных
(или «хранимых») процедур.
Язык управления данными используется для управления правами доступа к данным и выполнением процедур в многопользовательской среде. Более точно его можно назвать «язык управления доступом». Он состоит из двух основных команд: дать права
(GRANT) и забрать права (REVOKE).
Язык манипулирования данными предоставляет средства для
выполнения четырех основных операций с данными на сервере: выборка (SELECT), добавление (INSERT), обновление (UPDATE) и удаление (DELETE).
Каждая команда языка SQL описывается соответствующим предложением языка, построенным с учетом его синтаксических и семантических правил. Клиентское приложение, желающее выполнить
какое-либо действие с данными, должно сформулировать его в виде
предложения языка SQL, направить запрос с этим предложением
серверу данных и дождаться ответа от него, в котором будет представлен результат выполнения операции. Если действие не может
быть выполнено с помощью одной команды языка SQL, оно разбивается на несколько команд, которые выполняются последовательно.
С точки зрения клиентского приложения и сервера данных язык
SQL – это формализованный язык, принципы использования которого очень похожи на принципы языков программирования. При
этом следует отметить, что поскольку именно клиентское приложение отвечает за построение предложений на языке SQL, то клиентская часть выступает как генератор предложений языка SQL. Часто
используемые команды языка SQL закладываются в клиентское
приложение на этапе разработки – то есть, их создает разработчик
клиентской программы. При этом эти команды SQL так или иначе
должны быть записаны в исполняемый код клиентского приложе39
ния (способ их создания и включения в состав исполняемого кода
зависит от используемых технологий и среды разработки). Но в
ряде случаев клиентское приложение не содержит в своем составе
готовые команды SQL, а формирует их динамически. Но и в этом
случае разработчик клиентского приложения должен позаботиться
о том, чтобы правила формирования этих команд соответствовали
грамматике языка SQL.
На стороне сервера каждое предложение SQL должно интерпретироваться в последовательность операций, выполняемых сервером. Получив SQL-запрос от клиента, сервер распознает его на основе грамматики SQL, определяющей синтаксис запроса, а также
проверяет семантику, основываясь на структуре БД, которая известна серверу данных. Если запрос содержит синтаксические или
семантические ошибки, сервер сообщает об этом клиенту – в этом
случае сам запрос не выполняется, а его результатом служит сформированное сервером данных сообщение об ошибке.
Если же запрос синтаксически и семантически правильный, то
на его основе сервер данных строит схему выполнения запроса, которую затем выполняет и передает результат ее выполнения клиенту. Сервер данных выступает как распознаватель языка SQL и является интерпретатором данного языка. Чаще всего эту функции
выполняет СУБД, на основе которой построен сервер данных.
Видно, что схема обработки и выполнения SQL-запросов на сервере данных полностью соответствует принципам, на основе которых функционируют интерпретаторы и компиляторы для языков
программирования. С этой точки зрения язык SQL является полноправным компьютерным языком (хотя нельзя сказать, что он является языком программирования).
Можно отметить, что этой схеме обработки запросов на языке
SQL присущ недостаток, который связан со всеми интерпретируемыми языками – каждый раз сервер данных вынужден тратить
время на распознавание запроса и проверку его корректности. В том
случае, когда клиент направляет серверу часто повторяющиеся типовые запросы, это ведет к неэффективным затратам времени. Эффективность схемы была бы выше, если бы сервер данных мог работать по схеме компилятора – один раз распознавать запрос, а потом
выполнять его каждый раз при обращении клиента с таким же запросом. Разработчики СУБД обратили на это внимание, и в современных серверах данных присутствуют соответствующие решения
в виде запросов с параметрами, предопределенных выборок (VIEW)
и хранимых (или «сохраняемых» – stored) процедур сервера. В этих
40
случаях сервер только один раз распознает запрос, анализирует его
синтаксические конструкции и запоминает у себя в виде внутренних команд. При повторном выполнении того же запроса (а также
VIEW или хранимой процедуры) сервер находит уже построенную
последовательность внутренних команд и выполняет ее. Это, конечно, не делает текст на языке SQL компилируемым (поскольку выполняются всё равно команды СУБД, а не машинные команды), но
повышает эффективность его выполнения.
Более подробно об этом лучше узнать в специализированной литературе, посвященной современным СУБД.
Другим важным механизмом, определяющим взаимодействие
клиентской и серверной части, является механизм транзакций. Его
суть заключается в том, что клиентское приложение может определить группу взаимосвязанных действий над данными, которые
либо должны быть выполнены все в комплексе, либо не выполнены вообще. Взаимосвязь действий определяется логикой клиентской части. Тогда, начав выполнение этой группы действий (открыв
транзакцию), клиент последовательно передает серверу данных все
команды в виде предложений языка SQL и ожидает результатов.
При правильном выполнении всех команд клиентская часть подтверждает это (закрывает транзакцию), и только после этого операция считается выполненной, а все сделанные изменения вносятся
в данные на сервере. Если же по каким-то причинам операция не
смогла быть выполнена, клиент отказывается от нее (отменяет транзакцию), и сервер должен восстановить то состояние данных, которое было до начала данной транзакции.
Взаимодействие клиентской и серверной части приложения в
архитектуре «клиент-сервер» здесь описано только в самом общем
виде. Рассмотрение операторов языка SQL, механизма транзакций
и других механизмов, связанных с работой СУБД не входит в рамки данного учебного пособия. Об этом можно узнать из книг, посвященным современным СУБД [5].
Естественно, что базовый стандарт языка SQL не всегда может
предусмотреть все возможные потребности пользователей, поэтому
многие фирмы-производители СУБД предлагают свои собственные
расширения языка SQL. Например, достаточно широко распространенные на рынке СУБД, поставляемые фирмами Oracle (Oracle
Database) и Microsoft (Microsoft SQL Server) имеют собственные
расширения оператора SELECT, которые позволяет эффективно
разворачивать в горизонтальное дерево иерархически упорядоченные данные. Количество различных расширений языка SQL может
41
исчисляться десятками для сервера СУБД от одной фирмы. Часто
эти расширения являются непереносимыми – если они применимы
для СУБД одной фирмы, то для СУБД другой фирмы их использовать невозможно. В этом случае перед разработчиками клиентской
программы встает дилемма: или отказаться от расширений и ограничиться использованием стандартизованных команд языка, или
применить какое-то из предлагаемых нестандартных расширений.
В первом случае разработчики клиентской программы исключают ее зависимость от конкретного типа СУБД – и тем самым улучшают ее позицию на рынке, так как такое клиентское приложение
может использоваться в комплекте практически с любой доступной
СУБД. Но при этом общая эффективность программы может снижаться, так как некоторые задачи в рамках стандарта языка решаются с большими затратами времени и ресурсов (как клиентской,
так и серверной частей приложения), чем с применением расширений, предлагаемых определенной СУБД. Если же разработчики
клиентской части приложения отложат создание новых функций,
ожидая выхода стандарта, который предоставит им новые возможности, то тогда они останутся вне зависимости от производителей
СУБД и могут использовать в качестве сервера данных для своего
приложения любую СУБД из доступных на рынке. Но, выжидая
определенное время, они могут отстать от конкурентов, которые
могут реализовать те же функции более эффективными, но нестандартными методами.
Во втором случае разработчики клиентского приложения могут
выиграть время, опередив конкурентов, и при этом они по максимуму используют возможности выбранной СУБД, за счет чего повышают эффективность клиентской части приложения. Но при этом
могут сужать доступный для разработанного приложения рынок,
так как жестко привязывают свое клиентское приложение к определенному типу СУБД. Кроме того, в этом случае разработчики клиентской части попадают в прямую зависимость от разработчиков
соответствующей СУБД, так как нововведения SQL, реализованные
вне рамок стандарта в одном типе СУБД, редко могут быть применимы на СУБД другого типа. Поэтому дальше они могут развивать свое
приложение только при условии сохранения на рынке этой СУБД и
ее поддержки со стороны фирмы-производителя. Кроме того, если
использованные при создании приложения новшества позже войдут
в новый стандарт, но в ином виде, нежели они были предварительно
реализованы разработчиками какой-то СУБД, разработчики клиентского приложения вынуждены будут переделывать свою про42
грамму под требования обновленного стандарта (фактически, второй
раз создавать функции, которые уже были один раз реализованы).
Каждый из рассмотренных путей создания клиентских приложений для архитектуры «клиент-сервер» имеет свои преимущества и
недостатки. Общего и оптимального для всех решения не существует. То, какой путь развития выбрать, должны решать разработчики
клиентских приложений, причем их выбор должен определяться
не только техническими требованиями, но и существующими рыночными условиями для каждого приложения в отдельности. Возможен и часто используется промежуточный вариант, сочетающий
возможности двух рассмотренных выше путей развития: разработчики ориентируют свое приложение не на одну конкретную СУБД, а
на несколько доступных (как правило, наиболее распространенных
в данной сфере). Такое решение достаточно разумно, поскольку на
рынке СУБД основную роль играют лишь несколько ведущих производителей. Поэтому разработчики клиентских приложений могут
выбрать в качестве серверов данных для своих приложений СУБД
только от 2-3 основных фирм и не рассматривать другие. Тогда можно ориентироваться только на нововведения, предлагаемые именно
этими разработчиками СУБД, и в процессе выполнения клиентского
приложения динамически подстраивать SQL-команды под тот тип
СУБД, который используется на конкретном сервере данных.
Такой подход позволяет клиентскому приложению, с одной стороны, использовать специфические расширения, предлагаемые СУБД,
там, где это необходимо и требуется, а с другой стороны, разработчики этого приложения предлагают своим заказчикам выбор из нескольких СУБД и при этом не попадают в жесткую зависимость от
производителя одной из них. Однако в этом случае несколько увеличивается объем разрабатываемого кода на языке SQL (а иногда – и исходного кода клиентского приложения). Это происходит, поскольку
в тех местах кода, где требуется применять доступные расширения
языка SQL, клиентское приложение должно выбрать одно из них в
зависимости от типа СУБД (но в коде должны быть предусмотрены
расширения для всех поддерживаемых типов СУБД). Тем не менее,
такой подход зачастую оправдан и окупает некоторое увеличение затрат на разработку кода клиентского приложения.
3.2.2. Технологии доступа к серверу данных
Используя стандартизованный язык SQL, разработчик клиентской части приложения, работающего в архитектуре «клиент-сер43
вер» может строить запросы к серверу данных, не ориентируясь на
определенный тип СУБД. При этом если используются стандартизованные команды на языке SQL, то взаимодействие клиентской
части с сервером на уровне запросов не будет зависеть от типа используемого сервера данных (СУБД). Однако остается открытым вопрос о том, как SQL-запросы будут передаваться от клиента серверу,
и каким образом клиент будет получать ответы.
Наиболее очевидным решением было бы использовать для этой
цели динамически загружаемые библиотеки. Клиентское приложение обращается к функции соответствующей библиотеки и передает ей запрос к серверу в виде предложения на языке SQL. В задачу
библиотеки входит установить связь с сервером, передать ему запрос, дождаться ответа и вернуть результат клиенту в качестве результата выполнения функции. Такой способ взаимодействия с сервером данных возможен, и соответствующие библиотеки функций
существуют. Однако такое простое решение обладает одним существенным недостатком: для каждого типа сервера данных должна
использоваться своя динамически загружаемая библиотека со своими функциями, что делает клиентское приложение зависимым от
типа СУБД. Тем самым нивелируются преимущества, которые дает
использование стандартизованных SQL-запросов.
В настоящее время на рынке СУБД доминируют несколько крупных производителей, среди которых всегда можно выбрать сервер
данных, удовлетворяющий тем или иным требованиям, предъявляемым для решения прикладной задачи. Поэтому зачастую разработчики клиентской части программного обеспечения, работающего в архитектуре «клиент-сервер» пренебрегают указанным недостатком, используя описанную выше схему для взаимодействия
с сервером данных. Они разрабатывают свои приложения, ориентируясь на определенный тип СУБД. Этому способствует тот факт, что
многие фирмы-производители СУБД (такие, например, как Oracle
или Microsoft) предлагают не только серверы данных, но и системы программирования, ориентированные на работу с конкретным
типом СУБД. Такой путь имеет свои преимущества, так как прямое обращение к динамической библиотеке, взаимодействующей с
сервером данных, дает наибольшую эффективность по скорости выполнения запросов клиента.
Однако зависимость от типа СУБД не всегда допустима для клиентской части в архитектуре «клиент-сервер», особенно в том случае, когда разработчики стремятся добиться переносимости своего
программного обеспечения и исключить зависимость от конкрет44
ной СУБД. Для этой цели служат универсальные интерфейсы взаимодействия клиентской и серверной части в архитектуре «клиентсервер». Существует несколько вариантов таких интерфейсов от
разных производителей. В этой области развитие вычислительных
систем тоже не стояло на месте. По мере распространения архитектуры «клиент-сервер» появилось значительное количество технологий обеспечения взаимодействия клиентской и серверной части
приложения, построенного по этой архитектуре. И хотя при решении этой задачи не сложился такой же общепринятый стандарт, как
при решении задачи создания языка манипулирования данными,
все-таки количество доступных и широко используемых для этой
цели технологий ограничено. Одни из них являются универсальными, другие ориентированы на определенные системы программирования. Некоторые такие технологии будут рассмотрены далее.
Одним из достаточно распространенных средств, позволяющих
унифицировать организацию взаимодействия с различными СУБД,
является интерфейс ODBC. ODBC (Open Database Connectivity) – это
интерфейс доступа к базам данных, наиболее распространенный в
среде ОС типа Windows. Доступ к БД осуществляется при помощи
специального ODBC-драйвера, который транслирует запросы к БД
на язык, поддерживаемый конкретной СУБД.
Для установления соединения с БД технология ODBC использует
ODBC-драйверы и источники данных, которые позволяют настроиться на сеанс конкретного пользователя СУБД. Для этого источник содержит имя пользователя и его пароль, а также, при необходимости, другую информацию, требуемую для присоединения к
СУБД. ODBC-драйвер представляет собой динамически загружаемую библиотеку, которая может использоваться приложением для
получения доступа к конкретному серверу данных. Каждому типу
СУБД соответствует свой ODBC-драйвер.
Взаимодействие клиентской части приложения с СУБД осуществляется при помощи набора системных вызовов, которые выполняются по отношению к источнику данных. Источник данных взаимодействует с драйвером ODBC, транслирует ему запросы клиента
и получает ответы, а тот, в свою очередь, обращается к СУБД. При
необходимости работать с другим типом СУБД достаточно указать
другой тип ODBC-драйвера в источнике данных, при этом не требуется изменять клиентскую часть приложения.
Такая двухступенчатая схема взаимодействия клиента с сервером данных обеспечивает независимость клиентской части от типа
СУБД на сервере данных, но в целом снижает эффективность рабо45
ты приложения, поскольку запрос, посланный клиентом, дважды
передается различным библиотекам функций прежде, чем попадет
на сервер. Решение вопроса о выборе способа взаимодействия с сервером данных остается за разработчиком клиентской части приложения и зависит от предъявляемых к нему требований.
Физически ODBC представляет собой набор динамических библиотек (DLL – Dynamic Link Library), которые обслуживают подключение и работу с конкретным типом базы данных. При запросе
на подключение к определенной, заранее описанной базе активизируется определенная библиотека – драйвер этого типа БД. Обращение к определенной базе данных происходит по имени, так называемого источника данных ODBC или DSN.
DSN (Data Source Name) – это именованный источник данных
ODBC. Источник данных содержит данные и сведения о подключении, необходимые для доступа к данным. Примерами таких источников данных могут служить базы данных Microsoft Access, Oracle
Database, Microsoft SQL Server, электронная таблица и текстовый
файл. К примерам сведений о подключении относятся: папка на
сервере, имя базы данных, сетевое имя, пароль, а также различные
параметры драйвера ODBC, описывающие способ подключения к
источнику данных. Управление источниками данных ODBC (да и
вообще настройкой всей системы ODBC) осуществляется с помощью
специальной программы – ODBC-администратора.
В настоящее время ODBC представляет собой развитую и хорошо
стандартизированную технологию, доступную для вычислительных систем различных архитектур. Данная технология сейчас широко используется в системах, построенных на основе архитектуры
«клиент-сервер», но дальнейшее развитие этой технологии под вопросом, так как основные производители предлагают на рынок новые, более современные технологии.
Другим примером средств, позволяющих унифицировать организацию взаимодействия с различными СУБД, являются технологии OLE DB и ADO.
Технологии OLE DB и ADO были созданы компанией Microsoft
и первоначально также получили распространение в среде ОС типа
Windows. Основой для их создания, в свою очередь, послужила
технология OLE (Object Linking and Embedding – связывание и
внедрение объектов), которая создавалась и развивалась в ОС типа
Windows для обеспечения взаимосвязи между прикладными программами (в первую очередь – для связи между собой приложений Microsoft Office). После того, как в основу OLE была положена
46
принципиально новая технология COM (Component Object Model –
Модель многокомпонентных объектов), стало возможным использовать OLE для связи любых типов программ.
В результате применения технологии OLE к решению задачи организации взаимодействия клиентской и серверной частей
приложений была получена новая технология – OLE DB (OLE for
Databases – OLE для баз данных).
С точки зрения компании Microsoft, OLE DB представляет собой
следующую ступень развития технологии ODBC. Обе технологии образуют относительно независимый программный слой, использующий однотипные интерфейсы прикладных программ (API) для доступа к разным типам СУБД. Их работа обеспечивается программными модулями, которые учитывают специфические особенности
каждой СУБД. В OLE DB полностью реализован принцип универсального доступа к разнотипным СУБД. Наибольшие различия технологий ODBC и OLE DB проявляются в использовании некоторых
основных терминов и в окружающем контексте.
Технология ADO родилась в результате объединения OLE DB с
еще одной технологией, созданной компанией Microsoft – ActiveX.
Отсюда происходит и название технологии ADO – ActiveX Data
Object (объекты данных ActiveX).
С точки зрения разработчика клиентской части приложения в
архитектуре «клиент-сервер» ADO представляет собой прикладной
объектный интерфейс более высокого уровня, чем OLE DB. Этот интерфейс упрощает доступ к средствам OLE DB разработчикам, использующим языки высокого уровня. В настоящее время разработчик этих технологий – компания Microsoft – выпустила уже несколько версий библиотек ADO и продолжает развивать эту технологию.
Однако развитие этих технологий ограничено, прежде всего,
тем, что они ориентированы в основном только на вычислительные
системы, построенные на базе ОС типа Windows. И хотя появляются версии ADO для других типов ОС, переносимость приложений,
созданных на основе этой технологии, на вычислительные системы,
не использующие Windows, остается проблемой.
Способы организации взаимодействия клиентской и серверной частей приложений на основе архитектуры «клиент-сервер»
не ограничиваются только перечисленными технологиями. Сложно даже перечислить их все в рамках данного пособия, а тем более
подробно описать. Более подробно об организации приложений на
основе архитектуры «клиент-сервер» можно узнать в специализированной литературе [5, 8].
47
Переход клиентской части программного обеспечения в архитектуре «клиент-сервер» с одного типа сервера данных на другой возможен только в том случае, если для взаимодействия с СУБД клиентская часть использует запросы, удовлетворяющие стандарту,
поддерживаемому обоими серверами.
3.2.3. Поддержка технологии «клиент-сервер»
в системах программирования
Ситуация, связанная с распространением на рынке приложений, построенных на основе архитектуры «клиент-сервер», оказала свое влияние и на структуру систем программирования. В ходе
развития архитектуры «клиент-сервер» появился язык манипулирования данными, а также множество технологий взаимодействия
клиентских приложений и сервера данных. Появление и развитие
различных технологий доступа клиентской части приложений к
серверу данных не осталось без внимания разработчиков систем
программирования (особенно если учесть, что такие создатели новых технологий, как компания Microsoft, являются одновременно
и разработчиками систем программирования). Поэтому на рынке
систем программирования появились системы, поддерживающие
основные существующие технологии доступа клиентской части
приложения к серверу данных.
Для создания приложения в архитектуре «клиент-сервер» разработчику необходимо решить два основных вопроса:
– выбрать способ формирования команд обработки данных, которые должны быть понятны серверу данных;
– обеспечить взаимодействие клиентского приложения с сервером данных.
Поскольку в подавляющем большинстве приложений, построенных по архитектуре «клиент-сервер», разработчики не создают
сервер данных, а используют в качестве него одну из доступных
на рынке СУБД, способ формирования команд обработки данных
не может быть прерогативой разработчиков клиентского приложения – он должен быть согласован с поставщиками серверов данных.
Чаще всего в качестве средства манипулирования данными используется язык SQL, который был рассмотрен выше, но существуют и
другие варианты решения этой задачи (о некоторых из них будет
рассказано далее).
Если разработчик клиентской части приложения останавливает
свой выбор на одной из существующих стандартных технологий, то
48
в этом случае он не только избегает зависимости создаваемого приложения от типа СУБД, но и получает возможность выбора среди
систем программирования, доступных на рынке. Это обусловлено
тем, что практически все современные системы программирования
поддерживают такие распространенные технологии как ODBC или
ADO и предоставляют разработчикам инструменты и библиотеки, снижающие трудоемкость создания клиентов на основе таких
технологий. В дальнейшем возможности созданного приложения
будут ограничены только возможностями выбранной технологии:
например, технология ADO имеет широкие возможности, но ее применение ограничено только вычислительными системами, построенными на базе ОС типа Windows.
Таким образом, выбирая стандартную технологию, разработчик
получает выигрыш в выборе СУБД и средств разработки, но проигрывает в производительности, так как универсальные методы доступа к СУБД менее эффективны, чем специализированные.
Если же разработчик клиентской части приложения выберет
для взаимосвязи с сервером данных специализированную технологию, ориентированную на определенный тип СУБД, то он, безусловно, получит более высокую скорость обмена данными между сервером и клиентом. Однако в этом случае он будет ограничен и в выборе типа СУБД, и в выборе средств разработки. Первое утверждение
очевидно, так как специализированный метод доступа ориентирован на определенный тип СУБД (а зачастую – и на определенную
версию СУБД). Второе утверждение основано на том, что специализированные методы доступа к СУБД либо совсем не поддерживаются системами программирования от других производителей, либо
имеют ограниченные инструменты поддержки, снижающие эффективность разработки. В этом случае лучше всего использовать систему программирования, созданную тем же производителем, что
и СУБД (в настоящее время многие ведущие производители СУБД
предлагают и свои средства разработки).
Выигрыш в эффективности доступа клиента к серверу данных
при использовании специализированных методов обусловлен еще
одним немаловажным фактором: все производители СУБД заинтересованы в создании как можно большего количества клиентских
приложений, ориентированных именно на их СУБД. Поэтому все
полезные для клиентов нововведения появляются в первую очередь
именно в специализированных средствах доступа и только потом
уже, если это возможно, переносятся в инструменты, обеспечивающие поддержку стандартных технологий.
49
Каждый из описанных путей создания клиентского приложения в архитектуре «клиент-сервер» не лишен своих преимуществ и
недостатков. Выбор одного из них остается за разработчиком и зависит от тех условий, для которых создается то или иное приложение.
По мере развития и распространения на рынке технологии «клиент-сервер» различные средства, ориентированные на создание
приложений по этой технологии, стали входить в состав систем программирования. Поэтому на рынке появился (и продолжает оставаться) достаточно широкий выбор систем программирования, обеспечивающих, в том числе, разработку приложений для архитектуры «клиент-сервер».
Во-первых, системы программирования стали предлагать средства для создания команд и запросов на языке SQL. С точки зрения
системы программирования, не ориентированной на технологию
«клиент-сервер», команда SQL – это просто строка, которая никак не
обрабатывается на этапах компиляции и построения исполняемой
программы (клиентской части приложения), а просто включается в
ее состав. Уже только во время выполнения программы эта строка
при необходимости выполнения соответствующей команды передается клиентом на сервер данных, где интерпретируется как команда SQL. Такой подход, в принципе, возможен и не требует никаких
дополнительных средств от системы программирования, но создает
проблемы разработчику, так как если он допустил ошибку в команде
SQL, то обнаружена она будет только в момент выполнения программы. Это идет вразрез со сложившимися правилами в самих системах
программирования, где все синтаксические и даже часть семантических ошибок входного языка обнаруживаются на этапе компиляции.
Поэтому в состав систем программирования стали входить средства автоматизированного построения команд SQL, которые могут
помочь разработчику подготовить текст команды, а после его построения – представить этот текст в наглядном виде, выделяя все
ключевые лексемы языка SQL, аналогично тому, как это происходит для текста исходной программы. Многие системы программирования пошли дальше и предлагают более мощные средства: если
в тексте исходной программы или в ее пользовательских ресурсах
команда SQL выделена не просто как строка, а именно как команда
SQL, то система программирования анализирует ее синтаксис и сообщает пользователю об имеющихся ошибках еще на этапе компиляции. Более того, если известна структура БД, на которой должна
выполняться эта команда SQL, то система программирования может проверить не только ее синтаксис, но и некоторые возможные
50
семантические ошибки. Такой подход позволяет упростить обнаружение ошибок и сокращает трудозатраты на разработку клиентских приложений.
Во-вторых, все современные системы программирования содержат
в своем составе статические и динамические библиотеки, которые
позволяют организовать взаимодействие клиентской части приложения с сервером данных. Большинство систем программирования
предлагают разработчикам не одну, а несколько таких библиотек,
каждая из которых использует свою технологию обмена с сервером
данных. Эти средства поставляются в составе системы программирования и поддерживают возможность работы с широким диапазоном
известных серверов данных через один или несколько доступных
интерфейсов обмена данными. Разработчик прикладной программы
выбирает одно из доступных средств, плюс возможный тип сервера
(или несколько возможных типов), и тогда его задача сводится только к созданию клиентской части приложения, построенной с использованием выбранной библиотеки взаимодействия с сервером данных.
Кроме технических вопросов, связанных с разработкой приложений для архитектуры «клиент-сервер», возникают также вопросы организационно-правового плана. Это связано с тем, что, создав
клиентскую часть приложений, разработчик может дальше распространять ее только в комплексе с сервером данных и с теми библиотеками, которые он использовал для организации взаимодействия с
этим сервером. Соответственно, пользователь прикладной программы не сможет использовать ее без наличия сервера и необходимых
библиотек.
Что касается сервера данных, то для полномасштабного использования прикладной программы, построенной по архитектуре
«клиент-сервер» пользователь, как правило, должен приобрести
лицензию у его правообладателя. Таким образом, он приобретает
лицензии на две программы: клиентскую и серверную, причем зачастую у разных поставщиков. Нередко конечный пользователь
приложения получает целый комплекс программных продуктов от
множества разработчиков. При этом есть возможность совмещать
их и использовать один и тот же сервер данных для обслуживания клиентских приложений разных типов. Количество лицензий
на клиентские приложения, как правило, должно соответствовать
количеству компьютеров, где используются эти приложения. Но и
стоимость серверной лицензии часто зависит от количества клиентов, либо от мощности компьютера сервера, на котором установлена
серверное приложение.
51
Зачастую пользователь прикладной программы хочет сократить
стоимость лицензии на серверную часть, если он собирается использовать ограниченное количество клиентов, либо приобретает
программу для тестовых или демонстрационных целей. Кроме того,
возникает вопрос о лицензии для разработчиков клиентского приложения: ведь для тестирования и отладки своей программы им
тоже необходимо использовать сервер данных.
По мере развития архитектуры «клиент-сервер» в этом направлении также появились различные решения. Во-первых, многие простейшие СУБД, доступные для разработки клиентских программ,
либо предлагают дешевые лицензии, либо поставляются бесплатно
(или позволяют выполнять бесплатное распространение серверной
части в комплекте с клиентской). Для целей тестирования, отладки
и демонстрации клиентского приложения этого часто бывает достаточно. Во-вторых, разработчики промышленных СУБД, лежащих в
основе большинства серверов данных, предлагают широкий спектр
лицензий от полных версий, ориентированных на работу десятков
и сотен клиентов, до ограниченных версий, позволяющих работать
единичным клиентам – в простейшем виде они зачастую поставляются бесплатно. Кроме того, разработчики промышленных СУБД,
заинтересованные в распространении своих программных продуктов, предлагают льготные условия лицензирования и партнерские
программы для разработчиков клиентских приложений, которые
будут ориентированы на их СУБД.
Проблема с распространением библиотек, используемых для взаимодействия клиентской и серверной частей приложения, обычно
решается еще проще, чем схожая проблема для сервера данных.
Многие библиотеки, необходимые для наиболее известных технологий взаимодействия клиентов с сервером данных, входят в состав
ОС. Разработчики клиентского приложения, ориентированного на
определенную целевую вычислительную систему, как правило, выбирают для взаимодействия с сервером одну из технологий, доступных именно в этой вычислительной системе. Если же используется
какая-то библиотека, входящая в состав системы программирования, то в большинстве случаев, разработчики системы программирования позволяют распространять модули этой библиотеки, необходимые для взаимодействия с сервером данных, вместе с клиентским приложением, созданным в данной системе программирования, без каких-либо дополнительных ограничений.
В целом в настоящее время в составе систем программирования
присутствует большое количество средств, ориентированных на
52
разработку клиентских приложений для архитектуры «клиент-сервер», а приложения, созданные для этой архитектуры, занимают
существенную долю рынка программных средств.
3.2.4. Дополнительные возможности
серверов данных
Как уже было сказано выше, в подавляющем большинстве случаев сервер данных представляет собой СУБД, под управлением которой находится одна или несколько баз данных, размещенных на
этом сервере. Архитектура «клиент-сервер» не требует, чтобы сервер данных был построен именно на основе СУБД и не запрещает
создавать сервера, созданные на основе других принципов, но на
практике такие системы встречаются значительно реже. Поэтому
развитие архитектуры «клиент-сервер» целиком и полностью связано с развитием СУБД.
В качестве СУБД на сервере данных может быть использована, в
том числе, и простейшая («настольная») СУБД с файловым методом
доступа типа Microsoft Access или PARADOX. В этом случае для
доступа к серверу данных могут применяться те же команды и технологии, что и для других типов СУБД. Но в такой конфигурации,
хотя структурно приложение и будет соответствовать технологии
«клиент-сервер», реально доступ к БД, находящейся под управлением файловой СУБД, будет происходить по методам, характерным
для архитектуры «файл-сервер». В таком варианте построения приложений из всех преимуществ архитектуры «клиент-сервер» теряются преимущества, связанные со снижением требований к вычислительным ресурсам компьютера клиента и нагрузки на сеть. Сервера данных, построенные на основе СУБД с файловым доступом
(«файловых СУБД»), могут использоваться при тестировании и отладке клиентских приложений, а также в тех случаях, когда количество клиентов невелико (обычно не более десятка) и заказчик не
заинтересован в приобретении и использовании полномасштабной
СУБД на сервере данных. В дальнейшем, подобные сервера данных
здесь не рассматриваются.
Полноценное приложение, созданное в архитектуре «клиентсервер», имеет все преимущества данной архитектуры, указанные
выше, но требует наличия СУБД со специализированным методом
доступа и развитых средств взаимодействия с ней. Такие СУБД часто называют «промышленные СУБД», а построенные на их основе
сервера данных – «промышленные сервера данных».
53
По мере развития архитектуры «клиент-сервер» на рынке стали
появляться СУБД различных типов. Все СУБД можно разделить на
несколько типов, среди которых основными типами будут: реляционные, сетевые (не путать с распределенными БД) и объектные
(объектно-ориентированные). Кроме того, СУБД подразделяются по
способам доступа и хранения информации. В настоящее время наибольшее распространение на рынке СУБД получили реляционные
БД. В качестве примеров таких СУБД, рассчитанных на применение
в качестве промышленных серверов данных, можно назвать СУБД
Sybase, Microsoft SQL Server, Oracle, DB2. Принципы, лежащие в
основе реляционных СУБД, стали определяющими в выборе методов взаимодействия между клиентской и серверной частью в архитектуре «клиент-сервер». Этих базовых принципов стараются придерживаться все ведущие разработчики СУБД, в том числе и СУБД,
построенных на основании иных технологий, чем реляционные БД.
СУБД и все, что связано с ними – это отдельная очень интересная
тема, выходящая за рамки данного учебного пособия. Для ознакомления с ними лучше обратиться к специализированной литературе
[5]. Здесь же будут рассмотрены только отдельные аспекты, интересные с точки зрения технологий разработки программного обеспечения и систем программирования.
Язык SQL хорошо стандартизован – и этот факт определил его
широкое использование в приложениях, построенных на основе
архитектуры «клиент-сервер». Но этот же факт является причиной
одного из недостатков использования этого языка: как и все, что хорошо стандартизовано, язык SQL развивается достаточно медленно
и скорость его развития зачастую отстает от потребностей клиентских приложений
Главной движущей силой развития SQL являются разработчики СУБД, так как именно они являются наиболее значительными
игроками на рынке программных средств, связанных с архитектурой «клиент-сервер». Разработчики СУБД стараются следить за потребностями разработчиков клиентских приложений, так как они
заинтересованы в максимальном количестве приложений, взаимодействующих именно с их СУБД. На основе собранной информации
они предлагают различные нововведения в язык SQL, но пока эти
нововведения пройдут все необходимые этапы стандартизации,
пройдет значительное время. Разработчики СУБД, стремясь удовлетворить разработчиков клиентских приложений, зачастую не
ждут завершения этого процесса и вводят новшества в свои СУБД
до появления нового стандарта SQL.
54
И в этом случае перед разработчиками клиентских приложений
возникает дилемма, о которой уже было сказано выше: использовать только что появившиеся, но еще не стандартизованные возможности языка, либо ждать завершения процесса их стандартизации (и еще не факт, что эти новшества войдут в стандарт).
Кроме проблем, связанных со стандартизацией языка SQL, на
серверах данных могут существовать дополнительные возможности, которые не охвачены этим языком. Дело в том, что практически все современные СУБД предусматривают возможность создания в БД хранимых (или «сохраняемых» - stored) процедур, которые выполняются по наступлению определенных событий, по командам клиентов или по расписанию. Язык, на котором создается
исходный текст хранимых процедур, фактически является языком
программирования и лежит вне рамок стандарта языка SQL (фактически, язык SQL является подмножеством языка хранимых процедур). И здесь разработчики СУБД реализуют все возможности своих
СУБД без всякого согласования друг с другом.
Этот язык, лежащий в основе текстов хранимых процедур большинства современных СУБД, по своим возможностям практически
ни в чем не уступает многим языкам программирования. После
создания хранимой процедуры ее текст обрабатывается и анализируется СУБД, которая в этом случае выступает в роли полноценного компилятора. Если исходный текст хранимой процедуры не содержит синтаксических и семантических ошибок, он сохраняется
на сервере в виде внутреннего представления этой процедуры. При
необходимости выполнить хранимую процедуру СУБД выполняет
созданное ранее ее внутреннее представление, выступая при этом в
роли интерпретатора.
Если разработчики приложения, функционирующего в архитектуре «клиент-сервер», используют хранимые процедуры, у них
появляется возможность вынести на сервер не только функции
логики работы с данными, но и значительную часть функций прикладной логики («бизнес-логики») своего приложения. Поскольку
возможности языка хранимых процедур мало в чем уступают возможностям языков программирования, используемых для создания клиентских приложений, в предельном случае на сервер данных может быть вынесена вся прикладная логика приложения, а
на клиентской части останутся только функции, непосредственно
связанные с интерфейсом пользователя.
Разработчики современных СУБД предоставляют разработчикам
клиентских приложений для создания хранимых процедур в своих
55
СУБД не просто текстовые редакторы, а целые наборы инструментальных средств. В состав этих средств входят интегрированные
(чаще всего графические) среды для создания исходного кода хранимых процедур, компиляторы и отладчики этого кода, различные
вспомогательные инструменты. Фактически, возможности таких
инструментариев полностью соответствуют возможностям современных систем программирования с той только разницей, что они ориентированы на создание интерпретируемого кода для единственной
целевой вычислительной системы – СУБД соответствующего типа.
Использование хранимых процедур дает разработчикам клиентских приложений в архитектуре «клиент-сервер» широкие возможности, но при этом жестко ограничивает для них выбор сервера
данных одним единственным типом СУБД, так как исходный код
хранимых процедур не является переносимым.
3.3. Трехуровневые и многоуровневые технологии
3.3.1. Расширенные возможности технологии
«клиент-сервер»
Приложения, созданные на основе архитектуры «клиент-сервер», получили ряд преимуществ по сравнению с приложениями, не
использующими распределенных вычислений, а также приложениями, созданными на основе архитектуры «файл-сервер». Тот факт,
что основные производители систем программирования включили
в свои системы средства поддержки разработки приложений в этой
архитектуре, обусловил широкое распространение таких приложений на рынке программных средств.
В то же время, как уже было сказано, сама по себе архитектура
«клиент-сервер» не лишена некоторых недостатков:
– функции управления данными возложены на сервер данных,
но обработка данных (прикладная логика или бизнес-логика) попрежнему выполняется клиентами, что не позволяет существенно
снизить требования к ним, если логика приложения предусматривает достаточно сложные вычисления;
– при необходимости изменить или дополнить логику обработки
данных необходимо выполнить обновление клиентских приложений на всех рабочих местах, что может быть достаточно трудоемко;
– если необходимо изменить только внешний вид интерфейса пользователя (отображение данных), но оставить неизменной логику обра56
ботки данных, при этом чаще всего требуется заново создать и установить на рабочем месте новый вариант клиентской части системы.
Наличие хранимых процедур и других мощных средств, расширяющих возможности серверов данных, позволяет перенести на
них так же и значительную долю функций прикладной логики. Это
несколько нивелирует большинство указанных недостатков архитектуры «клиент-сервер», но не позволяет полностью избавиться от
них по следующим причинам:
– внутренние языки СУБД, используемые для создания хранимых процедур и других подобных средств, хотя и сравнимы в настоящее время по своим возможностям с языками современных систем программирования, но всё же уступают им – поэтому не все
функции прикладной логики могут быть реализованы на сервере
данных столь же эффективно, как на клиенте;
– хранимые процедуры, триггеры и другие средства СУБД, созданные на ее внутреннем языке, после предварительной компиляции сохраняются во внутреннем коде СУБД (но не в машинных кодах), а во время исполнения интерпретируются СУБД – поэтому они
проигрывают в производительности результирующим программам,
созданным в машинных кодах.
При разработке приложений в архитектуре «клиент-сервер» вовсе не следует стремиться все функции прикладной логики возложить на сервер данных. Следует помнить, что СУБД интерпретирует код, а потому серверу всегда потребуется больше ресурсов для
выполнения тех же функций, которые на клиенте выполняются в
машинных кодах. Разумное распределение функций между клиентской и серверной частью приложения зависит от многих факторов, в том числе от количества клиентов, мощности клиентских и
серверного компьютеров и др.
Еще одним средством, которое может расширить возможности
приложений, построенных на основе архитектуры «клиент-сервер»,
является использование терминального доступа в сочетании с возможностями этой архитектуры. В этом случае компьютер-клиент, на
котором выполняется клиентская часть приложения, одновременно
становится терминальным сервером, к которому могут подключаться компьютеры-терминалы. Тогда вся логика организации пользовательского интерфейса выполняется компьютерами-терминалами,
прикладная логика приложения выполняется на терминальном сервере (который одновременно является клиентом), а логика обработки данных и файловые операции выполняются на сервере данных.
Поскольку клиентов может быть несколько, то и терминальных сер57
веров в такой структуре может быть несколько. Тогда пользователь
компьютера-терминала либо подключается только к заданному терминальному серверу, либо имеет возможность выбрать один из доступных терминальных серверов для подключения.
В общем случае схема организации распределенных вычислений
с использованием комбинации архитектуры «клиент-сервер» и терминального доступа представлена на рис. 5.
Схема, представленная на рис. 5, позволяет избежать основных
недостатков, присущих приложениям, построенным на основе архитектуры «клиент-сервер». При такой организации распределенных вычислений к вычислительным ресурсам компьютеров-терминалов предъявляются минимальные требования, прикладная логика приложения выполняется на терминальных серверах, которых
может быть несколько, но в любом случае значительно меньше, чем
терминальных компьютеров, за которыми работают пользователи.
При необходимости изменить или дополнить логику обработки данных необходимо выполнить обновление клиентских приложений
только на терминальных серверах.
Терминальные
компьютеры
пользователей
приложения
Терминальный сервер-2
Терминальный сервер-1
Клиент-1
(копия 1)
Сеть
Клиент-1
(копия 2)
Клиент-2
(копия 1)
Клиентская Клиентская
часть СУБД часть СУБД
Клиент-2
(копия 2)
Клиентская Клиентская
часть СУБД часть СУБД
СУБД
Данные
Рис. 5. Схема организации распределенных вычислений
на основе комбинирования технологии «клиент-сервер»
с технологией терминального доступа
58
Основной недостаток такой организации распределенных вычислений связан с основным недостатком терминального доступа:
для каждого компьютера-терминала на терминальном сервере запускается на выполнение своя копия клиентской части приложения. Все клиентские части приложения, выполняемые на каждом
терминальном сервере, функционируют независимо друг от друга
и взаимодействуют между собой только через сервер данных. Это
ведет к не вполне эффективному использованию вычислительных
ресурсов терминальных серверов.
Во-первых, каждая копия клиентского приложения выполняется на терминальном сервере в своем адресном пространстве, поэтому на терминальном сервере будет запущено столько же экземпляров этого приложения, сколько компьютеров-терминалов (а,
следовательно, и пользователей) подключится к нему. При этом для
каждой запущенной копии приложения (в комплексе со всеми используемыми ею библиотеками и данными) необходимо выделить
оперативную память. Таким образом, один и тот же код (и одни и
те же используемые им библиотеки) будет загружаться в память несколько раз (по количеству подключений), что ведет к неэффективному использованию оперативной памяти терминального сервера.
Во-вторых, все клиентские приложения, выполняющиеся на
терминальном сервере, никак не взаимодействуют между собой
(взаимодействие возможно только через сервер данных). Поэтому
даже если всем им необходимы одни и те же данные, они будут запрашивать их с сервера данных независимо друг от друга. В результате может оказаться, что одни и те же данные могут несколько раз
поступать на терминальный сервер с сервера данных для каждой
выполняемой на нем копии клиентского приложения.
Несмотря на указанные недостатки, организация распределенных вычислений на основе сочетания технологии «клиент-сервер» и
технологии терминального доступа оказалась достаточно эффективным средством. Практически все современные системы, построенные
на основе технологии «клиент-сервер», предполагают возможность
выполнения клиентской части приложения на терминальном сервере (об особенностях функционирования приложений на терминальном сервере уже было сказано в соответствующем разделе). Главным
преимуществом такой схемы организации распределенных вычислений является практическое отсутствие дополнительных требования к разработке приложения, а повышенная требовательность к ресурсам терминального сервера зачастую вполне компенсируется их
относительной дешевизной и простотой администрирования.
59
Сочетание технологии «клиент-сервер» с технологией терминального доступа позволяет существенно нивелировать влияние
указанных выше недостатков, присущих технологии «клиент-сервер». Если при этом разработчики приложения, кроме того, грамотно разделяют функции прикладной логики (бизнес-логики) приложения между клиентской и серверной частью и полноценно используют дополнительные возможности СУБД, основные минусы этой
технологии удается свести к минимуму. Тем не менее, полностью
исключить этими средствами все недостатки технологии «клиентсервер» невозможно.
Для более эффективного устранения перечисленных выше недостатков была предложена следующая модель разработки приложений – трехуровневая, а в общем случае, многоуровневая архитектура организации распределенных вычислений.
3.3.2. Понятие о трехуровневой и многоуровневой
архитектурах приложений
Трехуровневая архитектура и соответствующая ей технология
разработки приложений явились логическим продолжением идей
организации распределенных вычислений, заложенных в архитектуре «клиент-сервер». Главной целью появления этой новой технологии являлась задача полностью исключить недостатки, присущие приложениям, разработанным по технологии «клиент-сервер».
Главным недостатком архитектуры приложений типа «клиентсервер» стал тот факт, что в клиентской части приложения совмещались как довольно сложные функции прикладной логики обработки
данных (бизнес-логики), так и более простые функции организации
интерфейса пользователя. Для выполнения этих функций к вычислительной системе должны предъявляться разные требования, и в
том случае, когда в приложении выполняется достаточно сложная
обработка данных, эти требования со стороны «клиентской» части
приложения могут быть непомерно велики. Если же разделить эти
функции на разные компьютеры средствами ОС с помощью терминального доступа, то в этом случае параллельное и несогласованное
между собой выполнение функций прикладной логики ведет к неэффективному использованию вычислительных ресурсов. Можно
также вынести часть или всю бизнес-логику приложения на сервер
данных, используя дополнительные возможности установленной на
нем СУБД, но в этом случае разработчики приложения становятся
жестко привязанными к определенному типу СУБД. Кроме того,
60
код, исполняемый (а фактически, интерпретируемый) под управлением СУБД на сервере данных, выполняется менее эффективно, чем
исполняемый код клиентской части приложения.
Также следует отметить, что функции обработки данных (бизнеслогика приложения), как правило, изменяются не столь значительно
по мере прохождения жизненного цикла программного обеспечения,
развития приложения и выхода его новых версий. В то же время, интерфейсная часть может серьезно видоизменяться и, в предельном
случае, подстраиваться под требования конкретного заказчика.
Еще одним фактором, повлиявшим на дальнейшее развитие архитектуры «клиент-сервер», стало распространение глобальных сетей и развитие всемирной сети Интернет. Многие приложения стали
нуждаться в предоставлении пользователю возможности доступа к
данным посредством глобальной сети. Возможностей архитектуры
«клиент-сервер» для этой цели во многих случаях недостаточно, поскольку клиент зачастую мог не иметь никаких вычислительных
ресурсов, кроме программы навигации по сети (браузера, browser).
Поэтому дальнейшим развитием архитектуры «клиент-сервер»
стало разделение клиентской части еще на две составляющих: сервер приложений (английский термин «application server»), реализующий прикладную логику обработки данных (бизнес-логику приложения), и «тонкий клиент» («thin client»), обеспечивающий интерфейс и доступ к результатам обработки (далее «тонкий клиент»
будем называть просто «клиентом»). Серверная часть осталась без
изменений, но теперь она обязательно должна называться не просто «сервер», а «сервер данных» или «сервер баз данных» («database
server»), чтобы не путаться с сервером приложений.
Простейшая структура программного обеспечения, построенного на основе трехуровневой архитектуры, представлена на рис. 6.
При этом, как уже было сказано, в состав программного обеспечения, построенного на основе трехуровневой архитектуры, входит
три основных составляющих:
– сервер данных;
– сервер приложений;
– клиенты (клиентская часть).
Сервер данных, как и в случае архитектуры «клиент-сервер»,
выполняет все операции, связанные с управлением данными: хранение данных, доступ к данным, защита и резервное копирование
данных. Как и в архитектуре «клиент-сервер», в качестве сервера
данных в трехуровневой архитектуре чаще всего выступает соответствующая СУБД. Таким образом, при использовании трехуров61
Клиентские
рабочие
места
ПО «Клиент-1»
ПО «Клиент-2»
Интерфейс с сервером
приложений
Интерфейс с сервером
приложений
Сеть
Сервер приложений
Клиентская часть СУБД
Сеть
Сервер
данных
СУБД
Данные
Рис. 6. Схема организации распределенных вычислений
на основе простейшей трехуровневой технологии
невой технологии разработчики, как правило, также не создают
программное обеспечение для сервера данных, как и при использовании технологии «клиент-сервер», а используют готовые программные продукты, имеющиеся на рынке.
Сервер приложений выполняет основные функции, связанные с
прикладной логикой обработки данных (бизнес-логикой приложения), а также именно он должен формировать все запросы к серверу
данных и обеспечивать представление данных для клиентских частей приложения в той или иной форме.
На клиентскую часть при такой организации распределенных вычислений приходятся функции, связанные с отображением данных
и организацией взаимодействия с пользователями приложения.
Описанное выше распределение функций между клиентскими и
серверными частями приложения, разработанного на основе трехуровневой технологии организации распределенных вычислений,
соответствует идеальному случаю. Однако такое идеальное распределение функций не всегда возможно и не всегда целесообразно.
Многие приложения, построенные на основе трехуровневой архитектуры, ранее были построены на основе технологии «клиент-сер62
вер», поэтому не все функции бизнес-логики у них вынесены на сервер приложений – часть этих функций может продолжать выполняться на клиентских частях или на сервере данных. Кроме того,
некоторые данные (особенно если эти данные не требуют сложных
запросов и вычислений и могут быть напрямую получены от СУБД)
клиентские части могут напрямую запрашивать у сервера данных,
минуя сервер приложений. Причем зачастую такой подход только
повышает эффективность работы приложения. Поэтому, говоря о
трехуровневой модели организации распределенных вычислений,
нельзя полностью исключать взаимодействие клиентских частей с
сервером данных. Большинство реально существующих приложений сочетает в себе возможности трехуровневой технологии с возможностями технологии «клиент-сервер».
Во многих случаях логика обработки данных (бизнес-логика) в
приложении может быть достаточно сложно организована. Тогда и
сервер приложений, обеспечивающий эту обработку данных (бизнес-логику), будет представлять собой сложно организованное программное обеспечение. В этом случае уже сам сервер приложений
можно разделить на несколько взаимодействующих частей и разнести эти части на несколько компьютеров. Причем возможно как
«горизонтальное» разделение (по составу обрабатываемых данных и
выполняемых функций) так и «вертикальное» разделение (по уровню обработки данных), либо их сочетание. Целесообразность такого
распределения вычислений, используемый способ разделение сервера приложений на части, а также количество этих частей зависят
от конкретного приложения и выполняемых им функций. В этом
случае можно говорить уже не о трехуровневой, а о многоуровневой
(английский термин «multi-tier») технологии организации распределенных вычислений.
В общем случае программное обеспечение, построенное на основе такой архитектуры, может иметь существенно более сложную
структуру, чем показано на рис. 6. Например, сервер приложений
может обмениваться данными не с одним, а с несколькими серверами данных, или клиентская часть может взаимодействовать с несколькими различными серверами приложений.
Обычно трехуровневую технологию организации распределенных вычислений не выделяют отдельно, а рассматривают как простейший случай многоуровневой технологии. Причина заключается в том, что, несмотря на возможные существенные различия в
структуре построения приложений, в основе этих технологий лежат одни и те же базисные принципы. В многоуровневой техноло63
гии организации распределенных вычислений сервер приложений
может представлять собой довольно сложную схему взаимодействующих вычислителей, тем не менее, при их создании и разработке
разработчики должны опираться на те же основные решения, что и
в простейшей трехуровневой схеме, представленной на рис. 6. Кроме того, переход от трехуровневой технологии организации распределенных вычислений к более сложным многоуровневым схемам
зачастую происходит при масштабировании системы и возрастании
нагрузки на сервер приложений. При небольшом количестве клиентских рабочих мест используется трехуровневая технология, но с
ростом количества клиентов возможно разбиение сервера приложений на несколько частей и переход к многоуровневой технологии.
Очевидно, что общие принципы построения приложения при этом
не должны существенно изменяться.
3.3.3. Особенности разработки приложений
для многоуровневой архитектуры
Несмотря на рассмотренные выше возможные усложнения трехуровневой архитектуры программного обеспечения, принципы, лежащие в ее основе, остаются неизменными и могут быть рассмотрены в рамках трехуровневой архитектуры. Увеличение количества
серверов данных или серверов приложений в каждом конкретном
случае, а также разбиение самого сервера приложений на несколько
уровней не вносит принципиальных изменений в организацию механизмов обмена данными между частями приложения. Просто увеличивается количество взаимодействующих частей приложения, а
также могут усложняться протоколы обмена данными между ними.
В архитектуре «клиент-сервер» разработчик прикладной программы создавал только клиентскую часть приложения, а в качестве сервера данных использовал, как правило, одну из имеющихся
на рынке СУБД. Главная особенность разработки приложений для
многоуровневой архитектуры заключается в том, что разработчики
должны создавать не одну, а несколько частей приложения, а также определять способы и протоколы взаимодействия между ними.
Даже в самом простейшем случае – в трехуровневой архитектуре – разработчик должен создать две составляющих приложения:
сервер приложений и клиентскую часть, а также выбрать механизм
обмена данными между ними и определить протокол обмена данными. В более сложных вариантах многоуровневой архитектуры разработчик должен будет создавать клиентскую часть и все необходи64
мые сервера приложений. Именно это является принципиальным
отличием разработки программного обеспечения для многоуровневой (и трехуровневой) архитектуры от разработки программного
обеспечения для архитектуры «клиент-сервер».
Поэтому разработка приложений для многоуровневой архитектуры является более сложной задачей, чем разработка приложений
для архитектуры «клиент-сервер». Для эффективного создания таких приложений должны выполняться следующие условия:
– целевая вычислительная система должна обеспечивать поддержку выбранной технологии взаимодействия частей приложения, а если для разных частей приложения будут использоваться
различные целевые вычислительные системы, то все они должны
поддерживать выбранную технологию;
– исходный язык программирования и система программирования должны предоставлять инструменты, ориентированные на создание приложений в трехуровневой архитектуре
Первое условие является обязательным, второе – настоятельно
рекомендуемым. Конечно, зная функции целевой ОС, обеспечивающие взаимодействие различных частей приложения, можно реализовать сервер приложений и клиентскую часть на основе системы
программирования, не предоставляющей средств поддержки многоуровневой архитектуры. Однако трудоемкость создания приложения в этом случае будет значительно выше, а переносимость его
частей – существенно хуже.
Развитие многоуровневой архитектуры привело к появлению в
составе современных ОС соответствующих средств, которые обеспечивают выполнение обращений клиентской части к серверу приложений. Это обеспечило выполнение необходимых условий для создания приложений в многоуровневой архитектуре и определило направления развития средств их разработки и поддержки в системах
программирования.
Сложная организация взаимодействия клиентской части с сервером приложений, с одной стороны, и большой интерес к разработке приложений для трехуровневой архитектуры, с другой стороны,
привели к появлению и развитию средств разработки, ориентированных на создание приложений для трехуровневой или многоуровневой архитектуры.
Современные системы программирования обеспечивают поддержку разработки приложений в трехуровневой и многоуровневой
архитектуре. Средства поддержки тех или иных стандартов, необходимых для работы клиентской части и сервера приложений, сейчас
65
присутствуют в составе многих систем программирования [1, 2, 8,
10, 12]. Принципы их использования и распространения аналогичны
принципам, применяемым для средств поддержки архитектуры типа
«клиент-сервер». Следует заметить, что существуют системы программирования, ориентированные на разработку либо клиентской
части, либо сервера приложений; и в то же время, многие системы
программирования стремятся предоставить разработчикам средства
для создания обеих частей приложения. Сервер баз данных в трехуровневой архитектуре по-прежнему чаще всего является продуктом
стороннего разработчика (как правило, производителя СУБД).
Далее будут рассмотрены механизмы, лежащие в основе технологий разработки серверов приложений и клиентских частей, а также организации обмена данными между ними. Детальное рассмотрение всех имеющихся возможностей, средств разработки и принципов их организации не входит в рамки данного учебного пособия.
Но далее авторы постараются дать обзор существующих технологий
и связанных с ними средств разработки в системах программирования, которые появились благодаря созданию и развитию многоуровневой архитектуры.
3.3.4. Сервера приложений. Методы доступа
к серверам приложений
Понятие «Сервер приложений» сейчас широко распространено на
рынке программных средств. Однако четкое определение данного понятия в настоящее время до сих пор отсутствует. Более того, зачастую
под термином «сервер приложений» подразумевают совершенно разные сущности, выполняющие разные функции и служащие для различных целей (например, под «сервером приложений» могут подразумевать среду исполнения промежуточного кода программ, созданных с помощью таких языков программирования, как Java и C#). Во
многом это связано с тем, что не разработаны четкие общепринятые
стандарты для многоуровневой архитектуры, как это было сделано
в свое время для архитектуры «клиент-сервер». Далее здесь термин
«сервер приложений» будет рассматриваться только с точки зрения
приложения, созданного на основе многоуровневой (трехуровневой)
архитектуры, все иные толкования этого понятия исключаются.
С точки зрения многоуровневой архитектуры, сервер приложений – это часть приложения, выполняющая возложенные на него
функции по обработке данных в соответствии с заданной функциональной спецификацией, получающая необходимые для обработки
66
данные и обеспечивающая предоставление результатов обработки
другим составным частям приложения.
В соответствии с этим определением сервер приложений должен
состоять из следующих основных частей (программных модулей):
– модуль получения данных, необходимых для обработки: в
трехуровневой архитектуре данные поступают от сервера данных,
в многоуровневой архитектуре – от сервера данных или от других
серверов приложений;
– модуль обработки данных – непосредственно реализует функции
прикладной логики (бизнес-логики), возложенные на данный сервер;
– модуль предоставления результатов – передает результаты обработки данных на другие части приложения: в трехуровневой архитектуре данные передаются на клиентскую часть, в многоуровневой архитектуре – на клиентскую часть или на другие сервера
приложений.
Указанные части сервера приложений не обязательно должны
быть реализованы в виде отдельных программных модулей или
библиотек, но так или иначе они должны присутствовать в составе
программного обеспечения этого сервера.
При этом основную проблему при создании сервера приложений
представляет не разработка модуля обработки данных, непосредственно реализующего функционал этого сервера, заданный функциональной спецификацией. Основную проблему представляет разработка модулей взаимодействия с другими частями приложения
для получения исходных данных и передачи результатов их обработки. И если для получения данных от сервера данных в трехуровневой архитектуре можно использовать технологии, рассмотренные
выше для архитектуры «клиент-сервер», то для взаимодействия с
клиентами в трехуровневой архитектуре, а также с другими серверами приложений в многоуровневой архитектуре требуются принципиально иные технологии.
Используя эти технологии и стандарты (которые частично описаны далее), разработчик может сам создать сервер приложений, а
затем и клиентскую часть для своего программного продукта, разработать протоколы обмена данными между ними и реализовать
соответствующие функции. Однако создание сервера приложений
и разработка протоколов взаимодействия с ним – это достаточно
сложный и трудоемкий процесс, зависящий от многих факторов,
которые потенциально могут привести к появлению сложно обнаруживаемых ошибок. С другой стороны, в составе сервера приложений
только связанные с логикой работы программной системы функции
67
(обработка данных) представляют собою «значимую» часть, которая
требует интеллектуального труда разработчика. А весь программный код, связанный с обеспечением обмена данными сервера приложений и клиентской части, как правило, требует кропотливого
рутинного труда, который может быть автоматизирован.
На этот факт обратили внимание производители систем программирования, и сейчас на рынке средств разработки программного
обеспечения появились программные продукты, часто носящие название «сервер приложений». Эти продукты зачастую входят в состав соответствующих систем программирования, но могут поставляться и отдельно от них. Такой сервер приложений представляет
собой своеобразный контейнер, обеспечивающий разработчику взаимодействие с клиентской частью и с сервером данных по определенному стандарту, а также облегчающий написание программного кода, реализующего логику обработки данных. От разработчика
требуется только создать код, отвечающий за саму обработку – все
остальное большей частью обеспечит сервер приложений. Единственным ограничением при таком способе создания программного
обеспечения для трехуровневой архитектуры является тот факт, что
созданный таким образом полномасштабный сервер приложений
должен поставляться заказчику в комплекте с программным кодом
из состава системы программирования, а это иногда требует приобретения дополнительных лицензий от производителя системы программирования. Однако при таком пути достигается существенный
выигрыш в объеме трудозатрат на разработку сервера приложений.
В этом случае сервер приложений действует как набор компонентов, доступных разработчику программного обеспечения через
интерфейс прикладного программирования, определённый средой
разработки. Кроме обеспечения обмена данными с другими компонентами приложения современные серверы приложений включают
в себя много дополнительных возможностей таких, как поддержка
кластеризации, отказоустойчивость, балансировка нагрузки. Использование готовых «контейнеров» в качестве серверов приложений позволяет разработчикам сфокусироваться непосредственно на
реализации бизнес-логики приложения.
Программное обеспечение, обеспечивающее взаимодействие
между частями приложений, функционирующими на разных уровнях, получило название «промежуточное программное обеспечение» (от английского термина «middleware»).
В принципе, задача организации взаимодействия параллельно
функционирующих приложений возникла задолго до появления
68
многоуровневой архитектуры (просто с развитием распределенных
вычислений она стала более актуальной). Поэтому основные принципы базисных технологий, лежащих в основе взаимодействия частей приложения, построенного по многоуровневой архитектуре,
появились задолго до ее появления. Одной из таких базисных технологий является технология RPC.
3.3.5. Технология RPC (Remote Procedure Call)
Технология RPC (Remote Procedure Call, вызов удаленных процедур) возникла для обеспечения взаимодействия двух параллельно выполняющихся процессов в ОС типа UNIX задолго до появления многоуровневых архитектур программного обеспечения. Ее
основы были заложены в саму архитектуру ОС типа UNIX.
Вызов удаленной процедуры заключается в том, что один из процессов («процесс-клиент») запрашивает у другого процесса («процесса-сервера») некоторую услугу (сервис) и не продолжает свое выполнение до тех пор, пока не получит соответствующие результаты.
Видно, что по смыслу такой механизм взаимодействия процессов
напоминает вызов процедуры или функции в прикладной программе (отсюда и происходит название). Разница заключается в том, что
выполнение вызова может происходить не только в рамках разных
задач, но и на разных компьютерах.
Кроме того, видно, что механизм вызова RPC очень похож на обмен данными между клиентской частью и сервером данных в приложении, построенном на основе архитектуры «клиент-сервер» (не
случайно процессы и приложения имеют схожие названия). Это
не удивительно, поскольку в большинстве случаев программное
обеспечение в архитектуре «клиент-сервер» также использует механизмы RPC, просто они остаются закрытыми для разработчика
прикладной программы.
Реализация технологии RPC достаточно сложна, поскольку этот
механизм должен обеспечить работу взаимодействующих приложений, возможно, находящихся на разных компьютерах. При обращении к процедуре или функции в рамках одного приложения
на одном компьютере передача данных выполняется через стек,
регистры процессора или через общие области памяти (глобальные
переменные). В случае удаленного вызова передача параметров процедуре превращается в задачу синхронизации двух приложений и
осуществления путем передачи запроса по сети. Соответственно, получение результата также должно использовать сетевые механизмы
69
для взаимодействия двух приложений, однако это обычно остается
скрытым от разработчика.
Характерными чертами вызова удалённых процедур являются:
– асимметричность, то есть одна из взаимодействующих сторон
является инициатором;
– синхронность, то есть выполнение вызывающей процедуры
приостанавливается с момента выдачи запроса и возобновляется
только после возврата из вызываемой процедуры.
Можно обозначить следующие проблемы и задачи, которые необходимо решить при реализации RPC:
– Вызывающая и вызываемая процедуры, безусловно, имеют разные адресные пространства, и это создает проблемы при передаче параметров и результатов. Поскольку RPC не может использовать никакие методы передачи параметров, используемые при локальных
вызовах процедур, рассмотренные выше, это означает, что параметры
RPC не должны содержать указателей на ячейки памяти и что все
значения параметров должны копироваться с одного компьютера на
другой. Для копирования параметров вызова процедуры и результата ее выполнения через сеть выполняется их преобразование в однородный однонаправленный поток данных («сериализация»). При этом
задача усложняется тем, что в качестве параметров могут выступать
массивы и сложные структуры данных, которые, в свою очередь, могут включать в себя ссылки и указатели на другие структуры.
– В реализации RPC участвуют как минимум два процесса – по
одному в каждом из взаимодействующих компьютеров. В случае,
если один из них аварийно завершится, могут возникнуть следующие ситуации: при аварии вызывающего процесса удалённо
вызванные процедуры станут «осиротевшими», а при аварийном
завершении удалённых процедур станут «обездоленными родителями» вызывающие процедуры, которые будут безрезультатно
ожидать ответа от удалённых процедур. Аналогичные проблемы
могут возникнуть, если во время обработки вызова RPC соединение
между вызывающим и вызываемым компьютерами будет потеряно.
– Существует ряд проблем, связанных с неоднородностью языков программирования и ОС: структуры данных и структуры вызова процедур, поддерживаемые в каком-либо одном языке программирования, могут не поддерживаться точно так же в других
языках. Таким образом, имеется проблема совместимости, до сих
пор не решённая ни с помощью введения одного общепринятого
стандарта, ни с помощью реализации нескольких конкурирующих
стандартов на всех архитектурах и во всех языках.
70
– Также надо отметить, что одни и те же данные могут иметь разное представление в компьютерах с разной архитектурой (например,
разная кодировка символов или прямой, либо обратный порядок
байтов). Поэтому еще одной задачей RPC является автоматическое
обеспечение преобразования форматов данных при взаимодействии
приложений, выполняющихся на разнородных компьютерах.
В общем случае удаленный вызов процедуры по технологии RPC
включает в себя следующие шаги:
– процесс-клиент на вызывающем компьютере при обращении к
RPC осуществляет локальный вызов процедуры, называемой «заглушкой» (stub);
– процедура-заглушка принимает аргументы вызова, преобразует их в некую стандартную форму и формирует сетевой запрос к серверу, упаковка аргументов и создание сетевого запроса называется
«сборкой» (marshalling – маршаллинг);
– сетевой запрос пересылается на удаленный вызываемый компьютер (сервер), где соответствующий модуль RPC должен ожидать
такой запрос, после отправки запроса выполнение процедуры-заглушки и связанного с нею процесса на вызывающем компьютере
приостанавливается (вплоть до получения ответа на вызов или истечения срока ожидания ответа);
– модуль RPC (который, как правило, входит в состав ОС) на вызываемом компьютере должен находиться в постоянном ожидании
запросов на вызов, при получении запроса он извлекает параметры
вызова (unmarshalling – демаршаллинг), и определяет тип сервера,
которому предназначается вызов;
– модуль RPC на вызываемом компьютере локально обращается к серверу, передает ему параметры вызова и ожидает получения
результата (в это время процесс-сервер обрабатывает полученный
вызов, а модуль RPC на вызываемом компьютере находится в пассивном состоянии);
– после завершения обработки вызова полученный результат
опять преобразуется в некоторую стандартную форму, формируется сетевой запрос (marshalling) и передается процедуре-заглушке,
которая ожидает его на вызывающем компьютере;
– процедура-заглушка, получив ответ на вызов, возобновляет
свое выполнение, извлекает результат вызова из полученного сетевого запроса (unmarshalling) и возвращает его клиенту;
– получив ответ на вызов RPC, процесс-клиент продолжает свое
выполнение на вызывающем компьютере, выполнение вызова RPC
закончено.
71
В общем виде схема выполнения вызова RPC представлена на рис. 7.
Использование RPC накладывает определенные ограничения
на тип связи между приложениями. Дело в том, что в RPC применяется синхронный механизм взаимодействия: запрашивающее
приложение выдает запрос и ждет ответа. На время ожидания приложение оказывается заблокированным. В связи с этим развертывать основанные на RPC приложения представляется целесообразным в таких сетях, где время ответа обычно не очень велико (чаще
всего это локальные сети). Кроме того, RPC является механизмом
взаимодействия, ориентированным на соединении. В связи с этим
осложняется использование RPC в глобальных сетях, так как вероятность потери соединения между компьютерами в процессе обработки вызова RPC в этом случае достаточно велика.
Столь сложный механизм взаимодействия определяет тот факт,
что реализация механизма обмена данными между клиентской частью программного обеспечения и сервером приложений не может
быть полностью возложена на разработчика прикладной програмКлиентская программа.
Вызов процедуры
Извлечение результата
(unmarshalling)
Передача параметров
(marshalling)
Процедура-заглушка
клиентской части
Передача сетевого запроса
Передача сетевого запроса
на вызов
на возврат результата
Процедура-заглушка
серверной части
Извлечение параметров
(unmarshalling)
Передача результата
(marshalling)
Серверная программа.
Выполнение процедуры
Рис. 7. Схема организации удаленного вызова процедур
по технологии RPC
72
мы. Для этой цели должны использоваться функции ОС, а для организации обмена данными между приложениями, выполняющимися на компьютерах с различной архитектурой, должны быть разработаны соответствующие стандарты.
Из-за своей сложности и трудоемкости реализации технология
RPC практически никогда не используется непосредственно для
организации взаимодействия между серверными и клиентскими
частями приложений. Однако большинство технологий, используемых для взаимодействия клиентских частей с серверами приложений, в своей основе построены именно на базе технологии RPC
и ее основополагающих принципов. Чаще всего идея заключается
в том, что реализация такой технологии берет на себя решение части описанных выше проблем, связанных с RPC, и тем самым существенно упрощает ее использование и снижает трудоемкость разработки. Но при этом распределенные вызовы функций на уровне RPC
становятся закрытыми для разработчиков, которые используют
программные возможности уже более высокого уровня, предлагаемые соответствующей технологией разработки. Следует помнить и
о том, что различные технологии взаимодействия с серверами данных, рассмотренные выше в рамках архитектуры «клиент-сервер»,
и, в равной степени используемые во многоуровневой архитектуре,
также построены на основе технологии RPC.
Здесь далее будут рассмотрены только основные принципы
функционирования двух наиболее распространенных технологий,
используемых для организации взаимодействия с серверами приложений: технологии COM/DCOM и семейство технологий CORBA,
в основе которых лежит использование RPC.
3.3.6. Модель и технологии COM/DCOM
Аббревиатура COM расшифровывается как «Component Object
Model» (модель компонентных объектов). Эта объектная модель
была создана компанией Microsoft в рамках ОС типа Windows как
дальнейшее развитие средств взаимодействия приложений в этих
ОС. При этом были объявлены следующие основные цели COM:
– поддержка средств определения спецификации для создания
набора стандартных объектов, не ориентированных на специфический язык программирования;
– поддержка средств, разрешающих реализовывать объекты,
которые могут вызываться различными процессами, даже если эти
процессы выполняются на разных компьютерах.
73
В модели COM все приложения, которые поддерживают данную
модель и на которых выполняются распределенные вычисления,
являются серверами (COM-серверами). COM-сервера могут быть
внутренними (реализованными в рамках одного процесса), локальными (реализованными на том же компьютере) и удаленными (реализованными на другом компьютере в сети). Физически они могут
быть реализованы в виде исполняемых файлов или динамически
загружаемых библиотек. Местоположение и реализация сервера
являются прозрачными для клиента. В принципе, клиент при соединении может указать, какой сервер (внутренний, локальный или
удалённый) ему нужен, но обычно эта возможность не используется. Дальнейшая работа с сервером не зависит от его типа, клиент
может даже не знать, с сервером какого типа он работает.
COM/DCOM – это объектная модель, вся работа строится в ней
на объектах. Каждый COM-объект имеет тип, называемый коклассом (английский термин «CoClass», префикс «Co» указывает на
принадлежность к технологии COM). COM-сервер может создавать
свой COM-объект для обработки вызовов от каждого клиента или
использовать один COM-объект для обработки вызовов всех клиентов. Кроме того, один сервер может содержать несколько разных
коклассов. Именно кокласс, а не сервер является центральным
объектом для COM-клиента. Если клиент работает с разными коклассами, то он не может узнать, реализуются ли они одним сервером или разными. Каждый кокласс имеет своё имя и глобальный
идентификатор (GUID – Globally Unique Identifier, глобально уникальный идентификатор).
Не следует путать понятие кокласса в COM с понятиями класса или объекта в объектно-ориентированном программировании.
В объектно-ориентированных языках программирования кокласс
действительно удобнее всего реализовывать как класс (объект). Но
COM-сервер может быть написан и на таком не объектно-ориентированном языке, как, например, C или Visual Basic.
Другим не менее важным понятием технологии COM/DCOM
является интерфейс. По сути, интерфейс – это список функций,
которые реализует некий объект. С точки зрения двоичного кода
интерфейс представляет собой таблицу, содержащую указатели
на функции. Количество элементов в этой таблице соответствует
количеству функций в интерфейсе. По своей реализации такая таблица функций подобна таблице RTTI (Run Time Type Information,
информация о типах в ходе выполнения), которая используется при
организации виртуальных функций в объектно-ориентированных
74
языках программирования. При реализации функций COM-сервер,
создает таблицы с указателями на них, а указатель на каждую таблицу функций интерфейса может быть получен клиентом. Именно через эти указатели клиент получает доступ к функциям COMсервера. Количество интерфейсов, которые может экспортировать
один кокласс, не ограничивается.
Каждый интерфейс, как и кокласс, имеет имя и уникальный
GUID. Имя интерфейса должно быть идентификатором, корректным с точки зрения языка, на котором разрабатывается клиент или
сервер. Так как различные языки программирования имеют разные
требования к идентификаторам, в имени интерфейса рекомендуется использовать только английские буквы и символ подчёркивания
(«_»). Кроме того, многие языки программирования нечувствительны к регистру символов, поэтому нежелательно давать разным интерфейсам имена, отличающиеся лишь регистром символов. И, наконец, названия интерфейсов принято начинать с буквы «I».
Для описания интерфейсов, реализуемых ими функций и аргументов этих функций,используется специальный язык описания
интерфейсов (IDL – Interface Definition Language). В процессе разработки сервера разработчики должны создать все реализуемые им
кокласссы и описать обеспечиваемые ими интерфейсы на языке
IDL. Для создания таких описаний существуют специализированные средства, предоставляемые компанией Microsoft. Затем полученные файлы описаний IDL компилируются специальным компилятором IDL (а по сути – транслятором) в составе используемой
системы программирования в исходный код на применяемом языке
программирования (существующие и доступные на рынке в настоящее время системы программирования обеспечивают трансляцию
описаний IDL практически для всех используемых языков программирования). Далее разработчики должны создать разработать
код, реализующий функции каждого кокласса, на том языке и в
рамках той системы программирования, которые они используют.
Однажды созданный и опубликованный интерфейс не должен
меняться, потому что иначе клиент, получивший указатель на данный интерфейс, может попытаться вызвать функцию, которой он не
содержит или передать ей не те параметры. Если интерфейс устарел,
то вместо его модификации нужно создать новый интерфейс, оставив
старый без изменения. При создании новых интерфейсов их можно
наследовать от уже имеющихся. Интерфейс-наследник может добавлять новые функции, но перекрытие старых функций не имеет
смысла, потому что интерфейс не содержит реализации функций.
75
Имена интерфейсов удобны при использовании интерфейса для
разработчиков, однако они не годятся, когда клиент должен точно
указать, какой именно интерфейс объекта ему нужен. Для уникальной идентификации клиентом каждого интерфейса COM-сервера
используется GUID. GUID – это некая уникальная 16-байтовая
(128-битная) величина, обычно автоматически генерируемая соответствующей утилитой. Каждый может запустить такую утилиту
на любом компьютере и гарантированно (со всех практических точек зрения) получит GUID, который будет отличаться от всех других GUID, которые когда-либо были созданы или будут созданы.
Уникальность GUID обеспечивается его привязкой к моменту времени и к уникальному идентификатору компьютера в сети (при отсутствии сети используются дополнительные методы уникальной
идентификации компьютера).
В модели COM/DCOM сервер приложений должен представлять
собой множество коклассов и связанных с ними интерфейсов, а
клиентская часть приложения для выполнения необходимых ей
функций на сервере приложений должна обращаться к соответствующим коклассам и интерфейсам.
Поддержка в рамках технологии COM средств, которые могут
вызываться различными процессами, выполняющимися на разных
компьютерах, привела к появлению модели DCOM. Модель DCOM
(Distributed COM – распределенная COM) является неразрывной
составляющей COM. Для создания объекта на удалённой машине
библиотека COM вызывает менеджер управления сервисами (SCM
– Service Control Manager) локального компьютера, который связывается с SCM сервера и передаёт ему запрос на создание объекта.
Имя сервера может задаваться при вызове функции создания объекта или храниться в реестре. Точное описание методов и используемых типов данных, необходимое для выполнения маршаллинга и
демаршаллинга в процессе DCOM-вызовов, обеспечивается использованием IDL. Код, запускаемый на стороне клиента, называется
«прокси», на стороне объекта – «стаб», и загружается библиотекой
COM по необходимости. Протокол DCOM известен также как объектный RPC (ORPC). ORPC использует стандартные пакеты RPC с
дополнительной, необходимой для DCOM информацией. Заголовок
вызова DCOM содержит идентификатор интерфейса (уникальный
идентификатор GUID), который используется для идентификации
необходимого интерфейса на сервере. Данные в пакете ORPC передаются в формате с дополнительным типом данных, представляющим собой идентификатор объекта.
76
Для контроля наличия соединения и сохранения существования
вызывающего процесса в DCOM клиент должен периодически подтверждать свою активность путём посылки на сервер контрольных
сообщений («пингования» сервера). Если период пингования истёк без получения очередного контрольного сообщения («пинга»),
то считается, что либо соединение было потеряно, либо клиент завершил работу аварийно, и все его ссылки на интерфейсы объекта
уничтожаются.
В настоящее время модель COM/DCOM и основанные на ее технологиях многоуровневые приложения получили широкое распространение. Данная модель постоянно развивается и совершенствуется производителем (компанией Microsoft), находит все более
мощную поддержку в новых ОС типа Windows. Главным недостатком данной модели является ее ориентация на одного производителя и один тип ОС (Windows), и хотя в настоящее время на рынке
программных продуктов появляются реализации этой технологии
для других ОС, этот недостаток всё ещё нельзя считать полностью
устраненным.
3.3.7. Модель и семейство стандартов CORBA
Семейство стандартов CORBA (Common Object Request Broker
Architecture – общая архитектура брокера объектных запросов)
было разработано международным консорциумом OMG (Object
Management Group), который включает более 500 компаний, связанных с производством компьютерной аппаратуры и программного
обеспечения (в частности, членами OMG являются компании IBM,
Hewlett Packard, Intel, Microsoft, Borland International, Oracle и др.).
Идея CORBA заключается в следующем: во-первых, в каждый
объект, который должен быть включен в интегрированную систему, добавляется специальный программный код, обеспечивающий
принципиальную возможность взаимодействия объектов. Этот код
генерируется автоматически за счет использования определенного OMG языка определения интерфейсов IDL (Interface Definition
Language). В исходный текст программы включаются спецификации интерфейса на языке IDL. Затем этот текст должен быть обработан специальным предварительным компилятором (а точнее,
транслятором), который генерирует дополнительный программный
код. Во-вторых, для реального взаимодействия должным образом
настроенных объектов предполагается наличие специального программного обеспечения, называемого в документах OMG брокером
77
объектных заявок (ORB – Object Request Broker). Брокер объектных
заявок должен существовать и на стороне вызывающего объекта, и
на стороне вызываемого объекта.
Подобно «человеческому» брокеру, ORB выполняет функции интеллектуального посредника, т. е. принимает запросы от клиента
(клиентского приложения), осуществляет поиск и активизацию удаленных объектов (серверов приложений), которые принципиально
могут ответить на запрос, и передает ответ объектам запрашивающего приложения. ОRB – технология объектно-ориентированного подхода, базирующаяся на спецификациях CORBA консорциума OMG.
CORBA включает 13 пунктов (служб). Основные службы CORBA:
– служба именования, присваивает объектам уникальные имена, в результате чего пользователь может искать объект в сети;
– служба обработки транзакций, осуществляет управление
транзакциями из приложений или из ОС;
– служба событий, обеспечивает асинхронное распространение и
обработку сообщений о событиях;
– служба обеспечения безопасности и поддержки целостности
данных.
При применении ORB (в отличие от RPC) клиенту нет необходимости хранить сведения о расположении серверных объектов, ему
достаточно знать расположение в сети программы-посредника ORB.
Поэтому доступ пользователя к различным объектам (программам,
данным, принтерам и т. п.) существенно упрощен. Посредник должен определять, в каком месте сети находится запрашиваемый ресурс, направлять запрос пользователя в соответствующее место, а
после выполнения запроса возвращать результаты пользователю.
Применение ORB может несколько увеличить нагрузку на сеть,
однако имеет и ряд преимуществ: обеспечивается взаимодействие
разных платформ, не требуется дублирования прикладных программ во многих узлах, упрощается программирование сетевых
приложений и поддержка мультимедиа. В CORBA создан протокол
IIOP (Internet Inter-ORB Protocol), который обеспечивает взаимодействие между брокерами разных производителей.
Взаимодействие клиента с сервером в ORB, как и в RPC происходит через создаваемые для такого взаимодействия специальные
«заглушки» (stub). В этом случае из клиентской процедуры-заглушки происходит обращение к ORB, который в свою очередь создает соединение. ORB скрывает от разработчика процесс доступа к
удаленным объектам. Запрашивающий клиент должен знать имя
активизируемого объекта (либо посредника, либо сервера приложе78
ний) и передать ему некоторые параметры. Как правило, это информация об интерфейсе вызываемого объекта – своего рода программный интерфейс для ORB. Интерес к ORB подогревается тем, что это
программное обеспечение для серверов приложений поддерживает
объектную модель, ставшую де-факто стандартом при разработке
больших информационных систем.
При обработке заявки ORB ищет соответствующий код, пересылает параметры обращения и передает управление реализации
вызываемого объекта. Вызываемый объект принимает заявку через
генерируемый компилятором IDL промежуточный программный
код – скелетон, а также может обращаться к объектному адаптеру
и ORB. После завершения обработки заявки результаты обращения
возвращаются клиенту, который продолжает свое выполнение.
Брокеры объектных заявок могут быть по-разному реализованы
и могут поддерживать различные объектные механизмы. В структуре ORB выделяется ядро, обеспечивающее внутреннее представление объектов и передачу заявок, и набор настраиваемых компонентов, интерфейсы которых маскируют различия в реализации
ORB. Объекты-клиенты имеют возможность без изменения своего
кода работать в среде любого ORB, который поддерживает отображение IDL в соответствующий язык программирования. Реализации вызываемых объектов также могут работать в среде разных
ORB, если брокер поддерживает требуемое языковое отображение и
снабжен требуемым объектным адаптером.
Языковое отображение включает определение характерных для
языка программирования типов данных и интерфейсов доступа к
объектам при помощи ORB. В отображении определяется структура интерфейса процедуры-заглушки (stub) клиента, интерфейса
динамического вызова, скелетона реализации объекта, объектных
адаптеров, а также интерфейсы прямого взаимодействия с ORB.
В настоящий момент стандартизовано отображение языка IDL на
основные языки программирования, для которых существуют
общепринятые стандарты – Ada, C и C++, Cobol, Java и Smalltalk.
Существуют также отображения на Object Pascal, Perl, Python и некоторые другие языки программирования.
Понятие «объекта» в CORBA принципиально отличается от аналогичного понятия в COM. Объект CORBA не является переменной
языка программирования и в общем случае время его существования не связано со временем работы серверных или клиентских приложений. Объект СORBA не занимает никаких ресурсов компьютера – оперативной памяти, сетевых ресурсов и т. п. Эти ресурсы зани79
мает только так называемый «сервант» (servant), который является
«инкарнацией» одного или нескольких объектов CORBA. Именно
сервант является переменной языка программирования. Пока не существует сервант, сопоставленный с конкретным объектом CORBA,
этот объект не может обслуживать вызовы клиентов, но, тем не менее, он существует. Результатом создания объекта является так называемая «объектная ссылка» CORBA. Объектная ссылка сопоставлена с этим, и только с этим объектом, и это сопоставление остается
корректным в течение всего срока существования объекта CORBA.
Объектная ссылка CORBA правильно интерпретируется ORB от любого производителя программного обеспечения. После уничтожения объекта CORBA все объектные ссылки на него навсегда теряют
смысл. С помощью объектной ссылки клиент вызывает методы объекта, при этом «инкарнациями» этого объекта могут быть различные серванты (но не более одного одновременно), которые физически
могут находиться даже на различных компьютерах.
Семейство стандартов CORBA в настоящее время по распространенности на рынке соперничает с технологиями COM/DCOM, но
ему практически нет альтернативы в том случае, когда требуется
обеспечить переносимость приложений на вычислительные системы под управлением ОС, отличной от Windows. Также следует отметить, что CORBA, в отличие от COM, является концепцией, а не
ее реализацией. Технологии COM/DCOM подразумевают набор конкретных средств – элементов ОС, библиотек, утилит и т. п., являющихся составной частью ОС типа Microsoft Windows. Под термином
«CORBA» понимается именно концепция. Реализации же этой концепции могут сильно отличаться друг от друга по различным критериям, наиболее важным в том или другом случае.
3.3.8. Язык IDL. Интерфейсы и библиотеки классов
Описанные выше технологии и стандарты имеют существенные
различия, но при этом между ними есть и те общие черты, которые не могли не найти отражение в системах программирования,
ориентированных на разработку приложений для трехуровневой и
многоуровневой архитектуры.
В качестве таких общих черт можно выделить следующие особенности:
– наличие специального языка описания интерфейсов объектов
(языка IDL), предложения которого должны транслироваться на
предложения входного языка системы программирования;
80
– появление нового понятия «интерфейс», которое соответствует
описанию объекта, реализация которого может находиться за пределами данной результирующей программы.
На самом деле, язык IDL не является универсальным для всех
технологий описания интерфейсов. В настоящее время существуют
три различных реализации этого языка описаний с одним и тем же
названием – OSF IDL (исходный прообраз языка описания интерфейсов), Microsoft IDL (используемый в технологии COM/DCOM) и
OMG IDL (используемый в CORBA). Эти языки имеют много общих
черт (все они происходят от OSF IDL), но и ряд различий.
Сервер приложений и клиент должны иметь заранее согласованный способ описания взаимодействия, т. е. способ определения методов, которые могут быть вызваны клиентом на сервере, а также
параметров этих методов. Таким способом является описание на
языке IDL. Язык IDL является единым средством описания спецификаций взаимодействия между сервером и клиентом.
Использование языка IDL в системах программирования предполагает наличие в их составе трансляторов (речь идет именно о трансляторах, не компиляторах), которые могли бы осуществлять перевод
предложений с языка IDL на входной язык системы программирования и наоборот – переводить описания объектов с входного языка на
язык IDL. Выполнив подобным образом перевод описания с языка
IDL на входной язык программирования, разработчик сразу получает исходный текст шаблона для реализации соответствующего объекта. Причем на основе одного и того же текста IDL можно получить
описание как для вызываемого объекта (серверной части), так и для
вызывающего объекта (клиентской части) в зависимости от нужд
разработчика. Поскольку оба описания создаются на основе одного
и того же исходного текста, они гарантированно будут соответствовать друг другу. После этого разработчику остается только «наполнить» описания содержательным кодом на входном языке, который
будет обеспечивать реализацию функций объекта.
С другой стороны, создав новый объект, доступный для других
частей приложения, на исходном языке программирования, разработчик должен иметь возможность сформировать его описание, не
зависящее от используемого языка. В дальнейшем это описание может быть использовано при разработке других частей приложения,
взаимодействующих с созданным объектом.
Современные системы программирования, ориентированные на
разработку приложений для многоуровневой архитектуры, предоставляют разработчикам средства трансляции текстов языка IDL.
81
В зависимости от того, какую технологию взаимодействия частей
приложения поддерживает система программирования, транслятор IDL в ее составе должен обрабатывать соответствующее подмножество этого языка (или несколько его подмножеств, если поддерживаются разные технологии). При этом тексты на языке IDL
являются частью исходной программы, так же, как и тексты на
входном языке. Поскольку трансляция с разных подмножеств языка IDL возможна не на все языки программирования, разработка
приложения в трехуровневой архитектуре накладывает ограничения не только на выбор системы программирования, но и на выбор
входного языка программирования.
Не меньший интерес с точки зрения развития систем программирования и языков программирования представляет понятие
«интерфейс», которое появилось в технологиях, реализующих взаимодействие частей многоуровневого приложения. И хотя у двух
представленных выше технологий для этого понятия имеются существенные различия, тем не менее, оно имеет и ряд существенных
общих черт.
С точки зрения входного языка «интерфейс» – это спецификация
определенного объекта, его свойств и функций (методов). При этом в
отличие от класса (или объекта) в объектно-ориентированных языках программирования, интерфейс никак не связан с реализацией
объекта. Его взаимосвязь с объектом происходит уже во время выполнения результирующей программы, а способ взаимосвязи зависит от выбранной технологии, причем в обеспечении этой взаимосвязи может принимать участие несколько выполняющихся программ, которые могут находиться на разных компьютерах. Один и
тот же интерфейс могут реализовывать разные объекты и то, какой
конкретно объект будет связан с данным интерфейсом, определяется только во время выполнения приложения. Поэтому интерфейс не
может иметь полей, конструкторов и деструкторов – обязательных
атрибутов объектно-ориентированного программирования.
С точки зрения системы программирования интерфейс представляет собой универсальное средство обращения к объектам и классам, которые могут находиться в пределах адресного пространства
результирующей программы или вне него. Вызов методов интерфейса, по сути, схож с вызовом виртуальных функций через информацию, хранимую в таблицах RTTI. Но, в отличие от таблиц RTTI,
реализация которых никак не стандартизована и зависит от используемой системы программирования, принципы использования
интерфейсов регламентируются соответствующей технологией. По82
этому объекты, реализующие интерфейсы и созданные с помощью
некоторой системы программирования, могут быть вызваны через
те же интерфейсы результирующей программой, построенной в совершенно другой системе программирования (что невозможно осуществить при использовании обычных библиотек классов, основанных на таблицах RTTI). Важно только, чтобы обе системы программирования поддерживали разработку приложений многоуровневой
архитектуры на основе используемой технологии.
Интерфейс – это новое понятие, появившееся в связи с развитием трехуровневой и многоуровневой архитектуры. В исходном языке программирования он, в принципе, может быть реализован и без
введения новых понятий и типов в синтаксис и семантику языка.
Но подход взаимодействия с внешними объектами, основанный на
понятии интерфейса, можно признать настолько удачным, что во
многих современных языках программирования появились синтаксические конструкции, специально предназначенные для реализации интерфейсов (в первую очередь это касается технологии
COM/DCOM, которая подразумевает не только идею, но и ее реализацию).
Технологии и средства программирования (включающие в себя
и языки, и системы программирования), связанные с созданием
приложений для трехуровневой и многоуровневой архитектуры,
продолжают развиваться и совершенствоваться. Поэтому в этом направлении можно ожидать появления новых решений.
3.3.9. Возможности трехуровневой
и многоуровневой архитектуры
По сравнению с архитектурой «клиент-сервер» трехуровневая (а
в общем случае – многоуровневая) архитектура создания приложений предоставляет разработчику программного обеспечения следующие преимущества:
– функции обработки данных возложены на сервер приложений,
а на клиентскую часть приходятся только функции отображения
данных и организации интерфейса пользователя, что существенно
снижает требования к ресурсам вычислительной системы клиентской части программного обеспечения;
– при необходимости изменить или дополнить логику обработки
данных достаточно модифицировать только программное обеспечение на сервере приложений, а обновление клиентских приложений
на всех рабочих местах не обязательно;
83
– если необходимо изменить только внешний вид интерфейса
пользователя, то достаточно только изменить простую по своей структуре клиентскую часть на тех рабочих местах, где это необходимо.
Главным недостатком трехуровневой (и многоуровневой) архитектуры следует признать увеличение трудоемкости разработки
приложения, функционирующего в такой архитектуре. Если при
использовании архитектуры «клиент-сервер» разработчики должны были создать только клиентскую часть приложения, то в трехуровневой архитектуре они должны создавать уже две его части (сервер приложений и клиентскую часть), а также определять способ
взаимодействия между ними. При увеличении количества уровней
пропорционально возрастает и количество создаваемых приложений, и количество точек их взаимодействия. Тот факт, что системы
программирования и технологии разработки сейчас активно развиваются и предоставляют широкий набор инструментов, ориентированных на создание приложений в многоуровневой архитектуре,
пока еще не способен полностью компенсировать рост трудозатрат и
сложности разработки.
Другим немаловажным недостатком трехуровневой архитектуры следует признать довольно сложный и трудоемкий процесс организации взаимодействия между клиентскими частями и сервером
приложений (а в многоуровневой архитектуре – также и между различными частями сервера приложений). Именно по этой причине
далеко не все современные программные системы, построенные на
основе архитектуры «клиент-сервер», быстро переходят на трехуровневую архитектуру, поскольку выделить в составе программного комплекса сервер приложений, описать его функции и организовать взаимодействие клиентских частей с ним – это сложный
процесс, требующий усилий от разработчиков.
Очень часто в том случае, если функциональность программного
обеспечения, построенного на основе архитектуры «клиент-сервер»,
достаточно стабильна, а обработка данных не содержит сложных
ресурсоемких операций, переход на трехуровневую архитектуру не
всегда оправдан. В ряде случаев сочетание архитектуры «клиентсервер» с возможностями терминального доступа (как это было показано выше) позволяет приложению достичь того же эффекта, что
и использование многоуровневой архитектуры. И хотя в этом случае, как было сказано ранее, неэффективно используются вычислительные ресурсы терминальных серверов, но зачастую это бывает
оправдано, так как позволяет избежать трудоемкого процесса перевода приложения в трехуровневую архитектуру.
84
Этому способствует также современная ситуация с развитием
программно-аппаратных средств: замена программно-аппаратного
обеспечения клиентских компьютеров зачастую обходится намного
дешевле, чем переработка программного кода приложения. И при
этом средний по характеристикам компьютер, доступный на рынке, вполне способен выполнять функции терминального сервера.
Другим фактором, сдерживающим развитие и распространение
приложений, построенных на основе трехуровневой и многоуровневой архитектуры, является отсутствие единого для всех стандарта,
каким в свое время стал стандарт языка SQL для архитектуры «клиент-сервер». Технологии COM/DCOM активно развиваются и продвигаются компанией Microsoft, но они ориентированы исключительно
на ОС производства этой компании. В то же время, концепция CORBA
является стандартом, совместимым со всеми современными ОС, но по
реализации она зачастую проигрывает для ОС типа Windows, которые занимают существенную долю рынка вычислительных систем.
Контрольные вопросы
1. Какие критерии используются в данной главе для разделения вычислительных сетей на локальные и глобальные? Оцените,
насколько четкими и однозначными являются предложенные для
этой цели критерии.
2. Какие особенности локальных вычислительных сетей оказывают принципиальное влияние на организацию распределенных
вычислений в этих сетях?
3. В чем состоит суть технологии организации распределенных
вычислений «клиент-сервер»? Оцените, насколько удачным или неудачным является термин, используемый для наименования данной технологии.
4. Какие операции выполняет серверная часть приложения в технологии организации распределенных вычислений «клиент-сервер»?
5. Какие преимущества имеет технология организации распределенных вычислений «клиент-сервер» по сравнению с технологией
«файл-сервер»?
6. Какие недостатки присущи технологии организации распределенных вычислений «клиент-сервер»?
7. Какие методы можно использовать для нивелирования недостатков, присущих технологии организации распределенных вычислений «клиент-сервер»? Оцените, насколько эффективны эти методы.
85
8. В чем состоит суть трехуровневой технологии организации
распределенных вычислений? Каким образом происходит переход
от трехуровневой технологии организации распределенных вычислений к многоуровневой?
9. Какие функции выполняет сервер приложений в трехуровневой технологии организации распределенных вычислений? Сравните эти функции с функциями сервера в технологии «клиент-сервер» и в многоуровневой технологии организации распределенных
вычислений.
10. Сравните преимущества и недостатки трехуровневой технологии организации распределенных вычислений с преимуществами и
недостатками технологии «клиент-сервер» в сочетании с терминальным сервером для организации распределенных вычислений.
11. В чем состоит основная особенность разработки приложений
для трехуровневой и многоуровневой технологий организации распределенных вычислений? Сравните эти особенностями с разработкой приложений для технологии «клиент-сервер».
12. Какие характерные черты имеет технология вызова удаленных процедур RPC? Какие задачи необходимо решить для организации удаленного вызова процедур?
13. Опишите основные шаги удаленного вызова процедуры по
технологии RPC? Какие проблемы ограничивают использование
этой технологии?
14. Какие основные цели преследовали разработчики при создании технологии COM/DCOM?
15. Что подразумевается под понятием «интерфейс» в технологиях взаимодействия различных частей приложения при многоуровневой организации распределенных вычислений?
16. Какие возможности дает многоуровневая технология организации распределенных вычислений разработчикам приложений?
Сравните их с возможностями технологии «клиент-сервер».
86
4. ОРГАНИЗАЦИЯ РАСПРЕДЕЛЕННЫХ ВЫЧИСЛЕНИЙ
В ГЛОБАЛЬНЫХ СЕТЯХ
4.1. Принципы организации распределенных вычислений
в глобальных сетях
Ранее уже шла речь о разделении вычислительных сетей на глобальные и локальные и тех критериях, которые здесь использованы
для такого разделения.
В качестве первого критерия была указана скорость передачи информации по сети, непосредственно влияющая на время реакции
распределенного приложения на воздействия пользователя. При
этом было указано, что для локальных вычислительных сетей скорость обмена данными должна быть такой, при которой пользователь
может взаимодействовать с приложением в режиме реального времени так, чтобы ожидание реакции приложения на воздействие пользователя не создавало впечатление о потери им работоспособности.
В качестве второго критерия была указана возможность пользователей приложений получать информацию о вычислительных системах всех компонент распределенного приложения в составе сети.
При этом разработчики таких приложений также могут предъявлять свои требования к вычислительным системам, под управлением которых будут функционировать компоненты этих приложений.
При этом было указано, что в настоящее время оба критерия не
являются строго определенными, а потому с этой точки зрения граница между локальными и глобальными вычислительными сетями
не четкая.
Если говорить о критерии времени реакции на воздействие, то в
настоящий момент он действительно всё более и более размывается.
Производительность самых различных сетей растет сейчас опережающими темпами, при этом даже рядовые глобальные сети имеют сейчас
такую пропускную способность, какой всего 5-10 лет назад не могли похвастаться и многие весьма развитые локальные сети. Поэтому мгновенный (с точки зрения человека) ответ на воздействие для распределенного приложения, даже функционирующего в глобальной сети, не
является теперь чем-то из ряда вон выходящим. Кроме того, технологии разработки таких приложений зачастую позволяют сейчас обойти
узкие моменты, связанные с передачей данных через глобальные сети.
Но критерий полноты информации о составе вычислительных
систем, входящих в сеть, продолжает оставаться актуальным. Более того, с появлением на рынке все большего количества мобиль87
ных устройств, основанных на различных вычислительных системах, этот критерий выделения глобальных сетей становится всё
более и более важным. Другое дело, что и некоторые сети, считающиеся локальными, иногда также соответствуют этому критерию.
Таким образом, можно указать, что на разработку приложений,
использующих распределенные вычисления в глобальных сетях,
будут влиять два фактора: необходимость учитывать возможные задержки, связанные с передачей данных по сети, а также невозможность установить жесткие требования к вычислительным системам
всех компонент, входящих в состав приложения. Причем именно
второй фактор является определяющим. В глобальных сетях разработчики могут предъявлять требования к вычислительным системам только части взаимодействующих компонент, и, как правило,
это серверные компоненты.
Главной и наиболее известной глобальной сетью в настоящее
время является глобальная всемирная сеть Интернет. Эта сеть является доминирующей, и потому практически все технологии создания приложений, использующих распределенные вычисления в
глобальных сетях, ориентированы именно на эту сеть. Кроме того,
нередко встречаются локальные сети, построенные на основе принципов сети Интернет – такие сети часто называют сетями «интранет» (от «intranet» – «внутренняя сеть»). Поэтому, говоря о технологиях разработки приложений для распределенных вычислений в
глобальных сетях, далее будем иметь в виду именно сеть Интернет.
Интернет – это всемирная «сеть сетей». Он объединяет в себя вычислительные системы и локальные сети, построенные на базе различных аппаратно-программных архитектур. При осуществлении
взаимодействия по сети двух компьютеров один из них выступает
в качестве источника данных (интернет-сервера), а другой – приемника данных (интернет-клиента). Сервер подготавливает данные, а
клиент принимает их и каким-то образом обрабатывает. Нередко в
качестве данных выступают тексты программ, которые подготавливает сервер, а исполнять их должен клиент. При этом нельзя заранее определить или установить, под управлением какой вычислительной системы будет функционировать компьютер клиента.
В таких условиях определяющим становится требование унифицированного исполнения кода программы вне зависимости от архитектуры вычислительной системы. Компиляция и создание объектного
кода в условиях всемирной сети становятся бессмысленными, потому
что заранее не известно, на какой целевой вычислительной системе потребуется исполнять полученный в результате компиляции код.
88
Поэтому основной особенностью программирования в сети Интернет является использование в качестве основного средства программирования интерпретируемых языков. При интерпретации
исполняется не объектный код, а сам исходный код программы, и
уже непосредственно интерпретатор на стороне клиента отвечает за
то, чтобы этот исходный код был исполнен всегда одним и тем же
образом вне зависимости от архитектуры вычислительной системы.
Тогда сервер готовит код программы всегда одним и тем же образом
вне зависимости от типа клиента.
Еще одной особенностью современной сети Интернет является наличие заранее известной клиентской составляющей распределенного приложения, которое ориентировано на выполнение в этой сети.
Интернет прошел долгий путь развития и предлагал своим пользователям различные сервисы и службы (услуги), из которых те или
иные со временем обретали большую или меньшую популярность.
Но к настоящему моменту доминирующей и наиболее востребованной сетевой услугой Интернета стала так называемая «всемирная
паутина» – Word Wide Web (сокращенно – WWW). Все остальные
сервисы и службы, предоставляемые сетью Интернет, так или иначе, по факту, стали ее составляющими элементами. Взаимодействие
пользователей со «всемирной паутиной» подразумевает использование специализированных программ – программ навигации по сети
(browser, по-русски также иногда называется «браузер»).
Таким образом, если при применении технологий разработки,
ориентированных на создание приложений, использующих распределенные вычисления в локальных сетях, разработчики могли
использовать готовые компоненты для серверной части, то при создании приложений, рассчитанных на распределенные вычисления
в глобальной сети Интернет, разработчики фактически имеют готовую клиентскую часть в виде программы навигации по сети. При
этом они также могут использовать готовые компоненты при создании серверных частей приложения, о чем будет сказано далее.
4.2. Простейшие статические Web-страницы
Здесь нет возможности детально рассмотреть все основные принципы, на базе которых построена и функционирует сеть Интернет.
Поэтому будут описано только некоторые моменты, важные с точки зрения организации распределенных вычислений на основе
этой сети.
89
Как уже было сказано выше, основной принцип выполнения
приложений в этой сети основан на том, что клиентская часть приложения формирует запрос, в котором указывает, что она хочет
получить, и отправляет его на сервер. Этот запрос формируется по
результатам каких-то действий пользователя на стороне клиента.
Сервер в ответ на полученный корректный запрос должен подготовить код и передать его на клиентский компьютер. Клиент получает
код и исполняет его, предоставляя результат выполнения пользователю, который формировал запрос. Таким образом, пользователь
получает различные данные в ответ на свои действия.
В рамках сети Интернет были разработаны системы уникальных адресов (IP-адреса, IP – Internet Protocol, протокол Интернет),
позволяющие однозначно идентифицировать сервер сети, которому
предназначен запрос, а также доменные имена серверов, позволяющие представить идентификатор сервера сети в удобной для пользователя форме. Процессы и службы, связанные с поиском и идентификацией нужного сервера, передачей данных по сети, обработкой
возможных ошибок и потерь данных, остаются за рамками данного
учебного пособия.
Определяющим фактором глобальной сети является отсутствие на
сервере информации о том, под управлением какой вычислительной
системы будет функционировать клиент, пославший запрос на данный сервер. Поэтому код, который сервер предоставляет клиенту в ответ на запрос, не может быть откомпилирован. Конечно, в сам момент
поступления запроса сервер уже может получить сведения о вычислительной системе клиента, и теоретически можно было бы предположить наличие на сервере множества кодов для всех возможных вычислительных систем, из которых он мог бы выбрать код под систему
каждого клиента. Но тогда владельцы сервера должны были бы поддерживать это множество кодов опережающими темпами, постоянно
пополняя и актуализируя его по мере появления всё новых и новых
вычислительных систем на рынке, что практически вряд ли возможно. Следовательно, для построения кодов, предоставляемых клиентам
сети Интернет, необходимо использовать интерпретируемые языки.
В результате основой кода, который сервера Интернет предоставляют клиентам, стал интерпретируемый язык HTML. Язык HTML
(Hyper-Text Markup Language, язык разметки гипертекста) своим
появлением во многом определил развитие и широкое распространение сети Интернет по всему миру. Сам по себе язык достаточно
прост, а для овладения им нужны только самые примитивные знания в области программирования.
90
Язык позволяет описывать структурированный текст (гипертекст), содержащий ссылки и взаимосвязи фрагментов; графические элементы (изображения), которые могут быть связаны как с
текстовой информацией, так и между собой; а также простейшие
элементы графического интерфейса пользователя (кнопки, списки, поля редактирования, таблицы и т. п.). На основе описания,
построенного в текстовом виде на HTML, эти элементы могут располагаться на экране компьютера, им могут присваиваться различные атрибуты, определяющие используемые ресурсы интерфейса
пользователя (такие, как цвет, шрифты, размер и т. п.). В результате получается графический образ – Web-страница (от «web» – «паутина» – слова, входящего в состав аббревиатуры WWW – World
Wide Web – всемирная паутина). Построенная в результате интерпретации кода на языке HTML страница на клиентском компьютере, в принципе, может содержать различные мультимедийные элементы, включая размеченный текст, графические изображения,
видео и анимацию.
Широкому распространению HTML послужил принцип, на основе которого этот язык стал использоваться в глобальной сети. Суть
его достаточно проста: клиент посылает запрос на сервер, а интернетсервер в ответ на этот запрос создает текст на языке HTML и передает его в виде текстового файла на клиентскую сторону сети по специальному протоколу обмена данными HTTP (Hyper-Text Transfer
Protocol, протокол передачи гипертекста). Клиент, получая исходный текст на языке HTML, интерпретирует его и в соответствии с
результатом интерпретации строит соответствующие интерфейсные
формы и изображения на экране клиентского компьютера.
Тогда в общем виде работу сервера и клиента с простейшей Webстраницей можно представить так, как показано на рис. 8. Как уже
было сказано выше, сервера в сети Интернет идентифицируются
уникальными адресами и связанными с ними именами. Для однозначной идентификации всех Web-страниц, которые могут существовать в сети, была придумана система доменных имен и структура универсальных указателей ресурсов – URL (Universal Resource
Locator, универсальный указатель ресурса). Каждый URL содержит адрес сервера, которому необходимо направить запрос, а также дополнительные данные, необходимые серверу для однозначной
идентификации Web-страницы. В простейшем случае в качестве
идентификатора страницы может быть указано наименование этой
страницы на сервере (при этом имена страниц на сервере могут образовывать иерархическую структуру, подобную иерархической
91
Клиент Интерпретатор HTML
Интернет
Обработчик
протокола HTTP
Текст
HTML
Обращения
к URL
Клиент Интерпретатор HTML
Интернет
Обработчик
протокола HTTP
Сеть
Интернет
Обращения
к URL
Файлы
HTML
Сервер
Интернет
Текст
HTML
Обработчик
протокола HTTP
Рис. 8. Взаимодействие сервера и клиента в сети Интернет
для отображения простейшей Web-страницы
структуре файловой системы). Тогда клиент, запрашивая у сервера
Web-страницу, должен передать ему URL этой страницы.
Грамматика языка HTML проста, а потому не составляет сложности построить соответствующий интерпретатор. Именно такими
интерпретаторами явились уже упомянутые выше программы-навигаторы в сети Интернет (браузеры, browser), которые, по сути,
должны были содержать, как минимум, две составляющих: клиентскую часть для обмена данными по протоколу HTTP и интерпретатор языка HTML.
Некоторое время на рынке существовало огромное количество
такого рода программ, а несколько компаний-производителей боролись за свою долю рынка («война браузеров»). В настоящее время существует несколько известных фирм-производителей программного обеспечения, предлагающих свои программы навигации по сети
Интернет. Среди них можно выделить наиболее известные браузеры: Internet Explorer, предназначенный для вычислительных систем, построенных на основе ОС типа Windows, а также более универсальные программы навигации Firefox и Opera, предлагаемые
для различных типов ОС, и другие браузеры. В последнее время на
рынке программ навигации стали появляться браузеры, созданные
92
компаниями, которые сами предоставляют различные информационные услуги в сети Интернет – например, Chrome от компании
Google и Yandex от одноименной компании.
Таким образом, рынок программ навигации по сети сейчас можно считать сложившимся, его стабильность обеспечивают крупные
производители программных продуктов и востребованных в глобальной сети информационных услуг. Программы-навигаторы в настоящее время доступны практически всем, так как являются либо
свободно распространяемыми программами, либо поставляются
вместе с ОС и могут использоваться без ограничений. Производители этих программ извлекают выгоду не от прямой продажи лицензий, а от опосредованных преимуществ, связанных с распространением их программ навигации.
Но, так или иначе, все существующие браузеры должны соответствовать общепринятым стандартам протокола HTTP и языка
HTML, чтобы конечный пользователь клиента сети Интернет мог
получить доступ к ресурсам сети вне зависимости от того, какую
конкретно программу навигации по сети он использует. Такие общепринятые стандарты со временем сложились, были приняты и
поддерживаются всеми основными фирмами-производителями.
Однако глобальная сеть Интернет развивается, а потому лежащие
в ее основе стандарты тоже не могут оставаться неизменными. К сожалению, по мере развития сети Интернет было создано несколько разных версий этих стандартов, что иногда затрудняет работу в
сети, особенно для браузеров устаревших версий. Далее будут рассмотрены и другие факторы, из-за которых доступность ресурсов
сети Интернет может зависеть от типа и версии используемой программы навигации, а также и от ее внутренних настроек.
Гораздо разнообразнее программное обеспечение серверной части. Это вызвано тем, что в протоколе HTTP нигде строго не специфицирован источник HTML-текста. Самым простым источником
данных на сервере может служить множество файлов, содержащих
текст на языке HTML. В начале появления и развития сети WWW
большинство Web-страниц было организовано именно таким образом. В этом случае пользователи, присоединявшиеся к этим серверам, видели на экране своих компьютеров неизменную (статическую) картинку – отсюда название «статические Web-страницы».
В том случае, когда источником данных на сервере служит файл,
содержащий текст на языке HTML, пользователь на клиентском
компьютере получает у себя на экране картинку в соответствии с
содержимым этого файла. Изображение на экране может менять93
ся в соответствии с достаточно скромными возможностями языка
HTML, пользователь может перейти по ссылкам, содержащим URL
других Web-страниц, к другим страницам этого или другого сервера. Но в этом простейшем случае он не имеет возможности как-то
повлиять на содержимое страницы, на ту информацию, которую
предоставляет ему сервер.
Язык HTML прост и поэтому удобен. Однако отсюда же проистекают и основные его недостатки.
Во-первых, он не предоставляет средств динамического изменения содержимого интерфейсных форм и изображений, поэтому
основной метод – динамическое изменение самого текста HTML.
Во-вторых, сам язык никак не оговаривает методов создания исходных текстов HTML на стороне сервера. Он не предлагает никаких средств поддержки современных технологий разработки типа
«клиент-сервер» или трехуровневой архитектуры. Он не позволяет
обмениваться данными ни с серверами БД, ни с серверами приложений как на стороне сервера, где готовятся тексты HTML, так и на
стороне клиента, где эти тексты интерпретируются. Наконец, этот
язык имеет очень ограниченные средства для реакции на действия
пользователя в интерфейсных формах, созданных с его помощью.
Простейшая реализация Web-страниц ограничивала их возможности возможностями языка HTML. Для устранения указанных недостатков были предложены средства, выходящие за рамки HTML,
и позволяющие расширить возможности как сервера, так и клиента. Некоторые из них рассмотрены ниже.
4.3. Динамические Web-страницы
Самая простая идея расширения возможностей Web-страниц
заключалась в том, чтобы отказаться от статического источника
текста HTML в виде файла. Сервер может порождать новый HTMLтекст всякий раз, когда клиент устанавливает с ним соединение,
или даже менять текст по ходу взаимодействия клиента с сервером.
Причем клиент может передавать серверу в тексте запроса URL дополнительную информацию о том, какие данные и в каком виде он
хотел бы получить. Тогда и изображение на стороне клиента, зависящее от интерпретируемого текста HTML, будет динамически изменяться по мере изменения самого текста HTML, порождаемого
сервером. Вот в этом направлении и шло развитие основных средств
программирования для глобальной сети Интернет.
94
При динамической генерации Web-страниц вся страница на языке HTML или какая-то ее часть не хранится в статическом файле на
сервере, а порождается непосредственно каждый раз при обращении
клиента к серверу. При этом в запросе URL, который сервер получает
от клиента, должны быть указаны данные, необходимые серверу для
создания кода страницы HTML. Тогда сервер формирует эту страницу и сразу же по готовности передает ее код клиенту. Таким образом, всякий раз при новом обращении клиент получает новый текст
HTML, и не исключено, что тексты могут значительно различаться
между собой даже при обращении к одному и тому же серверу.
Вопрос только в том, как обеспечить динамическую генерацию
HTML-кода на стороне сервера.
Самое очевидное решение заключается в том, чтобы разработать
некоторый исполняемый файл (приложение), который будет динамически строить новый HTML-код. Тогда на вход такого исполняемого файла поступают параметры, выбранные сервером из запроса URL, полученного от клиента, а на выходе он должен порождать
HTML-код в виде текста. Для этой цели служат специальные приложения, называемые CGI-приложениями.
CGI (Common Gateway Interface, общедоступный шлюзовой интерфейс) – это интерфейс для запуска внешних программ на сервере
в ответ на действия клиента, установившего соединение с ним через
глобальную сеть. Пользуясь этим интерфейсом, приложения могут
получать информацию от удаленного пользователя в виде запросов
URL, анализировать ее, формировать HTML-код и отсылать его клиенту в ответ на поступивший запрос. CGI-приложения могут получать данные из заполненной формы, построенной с помощью HTML,
либо из командной строки описания URL. Строка URL вводится в
программе-навигаторе, осуществляющей доступ к серверу со стороны клиента. То, какие CGI-приложения по каким действиям пользователя должны выполняться на сервере, указывается непосредственно в коде HTML-страницы, которую сервер передает клиенту.
Кроме интерфейса CGI существуют и другие варианты интерфейсов, позволяющие динамически создавать HTML-код путем запуска на сервере приложений в ответ на действия клиента. Например, можно выделить интерфейс ISAPI (Internet Server Application
Programming Interface, интерфейс прикладных программ интернет-сервера). Отличие ISAPI от CGI заключается в том, что для поддержки CGI создаются отдельные приложения, выполняющиеся
в виде самостоятельных программ, а ISAPI поддерживается с помощью библиотек, динамически подключаемых к серверу. ISAPI95
библиотеки исполняются непосредственно в адресном пространстве
сервера, имеют большие возможности и обеспечивают более высокую производительность сервера, в то время, как CGI-приложения
исполняются в ОС сервера как отдельные процессы и вынуждены
определенным образом организовывать обмен данными с самим
сервером (что снижает производительность). Но, с другой стороны,
ошибка в библиотеке ISAPI может привести к выходу всего сервера из строя и его длительной неработоспособности. В то же время,
ошибка в коде CGI-приложения может, в худшем случае, привести
только к аварийному завершению выполнения этого приложения, а
сам сервер при этом сохранит работоспособность. Тогда в результате ошибки будет неверно отображена только какая-то одна HTMLстраница, либо часть страницы, а все остальные части сервера будут продолжать исправно работать.
Современные системы программирования, позволяют создавать
приложения и библиотеки, рассчитанные на работу в глобальной
сети в соответствии со стандартами CGI или ISAPI. При этом создание исходного кода приложения практически ничем не отличается от создания обычной исполняемой программы: компилятор попрежнему порождает объектные файлы, но компоновщик собирает
исполняемый файл или библиотеку с учетом того, что они будут исполняться в архитектуре сервера глобальной сети. Функции загрузчика выполняет ОС по команде сервера, либо сам Интернет-сервер.
Этот метод удобен, но имеет один серьезный недостаток: при изменении содержимого динамической HTML-страницы или же при
изменении логики ее реакции на действия интернет-клиента требуется создать новые код CGI или ISAPI-приложения. А для этого
нужно выполнить полностью весь цикл построения результирующей программы, начиная от изменения исходного кода, включая
компиляцию и компоновку. Поскольку содержимое Web-страниц
меняется довольно часто (в отличие от обычных программ), то такой подход нельзя признать очень эффективным. Кроме того, может
потребоваться перенос Интернет-сервера с одной архитектуры вычислительной системы на другую, а это также потребует перестройки всех используемых CGI-приложений и ISAPI-библиотек, кроме
того, они в этом случае должны удовлетворять всем требованиям
переносимости программного обеспечения.
Лучших результатов можно добиться, если не выполнять на сервере уже скомпилированный и готовый объектный код, а интерпретировать код программы, написанной на некотором языке. При интерпретации исходного кода сервер, конечно, будет показывать произ96
водительность ниже, чем при исполнении готового объектного кода,
но этим фактором можно пренебречь, поскольку производительность
серверов Интернета ограничивает чаще всего не мощность вычислительной системы, а пропускная способность канала обмена данными. Тогда зависимость кода сервера от архитектуры вычислительной
системы будет минимальной, а изменить содержимое порождаемой
HTML-страницы можно будет сразу же, как только будет изменен порождающий ее исходный код (без дополнительной перекомпиляции).
Существует несколько языков и соответствующих им интерпретаторов, которые нашли применение в этой области и успешно
служат цели порождения HTML-страниц. Среди них можно назвать язык Perl; язык, лежащий в основе различных версий Webтехнологии PHP (Personal Home Pages); а также язык сценариев, на
котором основана Web-технология ASP (Active Server Pages) – последний предложен и поддерживается корпорацией Microsoft.
Эти сценарии можно писать на любом языке, поддерживаемом
сервером. Интернет-сервер обрабатывает их при поступлении соответствующего URL-запроса. Он разбирает текст, соответствующий
запросу, который может содержать и статические HTML-страницы,
находит в нем тексты сценариев, вырезает их и интерпретирует в
соответствии с синтаксисом и семантикой используемого языка.
В результате интерпретации получается выходной текст на языке
HTML, который сервер вставляет непосредственно в то место HTMLстраницы, где встретился сценарий. Так обрабатывается и формируется динамическая Web-страница на любом интерпретируемом
языке, ориентированном на работу в глобальной сети. Естественно,
для работы со страницей сервер должен иметь в своем составе интерпретатор соответствующего языка.
Все эти языки сценариев обладают присущими им характерными особенностями. Во-первых, они имеют мощные встроенные
функции и средства для работы со строками, поскольку основной
задачей программ, написанных с помощью таких языков, является
обработка входных параметров (строковых) и порождение HTMLкода (который также является текстом). Во-вторых, все они имеют средства для работы в архитектуре «клиент-сервер» для обмена
информацией с серверами БД, а многие современные версии таких
языков (например, язык, поддерживаемый технологией ASP) – также и средства для функционирования в трехуровневой архитектуре
для обмена данными с серверами приложений.
В том случае, если приложение или интерпретируемый код на
сервере Интернет взаимодействуют с БД и реализуют какую-то биз97
нес-логику для создания Web-страниц (а такая практика используется на многих серверах Интернет), то на стороне сервера можно
говорить о полноценном приложении, построенном на основе одной
из технологий разработки, рассмотренных выше. Тогда сам Интернет-сервер может представлять собой сложное приложение, использующее распределенные вычисления, компоненты которого распределены по локальной сети. Но при этом он сам будет серверной
компонентой другого приложения, использующего распределенные
вычисления уже в глобальной сети. При этом программный код, выполняемый на сервере Интернет, может представлять собой приложение, построенное по архитектуре «клиент-сервер», многоуровневой архитектуре или на основе их комбинации, к которому, в свою
очередь, обращаются клиенты Интернет. В таком варианте работу
сервера и клиента для отображения динамической Web-страницы
можно представить так, как показано на рис. 9.
Клиент Интерпретатор HTML
Обработчик
Интернет протокола HTTP
Текст
HTML
Обращения
URL
Клиент Интерпретатор HTML
Обработчик
Интернет протокола HTTP
Сеть
Интернет
Обращения
URL
Файлы
HTML
Текст
HTML
Обработчик
Сервер
протокола HTTP
Интернет
Команда Результат
(CGI,
(HTML)
ISAPI)
Локальная сеть
СУБД
Данные
Внешний обработчик
(клиент СУБД)
Рис. 9. Взаимодействие сервера и клиентов в сети Интернет
для отображения динамической Web-страницы с использованием
технологии «клиент-сервер»
98
В схеме взаимодействия приложений, представленной на рис. 9
выделяются три основных компоненты:
– клиент Интернет, отображающий Web-страницу для пользователя;
– сервер Интернет, подготавливающий Web-страницу в соответствии с логикой приложения, заложенной на этом сервере, и одновременно являющийся клиентом по отношению СУБД;
– СУБД, осуществляющая операции с данными и файловые операции.
Получается, что по распределению функций схема, представленная на рис. 9, аналогична приложению, построенному по трехуровневой архитектуре. Наверное, приложения, работающие подобным
образом, можно считать построенными по трехуровневой архитектуре (и некоторые производители в маркетинговых целях именно
так и поступают). Но здесь следует учитывать одно важное допущение: в такой схеме взаимодействие тонкого клиента с сервером
возможно только по протоколу HTTP, который накладывает существенные ограничения на самого тонкого клиента и его возможности, в то время как полноценное приложение, построенное по трехуровневой архитектуре, лишено такого рода ограничений.
Первый недостаток всех перечисленных методов организации
динамических Web-страниц заключается в том, что сначала сервер
вынужден строить HTML-описание, собирая его некоторым образом
из каких-то своих данных, а затем клиент Интернет на своей стороне
разбирает (интерпретирует) полученное описание HTML-страницы.
Таким образом, выполняется как бы двойная работа по генерации, а
затем интерпретации текстов языка HTML. Кроме того, между клиентом и сервером по сети передаются довольно громоздкие описания
HTML-страниц, что может значительно увеличивать трафик сети.
Еще один недостаток заключается в том, что на любые действия
пользователя Web-страница в такой схеме может реагировать только с некоторым опозданием. Сначала клиент должен передать на
сервер информацию о действиях пользователя, потом сервер должен обработать полученные данные и передать клиенту новый текст
HTML для Web-страницы, после чего клиент должен обработать полученные данные и отобразить изменения на экране. Все эти операции, а особенно передача данных по глобальной сети, занимают
заметное время, поэтому интерактивные возможности таких Webстраниц ограничены.
Тем не менее, несмотря на недостатки, данные методы довольно
распространены в глобальной сети, поскольку они очень просты, а,
99
кроме того, не требуют от клиентского компьютера ничего, кроме
способности интерпретировать тексты HTML. Эта особенность довольно существенна.
4.4. Интерактивные Web-страницы
Следующим шагом в развитии Web-страниц стало добавление в
них интерактивных возможностей. Наличие таких возможностей
подразумевает, что некоторая часть Web-страницы может, реагируя на действия клиента, менять свой вид и содержимое, не передавая при этом на сервер Интернет команды для изменения текста
страницы. То есть подразумевается, что в этом случае не требуется
формирование запроса URL, передача его на сервер и ожидание результатов его обработки для получения текста HTML. Иными словами, какая-то часть Web-страницы должна выполняться на компьютере клиента Интернет.
Такой подход предполагает, что Web-страница или какая-то ее
часть формируется именно на стороне клиентского компьютера на
основании выполнения кода, полученного от сервера Интернет, с
учетом действий пользователя на клиентской стороне. Очевидно,
что время реакции клиентского приложения на действия пользователя в этом случае будет более оперативным, чем при использовании технологий динамического формирования Web-страницы, так
как не требуется передавать данные по сети (в двух направлениях).
Очень часто такая схема используется при организации различных
интерфейсных элементов на Web-страницах для повышения наглядности представления данных на них, откуда и происходит название технологии – интерактивные Web-страницы.
Поскольку вычислительная система клиента Интернет может
быть любой (и заранее не известно, какой конкретно она будет), для
организации интерактивных Web-страниц не может быть использован компилируемый код. В принципе, возможны только следующие
способы организации выполнения кода Web-страницы на клиенте:
– использование интерпретируемых языков сценариев (script),
выполняемых на стороне клиента;
– использование языков и технологий, не зависящих от архитектуры целевой вычислительной системы.
При использовании интерпретируемого языка исполняемый код
(или сценарий – script) встраивается в HTML-текст Web-страницы,
передаваемой с сервера на клиентский компьютер. На клиентской
100
стороне обработчик (интерпретатор HTML) должен выделить этот
код в тексте и передать его на выполнение интерпретатору соответствующего языка. Результатом выполнения кода должен быть
фрагмент текста HTML, который встраивается в соответствующее
место Web-страницы и в итоге отображается на экране клиентского
компьютера. В целом это очень похоже на то, как формируются динамические Web-страницы при использовании интерпретируемых
языков. Принципиальная разница заключается в том, что интерпретация кода (исполнение сценария) происходит не на сервере, а
на клиентской стороне, при этом можно учесть информацию о вычислительной среде, действиях пользователя и некоторые входные
данные, имеющиеся именно на клиентском компьютере.
Интерпретация кода интерактивных Web-страниц на стороне
клиента накладывает достаточно жесткие ограничения на возможный язык для создания такого кода. Если на сервере для формирования динамических Web-страниц разработчики могут использовать любой доступный интерпретируемый язык, применимый для
этой функции, по своему выбору, то для создания интерактивных
Web-страниц выбор доступных языков существенно ограничен. Поскольку клиентской частью приложения для сети Интернет обычно
является программа навигации по сети («браузер»), в качестве языка разработки интерактивных Web-страниц может быть выбран
только такой язык, для которого в составе большинства браузеров
имеется соответствующий интерпретатор. Иначе разработчики вынуждены будут ограничить возможности своего приложения тем,
что оно будет доступно только для определенного типа браузеров,
что, безусловно, негативно скажется на конкурентоспособности этого приложения на рынке.
В настоящее время, по факту, наиболее распространенным языком для создания сценариев («скриптов», script) интерактивных
Web-страниц стал язык JavaScript. Это интерпретируемый язык,
синтаксис которого похож на синтаксис языка Java. При этом ни
в коем случае нельзя путать эти языки: Java – это компилируемый
объектно-ориентируемый язык со строгой типизацией, исходная
программа на котором преобразуется компилятором в промежуточный байт-код (который потом исполняется в среде выполнения, называемой «Java-машина»); при том, что JavaScript – это интерпретируемый объектно-ориентированный язык с динамической типизаций, код на котором непосредственно выполняется (интерпретируется). Интерпретаторы для языка JavaScript входят в состав всех
основных типов браузеров, используемых для доступа в Интернет.
101
В простейшем случае (например, для создания интерактивных
элементов вроде «всплывающего» меню) исполнение языков сценариев (script) на клиенте Интернет является приемлемым решением.
Но для реализации сложных интерактивных функций, связанных
с обработкой информации и БД, использование языков сценариев
будет связано с серьезными проблемами. Ведь в этом случае на клиентскую часть через Интернет должен быть передан значительный
объем текста на языке сценария, который затем должен быть обработан и интерпретирован на клиенте.
При использовании вместо интерпретируемых языков использование технологий, не зависящих от архитектуры целевой вычислительной системы, на клиентскую часть передается не код, а некоторый компонент (апплет, applet), который выполняется клиентом Интернет – то есть, программой навигации по сети (браузером).
Апплет может быть написан на полноценном языке программирования, но должен быть построен таким образом, чтобы не зависеть
от типа целевой вычислительной системы. При этом очевидно, что
клиентская часть приложения – то есть, браузер – должна допускать выполнение в своем составе таких апплетов.
Выбор средств для создания подобных апплетов ограничен тем же
условием, что и выбор доступных интерпретируемых языков для создания сценариев – эти средства (и соответствующие им технологии)
должно поддерживать большинство программ навигации по сети
(браузеров), которые являются основой клиентской части приложения, ориентированного на распределенные вычисления в глобальной
сети Интернет. В настоящее время большинство браузеров имеют в
своем составе Java-машину – среду для выполнения программ, созданных на языке Java. Поэтому достаточно широкое распространение получили Java-апплеты – компоненты, написанные на этом языке. В отличие от интерпретируемого языка JavaScript, в этом случае на клиентскую часть приложения передается не исходный код
компонент, а уже откомпилированный промежуточный байт-код,
который выполняется браузером в среде его Java-машины. Именно
использование промежуточного байт-кода вместо машинного кода
(который всегда ориентирован на строго определенную целевую систему) позволяет в этом случае использовать средства компиляции.
Альтернативным средством создания компонент для браузеров
является технология ActiveX, предлагаемая корпорацией Microsoft.
Эта технология создания апплетов построена на основе технологий
COM/DCOM, которые были упомянуты ранее, и также предполагает
выполнение промежуточного кода в так называемой «общеязыко102
вой среде выполнения» (Common Language Runtime – CLR). Однако технология ActiveX большей частью ориентирована на ОС типа
Microsoft Windows и браузеры, выполняющиеся под управлением этой ОС (прежде всего – браузер Internet Explorer от Microsoft).
И хотя в настоящее время существуют ее реализации под другие ОС,
ориентированность данной технологии на ОС типа Windows существенно ограничивает ее распространение в глобальных сетях.
Разработчики приложений, рассчитанных на распределенные
вычисления в глобальной сети Интернет и использующих интерактивные Web-страницы на клиентской части приложения, могут для
создания этих Web-страниц по своему выбору применять как интерпретируемые языки, так и апплеты, а также сочетать использование обоих этих средств.
Наличие кода, выполняющегося на клиентской стороне, в составе интерактивных Web-страниц заставляет их разработчиков и
пользователей принимать во внимание два немаловажных вопроса:
– совместимость со всеми возможными клиентскими приложениями;
– информационная безопасность кода, выполняемого на стороне
клиента.
Вопросы, связанные с совместимостью, уже были затронуты
выше, когда речь шла о выборе применяемых интерпретируемых
языков и апплетов. При использовании этих средств разработчики
приложения должны позаботиться о том, чтобы они могли выполняться на всех возможных клиентских частях этого приложения –
то есть, на всех распространенных типах браузеров. Однако добиться этого на практике довольно сложно. Возможности средств создания интерактивных Web-страниц постоянно совершенствуются и
расширяются, процесс развития программ навигации по глобальной сети идет параллельно, но не всегда поспевает за этими новшествами. Поэтому, по факту, на рынке всегда присутствует некоторое
количество клиентских программ (браузеров), которые не обеспечивают те или иные новые возможности интерактивных Web-страниц
(как правило, это браузеры устаревших версий). Кроме того, иногда
эти возможности могут быть отключены пользователями по различным причинам (например, по соображениям информационной
безопасности, о которых будет сказано далее).
Поэтому при разработке серверной части для интерактивных
Web-страниц их создателям следует учитывать следующие факторы:
– Необходимо заранее определиться, насколько широкое множество клиентских частей (браузеров) будет поддерживать разрабаты103
ваемое приложение. При этом надо либо заранее быть готовыми к
тому, что рынок пользователей приложения будет ограничен, либо
отказаться от каких-то технологических новинок, расширяя тем самым доступность приложения на рынке.
– Рекомендуется создавать интерактивные Web-страницы таким образом, чтобы при невозможности выполнения используемых
средств интерактивности (интерпретируемых языков сценариев и/
или апплетов) основной функционал приложения оставался работоспособным. То есть, при отсутствии интерактивности могут пострадать наглядность и качество интерфейса, но приложение должно
сохранять базовую функциональность.
Здесь, как и при решении многих других рассмотренных ранее
проблем, связанных с распределенными вычислениями, нет одного
однозначно правильного решения для всех случаев. Выбор решения
в каждом конкретном случае зависит от многих технологических и
экономических факторов, которые должны приниматься во внимание разработчиками.
Если же говорить об информационной безопасности, то сам факт
выполнения на стороне клиента кода, полученного из глобальной
сети, несет в себе потенциальную угрозу. На это накладываются особенности разработки программных продуктов в условиях глобальных сетей. Здесь определяющим фактором является тот факт, что ни
разработчики, ни конечные пользователи (потребитель программных продуктов) не имеют возможности полностью контролировать
все составляющие, участвующие в организации распределенных вычислений в условиях глобальной сети (в отличие от сети локальной).
В таких условиях у злоумышленников всегда есть возможности воздействовать на процесс организации распределенных вычислений.
Если заранее не предусмотреть никаких ограничений, то по причине наличия ошибок в коде или злонамеренного вмешательства код, полученный из глобальной сети, может повредить данные клиентского
компьютера, непосредственно не связанные с выполняемым приложением (с той Web-страницей, которая отображается на клиенте). Поэтому разработчики программ навигации по сети (браузеров) прилагают
определенные усилия, направленные на обеспечение информационной
безопасности при выполнении кода, полученного из глобальной сети
(вне зависимости от того, является ли этот код текстом на интерпретируемом языке или компонентом, встраиваемым в браузер).
Во-первых, любой код, выполняемый на клиентской части распределенного приложения, не должен иметь возможности получать
доступ к вычислительным ресурсам и привилегиям, не доступным
104
для программного кода самой клиентской части. Эти ограничения
обеспечиваются операционной системой на клиентском компьютере. Тогда любой код, исполняемый программой навигации по сети,
не сможет получить доступ за пределы адресного пространства, выделенного этой программе, а также выполняться с большими привилегиями, чем имеет данная программа (по этой причине крайне не
рекомендуется запускать на выполнение клиентские программы с
административными правами, даже если пользователь имеет такие
права на компьютере). При соблюдении этих условий любая возникшая ошибка кода или целенаправленное выполнение вредоносных
действий в худшем случае может привести к нарушению функционирования только самого браузера, не влияя на то окружение вычислительной среды клиентского компьютера, в которой он выполняется.
Во-вторых, в дополнение к указанным ограничениям со стороны
ОС, все современные программы навигации по сети (браузеры) вводят
дополнительные ограничения по отношению к выполнению кода, полученного из сети, на клиентском компьютере. Многие локальные
действия (например, такие, как доступ к локальной файловой системе, запуск на выполнение процессов) для такого кода или полностью
запрещены, или существенно ограничены. С точки зрения клиентской части приложения полученный из сети код выполняется в окружении, которое получило название «песочница» («sandbox»), где он
изолирован не только от ресурсов локальной вычислительной среды,
но и от других экземпляров кода и данных, обрабатываемых той же
клиентской программой (один и тот же браузер может одновременно выступать в качестве клиентской части нескольких приложений).
Любые нарушения выполнения кода в «песочнице» в идеале должны
оказывать влияние только на сам этот код и его данные.
Тем не менее, указанные выше ограничения обеспечивают информационную безопасность только при условии их предельно
корректной и безошибочной реализации, что достижимо только в
идеальном пределе. В реальности же идеальной безопасности достичь не удается. Как на уровне ОС, так и в различных браузерах в
системе безопасности время от времени обнаруживаются «прорехи»
и уязвимости, которые постепенно устраняются по мере развития
этих программных продуктов. Однако средства и технологии создания интерактивных Web-страниц также постоянно развиваются,
что наряду с новыми возможностями создает иногда и новые проблемы. Поэтому проблема информационной безопасности при использовании распределенных вычислений в глобальных сетях постоянно остается актуальной.
105
4.5. Сервис-ориентированные архитектуры.
Web-службы (Web-сервисы)
Всемирное распространение глобальных сетей (прежде всего,
сети Интернет) и развитие технологий разработки приложений для
подобных сетей, а также широкое применение внутренних корпоративных сетей, построенных на основе базисных принципов сети
Интернет (так называемых сетей «интранет») сделало возможным
дальнейшее развитие технологий организации распределенных вычислений в глобальных сетях. Основная идея их развития заключалась в том, что те же самые принципы, на основе которых построено
взаимодействие серверной и клиентской частей в Интернет-приложениях, можно использовать и для организации взаимодействия
между различными компонентами серверной части приложения.
Иными словами, протоколы и стандарты, ориентированные на взаимодействие с клиентом, можно применить и для обмена данными в
многоуровневой архитектуре серверной части приложения.
На базе этих основных принципов появилась сервис-ориентированная архитектура разработки (SOA – service-oriented architecture).
Это модульный подход к разработке, который позволяет построить
приложение как комбинацию распределенных слабо связанных
(«loose coupling») взаимозаменяемых компонентов, каждый из которых имеет стандартизированный интерфейс для взаимодействия
с другими компонентами по специфицированным протоколам. Интерфейсы компонентов в такой архитектуре скрывают (инкапсулируют) детали их реализации от остальных компонентов. За счет этого обеспечивается возможность комбинирования и многократного
использования компонентов для построения сложных распределённых приложений. Сервис-ориентированная архитектура предусматривает независимость компонентов от используемых платформ и
средств разработки, способствуя масштабируемости и управляемости приложений, создаваемых на ее основе. При этом архитектура
не привязана к какой-то определённой технологии. Она может быть
реализована с использованием широкого спектра технологий, включая рассмотренные ранее технологии RPC, DCOM, CORBA или Webслужбы (Web-сервисы), о которых пойдет речь далее.
Фактически сервис-ориентированная архитектура является вариантом многоуровневой архитектуры организации распределенных вычислений. Главное, что ее отличает – это то, что на каждом
уровне организации распределенных вычислений используются
независимые сервисы с чётко определёнными интерфейсами. Каж106
дый из таких сервисов для выполнения своих задач может быть
вызван неким стандартным способом. При этом каждый сервис заранее ничего не знает о приложении, которое его вызовет, а приложение, состоящие из этих сервисов на разных уровнях организации
распределенных вычислений, не знает, каким образом сервисы выполняют свою задачу. При таких условиях сервисы должны взаимодействовать на основе какого-либо строго определённого интерфейса, который не должен зависеть ни от вычислительной среды, ни от
средств реализации (разработки). Определение интерфейса должно
скрывать реализацию сервиса, которая внутри уже может зависеть
и от вычислительной среды, и от используемого языка.
Таким образом, приложения, основанные на SOA, могут быть независимы от технологий разработки и вычислительной среды. При этом
приложения, работающие на одних платформах, могут вызывать сервисы, работающие на других платформах, что облегчает повторное
использование компонентов, входящих в состав одного приложения,
в других приложениях. SOA может поддерживать интеграцию и консолидацию операций в составе сложных систем, однако SOA не определяет и не предоставляет методологий документирования сервисов.
Распределенные приложения, разработанные в соответствии с
сервис-ориентированной архитектурой, часто реализуются как набор Web-служб. Именно Web-служба в основном является единицей
модульности при использовании сервис-ориентированной архитектуры для построения распределенного приложения.
Web-служба (английский термин Web-Service, иногда и порусски это средство называют «Web-сервис») – это идентифицируемый некоторым Web-адресом программный компонент со стандартизированными интерфейсами. Web-службы могут взаимодействовать друг с другом и со сторонними приложениями посредством сообщений, основанных на определённых протоколах и соглашениях.
В обиходе Web-сервисами часто называют услуги, оказываемые
в сети Интернет. В основе таких Web-сервисов в большинстве случаев (но не обязательно всегда) лежит соответствующая Web-служба,
а в качестве клиента, запрашивающего услуги этой службы, обычно выступает программа навигации по сети Интернет (браузер).
Применительно к услугам, оказываемым в сети Интернет, термин
«Web-сервис» требует уточнения, идёт ли речь о поиске, Web-почте,
хранении документов, файлов, закладок и т. п. Поскольку все подобные сервисы построены на основе базисных принципов SOA, ими
можно пользоваться независимо от компьютера, браузера или места
доступа в сеть Интернет.
107
В общем случае Web-служба – это часть приложения или блок
находящегося на сервере исполняемого кода, функционирование
которого основано на применении протоколов обмена данными, использующими в качестве инструмента для обмена данными средства, построенные на основе языков разметки. Язык разметки –
это компьютерный язык, позволяющий описывать и передавать
по сети не только сами данные, но и информацию об их структуре и строении. То есть язык разметки – это текстовое представление самих данных и их структуры. В качестве наиболее часто используемых примеров таких языков можно назвать языки XML
(eXtensible Markup Language – расширяемый язык разметки) и
JSON (JavaScript Object Notation – описание объектов в нотации
JavaScript). Эти два языка разметки чаще всего находят применение при создании Web-служб, хотя существуют и другие используемые для этой цели языки разметки.
Общие принципы, объединяющие Web-службы со всеми остальными технологиями взаимодействия различных частей приложений при организации распределенных вычислений, заключаются
в порядке организации взаимодействия частей приложения между
собой. Во всех подобных технологиях последовательность действий,
выполняемых как со стороны клиентской части (запрашивающей
услуги), так и со стороны серверной части (предоставляющей услуги) подобна той, что была описана выше для технологии RPC. Главная особенность Web-служб заключается в том, что маршаллинг
(преобразование данных для передачи их по сети) и демаршаллинг
(преобразование принятых данных в локальное представление) выполняется на базе текстовых форматов, описываемых соответствующим языком разметки. Использование текстовых форматов, никак не зависящих от бинарного представления тех или иных данных, делает Web-службы полностью автономными компонентами
распределенного приложения.
Кроме того, Web-служба – это не объект в его традиционном
представлении в объектно-ориентированных языках (хотя подавляющее большинство Web-служб и реализуется именно такими объектами). Любой Web-метод, используемый Web-службой, является
неделимым и не имеющим фиксированной реализации и постоянного местонахождения. В некоторой степени любая Web-служба
подобна библиотеке динамических функций и, по сути, близка к
рассмотренным выше интерфейсам классов, но дает более высокий
уровень абстрагирования от реализации, чем это позволяют сделать
упомянутые интерфейсы. Это упрощение в значительной мере обе108
спечивает преимущества Web-служб. Именно поэтому Web-службы
не ограничены конкретной технологией и могут быть использованы
в любом сценарии, что существенным образом отличает их от таких
технологий как COM/DCOM и CORBA.
Можно выделить три инстанции, взаимодействующие в рамках
Web-службы:
– заказчик (service requester);
– разработчик (service provider);
– каталог (service broker).
Когда Web-служба разработана, разработчик создает ее описание на специализированном языке WSDL (Web Service Description
Language – язык описания Web-служб), который построен на основе языка текстовой разметки XML. Созданное описание разработчик может зарегистрировать в каталоге, где Web-службу могут
найти потенциальные заказчики. В свою очередь заказчик, найдя в каталоге подходящую Web-службу, импортирует оттуда её
WSDL-спецификацию и разрабатывает в соответствии с ней своё
программное обеспечение. WSDL описывает формат запросов и ответов, которыми обмениваются заказчик и исполнитель в процессе работы. Однако разработчик может не регистрировать описание
созданной службы в каталогах, если не планирует предоставлять ее
для общего доступа.
Как уже было сказано выше, одним из наиболее употребительных языков разметки для Web-служб является язык XML. Описание Web-служб также строится на основе подмножества этого языка. Язык XML по своей структуре похож на язык HTML и является
языком текстовой разметки. Файл XML – это обычный текстовый
файл, содержимое которого структурировано в соответствии с синтаксисом языка XML. Распознаватель текста XML оперирует синтаксическими конструкциями языка, главной из которых является тэг (от английского «tag»). Более строгие по сравнению с HTML
правила, и четкая стандартизация языка определили широкое распространение XML в качестве языка обмена данными. Удобство его
использование в этом качестве определяет тот факт, что представление любых структурированных данных на XML не зависит от
вычислительной системы и определяется только синтаксисом этого языка. При этом семантика (смысл данных, представленных на
XML) регламентируется разработчиком, которые определяет смысл
каждого тэга языка и его атрибутов. В результате широкого распространения языка XML библиотеки, содержащие распознаватели
этого языка, стали доступны практически для всех существующих
109
вычислительных систем и поддерживаются многочисленными системами программирования.
Можно указать следующие преимущества использования Webслужб для организации распределенных вычислений:
– Web-службы обеспечивают взаимодействие компонент распределенного приложения полностью независимо от вычислительной
платформы. Например, Windows-клиент может обмениваться данными с Java-сервером, работающим под Linux.
– Web-службы строятся на базе открытых стандартов и протоколов. Благодаря использованию языков типа XML и JSON, имеющих
широкую поддержку со стороны различных средств разработки, достигается простота разработки и отладки Web-служб.
– Использование распространенных протоколов глобальной сети
Интернет обеспечивает взаимодействие компонент распределенных
приложений через межсетевые экраны. Это значительное преимущество, по сравнению с такими технологиями, как CORBA, DCOM
и им подобными. С другой стороны, Web-службы не привязаны намертво к HTTP и могут использоваться протоколы.
В качестве главного недостатка Web-служб по сравнению с технологиями CORBA, DCOM и им подобным можно указать меньшую
производительность и больший размер сетевого трафика за счёт
использования текстовых сообщений для обмена данными. В этом
смысле сообщения на основе XML дают наибольший рост «паразитной» информации при передаче данных, использование JSON
позволяет достичь большей компактности сообщений, но всё равно
несравнимо с передачей двоичных данных по сети. Абстрагирование от вычислительной среды и использование текстовых языков
разметки неизбежно дает потери в производительности и сетевом
трафике. На некоторых Web-серверах возможна настройка сжатия
сетевого трафика, но и это не решает полностью данную проблему.
Еще одним важным вопросом являются аспекты безопасности.
Ответственные Web-службы должны использовать кодирование, а
возможно – требовать аутентификации пользователя. Здесь можно говорить об использовании протокола Интернет с применением
шифрования HTTPS (HyperText Transfer Protocol Secure), а также
использовать другие решения, которые должны быть выбраны и
определены разработчиком.
В настоящее различные Web-службы в сети Интернет, которые могут быть использованы как конечными пользователями, так и компонентами различных приложений, предоставляют многие ведущие
Интернет-компании, такие как Google, Yandex, Microsoft и другие.
110
Технология Web-служб широко применяется при создании распределенных приложений во многих отраслях, чаще всего там, где нет потребности в высокой производительности при обмене данными.
В кратком обзоре сложно дать даже общие представления о сервис-ориентированной архитектуре и связанных с нею технологиях
организации распределенных вычислений. Автор рекомендует обратиться к специализированной литературе или к ресурсам сети
Интернет. Эта область технологий сейчас продолжает развиваться и
совершенствоваться, так как в настоящее время является перспективным направлением многих ведущих IT-корпораций.
Контрольные вопросы
1. Какие особенности глобальных вычислительных сетей оказывают определяющее влияние на организацию распределенных вычислений в таких сетях?
2. Почему интерпретаторы и интерпретируемые языки программирования нашли широкое применение именно в глобальных вычислительных сетях?
3. Какие программы чаще всего выступают в роли клиентской
части приложения при организации распределенных вычислений в
глобальной сети Интернет?
4. Какие основные компоненты должны входить в состав любой
программы навигации по глобальной сети Интернет (браузера)?
5. Что представляет из себя URL? Какие данные он содержит?
6. Какой основной принцип используется для организации динамических Web-страниц?
7. Сравните основные методы подключения программного кода
для организации динамических Web-страниц на серверной части
приложения.
8. Почему компилируемые языки не всегда удобно использовать
для создания программного кода, генерирующего динамические
Web-страницы на серверной части приложения?
9. В чем состоит принцип создания интерактивных Web-страниц? Чем они принципиально отличаются от динамических Webстраниц?
10. Какие вопросы, связанные с информационной безопасностью, возникают при организации распределенных вычислений в
глобальной сети Интернет при использовании динамических Webстраниц? Как решаются эти вопросы?
111
11. Что такое апплет (applet)? Какие особенности связаны с созданием и использованием апплетов для организации распределенных вычислений в глобальной сети Интернет?
12. На основе каких базисных принципов построена разработка
приложений в сервис-ориентированной архитектуре (SOA)?
13. Что такое Web-службы? Что общего между Web-службами
и технологиями взаимодействия различных частей приложения в
локальных сетях? В чем заключаются принципиальные различия
между ними?
14. Что представляет собой язык гипертекстовой разметки XML?
Для каких целей он используется?
112
5. ОРГАНИЗАЦИЯ ОБЛАЧНЫХ ВЫЧИСЛЕНИЙ
5.1. Общие принципы облачных вычислений
В последнее время в области информационных технологий получил широкое распространение новый термин – облачные вычисления. И хотя облачные вычисления – это всего лишь особый способ
предоставления вычислительных ресурсов потребителям, а не новая технология, они вызвали революцию в методах предоставления
информации и услуг. При этом далеко не всегда потребители рынка
информационных услуг (как конечные пользователи, так и корпоративные клиенты), а также равно и поставщики этих услуг четко и
однозначно понимают, что подразумевает под собой новая терминология. Следствием этого является среди прочего и то, что тема из разряда реалий переходит в область модных слов и некой «мифологии».
Проблема заключается в том, что смысл реальных инновационных
идей растворяется в разговорах о моде, когда желание маркетологов
поскорее продвинуть новые возможности имеет результатом «запутывание слушателей», при котором серьезные обсуждения предлагаемых инноваций подменяются проповедями и заклинаниями.
Поэтому прежде, чем рассуждать об облачных вычислениях, а
также о тех преимуществах и недостатках, которые влечет за собой данная модель предоставления вычислительных ресурсов, надо
дать однозначное определение тому, что же собой представляют эти
облачные вычисления.
По сути, облачные вычисления (английский термин: cloud
computing) – это модель обеспечения удобного сетевого доступа по
требованию к некоторому общему фонду конфигурируемых вычислительных ресурсов (например, различным серверам, устройствам хранения данных, приложениям и сервисам), которые могут
быть оперативно предоставлены и освобождены с минимальными
эксплуатационными затратами. В результате в идеальном случае
получение требуемых вычислительных ресурсов, а равно и отказ
от их использования должны выполняться путем простейших обращений к провайдеру, предоставляющему эти вычислительные
ресурсы. Фактически облачные вычисления – это всего лишь множество специфических способов предоставления вычислительных
ресурсов и услуг, а не какая-то принципиально новая технология.
Однако реализация этих новых способов предоставления вычислительных ресурсов и услуг была бы невозможной без развития и
внедрения тех технологий, на которых они основаны. Облачные вы113
числения как способ предоставления услуг фактически выросли из
технологий организации распределенных вычислений, без которых
само их существование было бы немыслимым. Облачные вычисления – это реальная революция в организации вычислительных процессов и предоставлении соответствующих услуг. Но эта революция,
как и любая другая, содержит в своей основе проверенные технические решения и компоненты, из которых она эволюционировала.
Таким образом, чтобы правильно понимать суть облачных вычислений, нужно помнить, что они, по существу, генетически наследуют и включают в себя все предшествующие технологические
решения. В этом современном мире облачных вычислений есть место для инновационного кооперирования облачных методов и уже
проверенной эффективности предшествующих технологических
решений по организации распределенных вычислений. Это подлинное изменение подхода к вычислениям предоставляет IT-персоналу
новые возможности, позволяя взять управление изменениями на
себя и использовать их во благо себе и своей организации.
Именно поэтому разговору об облачных вычислениях в данном
учебном пособии предшествовало долгое и тщательное ознакомление со всевозможными современными технологиями организации
распределенных вычислений.
Наряду с технологическими возможностями, без которых появление облачных вычислений было бы невозможным, вторым аспектом, предопределившим их появление и распространение на рынке
IT-услуг, стал аспект экономический. Без наличия экономической
выгоды никакие самые современные технологии не могли бы завоевать рынок.
Если смотреть с экономической точки зрения, то потребители
облачных вычислений могут значительно уменьшить свои расходы
на инфраструктуру информационных технологий (в краткосрочном
и среднесрочном планах) и гибко реагировать на изменения вычислительных потребностей, используя свойства вычислительной эластичности (английский термин: elastic computing) облачных услуг.
При использовании облачных вычислений потребители информационных технологий могут существенно снизить капитальные расходы – на построение центров обработки данных, закупку серверного и
сетевого оборудования, аппаратных и программных решений по обеспечению непрерывности и работоспособности – так как эти расходы
полностью поглощаются провайдером облачных услуг. Кроме того,
длительное время построения и ввода в эксплуатацию крупных объектов инфраструктуры информационных технологий и высокая их
114
начальная стоимость ограничивают способность потребителей гибко
реагировать на требования рынка, тогда как использование облачных вычислений обеспечивает возможность практически мгновенно
реагировать на увеличение спроса на вычислительные мощности.
При использовании облачных вычислений затраты потребителя смещаются в сторону операционных – таким образом классифицируются расходы на оплату услуг облачных провайдеров. Для
объяснения экономической составляющей облачных подходов к
вычислениям часто используется аналогия с услугами водо- или
электроснабжения, предоставляемыми в развитых инфраструктурах по соответствующим коммунальным сетям, легкодоступными
и оплачиваемыми по мере потребления, в сравнении с разработкой
каждым потребителем собственного водозабора или монтированием собственной электроустановки.
Далее будут рассмотрены основные технологии предоставления
облачных вычислений. Следует обратить внимание, что, как уже
было с казано выше, это именно технологии предоставления доступа к вычислительным ресурсам, но не технологии организации
самих вычислений. Но вместе с этими способами предоставления
облачных вычислений будут рассмотрены и те технологии распределенных вычислений, на которых они основаны.
5.2. Технологии «HaaS» и «IaaS».
Виртуализация ресурсов
Как уже было сказано, одна из общих проблем, связанных с облачными вычислениями («IT-облаками», как модно говорить) – это
отсутствие четкого понятного структурированного представления
на рынке, что же это такое, что же, собственно, в них нового. В отсутствие такого общего понимания в дань моде и маркетинговым
преимуществам появляются всё новые и новые, иногда малопонятные и запутанные термины. В сфере, связанной с облачными вычислениями, таких малопонятных, а иногда и перепутанных, с точки зрения автора, терминов появилось уже немало. Так или иначе,
но говоря об облачных вычислениях, не удастся обойтись без их использования. Тем не менее, по каждому такому термину постараемся дать исчерпывающее объяснение его сути и возможные варианты
толкования.
Если говорить о формальных требованиях к облачным вычислениям, то Национальным институтом стандартов и технологий США
115
зафиксированы следующие обязательные характеристики облачных вычислений:
– Самообслуживание по требованию (английский термин: self
service on demand – SSOD). Это подразумевает, что потребитель
самостоятельно определяет и изменяет вычислительные потребности, такие как серверное время, скорости доступа и обработки данных, объём хранимых данных без взаимодействия с провайдером
услуг.
– Универсальный доступ по сети. Требование подразумевает, что
все предоставляемые услуги должны быть доступны потребителям
по сети передачи данных вне зависимости от используемого ими
терминального устройства.
– Объединение ресурсов (английский термин: resource pooling).
При этом провайдер (поставщик услуг) имеет возможность при обслуживании большого числа потребителей объединять имеющиеся
ресурсы в единый пул для динамического перераспределения мощностей между потребителями в условиях постоянного изменения
спроса на мощности.
– Эластичность. Данное требование означает, что услуги могут
быть предоставлены, расширены, сужены в любой момент времени,
без дополнительных издержек на взаимодействие с провайдером,
как правило, в автоматическом режиме.
– Учёт потребления. Провайдер (поставщик услуг) автоматически исчисляет потреблённые ресурсы на определённом уровне
абстракции (например, объём хранимых данных, пропускная способность, количество пользователей, количество транзакций), и на
основе этих данных оценивает объём предоставленных потребителям услуг.
Следует обратить внимание, что предъявляемые требования регламентируют более организационно-экономические, чем технические и технологические аспекты предоставления услуг в рамках
облачных вычислений. При этом выполнение всех указанных требований имеет положительные моменты как для провайдеров (поставщиков облачных услуг), так и для их потребителей.
С точки зрения поставщика, благодаря объединению ресурсов
и непостоянному характеру потребления со стороны потребителей,
облачные вычисления позволяют экономить на масштабах, используя меньшие аппаратные ресурсы, чем требовались бы при жестко
выделенных аппаратных мощностях для каждого потребителя. А за
счёт автоматизации процедур модификации выделения ресурсов,
существенно снижаются затраты на абонентское обслуживание.
116
С точки зрения потребителя эти характеристики позволяют получить услуги с высоким уровнем доступности (английский термин: high availability) и низкими рисками потери работоспособности, обеспечить быстрое масштабирование вычислительной системы благодаря эластичности без необходимости создания, обслуживания и модернизации собственной аппаратной инфраструктуры.
Удобство и универсальность доступа обеспечивается широкой
доступностью услуг и поддержкой различного класса терминальных устройств (персональных компьютеров, мобильных телефонов,
планшетов и др.).
Далеко не всегда и не все провайдеры, заявляющие о предоставлении потребителям услуг посредством организации облачных вычислений, соответствуют всем вышеуказанным требованиям. Кроме того, возможность их полноценного выполнения существенно
зависит от используемого способа организации облачных вычислений. Тем не менее, нельзя не отметить, что в большинстве случаев
провайдеры (поставщики облачных услуг) так или иначе стремятся
достичь полного удовлетворения заявленных требований.
С точки зрения способа организации облачных вычислений самым простейшим решением стало предоставление потребителям
возможности использовать вычислительные ресурсы провайдера.
Собственно говоря, в простейшем варианте такой способ организации облачных вычислений не требовал никаких дополнительных
технологических решений и мог сводиться к элементарной аренде
вычислительных мощностей с предоставлением сетевого доступа к
арендуемой вычислительной системе.
С появлением этого способа предоставления вычислительных ресурсов в свое время появился и первый «модный» термин «HaaS» –
«Hardware as a Service», что в буквальном переводе на русский обозначает «аппаратные средства как услуга».
Однако по мере развития информационных технологий стало понятно, что предоставлять потребителям реальные (физические) вычислительные мощности (или какую-то их часть) не удобно и не эффективно. Отказу от использования технологий прямой аренды вычислительных мощностей способствовало развитие возможностей
современных ОС, которые стали массово поддерживать технологии
виртуализации вычислительных ресурсов – в первую очередь, процессорного времени, оперативной памяти и дискового пространства.
С появлением таких средств в составе большинства современных ОС
в распоряжении провайдеров потребитель мог получать в пользование (в аренду) уже не выделенные ему явно вычислительные ресур117
сы провайдера в виде реальных физических устройств, а виртуальную вычислительную среду («виртуальную машину») с заданными
техническими характеристиками. Эти возможные технические
характеристики уже не имели жестких ограничений, связанных с
наличием тех или иных физических устройств, а могли быть практически любыми в рамках имеющихся в распоряжении провайдера
вычислительных мощностей. При этом провайдеры получили возможность динамически перераспределять имеющиеся в их распоряжении вычислительные мощности по мере необходимости и поступления запросов от потребителей в полном соответствии с требованиями эластичности и объединения ресурсов облачных вычислений.
Возможно, по причине ухода от физической аренды вычислительных мощностей в сторону виртуализации предоставляемых
ресурсов, а возможно, по иным причинам (совпадение с наименованием одной американской компании) термин «HaaS» практически
исчез с IT-рынка.
Ему на смену пришел другой, аналогичный по смыслу термин
«IaaS» – «Infrastructure as a Service», «инфраструктура как услуга».
При полномасштабной реализации этого способа организации облачных вычислений потребителю предоставляется возможность использования выделенной облачной инфраструктуры для самостоятельного управления ресурсами обработки, хранения, сетями и другими
доступными фундаментальными вычислительными ресурсами. При
этом, объем доступных ресурсов, либо изначально определяется по
соглашению с провайдером (и тогда потребитель может использовать
по своему усмотрению любые ресурсы в пределах выделенного объема
за фиксированную стоимость), либо выбирается самим потребителем
из общего объема доступных со стороны провайдера ресурсов (и тогда
стоимость использования зависит от объема реально затребованных
потребителем ресурсов). В первом случае не обеспечивается полная
эластичность облачных вычислений, так как изменение объема доступных ресурсов требует обращения к провайдеру. Могут также использоваться различные сочетания этих двух основных вариантов организации доступа к вычислительным ресурсам по модели IaaS.
При использовании данного способа организации облачных вычислений потребитель может устанавливать и запускать произвольное программное обеспечение, которое может включать в себя ОС,
а также любое системное и прикладное программное обеспечение.
Потребитель может контролировать операционные системы, виртуальные системы хранения данных и установленные приложения, а
также обладать ограниченным контролем над набором доступных
118
сетевых сервисов. Контроль и управление основной физической и
виртуальной инфраструктурой облака, в том числе сети, серверов,
типов используемых операционных систем, систем хранения в данном случае осуществляется провайдером облачных вычислений.
5.3. Технологии «PaaS» и «DaaS»
Следующий более совершенный с технологической точки зрения
способ организации облачных вычислений подразумевает предоставление в пользование потребителям не только вычислительных
мощностей, но и некоторого программного обеспечения. В этом случае потребитель получает от провайдера не просто вычислительные
ресурсы, но и установленное на них системное программное обеспечение, в первую очередь – операционную систему (ОС).
Со временем на рынке IT-услуг появился и соответствующий термин «PaaS» – «Platform as a Service», «платформа как услуга».
Platform as a Service (PaaS) – это модель предоставления облачных вычислений, при которой потребитель получает доступ к использованию информационно-технологических платформ, в рамках которых ему предоставляется возможность использования облачной инфраструктуры с размещением на ней базового программного обеспечения для последующего размещения на нём новых или
существующих приложений (собственных, разработанных на заказ
или приобретённых тиражируемых приложений). В простейшем
случае в понятие «платформа» входит главный образующий фактор
информационно-вычислительной среды – операционная система, на
основе которой потребитель может разворачивать любое программное обеспечение. В более сложных вариантах в состав информационно-технологических платформ кроме ОС могут входить инструментальные средства создания, тестирования и выполнения прикладного программного обеспечения, в том числе системы управления базами данных (СУБД), связующее программное обеспечение,
среды исполнения языков программирования. При таком способе
организации облачных вычислений все упомянутые программные
средства предоставляются провайдером облачных вычислений.
В модели PaaS вся информационно-технологическая инфраструктура, включая вычислительные сети, серверы, системы хранения, целиком управляется провайдером, провайдером же определяется набор доступных для потребителей видов платформ и набор
управляемых параметров платформ. Потребителю предоставляется
119
возможность использовать платформы, создавать их виртуальные
экземпляры, устанавливать, разрабатывать, тестировать, эксплуатировать на них прикладное программное обеспечение, при этом
динамически изменяя количество потребляемых вычислительных
ресурсов.
Контроль и управление основной физической и виртуальной инфраструктурой облака, в том числе сети, серверов, операционных
систем, хранения осуществляется провайдером облачных вычислений, за исключением разработанных или установленных приложений, а также, по возможности, некоторых параметров конфигурации среды (платформы).
Провайдер облачной платформы может взимать плату с потребителей в зависимости от уровня потребления, тарификация возможна по времени работы приложений потребителя, по объёму обрабатываемых данных и количеству транзакций над ними, по сетевому
трафику. Провайдеры облачных платформ достигают экономического эффекта за счёт использования виртуализации и экономии на
масштабах, когда из множества потребителей в одно и то же время
лишь часть из них активно использует вычислительные ресурсы.
Потребители получают экономический эффект за счёт отказа от
капитальных вложений в инфраструктуру и платформы, рассчитанных под пиковую мощность, и непрофильных затрат на непосредственное обслуживание всего комплекса (включая системное
администрирование). Однако затраты на управление прикладными
программами в модели PaaS остаются за потребителями.
При использовании модели PaaS уже нельзя не упомянуть о возможных технических и технологических ограничениях, связанных
с используемым программным обеспечением. Все современные операционные системы, безусловно, подразумевают возможность использования сетевого доступа и удаленной работы. Поэтому в простейшей ситуации в модели PaaS, когда программное обеспечение,
предоставляемое провайдером облачных вычислений, включает в
состав информационно-технологической платформы только ОС, не
должно возникать никаких дополнительных технических сложностей. То же самое относится к ситуации, когда в состав предоставляемой информационно-технологической платформы в дополнение
к ОС включается СУБД. Однако проблемы и технические ограничения могут возникнуть, если по модели PaaS потребителям предоставляются инструменты разработки или их компоненты. В этом
случае возможны два варианта: либо соответствующая среда разработки должна быть изначально построена с ориентацией на воз120
можность использования многоуровневых технологий организации
распределенных вычислений (что в настоящее время совсем не редкость), либо провайдер должен грамотно организовать распределенный доступ к этой среде (например, на основе средств терминального сервера), что не всегда технически осуществимо.
Поскольку кроме ОС именно СУБД стали одним из самых распространенных средств, предоставляемых провайдерами облачных
вычислений в составе информационно-технологических платформ
по модели PaaS, на рынке IT-услуг сложился и широко использовался (а где-то и продолжает использоваться) термин «DaaS». Данный термин в равной степени может расшифровываться как «Data
as a Service» или «Database as a Service» («данные как услуга» или
«база данных как услуга»). Обе предлагаемые расшифровки имеют
схожее по смыслу значение и подразумевают тот факт, что провайдер облачных вычислений предоставляет в составе информационнотехнологической платформы СУБД. Но в первом толковании («Data
as a Service») зачастую подразумевается, что кроме непосредственно
СУБД предоставляется и некоторое ее обслуживание и/или наполнение, в то время, как второй вариант расшифровки («Database as a
Service») чаще подразумевает предоставление провайдером только
непосредственно СУБД и доступа к ней, а наполнение и обслуживание БД остается за потребителем.
В настоящее время к существующим расшифровкам термина «DaaS» добавилась еще одна – «Desktop as a Service» («Рабочее
место как услуга»), что только добавляет путаницу в «облачную»
терминологию. Эта расшифровка термина «DaaS» относится уже к
другому способу организации облачных вычислений, который рассмотрен далее, и сточки зрения авторов, является совершенно неудачной.
Появление методов организации облачных вычислений PaaS и
DaaS на рынке вычислительных ресурсов и услуг оказалось почти
что «возвратом в прошлое» во времена доминирования на вычислительном рынке мощных ЭВМ «Mainframe». Изначально вся компьютерная индустрия использовала именно арендную бизнес-модель, поскольку мощные компьютеры стоили огромных денег. Поэтому и ранее вычислительные мощности и установленные на них
информационно-технологические платформы сдавались в аренду
заказчикам. Однако такую аренду нельзя считать разновидностью
организации облачных вычислений, поскольку в то время заказчики (потребители вычислительных услуг) получали доступ к компьютерам напрямую, а не через глобальные сети.
121
5.4. Технология «SaaS»
Рассмотренные выше модели организации облачных вычислений (IaaS, PaaS, DaaS) хотя по-прежнему доступны и представлены
на рынке вычислительных ресурсов и услуг, но не являются в настоящее время на нем доминирующими. Самой полномасштабной и
технологически совершенной моделью, которая, по сути, и определяет в настоящее время всю суть термина «облачные вычисления»,
является модель организации облачных вычислений, обозначаемая
термином «SaaS».
Термин «SaaS» – «Software as a Service», «программное обеспечение как услуга» – это форма организации облачных вычислений,
модель обслуживания, при которой потребителям предоставляется
готовое прикладное программное обеспечение, полностью обслуживаемое провайдером (поставщиком облачных вычислений). Для
обозначения этой же схемы организации облачных вычислений
также используется английский термин «Software on Demand»,
«программное обеспечение по требованию» (или «по запросу»). Поставщик в этой модели самостоятельно управляет приложением,
предоставляя потребителям доступ к его функциям с различных
клиентских устройств. Причем в настоящее время большое количество приложений позволяет использовать разнообразные типы
клиентских устройств – не только компьютеры, но и различные мобильные устройства.
Основное преимущество модели SaaS для потребителя услуги состоит в полном отсутствии затрат, связанных с установкой, обновлением и поддержкой работоспособности оборудования и работающего на нём программного обеспечения.
Организация облачных вычислений на основе модели SaaS предполагает следующие основные условия:
– приложение, предоставляемое потребителям, должно быть
приспособлено для удаленного использования;
– одним приложением пользуется несколько потребителей;
– оплата взимается либо в виде ежемесячной абонентской платы,
либо на основе объёма операций;
– техническая поддержка приложения включена в оплату;
– модернизация и обновление приложения происходит оперативно и прозрачно для потребителей.
Как и во всех других формах организации облачных вычислений, потребители в модели SaaS платят не за владение программным обеспечением как таковым, а за его аренду (то есть за его ис122
пользование). Таким образом, в отличие от классической схемы
лицензирования программного обеспечения, заказчик несет сравнительно небольшие периодические затраты, и ему не требуется
инвестировать значительные средства в приобретение прикладной
программы и всех необходимых программно-платформенных и аппаратных средств для ее развёртывания, а затем постоянно поддерживать работоспособность приобретенного программного обеспечения и всей необходимой инфраструктуры. Схема периодической
оплаты предполагает, что если необходимость в программном обеспечении временно отсутствует, то потребитель может приостановить его использование и заморозить выплаты провайдеру (поставщику облачных услуг).
С точки зрения разработчика программного обеспечения модель SaaS позволяет эффективно бороться с его нелицензионным
использованием, поскольку программное обеспечение как таковое
не попадает к конечным заказчикам. Кроме того, концепция SaaS
часто позволяет уменьшить затраты на развёртывание и внедрение
систем технической и консультационной поддержки продукта, хотя
и не исключает их полностью.
Поскольку модель SaaS более, чем другие способы организации
облачных вычислений, ориентирована на предоставление услуг посредством сети, её появление и развитие непосредственно связано с
развитием глобальных сетей и доступностью технологий организации распределенных вычислений. Очевидно, что без возникновения
технических проблем использовать в соответствии с моделью SaaS
возможно только такие приложения, которые рассчитаны на организацию распределенных вычислений в глобальных сетях.
При этом можно сопоставить технологии распределенных вычислений, которые были положены в основу при создании приложений, с возможностями использования этих приложений в облачных
вычислениях, организованных в соответствии с моделью SaaS:
– Если приложение ориентировано на распределенные вычисления в глобальных сетях и использует в качестве клиентской части Web-интерфейс, его использование в облачных вычислениях
по модели SaaS не должно создавать технических проблем. В качестве клиентской части такого приложения выступает программа
навигации по сети (браузер), которая доступна всем потребителям
облачных вычислений на различных типах клиентских устройств.
Возможны некоторые технические проблемы, связанные с использованием разных типов браузеров, которые, как правило, не являются неразрешимыми. Иногда такие приложения предусматрива123
ют использование специализированных программных модулей (мобильных приложений) для мобильных устройств с ограниченными
ресурсами, где возможности браузеров ограничены. В основе взаимодействия мобильных приложений с серверными частями чаще
всего используются технологии Web-служб.
– Если приложение построено на основе многоуровневой (трехуровневой) технологии организации распределенных вычислений,
оно, как правило, также может быть использовано в облачных вычислениях по модели SaaS без серьезных технических проблем.
Если клиентские части приложения используют Web-службы для
взаимодействия с серверными частями (либо могут быть легко перестроены на основе использования подобных технологий), то подключение потребителей к облачным вычислениям в таком варианте будет сводиться к установке клиентского модуля на рабочие места потребителя. При этом, чем более широкий выбор клиентских модулей
для различных программно-аппаратных платформ (включая мобильные платформы) предложит разработчик, тем шире будет круг
возможных потребителей приложения. В случае использования для
взаимодействия с серверными частями иных технологий, не рассчитанных на глобальные сети (таких, как COM/DCOM или CORBA), могут возникнуть сложности с передачей бинарных данных по общедоступным сетям. В этом случае кроме установки клиентских модулей
на рабочих местах потребителей может потребоваться организация
защищенных виртуальных каналов (VPN – Virtual Private Network)
между потребителями и провайдером через общедоступную сеть,
что, конечно же, осложнит процесс взаимодействия поставщика облачных вычислений с их потребителями по модели SaaS.
– Если приложение построено на основе двухуровневой технологии («клиент-сервер»), либо в принципе не предусматривает использование распределенных вычислений, его использование в облачных вычислениях по модели SaaS может вызвать определенные
технические сложности. В случае выделения в технологии «клиентсервер» на сторону провайдера облачных вычислений только сервера
данных, безусловно, потребуется установка клиентской части приложения у всех потребителей, но в отличие от многоуровневой технологии, в этом случае разработчики едва ли смогут предоставить
достаточно разнообразный выбор клиентских модулей для различных программно-аппаратных платформ, а использование мобильных устройств с ограниченными ресурсами станет просто технически невозможным. Кроме того, в этом случае могут возникнуть уже
описанные выше сложности, связанные с передачей данных через
124
общедоступную сеть, а производительности глобальной сети может
оказаться недостаточно для полноценного обмена клиентской части
с сервером данных. В принципе, такая схема больше подходит под
модель DaaS, чем SaaS. Ситуацию может упростить использование
на стороне провайдера сервера данных в сочетании с терминальным
сервером, на котором развернута клиентская часть приложения (как
на рис. 5 в п. 3.3), а для приложения, не предусматривающего использование распределенных вычислений, применение терминального доступа является просто единственным выходом. Однако протокол терминального доступа (RDP) предъявляет более высокие требования к пропускной способности сети и расходует больше сетевого
трафика, чем традиционные протоколы Web-интерфейса. Кроме
того, он доступен для существенно более узкого перечня устройств
и налагает гораздо больше различных технических ограничений
(хотя в большинстве случаев их всё-таки удается решить).
Сейчас кроме термина «SaaS» применительно к организации
облачных вычислений иногда применяется уже упомянутая выше
расшифровка термина «DaaS» – «Desktop as a Service» («Рабочее место как услуга»), которая является логическим продолжением идей
SaaS. При предоставлении облачных вычислений по модели DaaS
(в той расшифровке, что дана здесь) клиенты получают полностью
готовое к работе («под ключ») стандартизированное виртуальное
рабочее место, которое каждый пользователь имеет возможность
дополнительно настраивать под свои задачи. Таким образом, пользователь получает доступ не к отдельной программе, а к необходимому для полноценной работы программному комплексу. Однако
с точки зрения авторов термин «DaaS» нельзя признать удачным,
поскольку, с одной стороны, он не предполагает каких-то принципиальных отличий от уже рассмотренной здесь модели SaaS, а,
с другой стороны, создает путаницу, так как пересекается с ранее
использованными аналогичными сокращениями «DaaS», которые
имеют принципиально иное значение (оно было описано ранее). Далее термин «DaaS» в таком контексте более упоминаться не будет.
Программное обеспечение «по требованию» предоставляется
заказчику в аренду и всегда предполагает периодическую оплату.
В качестве единицы тарификации обычно используются количество
пользователей или же число записей в базе данных, реже – какието другие функциональные характеристики (например, количество
определённых операций или трафик). В некоторых случаях заказчикам предлагаются комбинированные модели, в рамках которых
могут дополнительно оплачиваться расширенные функции (напри125
мер, заказчик может платить за пользователей своих сервисов и за
расширенное хранилище данных).
Контракт на аренду SaaS включает в себя не только оплату за
использование ПО, но и оплату всех затрат, связанных с поддержкой его работоспособности, обновлением и защитой данных. Многие провайдеры облачных вычислений по модели SaaS предлагают
продвинутый вариант контракта на аренду – SLA (Service Level
Agreement). В таких контрактах фиксируются параметры, связанные с работоспособностью ПО, предоставляемого провайдером.
Обычно это гарантии доступности ПО в процентах в течение года.
Лучшие центры обработки данных способны гарантировать доступность ПО не менее 99,5 % времени за год.
В том случае, если программное обеспечение не требует первоначальной адаптации под потребности заказчика, первоначальный
платёж за его использование может отсутствовать вовсе. Данное
обстоятельство является важнейшим преимуществом модели SaaS
над классическим лицензированием программного обеспечения,
которое также (при условии платной лицензии) требует существенных начальных инвестиций на его закупку. Периодические арендные платежи можно сравнить со стоимостью технической поддержки – обычно они жёстко прописываются в договоре и потому являются предсказуемыми. Тем самым обеспечивается защита инвестиций заказчика в используемый программный продукт.
Именно работа всех потребителей с единым программным ядром
и его централизованное обслуживание провайдером облачных вычислений по модели SaaS обеспечивает основные положительные
свойства этой модели организации облачных вычислений. Ключевым фактором, объясняющим экономическую целесообразность
модели SaaS, является «эффект масштаба» – провайдер облачных
вычислений по модели SaaS обслуживает единое программное ядро,
которым пользуются все клиенты, и потому тратит меньшее количество ресурсов в сравнении с управлением отдельными копиями
программного обеспечения для каждого заказчика. Кроме того,
использование единого программного ядра позволяет планировать
вычислительные мощности и уменьшает пиковые нагрузки для отдельных заказчиков. Все это позволяет провайдерам облачных вычислений на основе данной модели существенно снизить стоимость
эксплуатации ПО. В результате стоимость услуг для конечного
пользователя такого ПО, становится ниже издержек, возникающих
при использовании классической модели лицензирования (особенно если лицензирование платное).
126
Другим ключевым фактором является уровень обслуживания
приложений, использующих облачные вычисления по модели SaaS.
Провайдер облачных вычислений способен предложить уровень обслуживания и поддержки ПО в работоспособном состоянии, недоступный для внутренних IT-отделов компаний. Это особенно ярко
проявляется в случае работы с провайдером облачных вычислений
по модели SaaS на основе контракта типа SLA.
5.5. Преимущества и недостатки
облачных вычислений
Основные возможности всех рассмотренных выше основных моделей организации облачных вычислений сведены в общую таблицу.
Знак «+» в таблице 1 обозначает обязательное предоставление
указанного вычислительного ресурса по данной модели, знак «–»
означает, что указанный ресурс по данной модели не предоставляется, а знак «?» предполагает, что предоставление ресурса по условиям данной модели возможно, но не является обязательным.
Следует заметить, что в настоящее время именно модель предоставления облачных вычислений SaaS является той основой, на
базе которой можно оценивать основные преимущества и недостатки организации облачных вычислений. Можно выделить несколько
главных факторов, стимулирующих использование программного
обеспечения по схеме организации облачных вычислений заказчиками и развитие приложений, ориентированных на такую схему
Таблица 1
Предоставление различных ресурсов
в разных моделях организации облачных вычислений
Аппаратные средства (с учетом виртуализации)
Операционные системы
СУБД
Средства разработки и тестирования
Прикладные программы
IaaS
(HaaS)
PaaS
DaaS
SaaS
+
+
+
+
?
–
–
–
+
?
?
–
+
+
?
–
+
+
+
+
127
использования (а значит, и на использование распределенных вычислений) разработчиками.
Положительные организации облачных вычислений по модели
SaaS для заказчиков (потребителей вычислительных услуг):
– не нужна установка клиентских частей приложения на рабочие места пользователей (либо установка сводится к автоматической установке минимальных клиентских программ);
– радикальное сокращение затрат на первоначальное развёртывание системы в организации;
– сокращение затрат на техническую поддержку и обновление
развернутых систем (вплоть до их полного отсутствия);
– скорость внедрения, обусловленная отсутствием затрат времени на развертывание системы;
– ясность и предсказуемость платежей, защита инвестиций;
– мультиплатформенность – минимальная зависимость (или
полное ее отсутствие) от программно-аппаратной платформы, выбранной разработчиком;
– возможность получить более высокий уровень обслуживания
приложений.
Положительные факторы облачных вычислений по модели SaaS
для разработчиков:
– ускоренный процесс внедрения приложения и сравнительно
низкие затраты ресурсов на обслуживание конкретного клиента;
– облегчение проникновения на глобальные рынки;
– отсутствие проблем с нелицензионным использованием и распространением приложений;
– клиент сильнее привязан к разработчику (в отличие от классической схемы лицензирования), он не может отказаться от услуг
разработчика и при этом продолжить использовать приложение
(таким образом, обеспечивается защита инвестиций разработчика
в процесс продаж);
– в долгосрочном периоде доходы от SaaS могут превысить доходы от продаж лицензий и оказания технической поддержки;
– разработчик выбирает рабочую программно-аппаратную платформу из соображений её технико-экономической эффективности,
а не из соображений её распространенности у возможных пользователей приложения.
Также существуют немаловажные технологические аспекты,
положительным образом влияющие на развитие и распространение облачных вычислений. Это связано с постоянным развитием и
широким распространением технологий разработки приложений,
128
использующих распределенные вычисления в глобальных сетях,
поддержка этих технологий широким набором доступных систем
программирования и простота их реализации.
Надо отметить, что наряду с положительным влиянием, которое
оказывает развитие облачных технологий на рынок вычислительных ресурсов и IT-услуг, присутствуют и некоторые отрицательные
факторы. Так некоторые производители программных продуктов,
увлекшись модными идеями облачных вычислений, иногда совершенно неоправданно отказываются от традиционной модели лицензирования приложений, явно вынуждая потребителей применять
облачные вычисления без учета того, выгодно им это или нет. Еще
более странным является применение принципов лицензирования
приложений, используемых по схемам облачных вычислений, для
приложений, распространяемых вполне традиционными средствами без использования каких-либо технологий организации распределенных вычислений. Однако, как надеются авторы, соответствующая реакция потребителей рано или поздно заставит производителей подобных продуктов одуматься или просто вытеснит их с рынка.
Наряду с факторами, которые побуждают потребителей внедрять и использовать программное обеспечение на основе облачных
вычислений, а разработчиков – развивать соответствующие технологии и инвестировать ресурсы в создание приложений, ориентированных на облачные вычисления, существует ряд сдерживающих
факторов, ограничивающих использование данной модели.
Во-первых, концепция организации облачных вычислений по
модели SaaS применима далеко не для всех функциональных классов систем. Поскольку основная экономия ресурсов провайдера в
модели SaaS достигается за счёт масштаба, такие модели неэффективны для систем, требующих глубокой индивидуальной настройки (адаптации под каждого заказчика), а также для узкоспециализированных решений.
Во-вторых, многие заказчики опасаются применять модель SaaS
из-за соображений безопасности и возможной утечки информации
со стороны поставщика SaaS-услуг. Вопросы, связанные с безопасностью, ограничивают использование SaaS-модели в критически
важных системах, в которых обрабатывается конфиденциальная
информация. В том числе существуют различные законодательные
ограничения, ограничивающие применение данной модели, так
как провайдеры облачных вычислений и их потребители могут физически находиться на территориях различных государств. С другой стороны, ответственность за утечку информации со стороны
129
разработчика обычно регламентируется соответствующими договорами, и вероятность такой утечки часто ниже, чем при использовании собственных внутренних систем. В том числе этому способствует недоступность программно-аппаратного комплекса, на котором
развёрнута система, сотрудникам компании.
Третий существенный фактор, ограничивающий распространение облачных вычислений – необходимость наличия постоянно
действующего подключения к Интернету. Некоторые приложения,
ориентированные на использование по схеме облачных вычислений
в модели SaaS, пытаются компенсировать это ограничение наличием модулей для автономной работы.
Контрольные вопросы
1. Какие особенности глобальных вычислительных сетей оказывают определяющее влияние на организацию распределенных вычислений в таких сетях?
2. Какие принципиальные особенности присущи облачным вычислениям?
3. Какие формальные требования предъявляются к облачным
вычислениям?
4. Какие преимущества предоставляют облачные вычисления
потребителям услуг?
5. Какие преимущества предоставляют облачные вычисления
поставщикам услуг?
6. На основе каких принципов построена модель организации облачных вычислений «IaaS» (Infrastructure as a Service)?
7. Какие преимущества потребителю услуг дает аренда виртуальных вычислительных ресурсов по сравнению с арендой физических вычислительных мощностей?
8. Почему поставщику услуг выгоднее предоставлять потребителям именно виртуальные вычислительные ресурсы?
9. На основе каких принципов построена модель организации
облачных вычислений «PaaS» (Platform as a Service)? В чем ее отличие от модели «IaaS»?
10. Какие возможные термины обозначает сокращение «DaaS»?
В чем различие между этими терминами и связанными с ними моделями организации облачных вычислений?
11. На основе каких принципов построена модель организации
облачных вычислений «SaaS» (Software as a Service)? В чем ее отличие от моделей «IaaS» и «PaaS»?
130
12. Какие преимущества разработчикам приложений дает использование модели организации облачных вычислений «SaaS»?
13. Объясните, почему именно модель организации облачных
вычислений «SaaS» чаще всего используется для оценки преимуществ и недостатков организации облачных вычислений?
14. Каким критериям должно соответствовать приложение для
использования модели организации облачных вычислений «SaaS»?
15. Сопоставьте возможности различных технологий организации распределенных вычислений с их применением в модели организации облачных вычислений «SaaS».
16. Какие основные проблемы связаны с организацией облачных
вычислений?
131
ЗАКЛЮЧЕНИЕ
Несомненно, облачные вычисления являются сейчас тем элементом из сферы «IT-технологий», который постоянно находится
«на слуху» и часто появляется в новостных сообщениях, а также
обсуждается на различных конференциях и семинарах, организуемых теми или иными компаниями. Термин «облачные вычисления» («Cloud computing»), да и просто слово «облако» («cloud»)
играют заметную роль в маркетинговых кампаниях, как ведущих
мировых разработчиков, так и мелких производителей программных продуктов, способствуя продвижению их разработок на рынок
информационных технологий. Эти термины постоянно появляются
даже в средствах массовой информации, далеких от IT-индустрии.
Тем важнее понимать, что из себя представляют эти новомодные
и хорошо разрекламированные понятия, чтобы иметь возможность
отличать «зерна от плевел», а многословную бесполезную «шелуху»
от реальных технологических новшеств и достижений.
Авторы надеются, что данное учебное пособие даст его читателям
некоторое представление о том, что скрывают под собой громкие
слова о новых достижениях и какие реальные технологии лежат в
основе различных терминов и аббревиатур, связанных с разошедшимся в массы понятием «облачные вычисления». Надо отметить,
что кроме технологических вопросов, есть много не менее важных
экономических и организационно-технических аспектов, которые
тоже следует учитывать, говоря о новшествах в этой области информационных технологий.
Рынок информационных технологий не стоит на месте, и любые
появляющиеся на нем новшества и нововведения требуют дальнейшего продвижения. Наверняка в перспективе мы еще услышим от
ведущих игроков этого рынка много новых терминов, как связанных с реальными технологическими прорывами, так и с достижениями маркетологов.
132
БИБЛИОГРАФИЧЕСКИЙ СПИСОК
1. Ахо А., Лам М., Сети Р., Ульман Дж. Компиляторы: принципы, технологии и инструментарий, 2-е изд.: пер. с англ. – М.: Издательский дом «Вильямс», 2008. – 1184 с.
2. Головин И. Г. Языки и методы программирования / И. Г. Головин, И. А. Волкова. – М.: Издательский центр «Академия», 2012. –
304 с.
3. Гордеев А. В. Операционные системы: учебник для вузов. –
СПб.: Питер, 2004. – 416 с.
4. Карпов Ю. Г. Теория и технология программирования. Основы
построения трансляторов. – СПб.: БХВ-Петербург, 2012. – 272 с.
5. Карпова И. П. Базы данных: учеб. пособие. – СПб.: Питер,
2016. – 240 с.
6. Кучин Н. В. Основы организации мультипрограммных вычислительных систем: учеб. пособие / Н. В. Кучин, А. Ю. Молчанов. –
СПб.: ГУАП, 2017. – 103 с.
7. Молчанов А. Ю. Системное программное обеспечение: лабор.
практикум. – СПб.: ГУАП, 2014. – 131 с.
8. Молчанов А. Ю. Системное программное обеспечение: учебник
для вузов. 3-е изд. – СПб.: Питер, 2010. – 400 с.
9. Олифер В. Г., Олифер Н. А. Сетевые операционные системы:
учебник для вузов. – СПб.: Питер, 2008. – 672 с.
10. Орлов С. А. Теория и практика языков программирования:
учебник для вузов. 2-е изд. – СПб.: Питер, 2017. – 688 с.
11. Робин Хантер. Основные концепции компиляторов. – М.: Издательский дом «Вильямс», 2002. – 256 с.
12. Свердлов С. З. Языки программирования и методы трансляции: учеб. пособие. – СПб.: Питер, 2007. – 400 с.
13. Таненбаум Э. С., Уэзеролл Д. Компьютерные сети. 5-е изд. –
СПб.: Питер, 2017. – 960 с.
14. Таненбаум Э. С., Бос Х. Современные операционные системы.
4-е изд. – СПб.: Питер, 2018. – 1120 с.
133
СОДЕРЖАНИЕ
Введение.................................................................................... 3
1. Организация распределенных вычислений.................................. 5
1.1. Предпосылки появления облачных вычислений................... 5
1.2. Понятие о распределенных вычислениях............................. 7
1.3. Принципы организации распределенных вычислений........... 9
Контрольные вопросы.................................................................. 12
2. Простейшие методы организации распределенных вычислений..... 2.1. Какие методы обозначены как «простейшие»....................... 2.2. Технология «файл-сервер»................................................ 2.3. Графические серверы........................................................ 2.4. Терминальные серверы..................................................... Контрольные вопросы.................................................................. 13
13
14
18
21
25
3. Организация распределенных вычислений в локальных сетях....... 3.1. Принципы организации распределенных вычислений в ЛВС.. 3.2. Технология «клиент-сервер».............................................. 3.2.1. Взаимодействие с сервером данных.............................. 3.2.2. Технологии доступа к серверу данных.......................... 3.2.3. Поддержка технологии «клиент-сервер» в системах
программирования............................................................. 3.2.4. Дополнительные возможности серверов данных............ 3.3. Трехуровневые и многоуровневые технологии...................... 3.3.1. Расширенные возможности технологии «клиент-сервер»
3.3.2. Понятие о трехуровневой и многоуровневой
архитектурах приложений.................................................. 3.3.3. Особенности разработки приложений
для многоуровневой архитектуры........................................ 3.3.4. Сервера приложений. Методы доступа к серверам
приложений...................................................................... 3.3.5. Технология RPC (Remote Procedure Call)...................... 3.3.6. Модель и технологии COM/DCOM................................ 3.3.7. Модель и семейство стандартов CORBA........................ 3.3.8. Язык IDL. Интерфейсы и библиотеки классов............... 3.3.9. Возможности трехуровневой и многоуровневой
архитектуры..................................................................... Контрольные вопросы.................................................................. 26
26
28
37
43
4. Организация распределенных вычислений в глобальных сетях...... 4.1. Принципы организации распределенных вычислений
в глобальных сетях................................................................. 4.2. Простейшие статические Web-страницы.............................. 4.3. Динамические Web-страницы............................................ 4.4. Интерактивные Web-страницы.......................................... 4.5. Сервис-ориентированные архитектуры. Web-службы
(Web-сервисы)....................................................................... 134
48
53
56
56
60
64
66
69
73
77
80
83
85
87
87
89
94
100
106
Контрольные вопросы.................................................................. 5. Организация облачных вычислений........................................... 5.1. Общие принципы облачных вычислений............................. 5.2. Технологии «HaaS» и «IaaS». Виртуализация ресурсов.......... 5.3. Технологии «PaaS» и «DaaS»............................................. 5.4. Технология «SaaS»........................................................... 5.5. Преимущества и недостатки облачных вычислений.............. Контрольные вопросы.................................................................. Заключение............................................................................... Библиографический список.......................................................... 111
113
113
115
119
122
127
130
132
133
135
Учебное издание
Кучин Николай Валентинович
Молчанов Алексей Юрьевич
МНОГОУРОВНЕВЫЕ СИСТЕМЫ
И ОБЛАЧНЫЕ ВЫЧИСЛЕНИЯ
Учебное пособие
Публикуется в авторской редакции.
Компьютерная верстка С. Б. Мацапуры
Сдано в набор 13.02.18. Подписано к печати 06.04.18.
Формат 60×84 1/16. Усл. печ. л. 7,9. Уч.-изд. л. 8,5.
Тираж 50 экз. Заказ № 139.
Редакционно-издательский центр ГУАП
190000, Санкт-Петербург, Б. Морская ул., 67
Документ
Категория
Без категории
Просмотров
1
Размер файла
4 061 Кб
Теги
kuchinmolchanov
1/--страниц
Пожаловаться на содержимое документа