Модели архитектуры клиент-сервер — студенческий портал

Этот материал — часть цикла “Введение в Enterprise-разработку”. Первая часть о сети — здесь.
Архитектура программного обеспечения — структура, на базе которой создается приложение, взаимодействуют модули и компоненты всей программы. За создание хорошей архитектуры программисты взялись еще очень давно, поэтому неудивительно, что сейчас нам известно немало архитектурных шаблонов. Разбираться в них нужно: когда пишешь веб-приложение, проблема архитектуры становится острой, ведь в ней компонентов и модулей больше, чем в обычном приложении. Архитектурный шаблон — это уже придуманный способ решения какой-то задачи по проектированию программного обеспечения. Ты уже наверняка сталкивался с такими паттернами проектирования как фабричный метод (Factory Method), абстрактная фабрика (Abstract Factory), строитель (Builder), прототип (Prototype), одиночка (Singleton) и, возможно, другими. Они используются при простом написании кода, создании классов и планировании их взаимодействия. Архитектурные шаблоны задействуют на более высоком уровне абстракции — при планировании взаимодействия пользователя приложения с сервером, данными и другими компонентами проекта. Давай сразу рассмотрим некоторые шаблоны и то, как их использовать.
Из названия складывается впечатление, что с этой темой все просто и понятно. Но давай уточним кое-какие моменты, чтобы приступив к изучению условного Спринга ты точно понимал, о чем идет речь. Допустим, ты написал чат, и вы с приятелем начинаете его использовать. Здесь возможен простой вариант — вы отправляете сообщение друг другу напрямую через интернет по IP-адресам, которые вы знаете:
Поначалу может показаться, что все отлично работает, пока не появляется еще один ваш друг с вопросом: “А почему вы не добавите меня в свой чат?”. И вот когда ты решаешь добавить общего друга в чат, ты сталкиваешься с архитектурной проблемой: каждому пользователю чата нужно обновить информацию о количестве пользователей, добавить IP-адрес нового юзера. А еще при отправке сообщения оно должно доставляться всем участникам. Это самые очевидные проблемы из тех, которые возникнут. Еще куча проблем будет спрятана в самом коде. Чтобы избежать их, нужно использовать сервер, который будет хранить всю информацию о пользователях, знать их адреса. Сообщение нужно будет отправить только на сервер. А он, в свою очередь, разошлет сообщение всем адресатам. Когда ты решишь добавить серверную часть в свой чат, ты начнешь строить клиент-серверную архитектуру.
Давай разберемся, что она представляет из себя. Клиент-серверная архитектура — шаблон проектирования, основа для создания веб-приложений. Данная архитектура состоит из трех компонентов:

1. Клиент — из названия становится понятно, что это пользователь сервиса (веб-приложения), который обращается к серверу для получения какой-то информации.

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

3. Сеть — все просто: обеспечивает обмен информацией между клиентом и сервером.

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

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

Когда мы хотим посмотреть полезную (или не очень полезную) информацию в интернете, мы открываем браузер, в строке поиска вводим запрос, и в ответ получаем информацию от поисковика. В этой цепочке браузер — это наш клиент. Он отправляет запрос с информацией о том, что мы ищем, серверу. Сервер обрабатывает запрос, находит наиболее релевантные результаты, упаковывает их в понятный для браузера (клиента) формат и отправляет назад. В таких сложных сервисах как поисковики серверов может быть много. Например, сервер авторизации, сервер для поиска информации, сервер для формирования ответа. Но клиент об этом ничего не знает: для него сервер является чем-то единым. Клиент знает только о точке входа, то есть, адресе сервера, которому нужно отправить запрос. Вспомним о приложении, которое мы рассматривали в предыдущей части — для мониторинга средней температуры воздуха во всех странах в режиме реального времени. Его архитектура будет выглядеть примерно так:
Наше приложение располагается на сервере. Скажем, каждые пять секунд оно отправляет запросы на серверы локальных гидрометцентров, получает у них информацию о температуре в конкретной стране, сохраняет эту информацию. Когда клиент обращается к нам с запросом “посмотреть текущую температуру воздуха в мире”, мы возвращаем последнюю сохраненную информацию, рассортированную по странам. Таким образом наше приложение одновременно и сервер (когда обрабатывает запросы юзеров), и клиент (когда получает информацию у других серверов).

Важно: понятие сервер — не о конкретном компьютере, а о взаимоотношениях абонентов сети.

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

1. Клиентский слой — интерфейс пользователя. Это может быть веб-браузер, которому отправляются HTML-страницы, или графическое приложение, написанное с помощью JavaFX. Главное, чтобы с его помощью пользователь мог отправлять запросы на сервер и обрабатывать его ответы.

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

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

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

1. Возможность построить защиту от SQL-инъекций — это атака на сервер, при которой передается SQL-код, и при выполнении этого кода злоумышленник может воздействовать на нашу базу данных.

2. Разграничение данных, к которым мы хотим регулировать пользовательский доступ.

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

4. Масштабируемость — возможность расширить наше приложение на несколько серверов, которые будут использовать одну и ту же базу данных.

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

Если ты знаком, скажем, с паттерном проектирования Фабричный метод, ты наверняка задумывался, когда его стоит использовать. Иногда трудно определиться, что делать: создать объект с помощью оператора new или использовав фабричный метод. Но со временем понимание приходит. С архитектурными шаблонами дела обстоят немного иначе. Enterprise-фреймворки рассчитаны на то, что программист с их помощью создает проект на основе какого-то общепринятого паттерна. Поэтому перед изучением Spring Framework тебе обязательно нужно понимать, что такое клиент-серверная архитектура, трехуровневая архитектура и MVC-архитектура. Не переживай: об MVC-архитектуре мы еще поговорим. Часть 1. Что нужно знать перед изучением Spring и JavaEE Часть 3. Протоколы HTTP/HTTPS
Часть 4.Основы Maven
Часть 5. Сервлеты. Пишем простое веб-приложение
Часть 6. Контейнеры сервлетов
Часть 7. Знакомство с паттерном MVC (Model-View-Controller)
Часть 8. Пишем небольшое приложение на spring-boot

Источник: https://javarush.ru/groups/posts/2519-chastjh-2-pogovorim-nemnogo-ob-arkhitekture-po

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

Привет, посетитель сайта ZametkiNaPolyah.ru! Продолжаем рубрику Сервера и протоколы. В этой записи мы поговорим о том, как работают приложения и сайты в сети Интернет, да и вообще в любой компьютерной сети.

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

Модель взаимодействия клиент-сервер. Архитектура «клиент-сервер».

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

Концепция взаимодействия клиент-сервер

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

Здесь мы разберемся с концепцией, которая позволяет нам выполнять все эти действия в сети Интернет. Данная концепция получила название «клиент-сервер». Как понятно из названия, в данной концепции участвуют две стороны: клиент и сервер.

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

Клиент и сервер взаимодействую друг с другом в сети Интернет или в любой другой компьютерной сети при помощи различных сетевых протоколов, например, IP протокол, HTTP протокол, FTP и другие. Протоколов на самом деле очень много и каждый протокол позволяет оказывать ту или иную услугу.

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

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

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

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

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

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

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

Мы видим, что к одному серверу может обращаться сразу несколько клиентов (действительно, на одном сайте может находиться несколько посетителей). Также стоит заметить, что количество клиентов, которые могут одновременно взаимодействовать с сервером зависит от мощности сервера и от того, что хочет получить клиент от сервера.

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

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

Давайте теперь ответим на вопрос: «зачем веб-мастеру или веб-разработчику понимать концепцию взаимодействия клиент-сервер?».  Ответ, естественно, очевиден. Чтобы что-то делать своими руками нужно понимать, как это работает. Чтобы сделать сайт и, чтобы он правильно работал в сети Интернет или хотя бы просто работал, нам нужно понимать, как работает сеть Интернет.

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

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

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

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

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

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

При этом взаимодействие всегда начинает клиент, а правила, по которым происходит взаимодействие описывает протокол.

Существует два вида архитектуры взаимодействия клиент-сервер: первый получил название двухзвенная архитектура клиент-серверного взаимодействия, второй – многоуровневая архитектура клиент-сервер (иногда его называют трехуровневая архитектура или трехзвенная архитектура, но это частный случай).

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

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

Здесь четко видно, что есть клиент (1-ый уровень), который позволяет человеку сделать запрос, и есть сервер, который обрабатывает запрос клиента.

Если говорить про многоуровневую архитектуру взаимодействия клиент-сервер, то в качестве примера можно привести любую современную СУБД (за исключением, наверное, библиотеки SQLite, которая в принципе не использует концепцию клиент-сервер).

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

На рисунке ниже вы можете увидеть пример многоуровневой архитектуры клиент-сервер.

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

Типичный пример трехуровневой модели клиент-сервер.

Если говорить в контексте систем управления базами данных, то первый уровень – это клиент, который позволяет нам писать различные SQL запросы к базе данных.

Второй уровень – это движок СУБД, который интерпретирует запросы и реализует взаимодействие между клиентом и файловой системой, а третий уровень – это хранилище данных.

Если мы посмотрим на данную архитектуру с позиции сайта. То первый уровень можно считать браузером, с помощью которого посетитель заходит на сайт, второй уровень – это связка Apache + PHP, а третий уровень – это база данных. Если уж говорить совсем просто, то PHP больше ничего и не делает, кроме как, гоняет строки и базы данных на экран и обратно в базу данных.

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

Преимуществом модели взаимодействия клиент-сервер является то, что программный код клиентского приложения и серверного разделен.

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

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

Если в локальной сети ложится сервер, то и клиенты не смогут работать (в качестве частного случая можно привести пример: мощности сервера не всегда хватает, чтобы удовлетворит запросы клиентов, если вы хоть раз работали с биллинговыми системами, то понимаете о чем я: время ожидания ответа от сервера может быть очень большим).

Источник: https://zametkinapolyah.ru/servera-i-protokoly/o-modeli-vzaimodejstviya-klient-server-prostymi-slovami-arxitektura-klient-server-s-primerami.html

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

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

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

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

в несколько раз уменьшает объем информации, передаваемый по сети.

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

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

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

<

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

1.2. История…

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

До этого не было ясного разделения — программа обычно всё делала сама — в том числе работала с данными в файловой системе, представлением данных пользователю и др. Со временем рос объем и критичность данных для бизнеса, и это со временем начало породить проблемы (быстродействия, безопасности и другие).

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

По существу «взрыв» популярности технологии «клиент-сервер» был вызван изобретением фирмой IBM простого языка запросов к реляционным базам данных SQL. Сегодня SQL всеобщий стандарт работы с базами данных. В последнее время этот «взрыв» продолжает изобретение Интернета, в котором буквально каждое взаимодействие происходит по архитектуре «клиент-сервер».

1.3. Протоколы

Сервер и клиент в сети между собой «разговаривает» на «языке» (в широком смысле слов), понятном обеим сторонам. Этот «язык» называют протоколом.

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

В нашем же случае, примеры протоколов:

FTP (File Transfer Protocol)

HTTP (Hyper Text Transfer Protocol)

SMTP (Simple Mail Transfer Protocol)

MySQL Client/Server Protocol

Заметим, что протоколы может быть разных уровней. Классификационные системы уровней может быть разные, но одна из самых известных линеек — OSI (Open Systems Interconnection ), в котором 7 уровней.

Например, HTTP — протокол прикладного (седьмого — самого высокого) уровня, а IP — протокол сетевого (третьего) уровня.

1.4. Распределение функций в архитектуре «клиент-сервер»

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

Обычно ПО хранения данных располагается на сервере (например, сервере базы данных), интерфейс с пользователем — на стороне клиента, а вот обработку данных приходится распределять между клиентской и серверной частями.

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

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

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

Читайте также:  Первая пуническая война 264-241 гг. до н.э. - студенческий портал

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

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

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

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

Такое решение имеет очевидные преимущества, например его легче поддерживать, т. к. все изменения нужно вносить только в одном месте — на сервере.

• рассмотренные выше модели имеют следующие недостатки.
• 1. «Толстый» клиент:
• – сложность администрирования;
• – усложняется обновление ПО, поскольку его замену нужно производить одновременно по всей системе;
• – усложняется распределение полномочий, так как разграничение доступа происходит не по действиям, а по таблицам;
• – перегружается сеть вследствие передачи по ней необработанных данных;
• – слабая защита данных, поскольку сложно правильно распределить полномочия.
• 2. «Толстый» сервер:
• – усложняется реализация, так как языки типа PL/SQL не приспособлены для разработки подобного ПО и нет хороших средств отладки;
• – производительность программ, написанных на языках типа PL/SQL, значительно ниже, чем созданных на других языках, что имеет важное значение для сложных систем;
• – программы, написанные на СУБД-языках, обычно работают недостаточно надежно; ошибка в них может привести к выходу из строя всего сервера баз данных;
• – получившиеся таким образом программы полностью непереносимы на другие системы и платформы.

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

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

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

