Размещено на http: //www. allbest. ru/
СОДЕРЖАНИЕ
ВВЕДЕНИЕ
Данная работа рассматривает теоретические вопросы принципов построения современных компьютеров и архитектуры «клиент-сервер», а также содержит результат практического выполнения табличного расчета с иллюстрацией результата по указанным входным данным с использованием ППП на ПК.
При рассмотрении вопроса принципов построения современных компьютеров раскрываются основные элементы архитектуры современных вычислительных систем с небольшим историческим экскурсом, описывающим элементы предыдущих поколений ЭВМ. Описываются новые и развивающиеся тенденции в использовании компьютеров и описаны основные их достоинства и недостатки. Особое внимание уделяется модульному принципу построение современных компьютерных систем.
При анализе вопроса «клиент-серверной» архитектуры изучаются основные понятия данной модели программного взаимодействия и способы решения вычислительных задач при данной модели взаимодействия. Указываются основные достоинства и недостатки, а также определяются предложения по устранению данных недостатков. Особое внимание уделяется системам СУБД как наиболее популярной и удачной реализации данной модели межпрограммного взаимодействия.
Выполнение практической задачи предусматривает заведение в ППП исходных данных в табличной форме, определение промежуточных и выходных параметров как функциональной зависимости от входных и самих промежуточных (построение связей на уровне ячеек), а также иллюстрирование результатов вычислений в виде гистограммы. В качестве ППП для выполнения данных расчетов был использован пакет Microsoft Excel 2000, входящий в состав программного продукта Microsoft Office 2000. Выбор определен тем, что данный продукт имеет наибольшую популярность среди аналогов и представляет наибольшую функциональности и дружественный (интуитивно понятный) интерфейс.
1. ОСНОВНЫЕ ПОНЯТИЯ АРХИТЕКТУРЫ КЛИЕНТ-СЕРВЕР
1.1 Определение технологии «клиент-сервер»
Уже само понятие "архитектура «клиент-сервер»" трактуется разработчиками по-разному. Наиболее точным, на мой взгляд, определением архитектуры «клиент-сервер», является определение ее как системы, прикладная составляющая которой имеет распределенный характер и состоит из двух взаимосвязанных компонент, одна из которых (клиент) формирует и посылает запросы высокого уровня другой компоненте (серверу), задача которой состоит в обслуживании этих запросов. Данное определение можно расширить более наглядным примером из системы СУБД, сказав, под архитектурой «клиент-сервер» понимается такая организация вычислительного процесса, при которой вся обработка происходит в основном на персональном компьютере, обращающемся с SQL-запросами к серверу, где содержатся общие базы данных. По сети циркулируют только SQL-запросы/ответы (а не фрагменты или отдельные записи СУБД, как в архитектуре файл-сервер), благодаря чему резко снижается нагрузка на сеть. Обработка данных при этом более равномерно распределяется между клиентом и сервером.
Однако, некоторые разработчики считают, что в последнее время термин «клиент-сервер», к сожалению, девальвировался и стал применяться по отношению к любым локально-сетевым технологиям. Самое примечательное свойство архитектуры «клиент-сервер» состоит в возможности удалить клиента от сервера на любое расстояние без существенного снижения скоростных характеристик системы (даже в случае сложных запросов) и без всяких изменений в программном обеспечении. Удаленный клиент подключается к серверу с помощью телефонного или иного канала. Это свойство очень ценно для организации распределенной обработки данных. Кроме того, оно позволяет заменять СУБД, операционную систему и сервер, не изменяя программного обеспечения клиентской части системы.
1.2 Модели взаимодействия клиента и сервера
Обычно выделяются три модели взаимодействия клиента и сервера:
1. RDA (Remote Data Access), в которой компонента представления (пользовательский интерфейс) и прикладная компонента (логика работы программы) совмещены в клиентской части, а компонента доступа к информационным ресурсам (данным) размещена в серверной части.
2. DBS (DataBase Server), в которой компонента представления размещена в клиентской части, а прикладная компонента и доступ к информационным ресурсам - в серверной;
3. AS (Application Server), в которой компонента представления находится в клиентской части, прикладная компонента - в «сервере приложения», а компонента доступа к информационным ресурсам - в «сервере базы данных».
Рассмотрим другую, более детальную классификацию архитектур (по методике Garthner Group). Пользовательский интерфейс (компонента представления) может быть размещен в серверной части, тогда получается модель хост-терминал, которая является предельным случаем архитектуры «клиент-сервер». Другим предельным случаем (вырожденным) являются автономные вычисления на одном компьютере, когда все данные, логика работы (прикладная компонента) и пользовательский интерфейс сосредоточены в клиентской части. Учтем также, что и прикладные компоненты (логика работы), и сами данные могут быть по-разному распределены между клиентской и серверной частями. Кроме того, серверов приложений может быть несколько.
Системы с архитектурой «клиент-сервер» могут быть двух- или трехуровневыми.
Система является двухуровневой, если она построена с использованием набора прикладных клиентских программ, имеющих общий доступ к ресурсам системы и работающих с сервером базы данных или SQL-сервером. Прикладная программа может при этом размещаться как в клиентской, так и в серверной частях в виде хранимых процедур, триггеров и правил.
Система является трехуровневой, если она содержит три следующие самостоятельные компоненты:
1. интерфейс пользователя, в функции которого входят только отображение (вывод) результатов и взаимодействие с пользователем;
2. сервер приложения, в котором сосредоточены все бизнес-функции, правила и/или хранимые процедуры;
3. сервер базы данных (в большинстве случаев - SQL-сервер СУБД), он же - менеджер ресурсов.
Легко видеть, что трехуровневая система относится к модели AS.
Такая система строится с использованием промежуточного программного обеспечения (чаще всего - монитора транзакций), причем прикладная логика переносится из клиентских программ в отдельный от СУБД сервер приложений.
1.3 Преимущества и недостатки технологии клиент-сервер и способы их устранения
Сегодня пропагандируется мнение, что самым лучшим и даже чуть ли не единственно правильным вариантом архитектуры «клиент-сервер» является SQL-сервер. Однако в этом варианте клиент не имеет непосредственного навигационного доступа к записям в базе данных, а посылает серверу запросы на языке SQL и получает от него множества записей, удовлетворяющих запросу. При больших и сложных запросах такая архитектура действительно резко сокращает сетевой трафик и позволяет существенно повысить производительность. Современные версии SQL-серверов стараются использовать архитектуру SuperServer, когда всем сервером управляет один процесс, а для обслуживания клиентов, выполнения запросов и других задач создаются потоки (threads). Безусловно, такая архитектура применительно к SQL-серверам имеет преимущества:
- Увеличение производительности при тех-же характеристиках сервера
- Использование общего кэша при операциях ввода-вывода
- Меньший объем используемой памяти
- Большее количество обслуживаемых пользователей при том-же объеме памяти
и недостатки
- меньшая защищенность сервера при внутренних сбоях
Последний пункт относится ко всем SQL-серверам, имеющим архитектуру SuperServer. Действительно, все потоки (threads) находятся в одном адресном пространстве, и любой сбой может привести к "падению" SQL-сервера.
Однако повседневная работа пользователей современных приложений, особенно банковских, состоит в основном не в исполнении мудреных запросов, а в проведении таких элементарных операций, как ввод записи, редактирование записи, поиск записи по ключу и пролистывание массива записей на экране. Операции такого рода выполняются SQL-сервером отнюдь не быстрее, чем традиционными СУБД с навигационным способом доступа, а пролистывание вообще сопряжено с массой трудностей.
Из сказанного отнюдь не следует, что язык SQL не нужен или вреден. Для определенного круга задач он очень удобен, но далеко не для всех. В том, что этот язык не в состоянии удовлетворить многие потребности современных пользователей, нет ничего удивительного: хотя он часто выдается за новейшую технологию, на самом деле он был разработан десятки лет назад, в эпоху пакетной обработки данных, когда потребители данных общались с компьютерами через операторов, передавая им свои запросы и получая в ответ распечатки. Естественно, технология обработки данных и взаимоотношения человека с компьютером с тех пор сильно изменились, что потребовало разработки более современных языков доступа к данным.
В качестве общего вывода к данной части обзора можно сказать следующее. Архитектура «клиент-сервер», минимизируя сетевой трафик, максимизирует нагрузку на сервер. Поэтому целесообразность применения этой архитектуры зависит от того, какой элемент системы является узким местом.
Система разбивается на две части, которые могут выполняться в разных узлах сети, - клиентскую и серверную части. Прикладная программа или конечный пользователь взаимодействуют с клиентской частью системы, которая в простейшем случае обеспечивает просто надсетевой интерфейс. Клиентская часть системы при потребности обращается по сети к серверной части. Заметим, что в развитых системах сетевое обращение к серверной части может и не понадобиться, если система может предугадывать потребности пользователя, и в клиентской части содержатся данные, способные удовлетворить его следующий запрос.
Интерфейс серверной части определен и фиксирован. Поэтому возможно создание новых клиентских частей существующей системы (пример интероперабельности на системном уровне).
Основной проблемой систем, основанных на архитектуре "клиент-сервер", является то, что в соответствии с концепцией открытых систем от них требуется мобильность в как можно более широком классе аппаратно-программных решений открытых систем. Даже если ограничиться UNIX-ориентированными локальными сетями, в разных сетях применяется разная аппаратура и протоколы связи. Попытки создания систем, поддерживающих все возможные протоколы, приводит к их перегрузке сетевыми деталями в ущерб функциональности.
Еще более сложный аспект этой проблемы связан с возможностью использования разных представлений данных в разных узлах неоднородной локальной сети. В разных компьютерах может существовать различная адресация, представление чисел, кодировка символов и т.д. Это особенно существенно для серверов высокого уровня: телекоммуникационных, вычислительных, баз данных.
Общим решением проблемы мобильности систем, основанных на архитектуре "клиент-сервер" является опора на программные пакеты, реализующие протоколы удаленного вызова процедур (RPC - Remote Procedure Call). При использовании таких средств обращение к сервису в удаленном узле выглядит как обычный вызов процедуры. Средства RPC, в которых, естественно, содержится вся информация о специфике аппаратуры локальной сети и сетевых протоколов, переводит вызов в последовательность сетевых взаимодействий. Тем самым, специфика сетевой среды и протоколов скрыта от прикладного программиста.
При вызове удаленной процедуры программы RPC производят преобразование форматов данных клиента в промежуточные машинно-независимые форматы и затем преобразование в форматы данных сервера. При передаче ответных параметров производятся аналогичные преобразования.
Если система реализована на основе стандартного пакета RPC, она может быть легко перенесена в любую открытую среду.
2. ПРАКТИЧЕСКАЯ ЧАСТЬ
2.1 Общая характеристика задачи
Используя пакет прикладных программ (ППП) на ПК, необходимо рассчитать оптимальное сочетание цены и количества произведенного товара при максимальном значении получаемой прибыли путем задания переменных издержек на единицу товара. Указанный расчет следует произвести на основе следующих статистических данных:
· цены товара;
· количество выпущенного товара;