• Использоваться клиент серверная модель архитектуры. Клиент-серверная архитектура

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

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

    Основные особенности:

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

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

    Полная поддержка многопользовательской работы

    Гарантия целостности данных

    Бизнес логика приложений осталась в клиентском ПО. При любом изменении алгоритмов, надо обновлять пользовательское ПО на каждом клиенте.

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

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

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

    Необходимость использовать мощные ПК на клиентских местах.

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

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

    Переходная к трехслойной архитектуре (2.5 слоя)

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

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

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

  • Разработка под iOS ,
  • Разработка мобильных приложений

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

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

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

    Обработка ошибок

    Чаще всего мне попадалось что-то вроде этого:

    HTTP code 200 (OK) false The username or password is incorrect. Please try again.
    Т.е. результат обработки запроса содержится в самом отдаваемом XML, HTTP-код возврата – 200, т.е. нормально, данные представлены в виде обычного RPC. Например, похожим образом в 90% случаев реализуется обработка ошибок в протоколе SOAP.

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

    Но давайте рассмотрим недостатки данного подхода в принципе.

    • Во-первых, приходится парсить XML. Это лишние данные, переданные по сети, лишнее процессорное время, затраченное на парсинг XML, лишняя оперативная память для хранения текстовых данных. Всё это не так страшно на современных девайсах в зоне Wi-fi, но даже такие излишества могут иметь значение в метро между станциями в приложении, посылающем одновременно десятки запросов (а ведь при таком подходе пустые блоки для обработки ошибок должны быть в каждом запросе, даже успешном).
    • Во-вторых, веб-разработчику приходится самому выдумывать тексты ошибок. Очень часто они совершенно непонятны пользователю, т.к. точность формулировки – последнее, о чём думает веб-разработчик в момент написания сервиса. Текст ошибки в 90% случаев не согласовывается с native-спикерами и последнее, но самое важное – огромное количество мобильных приложений нуждается в локализации. В то время как текст ошибки, скорее всего, пишется всегда только по-английски, следовательно он абсолютно бесполезен для фронтэнд-программиста – он не может его просто взять и вывести.

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

    Как решить проблему?

    В протоколе HTTP уже много лет заложена возможность добавлять свои коды ошибок, для этого они просто должны принадлежать диапазону от 512 до 597. Такого количества ошибок, я уверен, хватит для покрытия всех возможных ошибок в приложении среднего размера. Очевидно, какие плюсы это даёт, но всё же подытожим:

    1. Нет избыточности. Передаётся только HTTP код в хэдере, тела запроса просто нет.
    2. На стороне клиента существуют только две ветки кода обработки запросов – успешное выполнение, либо ошибка при выполнении (оба колбэка уже имплементированы из коробки в любой библиотеке запросов). Нет веток “запрос выполнился успешно, но логическая ошибка может быть в теле ответа”.
    5xx Server Error

    The server failed to fulfill an apparently valid request.
    Response status codes beginning with the digit «5» indicate cases in which the server is aware that it has encountered an error or is otherwise incapable of performing the request. Except when responding to a HEAD request, the server should include an entity containing an explanation of the error situation, and indicate whether it is a temporary or permanent condition. Likewise, user agents should display any included entity to the user. These response codes are applicable to any request method.

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

    Хотя не будем обобщать – идею использовать HTTP коды мне подсказал как раз-таки американец несколько лет назад.

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

    Привязка к сессии или cookie.

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

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

    Допустим, ваше мобильное приложение реализует только 70% функционала веб-сайта. Остальные 30% функционала доступны только в вебе, а ваше приложение лишь содержит ссылки на соответствующие веб-страницы.

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

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

    Возврат HTML

    Это уже ведёт корнями к устройству самих веб-серверов, которые изначально были заточены только под браузер. Ошибки 403, 404, а порой и более сложные очень часто отдаются в виде HTML-страницы, которую зачастую просто нет средств показать в мобильном приложении. Точнее, средства есть, но увидев “404 page not found” здоровенным черным Arial Black на белом фоне внутри веб-вью, мобильный пользователь испугается и закроет приложение.

    Запомните, сервер на любое обращение к веб-сервисам должен отдавать XML (или JSON), и только в том формате, который был изначально оговорен. Мобильный разработчик не может сделать ничего путного с HTML, который приходит с сервера.

    Используйте WSDL

    На майкрософтовский технологиях ситуация еще ничего - большинство их современных технологий поддерживает WSDL из коробки. Чего не скажешь про PHP и Java - особенно PHP-разработчики очень любят создавать вручную обычные странички, которые по сути являются веб-сервисами. А ведь для того, чтобы интегрироваться с WSDL-совместимым веб-сервисом, мобильному разработчику достаточно использовать тулзу для генерации кода, в то время как составленные «вручную» ответы веб-сервисов тоже нужно парсить «руками».

    Правда, и здесь есть тонкости - стандартные реализации WSDL от MS и Sun (Oracle) всё-таки имеют несовместимости, но все же быстрее подправить напильником эти несовместимости, чем писать все вручную.

    Заключение

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

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

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

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

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

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

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

    Рисунок Модель клиент-сервер

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

    В сетях с выделенным файловым сервером на выделенном автономном ПК устанавливается серверная сетевая операционная система . Этот ПК становится сервером. Программное обеспечение (ПО ), установленное на рабочей станции, позволяет ей обмениваться данными с сервером. Наиболее распространенные сетевые операционная системы:

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

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

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

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

    Позволяют организовывать сети с большим количеством рабочих станций;

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


    Эффективный доступ к сетевым ресурсам;

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

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

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

    Требуют квалифицированного персонала для администрирования;

    Имеют более высокую стоимость сетей и сетевого оборудования.

    Системы "клиент-сервер". Часть 2

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

    Что такое архитектура клиент-сервер? Варианты построения приложений

    Итак, поговорим, наконец, о том,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    В третьей части рассмотрен пример трехзвенной структуры Baikonur Server .

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

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

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

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

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

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

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

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

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

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

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

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

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

    Архитектура клиент-сервер: Да, но...

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

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

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

    И, наконец, самым большим подводным камнем на пути создания КС системы на предприятии является необходимость менять структуру управления и связанные с этим организационные издержки

    .

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

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

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

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

     БД , на структурном языке запросов SQL (Structured Query Language ), являющемся промышленным стандартом в мире реляционных БД . Удаленный сервер принимает запрос и переадресует его SQL -серверу БД . SQL - сервер – специальная программа , управляющая удаленной базой данных. SQL - сервер обеспечивает интерпретацию запроса, его выполнение в базе данных, формирование результата выполнения запроса и выдачу его приложению-клиенту. При этом ресурсы клиентского компьютера не участвуют в физическом выполнении запроса; клиентский компьютер лишь отсылает запрос к серверной БД и получает результат, после чего интерпретирует его необходимым образом и представляет пользователю. Так как клиентскому приложению посылается результат выполнения запроса, по сети "путешествуют" только те данные, которые необходимы клиенту. В итоге снижается нагрузка на сеть . Поскольку выполнение запроса происходит там же, где хранятся данные (на сервере), нет необходимости в пересылке больших пакетов данных. Кроме того, SQL - сервер , если это возможно, оптимизирует полученный запрос таким образом, чтобы он был выполнен в минимальное время с наименьшими накладными расходами [ [ 3.2 ] , [ 3.3 ] ]. системы представлена на рис. 3.3 .

    Все это повышает быстродействие системы и снижает время ожидания результата запроса. При выполнении запросов сервером существенно повышается степень безопасности данных, поскольку правила целостности данных определяются в базе данных на сервере и являются едиными для всех приложений, использующих эту БД . Таким образом, исключается возможность определения противоречивых правил поддержания целостности. Мощный аппарат транзакций, поддерживаемый SQL -серверами, позволяет исключить одновременное изменение одних и тех же данных различными пользователями и предоставляет возможность откатов к первоначальным значениям при внесении в БД изменений, закончившихся аварийно [ [ 3.2 ] , [ 3.3 ] ].


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

    • Существует локальная сеть, состоящая из клиентских компьютеров, на каждом из которых установлено клиентское приложение для работы с БД.
    • На каждом из клиентских компьютеров пользователи имеют возможность запустить приложение. Используя предоставляемый приложением пользовательский интерфейс, он инициирует обращение к СУБД, расположенной на сервере, на выборку/обновление информации. Для общения используется специальный язык запросов SQL , т.е. по сети от клиента к серверу передается лишь текст запроса.
    • СУБД инициирует обращения к данным, находящимся на сервере, в результате которых на сервере осуществляется вся обработка данных и лишь результат выполнения запроса копируется на клиентский компьютер. Таким образом СУБД возвращает результат в приложение.

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

    • Функции приложения-клиента:
      • Посылка запросов серверу.
      • Интерпретация результатов запросов, полученных от сервера.
      • Представление результатов пользователю в некоторой форме (интерфейс пользователя).
    • Функции серверной части:
      • Прием запросов от приложений-клиентов.
      • Интерпретация запросов.
      • Оптимизация и выполнение запросов к БД.
      • Отправка результатов приложению-клиенту.
      • Обеспечение системы безопасности и разграничение доступа.
      • Управление целостностью БД.
      • Реализация стабильности многопользовательского режима работы.

    В архитектуре " клиент – сервер " работают так называемые "промышленные" СУБД . Промышленными они называются из-за того, что именно СУБД этого класса могут обеспечить работу информационных систем масштаба среднего и крупного предприятия, организации, банка. К разряду промышленных СУБД принадлежат MS SQL Server , Oracle , Gupta, Informix , Sybase , DB2 , InterBase и ряд других [ [ 3.2 ] ].

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

    Рассмотрим основные достоинства данной архитектуры по сравнению с архитектурой " файл - сервер ":

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

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

    3.4. Трехзвенная (многозвенная) архитектура "клиент – сервер".

    Трехзвенная (в некоторых случаях многозвенная ) архитектура (N- tier или multi- трехзвенной архитектуры ? Теперь при изменении бизнес-логики более нет необходимости изменять клиентские приложения и обновлять их у всех пользователей. Кроме того, максимально снижаются требования к аппаратуре пользователей.

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

    • База данных в виде набора файлов находится на жестком диске специально выделенного компьютера (сервера сети).
    • СУБД располагается также на сервере сети.
    • Существует специально выделенный сервер приложений, на котором располагается программное обеспечение (ПО) делового анализа (бизнес-логика) [ [ 3.1 ] ].
    • Существует множество клиентских компьютеров, на каждом из которых установлен так называемый "тонкий клиент" – клиентское приложение, реализующее интерфейс пользователя.
    • На каждом из клиентских компьютеров пользователи имеют возможность запустить приложение – тонкий клиент. Используя предоставляемый приложением пользовательский интерфейс, он инициирует обращение к ПО делового анализа, расположенному на сервере приложений.
    • Сервер приложений анализирует требования пользователя и формирует запросы к БД. Для общения используется специальный язык запросов SQL , т.е. по сети от сервера приложений к серверу БД передается лишь текст запроса.
    • СУБД инкапсулирует внутри себя все сведения о физической структуре БД, расположенной на сервере.
    • СУБД инициирует обращения к данным, находящимся на сервере, в результате которых результат выполнения запроса копируется на сервер приложений.
    • Сервер приложений возвращает результат в клиентское приложение (пользователю).
    • Приложение, используя пользовательский интерфейс, отображает результат выполнения запросов.
    Читать еще: