Архитектуры клиент сервер функции сервера. Грамотная клиент-серверная архитектура: как правильно проектировать и разрабатывать web API

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

Основной принцип технологии "клиент-сервер" заключается в разделении функций приложения на три группы:

· ввод и отображение данных (взаимодействие с пользователем);

· прикладные функции, характерные для данной предметной области;

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

Поэтому, в любом приложении выделяются следующие компоненты:

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

· прикладной компонент

· компонент управления ресурсом

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

5.1.2. Модели взаимодействия клиент-сервер

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

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

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

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

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

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

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

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

Сейчас ряд поставщиков коммерческих СУБД объявило о планах реализации механизмов выполнения хранимых процедур с использованием языка Java. Это соответствует концепции "тонкого клиента", функцией которого остается только отображение данных (модель удаленного представления данных).

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

5.1.3. Мониторы транзакций

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

Для общения прикладной программы с монитором транзакций используется специализированный API (Application Program Interface - интерфейс прикладного программирования), который реализуется в виде библиотеки, содержащей вызовы основных функций (установить соединение, вызвать определенный сервис и т.д.). Серверы приложений (сервисы) также создаются с помощью этого API, каждому сервису присваивается уникальное имя. Монитор транзакций, получив запрос от прикладной программы, передает ее вызов соответствующему сервису (если тот не запущен, порождается необходимый процесс), после обработки запроса сервером приложений возвращает результаты клиенту. Для взаимодействия мониторов транзакций с серверами баз данных разработан протокол XA. Наличие такого унифицированного интерфейса позволяет использовать в рамках одного приложения несколько различных СУБД.

Использование мониторов транзакций в больших системах дает следующие преимущества:

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

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

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

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

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

5.2. Обработка распределенных данных

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

Существуют два подхода к организации обработки распределенных данных.

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

2. Технология тиражирования. В этом случае в каждом узле сети дублируются данные всех компьютеров. При этом:

· передаются только операции изменения данных, а не сами данные

· передача может быть асинхронной (неодновременной для разных узлов)

· данные располагаются там, где обрабатываются

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

Архитектура терминал – главный компьютер

Архитектура терминал – главный компьютер (terminal – host computer architecture) – это концепция информационной сети, в которой вся обработка данных осуществляется одним или группой главных компьютеров.

Рис. 7.1. Архитектура терминал – главный компьютер

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

Одноранговая архитектура

Одноранговая архитектура (peer-to-peer architecture) – это концепция информационной сети, в которой ее ресурсы рассредоточены по всем системам. Данная архитектура характеризуется тем, что в ней все системы равноправны.

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

Рис. 7.2. Одноранговая архитектура

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

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

Архитектура клиент – сервер (client-server architecture) – это концепция информационной сети, в которой основная часть ее ресурсов сосредоточена в серверах, обслуживающих своих клиентов (рис. 7.3.). Рассматриваемая архитектура определяет два типа компонентов: серверы и клиенты.

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

Рис. 7.3. Архитектура клиент – сервер

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

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

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

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

Существуют три основных топологии: общая шина (Bus); кольцо (Ring) и звезда (Star).

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

Рис. 7.4. Топология Общая шина

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

Кольцо – это топология ЛВС, в которой каждая станция соединена с двумя другими станциями, образуя кольцо (рис. 7.5.). Данные передаются от одной рабочей станции к другой в одном направлении (по кольцу). Каждый ПК работает как повторитель, ретранслируя сообщения к следующему ПК, т.е. данные, передаются от одного компьютера к другому как бы по эстафете. Если компьютер получает данные, предназначенные для другого компьютера, он передает их дальше по кольцу, в ином случае они дальше не передаются. Очень просто делается запрос на все станции одновременно. Основная проблема при кольцевой топологии заключается в том, что каждая рабочая станция должна активно участвовать в пересылке информации, и в случае выхода из строя хотя бы одной из них, вся сеть парализуется.

Рис. 7.5. Топология Кольцо

Звезда – это топология ЛВС (рис. 7.6.), в которой все рабочие станции присоединены к центральному узлу (например, к концентратору), который устанавливает, поддерживает и разрывает связи между рабочими станциями.

Рис. 7.6. Топология Звезда

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

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

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

Протоколы. Адресация

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

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

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

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

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

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

Согласованный набор протоколов разных уровней, достаточный для организации межсетевого взаимодействия, называется стеком протоколов. Существует достаточно много стеков протоколов, широко применяемых в сетях. Это и стеки, являющиеся международными и национальными стандартами, и фирменные стеки, получившие распространение благодаря распространенности оборудования той или иной фирмы. Примерами популярных стеков протоколов могут служить стек IPX/SPX фирмы Novell, стек TCP/IP, используемый в сети Internet и во многих сетях на основе операционной системы UNIX, стек OSI международной организации по стандартизации, стек DECnet корпорации Digital Equipment и некоторые другие.

Стеки протоколов разбиваются на три уровня:

– сетевые;

– транспортные;

– прикладные.

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

– DDP (Datagram Delivery Protocol – Протокол доставки дейтаграмм). Протокол передачи данных Apple, используемый в Apple Talk.

– IP (InternetProtocol – ПротоколInternet). Протокол стека TCP/IP, обеспечивающий адресную информацию и информацию о маршрутизации.

– IPX (Internetwork Packet eXchange – Межсетевой обмен пакетами) в NWLink. Протокол Novel NetWare, используемый для маршрутизации и направления пакетов.

– NetBEUI (NetBIOS Extended User Interface – расширенный пользовательский интерфейс базовой сетевой системы ввода вывода). Разработанный совместно IBM и Microsoft, этот протокол обеспечивает транспортные услуги для NetBIOS .

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

– ATP (Apple Talk Protocol – Транзакционный протокол Apple Talk) и NBP (Name Binding Protocol – Протокол связывания имен). Сеансовый и транспортный протоколы Apple Talk.

– NetBIOS (Базовая сетевая система ввода вывода). NetBIOS Устанавливает соединение между компьютерами, а NetBEUI предоставляет услуги передачи данных для этого соединения.

– SPX (Sequenced Packet eXchange – Последовательный обмен пакетами) в NWLink. Протокол Novel NetWare, используемый для обеспечения доставки данных.

– TCP (Transmission Control Protocol – Протокол управления передачей). Протокол стека TCP/IP, отвечающий за надежную доставку данных.

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

– AFP (Apple Talk File Protocol – Файловыйпротокол Apple Talk). ПротоколудаленногоуправленияфайламиMacintosh.

– FTP (FileTransferProtocol – Протоколпередачифайлов). Протокол стека TCP/IP, используемый для обеспечения услуг по передачи файлов.

– NCP (NetWare Core Protocol – Базовыйпротокол NetWare). Оболочка и редиректоры клиента Novel NetWare.

– SNMP (Simple Network Management Protocol – Простой протокол управления сетью). Протокол стека TCP/IP, используемый для управления и наблюдения за сетевыми устройствами.

– HTTP (Hyper Text Transfer Protocol) – протокол передачи гипертекста.

Наиболее распространенным стеком протоколов в операционных системах семейства Windows является TCP/IP.

Рассмотрим подробнее принципы адресации компьютеров, работающих через протокол TCP/IP.

Каждый компьютер в сетях TCP/IP имеет адреса трех уровней: физический (MAC-адрес), сетевой (IP-адрес) и символьный (DNS-имя).

Физический , или локальный адрес узла, определяется технологией, с помощью которой построена сеть, в которую входит узел. Для узлов, входящих в локальные сети - это МАС–адрес сетевого адаптера или порта маршрутизатора, например, 11-А0-17-3D-BC-01. Эти адреса назначаются производителями оборудования и являются уникальными адресами, так как управляются централизовано. Для всех существующих технологий локальных сетей МАС – адрес имеет формат 6 байтов: старшие 3 байта - идентификатор фирмы производителя, а младшие 3 байта назначаются уникальным образом самим производителем.

Сетевой , или IP-адрес, состоящий из 4 байт, например, 109.26.17.100. Этот адрес используется на сетевом уровне. Он назначается администратором во время конфигурирования компьютеров и маршрутизаторов. IP-адрес состоит из двух частей: номера сети и номера узла. Номер сети может быть выбран администратором произвольно, либо назначен по рекомендации специального подразделения Internet (Network Information Center, NIC), если сеть должна работать как составная часть Internet. Обычно провайдеры услуг Internet получают диапазоны адресов у подразделений NIC, а затем распределяют их между своими абонентами. Номер узла в протоколе IP назначается независимо от локального адреса узла. Деление IP-адреса на поле номера сети и номера узла - гибкое, и граница между этими полями может устанавливаться произвольно. Узел может входить в несколько IP-сетей. В этом случае узел должен иметь несколько IP-адресов, по числу сетевых связей. IP-адрес характеризует не отдельный компьютер или маршрутизатор, а одно сетевое соединение.

Символьный адрес, или DNS-имя , например, SERV1.IBM.COM. Этот адрес назначается администратором и состоит из нескольких частей, например, имени машины, имени организации, имени домена. Такой адрес используется на прикладном уровне, например, в протоколах FTP или telnet.

Компоненты ЛВС. Сетевое оборудование и среды передачи данных

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

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

1. Абонентские системы:

Компьютеры (рабочие станции или клиенты и серверы);

Принтеры;

Сканеры и др.

2. Сетевое оборудование:

Сетевые адаптеры;

Концентраторы (хабы);

Маршрутизаторы и др.

3. Коммуникационные каналы:

Разъемы;

Устройства передачи и приема данных в беспроводных технологиях.

Сетевые адаптеры. Для подключения ПК к сети требуется устройство сопряжения, которое называют сетевым адаптером, интерфейсом, модулем, или картой (рис. 7.7.). В сетевом адаптере имеется один разъем для подключения сетевого кабеля.

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

Рис. 7.7. Сетевой адаптер

К адаптеру подключается сетевой кабель – провод, по которому осуществляется передача информации по локальной сети. В качестве среды передачи данных в ЛВС используются различные виды кабелей: коаксиальный кабель, кабель на основе экранированной и неэкранированной витой пары и оптоволоконный кабель. Наиболее популярным видом среды передачи данных на небольшие расстояния (до 100 м) становится неэкранированная витая пара (рис. 7.8.), которая включена практически во все современные стандарты и технологии локальных сетей и обеспечивает пропускную способность до 100 Мб/с (на кабелях категории 5). Оптоволоконный кабель широко применяется как для построения локальных связей, так и для образования магистралей глобальных сетей. Оптоволоконный кабель может обеспечить очень высокую пропускную способность канала (до нескольких Гб/с) и передачу на значительные расстояния (до нескольких десятков километров без промежуточного усиления сигнала).

Рис. 7.8. Сетевой кабель типа «Витая пара»

Кабель типа «витая пара» соединяется с сетевым адаптером и другими сетевыми устройствами посредством разъема RJ-45 (рис. 7.9.)

Рис. 7.9. Разъем RJ-45

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

В основе качестве сетевого оборудования ЛВС используется 3 типа устройств для связи компьютеров - концентраторы , коммутаторы и маршрутизаторы . Каждый из них важен и исполняет различные роли в упрощении коммуникации между сетевыми компьютерами. Снаружи эти устройства могут выглядеть одинаковыми: маленькие, металлические коробочки с множеством соединителей или портов, куда подсоединяются кабели ethernet (рис. 7.10.). Термины «концентратор», «коммутатор» и «маршрутизатор» часто используются взаимозаменяемо, но неправильно – на самом деле, устройства отличаются друг от друга.

Рис. 7.10. Сетевой коммутатор

Сетевой концентратор. По сравнению с коммутаторами и маршрутизаторами, концентраторы – самые дешёвые, самые простые устройства в сети. Все данные, которые поступают в один порт концентратора, отсылаются на все другие порты. Следовательно, все компьютеры, подсоединённые к одному концентратору, «видят» в сети друг друга. Концентратор не обращает никакого внимания на передаваемые данные, он просто посылает их на другие порты. Значение концентратора в том, что он довольно дешёвый и предлагает быстрый и простой способ объединить компьютеры в маленькую сеть.

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

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

Порядок выполнения работы

Настройка сетевого подключения в ОС Windows XP

В случае, если. Входящие в состав компьютера сетевой адаптер и драйвера установлены корректно, то подключение по локальной сети появится в системе автоматически. Задача состоит в настройке этого подключения. Для отображения полного списка сетевых подключений выберите раздел:Пуск →Настройка →Панель управления (рис. 7.11.)

Рис. 7.11. Диалоговое окно «Панель управления»

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

Рис. 7.12. Диалоговое окно «Сетевые подключения»

Нажав правой кнопкой мыши, выберите в контекстном меню пункт Свойства .Воткрывшемся диалоговом окне (рис. 13), по умолчанию, установлены следующие компоненты:

– Клиент для сетей Microsoft;

– Служба доступа к файлам и принтерам сетей Microsoft;

– Планировщик пакетов QoS;

– Протокол Интернета TCP/IP.

Рис. 7.13. Диалоговое окно «Подключение по локальной сети - свойства»

Выберите компонент Протокол Интернета TCP/IP и нажмите на кнопку Свойства в диалоговом окне. В новом открывшемся диалоговом окне (рисунок 14) настройте IP-адрес компьютера, маску подсети, шлюз и сервера DNS.

Рис. 7.14. Диалоговое окно «Свойства: протокол Интернета (TCP/IP)»

В случае, если ваш компьютер подключен к многоранговой сети, в которой функционирует выделенный сервер, на этом сервере может быть настроен протокол DHCP (Dynamic Host Configuration Protocol - протокол динамической конфигурации узла). Это сетевой протокол, позволяющий клиентским компьютерам автоматически получать IP-адрес и другие параметры, необходимые для работы в сети TCP/IP. Если протокол DHCP на сервере вашей сети активирован, то вся настройка сетевого подключения сводится к выбору пункта «Получить IP-адрес автоматически». В противном случае настройку адреса придется проводить вручную.

Для каждого из компьютеров сети необходимо выбрать свой IP-адрес, причем так, чтобы эти адреса находились в одной логической IP-сети. IP-адрес состоит из двух частей: номера сети и номера узла. В случае изолированной сети её адрес может быть выбран администратором из специально зарезервированных для таких сетей блоков адресов (192.168.0.0÷16, 172.16.0.0÷12 или 10.0.0.0÷8). Если же сеть должна работать как составная часть Интернета, то адрес сети выдаётся провайдером. IP-адрес не может начинаться с числа 127, так как адреса в диапазоне 127.х.х.х зарезервированы для обозначения так называемого «локального хоста». Обращение по адресу 127.0.0.1 приводит к активированию так называемой «внутренней петли», образующей сеть из одного компьютера, что используется для самодиагностики сетевых протоколов.

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

DNS сервер – компьютер, обрабатывающий DNS-запросы - осуществляющий преобразование IP-адресов (например 192.168.0.4) в адреса доменного имени (например www.google.com). В случае многоранговой сети адрес DNS-сервера либо совпадает с адресом шлюза, либо выдается провайдером Интернет. В случае одноранговой сети адрес DNS-сервера оставляют пустым.

После определения всех необходимых настроек, нажмите кнопку «ОК». В случае, если выбранный вами IP-адрес уже используется в сети, то вскоре после нажатия на кнопку «ОК» операционная система выдаст соответствующее предупреждение.

Для завершения настройки сети выберите сетевое имя компьютера и рабочую группу (домен). Для этого: на рабочем столе (или в меню «Пуск») найдите значок «Мой компьютер», нажмите на нем правой кнопкой мыши, выберите пункт «Свойства», а в открывшемся окне перейдите на вкладку «Имя компьютера» (рис. 7.15). В поле «Описание» внесите произвольный текст для опознания вашего компьютера пользователями сети. Нажатие на кнопку «Изменить» открывает диалоговое окно (рис. 16), позволяющее дать вашему компьютеру сетевое имя и присоединить его к определенной рабочей группе или домену.

Рис. 7.15. Диалоговое окно «Свойства системы: Имя компьютера»

Рис. 7.16. Диалоговое окно «Изменение имени компьютера»

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

Для запуска командной строки нажмите в главном меню Windows на кнопку Пуск → Выполнить , а в открывшемся диалоговом окне наберите “cmd”. Общий вид окна командной строки представлен на рис.7.17.

Рис. 7.17. Окно командной строки Windows

Для получения информации о настройках протокола TCP/IP используется команда «ipconfig» (рис.7.18.). Команда выдает информацию о базовых настройках всех сетевых подключений, настроенных на компьютере. Более полная информация, включающая названия и физические адреса (MAC-адреса) сетевых адаптеров, сетевое имя компьютера и др. может быть получена при использовании команды «ipconfig» с ключом «-all».

Рис. 7.18. Результат выполнения команды ipconfig

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

Рис. 7.19. Результат выполнения команды ping

Общее использование ресурсов в Windows XP

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

Для обзора компьютеров, находящихся в локальной сети, найдите на рабочем столе или в основном меню значок «Сетевое окружение» и дважды щелкните на нем левой кнопкой мыши. В открывшемся окне выбирайте: Вся сеть → Microsoft Windows Network .

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

Рис. 7.20. Список рабочих групп локальной сети

Рис. 7.21. Список рабочих станций рабочей группы

Рис. 7.22. Список общих ресурсов рабочей станции

Альтернативным способом получения доступа к папке на удаленном компьютере является подключение сетевого диска . В этом случае папка общего доступа будет добавлена в систему в качестве логического диска (как, например, диски «С», «D»).Для подключения сетевого диска в окне любой открытой папки Windows выберите в главном меню Сервис → Подключить сетевой диск . Откроется диалоговое окно, представленное на рис.7.23.

Рис. 7.23. Подключение сетевого диска

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

Рис. 7.24. Диалоговое окно «Мой компьютер» с подключенными сетевыми дисками

Для того, чтобы произвести отключение ранее подключенного сетевого диска, в окне любой открытой папки Windows выберите в главном меню Сервис → Отключить сетевой диск , выберите желаемый диск и нажмите ОК .

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

Процесс установки драйвера для сетевого принтера: нажмите . В открывшемся диалоговом окне выберите пункт Установка принтера , после чего запустится Мастер установки принтеров . В первом диалоговом окне мастера нажмите Далее . Во втором диалоговом окне мастера выберите пункт Сетевой принтер или принтер, подключенный к другому компьютеру и также нажмите Далее . Откроется диалоговое окно, представленное на рис.7.25.

Рис. 7.25. Мастер установки принтеров

Если вы не знаете доменного имени или IP-адреса компьютера, к которому подключен интересующий вас принтер, выберите пункт Обзор принтеров и нажмите Далее , после чего система произведет поиск доступных принтеров в локальной сети. В зависимости от размера локальной сети, этот процесс может быть достаточно долгим. Чтобы ускорить его, выберите пункт «Подключиться к принтеру или выполнить обзор принтеров» и в поле ввода «имя» введите доменное имя или IP-адрес компьютера, к которому подключен сетевой принтер, в следующей форме: «\\host\» («\\ххх.ххх.ххх.ххх\»). В этом случае поиск принтеров будет производиться только на указанном вами компьютере и займет значительно меньше времени. После того, как сетевой принтер будет обнаружен, произведите установку его драйверов в систему нажатием на кнопку Установить .