Рис. 1. Распределение функций между клиентом и сервером

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

Источник: http://bukvi.ru/computer/osnovnye-ponyatiya-arxitektury-klient-server.html

GOUSPO студенческий портал! » Системы «клиент — сервер»

admin

1. Системы клиент – сервер.

• По мере развития представлений о распреде­ленных вычислительных процессах и процессах обработки дан­ных складывается концепция архитектуры «клиент — сервер» обобщенное представление о взаимодействии двух компонент информационной технологии (технического и/или программного обеспечения) в вычислительных системах и сетях, среди кото­рых логически или физически могут быть выделены:
• —        активная сторона (источник запросов, клиент);
• —        пассивная сторона (сервер, обслуживание запросов, источ­ник ответов).

В табл. приведены примеры реализации данного принципа.

Архитектура «клиент — сервер» (примеры)

Система	Клиент	Сервер
Вычислительная сеть	Терминал	Хост-машина
Локальная сеть (технология FS -файл-сервер)	Компьютер пользователя	Файловый сервер
Телекоммуникационные программы	Эмуляция терминала	Эмуляция хоста (BBS)
Norton Commander Link	Master-ПК	Slave-ПК
Операционная система Unix	Программа/системный вы­зов/ядро	Ядро/драйвер/устройство
RP	Программа RP	Программа-демон (рези­дентный драйвер) FTPD
Telnet	Программа Telnet	Программа Telnetd
Система информационного поискаWAIS	WinWAIS	Серверы WAIS
Электронная почта	mail, elm, Eudora, bml	Почтовые серверы
WWW-технологии	Web-браузеры NCSA Mosaic, Arena	Web-серверы: NCSA HTTPD, WinHTTPD, Rally, Apachie

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

Обычно клиент и сервер работают в рамках единого прото­кола (рис. а) — Telnet, FTP, Gopher, HTTP и пр., однако в связи с недостаточностью такого подхода появляются мульти­протокольные клиенты и серверы (рис.

 б), например — брау­зер Netscape Navigator. Наконец, появляются серверные прило­жения (брокеры, роботы), которые устанавливаются между разнопротокольными компонентами (рис.

 в) и осуществляют трансформацию протоколов.

2. Разновидности функциональных структур клиент – сервер.

Компьютер (процесс), управляющий тем или иным ресур­сом, является сервером этого ресурса, а компьютер, пользующий­ся им, —клиентом.

Каждый конкретный сервер определяется видом того ресур­са, которым он владеет. Например, назначением сервера баз данных является обслуживание запросов клиентов, связанных с обработкой данных; файловый сервер, или файл-сервер, распоря­жается файловой системой и т. д.

Этот принцип распространяется и на взаимодействие про­грамм.

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

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

Первая группа. Это функции ввода и отображения данных.

Вторая группа объединяет чисто прикладные функции, характерные для данной предметной области (например, для банковской системы — открытие счета, перевод денег с одного счета на другой и т. д.).

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

1. Четвертая группа — служебные функции, осуществляющие связь между функциями первых трех групп.
2. В соответствии с этим в любом приложении выделяются следующие логические компоненты:
3. •   компонент представления (presentation), реализующий функ­ции первой группы;
4. •  прикладной компонент (business application), поддерживаю­щий функции второй группы;
5. •  компонент доступа к информационным ресурсам (resource manager), поддерживающий функции третьей группы, а так­же вводятся и уточняются соглашения о способах их взаи­модействия (протокол взаимодействия).
6. Различия в реализации технологии «клиент — сервер» определяются следующими факторами:
7. •  виды программного обеспечения, в которые интегрирован каждый из этих компонентов;
8. •  механизмы программного обеспечения, используемые для реализации функций всех трех групп;
9. •  способы  распределения  логических  компонентов  между компьютерами в сети;
10. •  механизмы, используемые для связи компонентов между собой.
11. Выделяются четыре подхода, реализованные в следующих технологиях:
12. •  файловый сервер (File Server — FS);
13. •  доступ к удаленным данным (Remote Data Access — RDA);
14. •  сервер баз данных (Data Base Server — DBS);
15. •  сервер приложений (Application Server — AS).
16. 3. Файловый сервер (FS)

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

