Технология «клиент- сервер»

Содержание:

ВВЕДЕНИЕ

Эволюция компьютерных технологий начинается компьютерных сетей. Компьютерные сети - это новый этап в компьютерных технологиях.

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

С развитием аппаратной части сетей совершенствовалось и сетевое программное обеспечение. Со временем потребовалось модернизировать сами технологи, а не только развитие аппаратуры и программного обеспечения. Были разработаны современные сетевые технологии, такие как технология «клиент-сервер». Эта технология дает возможность пользователям сети получать быстрый доступ к ресурсам.

Цель курсовой работы заключается в изучении сетевой технологии «клиент-сервер»

Поставленные задачи:

1. рассмотреть вопрос о понятии сетевой технологии «клиент-сервер»;
2. изучить принципы взаимодействия между серверными и клиентскими частями и типы архитектур «клиент-сервера»;
3. рассмотреть программные средства разработки

Настоящая курсовая работа была написана с использованием многочисленных источников, среди которых такие как: «Многоуровневые системы клиент-сервер. Открытые системы» под редакцией В. Коржов, которая содержит в себе полную информацию об открытости системы и уровнях клиент-сервера. «Многоуровневые системы клиент-сервер». Далее была использована книга А. Горева, С. Макашарипова, Ю. Владимирова «SQL Server 6.5 для профессионалов», где описаны практические аспекты программных средств разработки. Также при написании курсовой работы была изучена «Публикация баз данных в Интернете».

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

Относительно к системам баз данных архитектура «клиент-сервер» интересна потому, что обеспечивает достаточно простое и недорогое решение такой проблемы, как проблема коллективного доступа к базам данных в локальной сети.

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

Настоящее распространение архитектуры «клиент-сервер» стало возможным в связи с развитием и широким внедрением в практику концепции открытых систем. Целесообразно в этой связи рассмотреть вопрос об открытых системах. [1]

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

Ключевым моментом открытых систем, направленной в сторону пользователей, представляется независимость от определённого поставщика. Выбирая продукцию компаний, придерживающихся стандартов открытых систем, потребитель, который приобретает продукт такой компании, не попадает к ней в рабство. Потребитель может продолжить наращивание мощности своей системы путем приобретения продуктов любой другой компании, соблюдающей стандарты. Это касается как аппаратных, так и программных средств.[3]

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

Технологии и стандарты открытых систем гарантируют реальную и проверенную практикой систему производства системных и прикладных программных средств со свойствами мобильности (portability) и интероперабельности (interoperability). Свойство мобильности заключается в сравнительной простоте переноса программной системы в широком спектре аппаратно-программных средств, которые соответствуют стандартам. Интероперабельность, в свою очередь, это упрощение комплексирования новых программных систем в основе использования готовых компонентов со стандартными интерфейсами.[1]

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

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

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

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

Рабочая станция необходима для непосредственной работы пользователя (или категории пользователей) и обладает соответствующими локальным потребностям этого пользователя ресурсами.

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

Сервера возможно разделить по следующим критериям: по типу услуг, которые они предоставляют.

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

• inetd от англ. internetsuper-serverdaemon демон сервисов IP — стандартное средство UNIX-систем — программа, дающая возможность писать серверы TCP/IP (и сетевых протоколов других семейств), взаимодействующие с клиентом через перенаправленные inetd потоки стандартного ввода и вывода (stdin и stdout).
• RPC от англ. RemoteProcedureCall удаленный вызов процедур — система интеграции серверов в виде процедур доступных для вызова удалённым пользователем через унифицированный интерфейс. Интерфейс, изобретённый SunMicrosystems для своей операционной системы (SunOS, Solaris; Unix-система), сегодня используется как в большинстве Unix-систем, так и в Windows.
• Прикладные клиент-серверные технологии Windows:
• (D-)COM (англ. (Distributed) ComponentObjectModel — модель составных объектов) и др. — Даёт возможность одним программам выполнять операции над объектами данных, используя процедуры других программ. Исходно эта технология необходима для их «внедрения и связывания объектов» (OLE англ. ObjectLinkingandEmbedding), но позволяет писать широкий спектр различных прикладных серверов. COM работает только в пределах одного компьютера, DCOM доступна удаленно через RPC.
• Active-X — расширение COM и DCOM для создания мультимедиа-приложений.[8]

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