Созданиепапки открытой для общего доступа .

В диалоговом окне Мой компьютер или Проводник найдите интересующую вас папку, нажмите на ней правой кнопкой мыши и в появившемся контекстном меню выберите пункт Свойства . В открывшемся диалоговом окне (рис. 7.26.) перейдите на вкладку Доступ .

Рис. 7.26. Вкладка «Доступ» диалогового окна «Свойства папки»

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

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

Чтобы разрешить пользователям сети пользоваться принтером, установленным на вашем компьютере, запустите Пуск → Настройка → Принтеры и факсы . Нажмите правой кнопкой мыши на интересующем вас принтере, в контекстном меню выберите пункт Свойства . В открывшемся диалоговом окне перейдите на вкладку Доступ (рис. 7.27.). Доступ к принтеру можно открыть аналогично доступу к папке - установив флажок напротив пункта Общий доступ к данному принтеру и выбрав его сетевое имя.

Рис. 7.27. Вкладка «Доступ» диалогового окна «Свойства принтера»

Контрольные вопросы

1. Что такое компьютерная сеть?

2. Назовите основные сетевые топологии. Какая из них наиболее надежная и почему?

3. В чем заключается функция сервера? Расскажите о технологии клиент-сервер.

4. Перечислите основные аппаратные сетевые компоненты и их назначение.

5. Что такое сетевой протокол? Расскажите о протоколе TCP/IP.

6. Как узнать основные сетевые настройки вашего компьютера?

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

8. Как установить в системе сетевой принтер?

9. Как предоставить общий доступ к папке, находящейся на вашем компьютере?

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

Задания

1. Определите IP-адрес вашего компьютера, его сетевое имя и рабочую группу, в которую он входит.

2. Создайте на локальном компьютере новую папку. Откройте общий доступ к созданной папке.

3. Создайте в папке текстовый файл, в который поместите ответы на задание 1, а также на индивидуальный вопрос вашего варианта.

4. Составьте список папок, открытых для общего доступа на сервере кафедры.

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

6. Установите в системе сетевой принтер, подключенный к серверу кафедры.

7. Разрешите сетевым пользователям изменение файлов, содержащихся в папке, созданной в задании 2.

8. Скопируйте в папку, созданную в задании 2, текстовый файл, созданный другим студентом вашей группы с ответом на вопросы его варианта. Нужный файл найдите на компьютере этого студента.

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

Индивидуальные вопросы

Вариант 1: Определите архитектуру локальной сети кафедры.

Вариант 2: Определите топологию локальной сети кафедры.

Вариант 3: Определите MAC-адрес сетевого адаптера вашего компьютера.

Вариант 4: Определите среднее время отклика сервера кафедры

Вариант 5: Определите, является ли IP-адрес 127.168.0.1 допустимым в локальной сети.

Вариант 6: Определите, является ли IP-адрес 168.127.1.0 допустимым в локальной сети.

Вариант 7: Определите тип сетевого кабеля, использованный для построения локальной сети в вашей аудитории.

Вариант 8: Определите, функционирует ли в сети кафедры DHCP-сервер.

Вариант 9: Определите адрес DNS-сервера локальной сети кафедры.

Вариант 10: Каким способом можно получить доступ к файлу, находящемуся на удаленном компьютере в папке общего доступа с названием «shared$».

©2015-2019 сайт
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Дата создания страницы: 2016-04-27

Рассказывает Владимир, веб-разработчик Noveo

Большинству разработчиков сайтов, веб-сервисов и мобильных приложений рано или поздно приходится иметь дело с клиент-серверной архитектурой, а именно разрабатывать web API или интегрироваться с ним. Чтобы не изобретать каждый раз что-то новое, важно выработать относительно универсальный подход к проектированию web API, основываясь на опыте разработки подобных систем. Предлагаем вашему вниманию объединенный цикл статей, посвящённых этому вопросу.

Приближение первое: Действующие лица

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

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

Клиент и сервер

Сервером в данном случае мы считаем абстрактную машину в сети, способную получить HTTP-запрос, обработать его и вернуть корректный ответ. В контексте данной статьи совершенно не важны его физическая суть и внутренняя архитектура, будь то студенческий ноутбук или огромный кластер из промышленных серверов, разбросанных по всему миру. Нам в той же мере совершенно неважно, что у него под капотом, кто встречает запрос у дверей, Apache или Nginx, какой неведомый зверь, PHP, Python или Ruby выполняет его обработку и формирует ответ, какое хранилище данных используется: Postgresql, MySQL или MongoDB. Главное, чтобы сервер отвечал главному правилу - услышать, понять и простить ответить.

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

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

Философия REST

