Архитектура аппаратно-программных средств




Скачать 299.25 Kb.
НазваниеАрхитектура аппаратно-программных средств
страница1/2
Дата публикации15.03.2013
Размер299.25 Kb.
ТипКурсовая
vbibl.ru > Информатика > Курсовая
  1   2
Архитектура аппаратно-программных средств распределенной обработки информации для интранет-технологии

Архитектура аппаратно-программных средств распределенной обработки

информации для интранет-технологии

МОСКОВСКИЙ ИНСТИТУТ РАДИОТЕХНИКИ, ЭЛЕКТРОНИКИ И

АВТОМАТИКИ (ТУ)

Курсовая работа по предмету

системное программное обеспечение

Тема: Архитектура аппаратно-программных средств

распределенной обработки информации для интранет-

технологии.

Студента группы ВВ-22-95

Головченко В.

Преподаватель Малыгина О.П.

Москва 1998

Содержание

1. Архитектура "клиент-сервер"

1.1. Открытые системы

1.2. Клиенты и серверы локальных сетей

1.3. Системная архитектура "клиент-сервер"

1.4. Серверы баз данных

1.5. Принципы взаимодействия между клиентскими

и серверными частями

1.6. Преимущества протоколов удаленного вызова

процедур

1.7. Типичное разделение функций между клиентами

и серверами

1.8. Архитектуры процессора базы данных

2. Трехуровневая архитектура "клиент-сервер"

3. Программные средства разработки

3.1. Универсальные средства

3.2. Персональные СУБД

4. Intranet и архитектура "клиент-сервер".

4.1. Двухуровневая архитектура "клиент-сервер"

4.2. Трехуровневая архитектура "клиент-сервер"

4.2.1. Программы расширения серверной части

5. Пример базы данных

1. Архитектура "клиент-сервер"

Применительно к системам баз данных архитектура "клиент-

сервер" интересна и актуальна главным образом потому, что

обеспечивает простое и относительно дешевое решение про-

блемы коллективного доступа к базам данных в локальной

сети.

1.1. Открытые системы

Реальное распространение архитектуры "клиент-сервер" ста-

ло возможным благодаря развитию и широкому внедрению в

практику концепции открытых систем. Поэтому мы начнем с

краткого введения в открытые системы.

Основным смыслом подхода открытых систем является упроще-

ние комплексирования вычислительных систем за счет между-

народной и национальной стандартизации аппаратных и про-

граммных интерфейсов. Главной побудительной причиной раз-

вития концепции открытых систем явились повсеместный пе-

реход к использованию локальных компьютерных сетей и те

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

которые вызвал этот переход. В связи с бурным развитием

технологий глобальных коммуникаций открытые системы при-

обретают еще большее значение и масштабность.

Ключевой фразой открытых систем, направленной в сторону

пользователей, является независимость от конкретного по-

ставщика. Ориентируясь на продукцию компаний, придержи-

вающихся стандартов открытых систем, потребитель, который

приобретает любой продукт такой компании, не попадает к

ней в рабство. Он может продолжить наращивание мощности

своей системы путем приобретения продуктов любой другой

компании, соблюдающей стандарты. Причем это касается как

аппаратных, так и программных средств.

Практической опорой системных и прикладных программных

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

ционная система. В настоящее время такой системой являет-

ся UNIX. Фирмам-поставщикам различных вариантов ОС UNIX в

результате длительной работы удалось придти к соглашению

об основных стандартах этой операционной системы. Сейчас

все распространенные версии UNIX в основном совместимы по

части интерфейсов, предоставляемых прикладным (а в боль-

шинстве случаев и системным) программистам. Как кажется,

несмотря на появление претендующей на стандарт системы

Windows NT, именно UNIX останется основой открытых систем

в ближайшие годы.

Технологии и стандарты открытых систем обеспечивают ре-

альную и проверенную практикой возможность производства

системных и прикладных программных средств со свойствами

мобильности (portability) и интероперабельности

(interoperability). Свойство мобильности означает сравни-

тельную простоту переноса программной системы в широком

спектре аппаратно-программных средств, соответствующих

стандартам. Интероперабельность означает упрощения ком-

плексирования новых программных систем на основе исполь-