Основная часть внутренних и сетевых специфических серверов Windows функционируют через универсальные серверы (RPC, (D-)COM).

Сетевые службы обеспечивают работу сети, к примеру серверы DHCP и BOOTP гарантируют стартовую инициализацию серверов и рабочих станций, DNS — трансляцию имен в адреса и наоборот.[4]

Серверы туннелирования (например, различные VPN-серверы) и прокси-серверы обеспечивают связь с сетью, недоступной роутингом.

Серверы AAA и Radius обеспечивают в сети единую аутентификацию, авторизацию и ведение логов доступа.

Информационные службы. К информационным службам следует отнести как простейшие серверы, сообщающие информацию о хосте (time, daytime, motd), пользователях (finger, ident), так и серверы для мониторинга, например, SNMP. Большинство информационных служб функционируют через универсальные серверы.

Специфичным видом информационных служб являются серверы синхронизации времени — NTP; помимо информирования клиента о точном времени NTP-сервер периодически опрашивает ряд других серверов по поводу коррекции собственного времени. Кроме коррекции времени анализируется и исправляется скорость хода системных часов. Коррекция времени проводится ускорением или замедлением хода системных часов, для избегания проблем возможных при простой перестановке времени.

Файл-серверы представляют собой серверы для предоставления доступа к файлам на диске сервера.

В первую очередь, это серверы передачи файлов по заказу, по протоколам FTP, TFTP, SFTP и HTTP. Протокол HTTP заключается в передаче текстовых файлов, однако серверы могут отдавать в качестве запрошенных файлов и произвольные данные, к примеру, музыку, динамически созданные веб-страницы, картинки и так далее.[8]

Другие серверы представляют возможность монтировать дисковые разделы сервера в дисковое пространство клиента и в полном объёме работать на них с файламих. Это позволяют серверы протоколов NFS и SMB. Серверы NFS и SMB работают через интерфейс RPC.

Недостатки файл-серверной системы:

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

Серверы доступа к данным отдают данные по запросам и обслуживают базу данных. Один из самых простых серверов подобного типа — LDAP (англ. LightweightDirectoryAccessProtocol — облегчённый протокол доступа к спискам).

Единого протокола для доступа к серверам баз данных не существует, но все без исключения серверы баз данных объединяет использование единых правил формирования запросов — язык SQL (англ. StructuredQueryLanguage — язык структурированных запросов).[7]

Службы обмена сообщениями позволяют пользователю передавать и получать сообщения (как правило — текстовые).

В первую очередь ими являются серверы электронной почты, работающие по протоколу SMTP. SMTP-сервер принимает сообщение и доставляет его в почтовый ящик пользователя либо на другой SMTP-сервер (сервер назначения или промежуточный). На многопользовательских компьютерах, пользователи работают с почтой прямо в веб-интерфейсе (или терминале). Для работы с почтой на персональном компьютере, почта берется из почтового ящика через серверы, работающие по протоколам IMAP или POP3.[10]

Для проведения конференций существует серверы новостей, работающие по протоколу NNTP.

Для обмена сообщениями в реальном времени есть серверы чатов, стандартный чат-сервер работает по протоколу IRC — ретранслируемый чат для интернета. Существует большое количество других чат-протоколов, например ICQ или XMPP.[9]

Серверы удаленного доступа

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

Для обеспечения доступа к командной строке служат серверы SSH, telnet, RSH.

Графический интерфейс для Unix-систем — X WindowSystem, имеет встроенный сервер удалённого доступа, так как с такой возможностью разрабатывался изначально.

Стандартный сервер удалённого доступа к графическому интерфейсу Microsoft Windows именуется терминальным сервером.[11]

Некоторую разновидность управления также предоставляет и протокол SNMP. Компьютер для этого должно иметь SNMP-сервер.

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

Серверные решения — это пакеты программ и/или операционные системы, скорректированные и предназначенные для выполнения компьютером функций сервера и/или содержащие в своём составе комплект программ для реализации типичных сервисов. Примером серверных решений является Unix-системы, изначально предназначенные для реализации серверной инфраструктуры, либо серверные модификации платформы Microsoft Windows.