REST (Representational state transfer) изначально был задуман как простой и однозначный интерфейс для управления данными, предполагавший всего несколько базовых операций с непосредственным сетевым хранилищем (сервером): извлечение данных (GET), сохранение (POST), изменение (PUT/PATCH) и удаление (DELETE). Разумеется, этот перечень всегда сопровождался такими опциями, как обработка ошибок в запросе (корректно ли составлен запрос), разграничение доступа к данным (вдруг этого вам знать не следует) и валидация входящих данных (вдруг вы написали ерунду), в общем, всеми возможными проверками, которые сервер выполняет перед тем, как выполнить желание клиента .

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

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

Пример: GET /api/v1/users/25/name

Независимость формата хранения данных от формата их передачи - сервер может поддерживать несколько различных форматов для передачи одних и тех же данных (JSON, XML и т.д.), но хранит данные в своем внутреннем формате, независимо от поддерживаемых.

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

Чего нам не хватает

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

Вызовы функций

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

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

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

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

Множественные операции

Часто бывает так, и разработчики клиентов поймут, о чем я, что клиентскому приложению удобнее создавать/изменять/удалять/ сразу несколько однородных объектов одним запросом, и по каждому объекту возможен свой вердикт серверной стороны. Тут есть как минимум несколько вариантов: либо все изменения выполнены, либо они выполнены частично (для части объектов), либо произошла ошибка. Ну и стратегий тоже несколько: применять изменения только в случае успеха для всех, либо применять частично, либо откатываться в случае любой ошибки, а это уже тянет на полноценный механизм транзакций.

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

Статистические запросы, агрегаторы, форматирование данных

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

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

Разновидности данных

Объекты

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

Коллекции объектов

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

Скалярные значения

В чистом виде скалярные значения как отдельная сущность на моей памяти встречались крайне редко. Обычно они фигурировали как свойства объектов или коллекций, и в этом качестве они могут быть доступны как для чтения, так и для записи. Например, имя пользователя может быть получено и изменено в индивидуальном порядке GET /users/1/name . На практике эта возможность пригождается редко, но в случае необходимости хотелось бы, чтобы она была под рукой. Особенно это касается свойств коллекции, например числа записей (с фильтрацией или без нее): GET /news/count .

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

Приближение второе: Правильный путь

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

О чем стоит подумать, стоя на берегу

Версионность

Рано или поздно любая действующая система начинает эволюционировать: развиваться, усложняться, масштабироваться, усовремениваться. Для разработчиков REST API это чревато в первую очередь тем, что необходимо запускать новые версии API при работающих старых. Здесь я говорю больше не об архитектурных изменениях под капотом вашей системы, а о том, что изменяется сам формат данных и набор операций с ними. В любом случае версионность нужно предусмотреть как в изначальной организации исходного кода, так и в принципе построения URL. Что касается URL, здесь существует два наиболее популярных способа указания версии API, которой адресован запрос. Префиксация пути example-api.com/v1/ и разведение версий на уровне субдомена v1.example-api.com . Использовать можно любой из них, в зависимости от потребности и необходимости.

Автономность компонентов

Web API сложных систем, поддерживающих несколько пользовательских ролей, зачастую требует разделения на части, каждая из которых обслуживает свой спектр задач. По сути, каждая часть может быть самостоятельным приложением, работать на разных физических машинах и платформах. В контексте описания API нам совершенно не важно, как сервер обрабатывает запрос и какие силы и технологии в этом замешаны. Для клиента API – система инкапсулированная. Тем не менее разные части системы могут обладать совершенно разной функциональностью, например, административная и пользовательская часть. И методология работы с одними и теми же, казалось бы, ресурсами может существенно отличаться. Поэтому такие части необходимо разделять на уровне домена admin.v1.example-api.com или префикса пути example-api.com/v1/admin/ . Это требование не является обязательным, и многое зависит от сложности системы и её назначения.

Формат обмена данными

Самым удобным и функциональным, на мой взгляд, форматом обмена данными является JSON, но никто не запрещает использовать XML, YAML или любой другой формат, позволяющий хранить сериализованные объекты без потери типа данных. При желании можно сделать в API поддержку нескольких форматов ввода/вывода. Достаточно задействовать HTTP заголовок запроса для указания желаемого формата ответа Accept и Content-Type для указания формата переданных в запросе данных. Другим популярным способом является добавление расширения к URL ресурса, например, GET /users.xml , но такой способ кажется менее гибким и красивым, хотя бы потому, что утяжеляет URL и верен скорее для GET-запросов, нежели для всех возможных операций.

Локализация и многоязычность

На практике многоязычность API чаще всего сводится к переводу сервисных сообщений и сообщений об ошибках на требуемый язык для прямого отображения конечному пользователю. Многоязычный контент тоже имеет место быть, но сохранение и выдача контента на разных языках, на мой взгляд, должна разграничиваться более явно, например, если у вас одна и та же статья существует на разных языках, то по факту это две разных сущности, сгруппированные по признаку единства содержания. Для идентификации ожидаемого языка можно использовать разные способы. Самым простым можно считать стандартный HTTP-заголовок Accept-Language . Я встречал и другие способы, такие, как добавление GET-параметра language="en" , использование префикса пути example-api.com/en/ или даже на уровне доменного имени en.example-api.com . Мне кажется, что выбор способа указания локали зависит от конкретного приложения и задач, стоящих перед ним.