зования готовых компонентов со стандартными интерфейсами.

Преимуществом для пользователей является то, что они мо-

гут постепенно заменять компоненты системы на более со-

вершенные, не утрачивая работоспособности системы. В ча-

стности, в этом кроется решение проблемы постепенного на-

ращивания вычислительных, информационных и других мощно-

стей компьютерной системы.

1.2. Клиенты и серверы локальных сетей

В основе широкого распространения локальных сетей компью-

теров лежит известная идея разделения ресурсов. Высокая

пропускная способность локальных сетей обеспечивает эф-

фективный доступ из одного узла локальной сети к ресур-

сам, находящимся в других узлах.

Развитие этой идеи приводит к функциональному выделению

компонентов сети: разумно иметь не только доступ к ресур-

сами удаленного компьютера, но также получать от этого

компьютера некоторый сервис, который специфичен для ре-

сурсов данного рода и программные средства. Так мы прихо-

дим к различению рабочих станций и серверов локальной се-

ти.

Рабочая станция предназначена для непосредственной работы

пользователя или категории пользователей и обладает ре-

сурсами, соответствующими локальным потребностям данного

пользователя.

Сервер локальной сети должен обладать ресурсами, соответ-

ствующими его функциональному назначению и потребностям

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

тых систем, правильнее говорить о логических серверах

(имея в виду набор ресурсов и программных средств, обес-

печивающих услуги над этими ресурсами), которые распола-

гаются не обязательно на разных компьютерах. Особенностью

логического сервера в открытой системе является то, что

если по соображениям эффективности сервер целесообразно

переместить на отдельный компьютер, то это можно проде-

лать без потребности в какой-либо переделке как его само-

го, так и использующих его прикладных программ.

Примерами сервером могут служить:

•сервер телекоммуникаций, обеспечивающий услуги по связи

данной локальной сети с внешним миром;

•вычислительный сервер, дающий возможность производить

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

циях;

•дисковый сервер, обладающий расширенными ресурсами внеш-

ней памяти и предоставляющий их в использование рабочим

станциями и, возможно, другим серверам;

•файловый сервер, поддерживающий общее хранилище файлов

для всех рабочих станций;

•сервер баз данных фактически обычная СУБД, принимающая

запросы по локальной сети и возвращающая результаты.

Сервер локальной сети предоставляет ресурсы (услуги) ра-

бочим станциям и/или другим серверам.

Принято называть клиентом локальной сети, запрашивающий

услуги у некоторого сервера и сервером - компонент ло-

кальной сети, оказывающий услуги некоторым клиентам.

1.3. Системная архитектура "клиент-сервер"

Понятно, что в общем случае, чтобы прикладная программа,

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

у некоторого сервера, как минимум требуется некоторый ин-

терфейсный программный слой, поддерживающий такого рода

взаимодействие (было бы по меньшей мере неестественно

требовать, чтобы прикладная программа напрямую пользова-

лась примитивами транспортного уровня локальной сети). Из

этого, собственно, и вытекают основные принципы системной

архитектуры "клиент-сервер".

Система разбивается на две части, которые могут выпол-

няться в разных узлах сети, - клиентскую и серверную час-

ти. Прикладная программа или конечный пользователь взаи-

модействуют с клиентской частью системы, которая в про-

стейшем случае обеспечивает просто надсетевой интерфейс.

Клиентская часть системы при потребности обращается по

сети к серверной части. Заметим, что в развитых системах

сетевое обращение к серверной части может и не понадо-

биться, если система может предугадывать потребности

пользователя, и в клиентской части содержатся данные,

способные удовлетворить его следующий запрос.

Интерфейс серверной части определен и фиксирован. Поэтому

возможно создание новых клиентских частей существующей

системы (пример интероперабельности на системном уровне).

Основной проблемой систем, основанных на архитектуре

"клиент-сервер", является то, что в соответствии с кон-

цепцией открытых систем от них требуется мобильность в

как можно более широком классе аппаратно-программных ре-

шений открытых систем. Даже если ограничиться UNIX-

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

няется разная аппаратура и протоколы связи. Попытки соз-

дания систем, поддерживающих все возможные протоколы,

приводит к их перегрузке сетевыми деталями в ущерб функ-

циональности.