Также необходимо выделить пакеты серверов и сопутствующих программ (к примеру, комплект веб-сервер/PHP/MySQL) для установки под Windows (для Unix свойственна модульная либо «пакетная» установка каждого компонента, поэтому такие решения редки).[6]

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

Серверные решения необходимы для упрощения организации базовой ИТ-инфраструктуры компаний, а именно для оперативного построения полноценной сети в компании, в том числе и «с нуля». Концентрация отдельных серверных приложений в решение предполагает, что решение предназначено для выполнения множества однотипных задач, в данном случае значительно снижается сложность развёртывания и стоимость владения ИТ-инфраструктурой, построенной на таких решениях.

Прокси-сервер (от англ. proxy — «представитель, уполномоченный») служба в компьютерных сетях, предоставляющая клиентам возможность выполнять косвенные запросы к другим сетевым службам. Сперва клиент подключается к прокси-серверу и запрашивает какой-либо ресурс (например, e-mail), расположенный на другом сервере. Потом прокси-сервер либо подключается к указанному серверу и получает ресурс у него, или возвращает ресурс из собственного кеша (в случаях, если прокси имеет свой кеш). В некоторых случаях ответ сервера или запрос клиента может быть изменён прокси-сервером в определённых целях. К тому же прокси-сервер позволяет защищать клиентский компьютер от некоторых сетевых атак.[11]

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

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

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

Интерфейс серверной части определен и фиксирован. В связи с чем возможно создание новых клиентских частей существующей системы (пример интероперабельности на системном уровне).

Главной проблемой систем, основанных на архитектуре «клиент-сервер», является то, что в соответствии с концепцией открытых систем от них необходима мобильность в как можно более широком классе аппаратно-программных решений открытых систем. При том если ограничиться UNIX-ориентированными локальными сетями, в разных сетях применяется разная аппаратура и протоколы связи. Стремление создания систем, поддерживающих все возможные протоколы, приводит к их перегрузке сетевыми деталями в ущерб функциональности.

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

Основным решением проблемы мобильности систем, основанных на архитектуре «клиент-сервер» является опора на программные пакеты, реализующие протоколы удаленного вызова процедур (RPC - RemoteProcedureCall). При применении таких средств обращение к сервису в удаленном узле выглядит как обычный вызов процедуры. Средства RPC, в которых, естественно, находится вся информация о специфике сетевых протоколов и аппаратуры локальной сети, переводит вызов в последовательность сетевых взаимодействий. В связи с этим, специфика сетевой среды и протоколов скрыта от прикладного программиста. [7]

При вызове удалённой процедуры программы RPC делают преобразование форматов данных клиента в промежуточные машинно-независимые форматы и затем преобразуют в форматы данных сервера. При передаче ответных параметров производятся аналогичные преобразования.

В случае если система реализована на основе стандартного пакета RPC, она может быть легко перенесена в любую открытую среду.

Технология «клиент-сервер» применительно к СУБД сводится к разделению системы на две составляющие – приложение-клиент (front-end) и сервер базы данных (back-end). Данная архитектура совмещает лучшие черты обработки данных на мэйнфреймах и технологии «файл-сервер». От мэйнфреймов технология «клиент-сервер» взяла такие черты, как централизованное администрирование, безопасность, надежность. От технологии «файл-сервер» унаследованы невысокая стоимость и возможность распределенной обработки данных, используя ресурсы компьютеров-клиентов. В настоящее время графический интерфейс пользователя стал стандартом для систем «клиент-сервер». Помимо этого, архитектура «клиент-сервер» значительно упрощает и ускоряет разработку приложений из-за того, что правила проверки целостности данных находятся на сервере. Неправильно работающее клиентское приложение не сможет привести к потере или искажению данных. Все эти возможности, ранее свойственные только сложным и дорогостоящим системам, сегодня доступны даже небольшим организациям. Стоимость оборудования, обслуживания и программного обеспечения для персональных компьютеров значительно ниже, чем для мэйнфреймов.[1]

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

Термином «сервер баз данных» как правило обозначают всю СУБД, основанную на архитектуре «клиент-сервер», в том числе и серверную, и клиентскую части. Такие системы предназначаются для хранения и обеспечения доступа к базам данных.[13]

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