Внутренняя маршрутизация

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

Пути к коллекциям

Для указания пути к коллекции мы просто используем название соответствующей сущности, например, если это список пользователей, то путь будет таким /users . К коллекции как таковой применимы два метода: GET (получение лимитированного списка сущностей) и POST (создание нового элемента). В запросах на получение списков мы можем использовать множество дополнительных GET параметров, применяемых для постраничного вывода, сортировки, фильтрации, поиска etc, но они должны быть опциональными, т.е. эти параметры не должны передаваться как часть пути!

Элементы коллекции

Для обращения к конкретному элементу коллекции мы используем в маршруте его уникальный идентификатор /users/25 . Это и есть уникальный путь к нему. Для работы с объектом применимы методы GET (получение объекта), PUT/PATCH (изменение) и DELETE (удаление).

Уникальные объекты

Во множестве сервисов существуют уникальные для текущего пользователя объекты, например профиль текущего пользователя /profile , или персональные настройки /settings . Разумеется, с одной стороны, это элементы одной из коллекций, но они являются отправной точкой в использовании нашего Web API клиентским приложением, и к тому же позволяют намного более широкий спектр операций над данными. При этом коллекция, хранящая пользовательские настройки может быть вообще недоступна из соображений безопасности и конфиденциальности данных.

Свойства объектов и коллекций

Для того, чтобы добраться до любого из свойств объекта напрямую, достаточно добавить к пути до объекта имя свойства, например получить имя пользователя /users/25/name . К свойству применимы методы GET (получение значения) и PUT/PATCH (изменение значения). Метод DELETE не применим, т.к. свойство является структурной частью объекта, как формализованной единицы данных.

В предыдущей части мы говорили о том, что у коллекций, как и у объектов, могут быть собственные свойства. На моей памяти мне пригодилось только свойство count, но ваше приложение может быть более сложным и специфичным. Пути к свойствам коллекций строятся по тому же принципу, что и к свойствам их элементов: /users/count . Для свойств коллекций применим только метод GET (получение свойства), т.к. коллекция – это только интерфейс для доступа к списку.

Коллекции связанных объектов

Одной из разновидностей свойств объектов могут быть связанные объекты или коллекции связанных объектов. Такие сущности, как правило, не являются собственным свойством объекта, а лишь отсылками к его связям с другими сущностями. Например, перечень ролей, которые были присвоены пользователю /users/25/roles . По поводу работы с вложенными объектами и коллекциями мы подробно поговорим в одной из следующих частей, а на данном этапе нам достаточно того, что мы имеем возможность обращаться к ним напрямую, как к любому другому свойству объекта.

Функции объектов и коллекций

Для построения пути к интерфейсу вызова функции у коллекции или объекта мы используем тот же самый подход, что и для обращения к свойству. Например, для объекта /users/25/sendPasswordReminder или коллекции /users/disableUnconfirmed . Для вызовов функций мы в любом случае используем метод POST. Почему? Напомню, что в классическом REST не существует специального глагола для вызова функций, а потому нам придется использовать один из существующих. На мой взгляд, для этого больше всего подходит метод POST т.к. он позволяет передавать на сервер необходимые аргументы, не является идемпотентным (возвращающим один и тот же результат при многократном обращении) и наиболее абстрактен по семантике.

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

Приближение третье: Запросы и ответы

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

Универсальный ответ

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

Success - маркер успешности выполнения запроса

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

POST /api/v1/articles/22/publish { "success": true }

Error - сведения об ошибке

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

GET /api/v1/user { "success": false, "error": { "code" : 401, "message" : "Authorization failed" } }

Data - данные, возвращаемые сервером

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

Пример возвращаемых данных в случае успеха. В данном случае ответ содержит запрашиваемый объект user.

GET /api/v1/user { "success": true, "data": { "id" : 125, "email" : "[email protected]", "name" : "John", "surname" : "Smith", } }

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

PUT /api/v1/user { "success": false, "error": { "code" : 422, "message" : "Validation failed" } "data": { "email" : "Email could not be blank.", } }

Pagination - сведения, необходимые для организации постраничной навигации

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

Минимальный набор значений для пагинации состоит из:

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

Некоторые разработчики web API также включают в пагинацию набор готовых ссылок на соседние страницы, а также первую, последнюю и текущую.

GET /api/v1/articles Response: { "success": true, "data": [ { "id" : 1, "title" : "Interesting thing", }, { "id" : 2, "title" : "Boring text", } ], "pagination": { "totalRecords" : 2, "totalPages" : 1, "currentPage" : 1, "perPage" : 20, "maxPerPage" : 100, } }