Еще более сложный аспект этой проблемы связан с возможно-

стью использования разных представлений данных в разных

узлах неоднородной локальной сети. В разных компьютерах

может существовать различная адресация, представление чи-

сел, кодировка символов и т.д. Это особенно существенно

для серверов высокого уровня: телекоммуникационных, вы-

числительных, баз данных.

Общим решением проблемы мобильности систем, основанных на

архитектуре "клиент-сервер" является опора на программные

пакеты, реализующие протоколы удаленного вызова процедур

(RPC - Remote Procedure Call). При использовании таких

средств обращение к сервису в удаленном узле выглядит как

обычный вызов процедуры. Средства RPC, в которых, естест-

венно, содержится вся информация о специфике аппаратуры

локальной сети и сетевых протоколов, переводит вызов в

последовательность сетевых взаимодействий. Тем самым,

специфика сетевой среды и протоколов скрыта от прикладно-

го программиста.

При вызове удаленной процедуры программы RPC производят

преобразование форматов данных клиента в промежуточные

машинно-независимые форматы и затем преобразование в фор-

маты данных сервера. При передаче ответных параметров

производятся аналогичные преобразования.

Если система реализована на основе стандартного пакета

RPC, она может быть легко перенесена в любую открытую

среду.

Технология "клиент-сервер" применительно к СУБД сводится

к разделению системы на две части – приложение-клиент

(front-end) и сервер базы данных (back-end). Эта архитек-

тура совмещает лучшие черты обработки данных на мэйнфрей-

мах и технологии "файл-сервер". От мэйнфреймов технология

"клиент-сервер" позаимствовала такие черты, как централи-

зованное администрирование, безопасность, надежность. От

технологии "файл-сервер" унаследованы низкая стоимость и

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

ресурсы компьютеров-клиентов. Сейчас графический интер-

фейс пользователя стал стандартом для систем "клиент-

сервер". Кроме того, архитектура "клиент-сервер" значи-

тельно упрощает и ускоряет разработку приложений за счет

того, что правила проверки целостности данных находятся

на сервере. Неправильно работающее клиентское приложение

не может привести к потере или искажению данных. Все эти

возможности, ранее свойственные только сложным и дорого-

стоящим системам, сейчас доступны даже небольшим органи-

зациям. Стоимость оборудования, программного обеспечения

и обслуживания для персональных компьютеров в десятки раз

ниже, чем для мэйнфреймов.

Особенности обработки данных в различных архитектурах по-

казаны на рис.1.

Рис.1. Обработка данных в различных архитектурах

Локальный компьютер

Локальное приложение

СУБД

Данные

Архитектура "файл-сервер"

Клиент

Файл-сервер

Сетевое приложение

Данные

СУБД

Клиент

пересылка Сетевое приложение

данных

СУБД

Архитектура "клиент-сервер"

Сервер БД

Клиентское

СУБД приложение

Данные

Клиентское

приложение

пересылка запросов

и результатов

1.4. Серверы баз данных

Термин "сервер баз данных" обычно используют для обозна-

чения всей СУБД, основанной на архитектуре "клиент-

сервер", включая и серверную, и клиентскую части. Такие

системы предназначены для хранения и обеспечения доступа

к базам данных.

Хотя обычно одна база данных целиком хранится в одном уз-

ле сети и поддерживается одним сервером, серверы баз дан-

ных представляют собой простое и дешевое приближение к

распределенным базам данных, поскольку общая база данных

доступна для всех пользователей локальной сети.

1.5. Принципы взаимодействия между клиент-

скими и серверными частями

Доступ к базе данных от прикладной программы или пользо-

вателя производится путем обращения к клиентской части

системы. В качестве основного интерфейса между клиентской

и серверной частями выступает язык баз данных SQL.

Это язык по сути дела представляет собой текущий стандарт

интерфейса СУБД в открытых системах. Собирательное назва-

ние SQL-сервер относится ко всем серверам баз данных, ос-

нованных на SQL.

Серверы баз данных, интерфейс которых основан исключи-

тельно на языке SQL, обладают своими преимуществами и

своими недостатками. Очевидное преимущество – стандарт-

ность интерфейса. В пределе, хотя пока это не совсем так,