1.5. Понятие прикладных протоколов

Нужно отличать понятия сетевых приложений и протоколов прикладного уровня. Протоколы прикладного уровня – это часть сетевых приложений. В этой связи следует рассмотреть два примера. Web является сетевым приложением, позволяющим пользователям получать веб-документы по запросу и состоящим из множества компонентов, в том числе и стандарта формата документов (HTML), браузеры (Opera, Microsoft Internet Explorer и др.), web-серверы (например, Apache, Microsoft или nginx), протоколы прикладного уровня. Протокол прикладного уровня для веба носит название протокола передачи гипертекста (HyperTextTransferProtocol, HTTP) и описывает формат и порядок обмена сообщениями между клиентом и сервером (RFC 2646). Таким образом, HTTP является лишь частью веб-приложения.[14]

Второй пример - приложение электронной почты. Электронная почта Интернета состоит из большого количества компонентов: почтовых серверов, программ для просмотра и создания электронных писем, протоколов прикладного уровня, стандартов, описывающих структуру электронных писем, а также интерпретацию полей, из которых состоят электронные письма. Главным протоколом прикладного уровня для электронной почты является протокол простой передачи сообщений (SimpleMailTransferProtocol, SMTP). Здесь можно убедиться в том, что SMTP (RFC 2821) — лишь часть (хотя и достаточно большая) структуры приложений электронной почты.[11]

Как заявлено выше, протоколы прикладного уровня определяют способ обмена сообщениями между двумя процессами, которые выполняются на разных оконечных системах. Как правило, протокол устанавливает такие элементы:

• типы используемых сообщений, например, запросы и ответы;

• синтаксис каждого из типов сообщений;

• семантику полей;

• описывающие события правила (причём события, вызывающие генерацию сообщений).

Определённые протоколы прикладного доступа (HTTP, SMTP и др.) являются официально документированными в RFC. Это значит, что если разработчик нового браузера следует стандарту, то у браузера будет возможность получать документы с любого web-сервера, построенного по этому же стандарту. Тем не менее существует большое число протоколов прикладного уровня, которые никак не стандартизированы и при этом используются для поддержки коммерческих продуктов. В частности, это свойственно для Интернет-телефонии.

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

Доступ к базе данных от прикладной программы или пользователя производится с помощью обращения к клиентской части системы. В качестве основополагающего интерфейса между клиентской и серверной частями выступает язык баз данных SQL.[2]

Данный язык представляет собой текущий стандарт интерфейса СУБД в открытых системах. Собирательное название SQL-сервер касается всех серверов баз данных, основанных на SQL.

Серверы баз данных, интерфейс которых основан только на языке SQL, обладают своими преимуществами и своими недостатками. Очевидное преимущество – стандартность интерфейса.

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

Одним из перспективных направлений СУБД является гибкая настройка системы, при котором распределение функций между серверной и клиентской частями СУБД определяется при установке системы.

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

Протоколы удаленного вызова процедур важны в системах управления базами данных, основанных на архитектуре «клиент-сервер».[1]

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

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

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

В типичном на сегодняшний день случае на стороне клиента СУБД функционирует только такое программное обеспечение, которое не имеет непосредственного доступа к базам данных, а обращается к серверу с использованием языка SQL.[5]

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

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

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

Основная часть любой системы «клиент-сервер» – это сервер БД. С момента возникновения архитектуры «клиент-сервер» появилось много вариантов архитектуры процессора БД, так как он во многом определяет успех всей системы. Главное требование к серверу БД – обеспечение минимального времени выполнения запросов при максимально возможном числе пользователей. Имеются две основные архитектуры для построения процессора БД: архитектура с несколькими процессами и многопоточная архитектура. [7]

1.9.1. Архитектура с несколькими процессами

Данная архитектура характеризуется тем, что несколько экземпляров исполняемого файла работают одновременно. Данные системы отличаются хорошей масштабируемостью, но требуют значительных расходов памяти, так как память каждому экземпляру приложения выделяется отдельно. Данная архитектура подразумевает наличие эффективного механизма взаимодействия процессов и полагается на операционную систему в разделении процессорного времени между отдельными экземплярами приложения. Самый известный пример сервера, построенного по этой архитектуре, - OracleServer.[12] При подключении пользователя к БД Oracle, он в действительности запускает отдельный экземпляр исполняемого файла процессора базы данных.[7]