Файловый сервер работает под управлением сетевой операцион­ной системы и играет роль компонента доступа к информацион­ным ресурсам (т. е. к файлам). На других ПК в сети функциони­рует приложение, в кодах которого совмещены компонент пред­ставления и прикладной компонент (рис).

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

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

4. Доступ к удаленным данным

Доступ к удаленным данным (RDA) существенно отличается от FS методом доступа к информационным ресурсам. В данной технологии программы компонента представления и прикладного компонента совмещены и выполняются на компьютере клиенте.

Доступ к информационным ресурсам обеспечивается оператора­ми специального языка (например, языка запросов SQL, если речь идет о базах данных) или вызовами функций специальной библиотеки (если имеется специальный интерфейс прикладного программирования —API).

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

К недостаткам можно отнести существенную загрузку сети при взаимодействии клиента и сер­вера посредством запросов; невозможность администрирования приложений в RDA, так как в одной программе совмещаются различные по своей природе функции (представления и при­кладные).

• Технологии RDA и DBS опираются на двухзвенную схему разделения функций:
• •  в RDA прикладные функции отданы программе-клиенту (прикладной  компонент  комбинируется  с  компонентом представления);
• •  в DBS ответственность за их выполнение берет на себя ядро СУБД (прикладной компонент интегрируется в ком­понент, доступа к информационным ресурсам).

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

Источник: http://gouspo.ru/?p=242

Модели архитектуры "клиент-сервер"

Клиент (Client) – программа, обеспечивающая пользователю доступ к ресурсам на удаленном компьютере, являющемся сервером.

«Толстый» клиент – это наиболее часто встречающийся вариант реализации архитектуры «клиент-сервер» в уже внедренных и активно используемых системах.

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

К описанной модели часто применяют аббревиатуру RDA – Remote Data Access.

«Тонкий» клиент (thin client) – это компьютер-клиент сети с архитектурой «клиент-сервер», который переносит большинство задач по обработке информации на сервер.

Эта модель активно используется в корпоративной среде в связи с распространением интернет-технологий и в первую очередь веб-браузеров.

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

Двухзвенная модель (two-tier model) – это система «клиент-сервер», в которую входят компьютеры клиента и сервера. Клиент запрашивает данные у сервера, а сервер предоставляет данные. Большинство систем «клиент-сервер» построены с использованием этой модели, но двухзвенные модели способны обеспечить работу лишь ограниченного числа клиентов.

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

Многозвенная модель (three-tier model) – это система «клиент-сервер», в которой промежуточное звено (компьютер) помещается между компьютером-клиентом и компьютером-сервером двухзвенной модели.

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

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

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

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

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

Существуют два основных способа передачи данных при пакетной коммутации: виртуальный канал, когда между узлами устанавливается и поддерживается соединение как бы по выделенному каналу (хотя на самом деле физический канал передачи данных разделен между несколькими пользователями) и дейтаграммный режим, когда каждый пакет из набора пакетов, содержащего данные пользователя, передается между узлами независимо друг от друга. Первый способ соединения называют также контактным режимом (connection mode), второй – бесконтактным (connectionless mode).

Источник: https://studme.org/97411/informatika/modeli_arhitektury_klient-server

Модели архитектуры клиент-сервер

Рассмотрим четыре подхода, реализованные в моделях технологии «клиент-сервер».

1) FS-модель

Базовая для локальных сетей персональных компьютеров. Применялась для разработки информационных систем на базе FoxPRO, Clipper, Paradox.

• Основные свойства:
• — выделяется файл-сервер для реализации услуг по обработке файлов других узлов сети; работает под управлением сетевых ОС;
• — играет роль компонент доступа к информационным ресурсам;
• — в остальных узлах функционирует приложение, в кодах которого совмещены компоненты представления и прикладной;
• — протокол обмена — набор низкоуровневых вызовов.

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