Работа над ошибками

Как уже упоминалось выше, не все запросы к web API завершаются успехом, но это тоже часть игры. Система информирования об ошибках является мощным инструментом, облегчающим работу клиента и направляющим клиентское приложение по правильному пути. Слово «ошибка» в этом контексте не совсем уместно. Здесь больше подойдёт слово исключение , так как на самом деле запрос успешно получен, проанализирован, и на него возвращается адекватный ответ, объясняющий, почему запрос не может быть выполнен.

Каковы же потенциальные причины получаемых исключений?

500 Internal server error - всё сломалось, но мы скоро починим

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

400 Bad request - а теперь у вас всё сломалось

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

401 Unauthorized - незнакомец, назови себя

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

403 Forbidden - вам сюда нельзя

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

404 Not found - по этому адресу никто не живёт

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

405 Method not allowed - нельзя такое делать

Эта разновидность исключения напрямую связана с использованным при запросе глаголом (GET, PUT, POST, DELETE), который, в свою очередь, свидетельствует о действии, которое мы пытаемся совершить с ресурсом. Если запрошенный ресурс не поддерживает указанное действие, сервер говорит об этом прямо.

422 Unprocessable entity - исправьте и пришлите снова

Одно из самых полезных исключений. Возвращается каждый раз, когда в данных запроса существуют логические ошибки. Под данными запроса мы подразумеваем либо набор параметров и соответствующих им значений, переданных методом GET, либо поля объекта, передаваемого в теле запроса методами POST, PUT и DELETE. Если данные не прошли валидацию, сервер в секции «data» возвращает отчет о том, какие именно параметры невалидны и почему.

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

Запросы

Получение элементов коллекции

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

Постраничная навигация

page - параметр указывает на то, какая страница должна быть отображена. Если этот параметр не передан, то отображается первая страница. Из первого же успешного ответа сервера будет ясно, сколько страниц имеет коллекция при текущих параметрах фильтрации. Если значение превышает максимальное число страниц, то разумнее всего вернуть ошибку 404 Not found .

GET /api/v1/news?page=1

perPage - указывает на желаемое число элементов на странице. Как правило, API имеет собственное значение по умолчанию, которое возвращает в качестве поля perPage в секции pagination, но в ряде случаев позволяет увеличивать это значение до разумных пределов, предоставив максимальное значение maxPerPage:

GET /api/v1/news?perPage=100

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

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

sortBy - существует несколько подходов к передаче данных о сложной сортировке в GET параметрах. Здесь необходимо четко указать порядок сортировки и направление.

В некоторых API это предлагается сделать в виде строки:

GET /api/v1/products?sortBy=name.desc,price.asc

В других вариантах предлагается использовать массив:

GET /api/v1/products? sortBy=name& sortBy=desc& sortBy=price& sortBy=asc

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

Простая фильтрация по значению

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

GET /api/v1/articles?authorId=25

Усложнённые варианты фильтрации

Многие интерфейсы требуют более сложной системы фильтрации и поиска. Перечислю основные и наиболее часто встречаемые варианты фильтрации.

Фильтрация по верхней и нижней границе с использованием операторов сравнения from (больше или равно), higher (больше), to (меньше или равно), lower (меньше). Применяется к полям, значения которых поддаются ранжированию.

GET /api/v1/products?price=500&price=1000

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

GET /api/v1/products?status=1&status=2

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

GET /api/v1/users?name=John GET /api/v1/products?code=123

Именованные фильтры

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

GET /api/v1/products?filters=recommended

Именованные фильтры могут также иметь свои параметры.

GET /api/v1/products?filters=kidds

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

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

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

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

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

Цикл выполнения запроса состоит из пересылки запроса и ответа между клиентом и сервером и непосредственным выполнением этого запроса на сервере.

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

Существует концепции построения системы клиент-сервер:

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

2) Сильный клиент - часть обработки информации перепоручается клиенту.

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

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

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

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

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

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

P.S. Нередко в ряде организаций в качестве сервера сознательно используют устаревшие компьютеры. На них хорошо размещать файловые хранилища, принт-серверы (к нему подключается офисный принтер), WEB-серверы (Интернет-серверы), небольшие базы данных (серверную часть). Это оправдано с экономической точки зрения.

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

Сергей СОКОЛОВ (БГУИР)

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

Среди многоуровневой архитектуры клиент-сервер наиболее распространена трехуровневая архитектура ( трехзвенная архитектура , three- tier ), предполагающая наличие следующих компонентов приложения: клиентское приложение (обычно говорят "тонкий клиент" или терминал ), подключенное к серверу приложений , который в свою очередь подключен к серверу базы данных [ , ].

рис. 5.4 .

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

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

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

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

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

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

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

1. Представление;
2. Уровень представления;
3. Уровень логики;
4. Уровень данных;
5. Данные.

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

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

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

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

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

5.1.6. Архитектура распределенных систем

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

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

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

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