клиентские части любой SQL-ориентированной СУБД могли бы

работать с любым SQL-сервером вне зависимости от того,

кто его произвел.

Недостаток тоже довольно очевиден. При таком высоком

уровне интерфейса между клиентской и серверной частями

системы на стороне клиента работает слишком мало программ

СУБД. Это нормально, если на стороне клиента используется

маломощная рабочая станция. Но если клиентский компьютер

обладает достаточной мощностью, то часто возникает жела-

ние возложить на него больше функций управления базами

данных, разгрузив сервер, который является узким местом

всей системы.

Одним из перспективных направлений СУБД является гибкое

конфигурирование системы, при котором распределение функ-

ций между клиентской и пользовательской частями СУБД оп-

ределяется при установке системы.

1.6. Преимущества протоколов удаленного вы-

зова процедур

Упоминавшиеся выше протоколы удаленного вызова процедур

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

ванных на архитектуре "клиент-сервер".

Во-первых, использование механизма удаленных процедур по-

зволяет действительно перераспределять функции между кли-

ентской и серверной частями системы, поскольку в тексте

программы удаленный вызов процедуры ничем не отличается

от удаленного вызова, и следовательно, теоретически любой

компонент системы может располагаться и на стороне серве-

ра, и на стороне клиента.

Во-вторых, механизм удаленного вызова скрывает различия

между взаимодействующими компьютерами. Физически неодно-

родная локальная сеть компьютеров приводится к логически

однородной сети взаимодействующих программных компонен-

тов. В результате пользователи не обязаны серьезно забо-

титься о разовой закупке совместимых серверов и рабочих

станций.

1.7. Типичное разделение функций между кли-

ентами и серверами

В типичном на сегодняшний день случае на стороне клиента

СУБД работает только такое программное обеспечение, кото-

рое не имеет непосредственного доступа к базам данных, а

обращается для этого к серверу с использованием языка

SQL.

В некоторых случаях хотелось бы включить в состав клиент-

ской части системы некоторые функции для работы с "ло-

кальным кэшем" базы данных, т.е. с той ее частью, которая

интенсивно используется клиентской прикладной программой.

В современной технологии это можно сделать только путем

формального создания на стороне клиента локальной копии

сервера базы данных и рассмотрения всей системы как набо-

ра взаимодействующих серверов.

С другой стороны, иногда хотелось бы перенести большую

  1   2

Добавить документ в свой блог или на сайт

Похожие:

Архитектура аппаратно-программных средств iconЗачет 2 «работа с базами данных»
Бд и комплекса аппаратно-программных средств для ее хранения, изменения и поиска информации, для взаимодействия с пользователем

Архитектура аппаратно-программных средств icon1. 1 Анализ существующих систем обработки анкет опросов
Выбор и обоснование использования аппаратно-программных средств, используемых для разработки и внедрения проекта, а также построение...

Архитектура аппаратно-программных средств iconНазвание команды
«внеплановых» покупок на основе снижения уровня существенной неопределенности у лиц принимающих решения (руководителей торгового...

Архитектура аппаратно-программных средств iconПравила заполнения бланков егэ для участников экзамена
При заполнении бланков регистрации и ответов участников егэ необходимо точно соблюдать правила, так как информация, внесенная в бланки,...

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

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

Архитектура аппаратно-программных средств iconОтчетном периоде за счет средств местного бюджета
Выполнение мероприятий в отчетном периоде за счет средств местного бюджета составило – 40,1 от запланированного объема финансирования...

Архитектура аппаратно-программных средств icon43. Характеристика инструментальных программных средств Состав инструментальных...
Редактор применяется для отладки программ;Транслятор;Отладчик;Библиотекарь применяется для упрощения процесса программирования

Архитектура аппаратно-программных средств iconКлассификация типов программных средств вт
Пс технологии программирования (для автоматизации процессов обработки и вывода информации)

Архитектура аппаратно-программных средств icon1 Архитектура с использованием сервера приложений (трехзвенная архитектура) 20
Что бывает, когда несколько человек одновременно пытаются обновить одни и теже данные 130

Вы можете разместить ссылку на наш сайт:
Школьные материалы


При копировании материала укажите ссылку © 2013
контакты
vbibl.ru
Главная страница