1.9.2. Многопоточная архитектура

Многопоточная архитектура использует только один исполняемый файл, с несколькими потоками исполнения. Основное преимущество – более скромные требования к оборудованию, чем для архитектуры с несколькими процессами. В данном случае сервер берет на себя разделение времени между отдельными потоками, иногда давая преимущество некоторым задачам над другими. Кроме того, отпадает необходимость в сложном механизме взаимодействия процессов. По такой архитектуре построены MS SQL Server и Sybase SQL Server. [14]

1.10 Преимущества архитектуры клиент-сервер

Основными преимуществами архитектуры клиент-сервер является надежность.[1]

Сервер баз данных осуществляет модификацию данных на основе механизма транзакций, который придает любой совокупности операций, объявленных как транзакция, следующие свойства:

• атомарность - при различных обстоятельствах будут либо выполнены все операции транзакции, либо не выполнена ни одна; целостность данных при завершении транзакции;

• независимость - транзакции, инициированные разными пользователями, никак не вмешиваются в дела друг друга;

• устойчивость к сбоям - после завершения транзакции, ее результаты уже не пропадут.

Механизм транзакций, поддерживаемый сервером баз данных, более эффективен, чем аналогичный механизм в настольных СУБД, т.к. сервер централизованно контролирует работу транзакций. Помимо этого в файл-серверной системе сбой на любой из рабочих станций может привести к потере данных и их недоступности для других рабочих станций, как в клиент-серверной системе сбой на клиенте, практически, никогда не сказывается на целостности данных и их доступности для других клиентов.

Еще одним преимуществом является масштабируемость.

Масштабируемость - это способность адаптироваться к росту количества пользователей и объема базы данных при равномерном повышении производительности аппаратной платформы, без замены программного обеспечения.

Общеизвестно, что возможности настольных СУБД серьезно ограничены - это пять-семь пользователей и 30-50 Мб, соответственно. Цифры, конечно, представляют собой некие средние значения, в конкретных случаях они могут отклоняться как в ту, так и в другую сторону. Что очень существенно, эти барьеры нельзя преодолеть за счет наращивания возможностей аппаратуры.

Системы на основе серверов баз данных могут поддерживать тысячи пользователей и сотни ГБ информации - при соответствующей аппаратной платформе.

Так же преимуществом является безопасность.

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

Еще одним преимуществом является гибкость.

В приложении, работающем с данными, можно отметить три логических слоя:

• пользовательского интерфейса

• правил логической обработки

• управления данными

Вывод:

Архитектура «клиент-сервер» является надежной, высокопроизводительной и безопасной в работе, что обеспечивает простое и относительно не дорогое решение проблемы коллективного доступа к базам данных в локальной сети.

2. Двух уровневая и многоуровневая архитектура «клиент-сервер»

2.1. Двухуровневая архитектура «клиент-сервер»

Двухуровневая архитектура начала распространяться с 1990-х годов, когда рос рынок персональных компьютеров и снижался спрос на мэйнфреймы.[6]

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

Схематически такую архитектуру можно представить, как показано на рис.1

Рис. 1. Классическое представление архитектуры «клиент-сервер»

Компания GartnerGroup, которая занимается исследованием информационных технологий предложила классификацию двузвенных моделей взаимодействия клиент-сервер (двухзвенными модели - это три компонента приложения различным образом распределяются между двумя узлами):

Рис. 2. Классификация двухзвенных моделей взаимодействия «клиент-сервер»

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

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

С возникновением первых специализированных серверов баз данных появилась возможность другой реализации модели доступа к удаленной базе данных. Теперь в одной программе совмещались различные функции. Ядро СУБД работает на сервере, протокол обмена обеспечивается с помощью языка SQL. Новый метод по сравнению с файловым сервером привел к уменьшению загрузки сети и единообразию интерфейса «клиент-сервер». Но сетевой трафик остается достаточно высоким, кроме того, по-прежнему невозможно удобное администрирование приложений.[6]

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