1. Недостатки: высокий сетевой трафик; небольшое число операций манипулирования; недостаточные требования к безопасности.
2. 2) RDA-модель
3. Основные свойства:
4. -коды компонента представления и прикладного компонента совмещены и выполняются на компьютере-клиенте;
5. -доступ к информационным ресурсам обеспечивается операторами непроцедурного языка SQL.
6. Технология:
7. клиентский запрос направляется на сервер, где функционирующее ядро СУБД обрабатывает запрос и возвращает результат (блок данных) клиенту. Ядро СУБД выполняет пассивную роль;
8. инициатор манипуляций с данными — программы на компьютере-клиенте.
9. Достоинства:
10. -процессор сервера загружается операциями обработки данных;

-уменьшается загрузка сети, т.к. по сети передаются запросы на языке SQL;

• -унификация интерфейса «клиент-сервер» в виде языка SQL; использование его в качестве стандарта общения клиента и сервера.
• Недостатки:
• удовлетворительное администрирование приложений в RDA-модели невозможно из-за совмещения в одной программе различных по своей природе функций (представления и прикладных).
• 3) DBS-модель
• Реализована в реляционных СУБД Informix, Ingres, Oracle.
• Основные свойства:
• -основа модель-механизм хранимых процедур — средство программирования SQL-сервера;
• -процедуры хранятся в словаре базы данных, разделяются между несколькими клиентами и выполняются на компьютере, где функционирует SQL-сервер;
• -компонент представления выполняется на компьютере-клиенте;
• -прикладной компонент и ядро СУБД на компьютере-сервере базы данных.
• Достоинства:
• -возможность централизованного администрирования;
• -вместо SQL-запросов по сети передаются вызовы хранимых процедур, что ведет к снижению сетевого трафика.
• Недостатки:
• -в большинстве СУБД недостаточно возможностей для отладки и типизирования хранимых процедур;
• ограниченность средств для написания хранимых процедур.
• На практике чаще используется разумный синтез RDA- и DBS-моделей для построения многопользовательских информационных систем.
• 4) AS-модель
• Основные свойства:
• -на компьютере-клиенте выполняется процесс, отвечающий за интерфейс с пользователем;
• -этот процесс, обращаясь за выполнением услуг к прикладному компоненту, играет роль клиента приложения (АС);
• -прикладной компонент реализован как группа процессов, выполняющих прикладные функции, и называется сервером приложения (AS);
• -все операции над БД выполняются соответствующим компонентом, для которого AS — клиент.

RDA- и DBS-модели имеют в основе двухзвенную схему разделения функций. В RDA-модели прикладные функции отданы клиенту, в DBS-модели их реализация осуществляется через ядро СУБД. В RDA-модели прикладной компонент сливается с компонентом представления, в DBS-модели интегрируется в компонент доступа к ресурсам.

1. В AS-модели реализована трехзвенная схема разделения функций, где прикладной компонент выделен как важнейший изолированный элемент приложения, имеющий стандартизированные интерфейсы с двумя другими компонентами.
2. AS-модель является фундаментом для мониторов обработки транзакций.
3. Язык запросов — это искусственный язык, на котором делаются запросы к базам данных и другим информационным системам, особенно к информационно-поисковым системам.
4. SQL — де-факто стандартный язык запросов к реляционным базам данных.

Language Integrated Query — расширение для некоторых языков программирования в .NET Framework, добавляющее к ним SQL-подобный язык запросов.

XQuery — язык запросов, разработанный для обработки данных в формате XML.

XPath — язык запросов к элементам XML-документа.

Источник: https://neudov.net/4students/otvety-po-pive/modeli-arxitektury-klient-server/

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

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

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

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

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

Распределенные системы и приложения

Распределенная система представляет из себя группу компьютеров, которую пользователи видят как единую объединенную систему.

Выделяют 2 аспекта распределенной системы:

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

Распределенные приложения в сети Интернет, как правило, имеют в своей основе модель типа клиент-сервер – в этой модели приложения структурируют, разделяя их на серверные процессы, предоставляющие специализированные службы для клиентских процессов, при этом серверные процессы могут работать с одним или несколькими клиентами:

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

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

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

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

Взаимодействие клиента и сервера в сети Интернет осуществляется при помощи запросов, которые клиент посылает серверу, и ответов, которые сервер отсылает на запрос клиента.

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

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

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

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

Как правило, программа обработки данных (клиентская часть) располагается на одном ПК, а сама БД — на другом.

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

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

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

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

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

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

Источник: https://servicemobil.ru/voprosi-otveti/client-server.html