ВУЗ:
Составители:
Рубрика:
18
способами.
• Клиент может получать доступ к любому количеству серверов, но лишь к одному
в одно и то же время (т.е. каждый запрос к базе данных должен быть направлен
только к одному серверу). В такой системе невозможно за один запрос получить
комбинированные данные двух или более серверов. Кроме того, пользователь в
такой системе должен знать, на какой именно машине какая часть данных
содержится.
• Клиент может получать доступ к любому количеству серверов одновременно (т.е.
за один запрос можно получить комбинированные данные двух или более серве-
ров). В этом случае серверы рассматриваются клиентом как один (с логической
точки зрения), и пользователь не обязан знать, на какой именно машине какая
часть данных содержится.
Второй случай - это пример системы, которую обычно называют распределенной
системой баз данных. Тема распределенных баз данных сама по себе весьма обширна.
Подводя ее определение к логическому завершению, отметим следующее: полная
поддержка для распределенных баз данных означает, что отдельное приложение может
"прозрачно" обрабатывать данные, распределенные на множестве различных баз данных,
управление которыми осуществляют разные СУБД, работающие на многочисленных
машинах с различными операционными системами, соединенных вместе
коммуникационными сетями. Здесь понятие "прозрачно" означает, что приложение
выполняет обработку данных с логической точки зрения, как будто управление данными
полностью осуществляется одной СУБД, работающей на отдельной машине. Такая
возможность может показаться невероятно трудной задачей, но весьма желанной с
практической точки зрения. Подробнее распределенные базы данных рассматривается
далее.
Понятно, что в общем случае, чтобы прикладная программа, выполняющаяся на
рабочей станции, могла запросить услугу у некоторого сервера, как минимум требуется
некоторый интерфейсный программный слой, поддерживающий такого рода
взаимодействие (было бы по меньшей мере неестественно требовать, чтобы прикладная
программа напрямую пользовалась примитивами транспортного уровня локальной сети).
Из этого, собственно, и вытекают основные принципы системной архитектуры "клиент-
сервер".
Система разбивается на две части, которые могут выполняться в разных узлах сети, -
клиентскую и серверную части. Прикладная программа или конечный пользователь
взаимодействуют с клиентской частью системы, которая в простейшем случае
обеспечивает просто надсетевой интерфейс. Клиентская часть системы при потребности
обращается по сети к серверной части. Заметим, что в развитых системах сетевое
обращение к серверной части может и не понадобиться, если система может
предугадывать потребности пользователя, и в клиентской части содержатся данные,
способные удовлетворить его следующий запрос.
Интерфейс серверной части определен и фиксирован. Поэтому возможно создание
новых клиентских частей существующей системы (пример интероперабельности на
системном уровне).
Основной проблемой систем, основанных на архитектуре "клиент-сервер", является
то, что в соответствии с концепцией открытых систем от них требуется мобильность в как
можно более широком классе аппаратно-программных решений открытых систем. Даже
если ограничиться UNIX-ориентированными локальными сетями, в разных сетях
применяется разная аппаратура и протоколы связи. Попытки создания систем,
поддерживающих все возможные протоколы, приводит к их перегрузке сетевыми
деталями в ущерб функциональности.
способами.
• Клиент может получать доступ к любому количеству серверов, но лишь к одному
в одно и то же время (т.е. каждый запрос к базе данных должен быть направлен
только к одному серверу). В такой системе невозможно за один запрос получить
комбинированные данные двух или более серверов. Кроме того, пользователь в
такой системе должен знать, на какой именно машине какая часть данных
содержится.
• Клиент может получать доступ к любому количеству серверов одновременно (т.е.
за один запрос можно получить комбинированные данные двух или более серве-
ров). В этом случае серверы рассматриваются клиентом как один (с логической
точки зрения), и пользователь не обязан знать, на какой именно машине какая
часть данных содержится.
Второй случай - это пример системы, которую обычно называют распределенной
системой баз данных. Тема распределенных баз данных сама по себе весьма обширна.
Подводя ее определение к логическому завершению, отметим следующее: полная
поддержка для распределенных баз данных означает, что отдельное приложение может
"прозрачно" обрабатывать данные, распределенные на множестве различных баз данных,
управление которыми осуществляют разные СУБД, работающие на многочисленных
машинах с различными операционными системами, соединенных вместе
коммуникационными сетями. Здесь понятие "прозрачно" означает, что приложение
выполняет обработку данных с логической точки зрения, как будто управление данными
полностью осуществляется одной СУБД, работающей на отдельной машине. Такая
возможность может показаться невероятно трудной задачей, но весьма желанной с
практической точки зрения. Подробнее распределенные базы данных рассматривается
далее.
Понятно, что в общем случае, чтобы прикладная программа, выполняющаяся на
рабочей станции, могла запросить услугу у некоторого сервера, как минимум требуется
некоторый интерфейсный программный слой, поддерживающий такого рода
взаимодействие (было бы по меньшей мере неестественно требовать, чтобы прикладная
программа напрямую пользовалась примитивами транспортного уровня локальной сети).
Из этого, собственно, и вытекают основные принципы системной архитектуры "клиент-
сервер".
Система разбивается на две части, которые могут выполняться в разных узлах сети, -
клиентскую и серверную части. Прикладная программа или конечный пользователь
взаимодействуют с клиентской частью системы, которая в простейшем случае
обеспечивает просто надсетевой интерфейс. Клиентская часть системы при потребности
обращается по сети к серверной части. Заметим, что в развитых системах сетевое
обращение к серверной части может и не понадобиться, если система может
предугадывать потребности пользователя, и в клиентской части содержатся данные,
способные удовлетворить его следующий запрос.
Интерфейс серверной части определен и фиксирован. Поэтому возможно создание
новых клиентских частей существующей системы (пример интероперабельности на
системном уровне).
Основной проблемой систем, основанных на архитектуре "клиент-сервер", является
то, что в соответствии с концепцией открытых систем от них требуется мобильность в как
можно более широком классе аппаратно-программных решений открытых систем. Даже
если ограничиться UNIX-ориентированными локальными сетями, в разных сетях
применяется разная аппаратура и протоколы связи. Попытки создания систем,
поддерживающих все возможные протоколы, приводит к их перегрузке сетевыми
деталями в ущерб функциональности.
18
Страницы
- « первая
- ‹ предыдущая
- …
- 16
- 17
- 18
- 19
- 20
- …
- следующая ›
- последняя »