Преимущества такого подхода:

• значительно т.к. передаются не SQL-запросы, а вызовы хранимых процедур (снижение сетевого трафика);

• возможно централизованное администрирование прикладных функций.

Недостаток - такого подхода ограниченность средств разработки хранимых процедур по сравнению с языками общего назначения (C и Pascal). [7]

На практике обычно используется смешанный подход:

• простейшие прикладные функции выполняются хранимыми процедурами на сервере;

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

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

Формирование результирующих отчетов выполняются в коде приложения, или предварительная обработка форм, предназначенных для запросов к базе данных. Язык SQL используется для интерфейса между клиентской частью приложения и клиентской частью сервера баз данных.

В следствии чего клиентская часть сервера баз данных, используя средства сетевого доступа, обращается к серверу базы данных, передавая текст оператора языка SQL.[14]

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

Пользователи и разработчики информационных систем, основанных на архитектуре «клиент-сервер» часто бывают не удовлетворены постоянно существующими сетевыми накладными расходами, которые исходят из потребности обращаться от клиента к серверу с каждым очередным запросом. На практике очень распространена ситуация, когда для эффективной работы отдельной клиентской составляющей информационной системы в действительности необходима только небольшая часть общей базы данных. Это все приводит к идее поддержки локального кэша общей базы данных на стороне каждого клиента. Практически, концепция локального кэширования базы данных является частным случаем концепции реплицированных баз данных. Как в случае, для поддержки локального кэша базы данных программное обеспечение рабочих станций должно иметь компонент управления базами данных – более упрощенный вариант сервера баз данных, который может не обеспечивать многопользовательский режим доступа. [2]

Отдельной проблемным вопросом является обеспечение согласованности кэшей и общей базы данных. В данном случае возможны различные решения – от автоматической поддержки согласованности за счет средств базового программного обеспечения до полного перекладывания этой задачи на прикладной уровень.[7]

Преимуществами данной архитектуры являются:

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

Недостатками данной архитектуры являются:

• неработоспособность сервера может сделать неработоспособной всю вычислительную сеть;
• администрирование данной системы требует квалифицированного профессионала;
• высокая стоимость оборудования;
• бизнес логика приложений остается в клиентском ПО.

Во время проектирования информационной системы, основанной на архитектуре «клиент-сервер», большее внимание следует обращать на грамотность общих решений. Технические средства пилотной версии могут быть совершенно минимальными (например, в качестве аппаратной основы сервера баз данных может быть использована одна из рабочих станций). Уже после создания пилотной версии нужно провести дополнительную исследовательскую работу, чтобы выяснить узкие места системы. Только лишь после этого необходимо принимать решение о выборе аппаратуры сервера, которая будет использоваться на практике.[1]

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

Данный вид архитектуры называют еще архитектурой с «толстым» клиентом. Тут логика представления данных и бизнес-логика размещаются на клиенте, который (скажем, в случае, если сервером является СУБД) общается с логикой хранения и накопления данных на сервере, применяя язык структурированных запросов SQL. Но необходимость установки «толстых клиентов», требующих значительного количества специальных библиотек и специальной настройки окружения, на большое количество пользовательских компьютеров с различными операционными средами, как правило, вызывает массу проблем.

Как альтернатива возникла также двухзвенная архитектура «с тонким клиентом». В этом случае в идеале программа-клиент реализует лишь графический интерфейс пользователя (GUI) и занимается передачей и приемом запросов, а вся бизнес-логика выполняется сервером. В вэтом случае клиентом является просто интернет-браузер, который имеется в любой стандартной операционной среде любого пользовательского компьютера и не требует специальной настройки, установки специализированного ПО и т.п. Но к сожалению, такая схема тоже не лишена недостатков, хотя бы уже потому, что серверу иногда приходится брать на себя несвойственные для него функции осуществления бизнес логики приложения (например, серверу СУБД приходится выполнять расчеты).

2.2 Многоуровневая архитектура «клиент-сервер»

Самая распространенная трехуровневая архитектура (трехзвенная архитектура, threetier), которая относится к многоуровневой архитектуры «клиент-сервер».[3]

У трехуровневой архитектуры должно быть наличие следующих компонентов приложения:

клиентское приложение (обычно называют «тонкий клиент» или терминал), подключенное к серверу приложений, который уже подключен к серверу базы данных.

Схематически такую архитектуру можно представить, как показано на рис. 3

.

Рис. 3. Представление многоуровневой архитектуры «клиент-сервер»

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

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

Сервер базы данных выносится на третий уровень и обеспечивает хранение данных. Обычно это стандартная реляционная или объектно-ориентированная СУБД. Третий уровень может представлять собой базу данных вместе с хранимыми процедурами, триггерами и схемой, которая описывает приложение в терминах реляционной модели, а второй уровень строится как программный интерфейс, который связывает клиентские компоненты с прикладной логикой базы данных.

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

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

Плюсами данной архитектуры являются:

• масштабируемость;

• клиентское ПО не нуждается в администрировании;

• конфигурируемость – изолированность уровней друг от друга, что позволяет быстро и простыми средствами переконфигурировать систему при возникновении сбоев или в том числе при плановом обслуживании на одном из уровней;

• высокая надежность и безопасность;

• низкие требования к производительности и техническим

характеристикам терминалов, следовательно, снижение их стоимости;

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

Минусами данной архитектуры являются:

• более высокая сложность создания приложений;

• повышение сложности серверной части, что ведет к затратам на администрирование и обслуживание;

• сложности в разворачивании и администрировании;

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

• высокие требования к скорости канала-сети между сервером базы

• данных и серверами приложений.

Начало процессу развития корпоративного программного обеспечения в многозвенной архитектуре было положено в рамках технологии «клиент-сервер». В них наравне с клиентской частью приложения и сервером баз данных появились серверы приложений (ApplicationServers).

В идеальном виде программа-клиент реализует GUI, передает запросы серверу приложений и принимает от него ответ, затем сервер приложений реализует бизнес-логику и дальше обращается с запросами к серверу «третьего уровня» (например, серверу базы данных за данными), который обслуживает запросы сервера приложений. Программа-клиент, таким образом, может быть «тонкой».

Преимущества такой архитектуры очевидны:

так как звенья не обмениваются между собой большими объемами информации, то снижаются нагрузки на сеть;

изменения на каждом из звеньев можно осуществлять независимо;

обеспечивается масштабирование и простая модернизация оборудования и программного обеспечения, поддерживающего все звенья, в том числе обновление СУБД, терминального оборудования, серверного парка и т.д.;

приложения могут создаваться на стандартных языках третьего или четвертого поколения (C/C++, Java).[1]

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

Ключевой проблемой систем, которые основаны на двухзвенной архитектуре «клиент-сервер», или тем более на многозвенной архитектуре, является то, что от них требуется мобильность в как можно более широком классе аппаратно-программных сред. И если ограничиться UNIX-ориентированными локальными сетями, в разных сетях применяется разная аппаратура и протоколы связи. Попытки создания систем, поддерживающих все возможные протоколы, приводит к их перегрузке сетевыми деталями в ущерб функциональности. Более проблемный аспект этого вопроса связан с возможностью использовать разные представления данных в разных узлах неоднородной локальной сети. В разных компьютерах может существовать различная адресация, представление чисел, кодировка символов и т.д. Это особенно существенно для серверов высокого уровня: телекоммуникационных, вычислительных, баз данных.

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

При вызове удаленной процедуры, программы RPC производят преобразование форматов данных клиента в промежуточные машинно-

независимые форматы, и затем преобразование в форматы данных сервера.

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

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

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

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

(трехзвенную) в виде пяти уровней (рис 4)

1. Представление;

2. Уровень представления;

3. Уровень логики;

4. Уровень данных;

5. Данные.

Рис. 4. Пять уровней многозвенной архитектуры «клиент-сервер»

К представлению относится вся информация, непосредственно отображаемая пользователю: сгенерированные html-страницы таблицы стилей, изображения.

Уровень представления содержит все, что относится к общению пользователя с системой. К основным функциям слоя представления можно отнести отображение информации и интерпретацию вводимых пользователем команд с реконструкцией их в определённые операции в контексте логики и данных.[6]

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

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

Данные системы обычно хранятся в базе данных. [6]

Вывод:

Двухуровневая архитектура по сравнению с многоуровневой простая, потому что запросы управляются одним сервером. Однако она ненадежна и для нее используются повышенные требования к производительности сервера. У многоуровневой архитектуры распределение действий идет между серверами. Это дает высокую гибкость, защиту и производительность. Основная проблема данных систем заключается в том, что нет мобильности в классе аппаратно-мобильных сред.3. Программные средства разработки

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

Для разработки клиентских приложений существует большое число универсальных пакетов программ, которые имеют возможность выполнить соединение с сервером и разработать для пользователя удобный графический интерфейс, позволяющий эффективно работать с данными. Часть из этих средств для разработки приложений в архитектуре «клиент-сервер» перечислены в таблице.[7]

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

При разработке клиентских приложений в большинстве случаев вместо универсальных средств разработки удобнее использовать персональные СУБД. Использование персональных СУБД дает не только эффективно организовывать работу с бизнес-правилами, но и возможность поддержать независимую работу клиентского приложения за счет наличия собственных форматов хранения данных. Краткая характеристика некоторых персональных СУБД приведена в таблице.[2]

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

Основной причиной использования программ-расширений серверной части на промежуточном уровне является возможность применять стандарты, существующих для двух крайних уровней, путем осуществления трансляции между ними. Прочие применения расширений серверной части состоят в поддержании соединений между БД с целью сократить трафик в сети и в поддержании резерва соединений между БД для сокращения затрат ресурсов на открытие/закрытие БД. Расширения серверной части к тому же поддерживают взаимозаменяемость в своих стандартных интерфейсах. В связи с чем серверы БД и Web-серверы можно сравнительно легко заменять или наращивать.[2]

Существует три категории расширений серверной части: с API, обычным CGI и гибридным CGI.

Вывод:

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

Заключение

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

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

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

Согласно задачам, поставленным во введении курсовой работы, было сделано следующее:

• • • рассмотрен вопрос о понятии сетевой технологии «клиент-сервер»;
    • рассмотрены преимущества протоколов удаленного вызова процедур
• изучены принципы взаимодействия между серверными и клиентскими частями и типы архитектур «клиент-сервера»;
• рассмотрены и проанализированы программные средства разработки

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

Литература

Основная:

1. Валерий Коржов, Многоуровневые системы клиент-сервер. Издательство Открытые системы (17 июня 1997). 
2. Хомоненко А. Д., Базы данных / Под ред. проф. Хомоненко А.Д. 6-е изд. – М: БИНОМ-Пресс; Спб., КОРОНА, 2007.
3. Таненбаум Э., Стеен ван М., Распределенные системы / Э. Таненбаум, М. Ван Стеен. – Спб.: BHV, 2003.

Дополнительная:

1. Альбитц П., Ли К., DNS и BIND / П. Альбитц, К. Ли. – Спб.: Симво л - Плюс, 2002. – 696 с
2. А. Горев, С. Макашарипов, Ю. Владимиров SQL Server 6.5 для профессионалов изд. Питер Санкт-Петербург, 1998.
3. Публикация баз данных в Интернете изд. Символ-Плюс Санкт-Петербург, 1998.
4. Oracle Database 11g. Программирование на языке PL/SQL: Майкл Мак-Локлин — Москва, Лори, 2013 г.- 902 с.
5. MicrosoftPress Секреты создания интрасетей изд. Питер Санкт-Петербург, 1998.
6. ICQ (клиент): Джесси Рассел — Москва, Книга по Требованию, 2013 г.- 104 с..
7. Почтовая программа: Джесси Рассел — Москва, Книга по Требованию, 2012 г.- 124 с.
8. Microsoft Windows XP Professional. Полное руководство: Гай Харт-Дэвис — Москва, Эком, 2003 г.- 816 с.

Интернет ресурсы:

1. www.oracle.com Сайт разработчиков СУБД Oracle 10g

(дата обращения: 03.12.2017).

1. www.ibm.com Сайт разработчиков СУБД IBM DB2

(дата обращения: 03.12.2017).

1. www.microsoft.com Сайт разработчиков СУБД MS SQL Server

(дата обращения: 03.12.2017).