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

Первоисточник:http://belani.narod.ru/1/Lklser2.htm

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

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

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

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

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

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

компонент представления (визуализации) данных;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Существующие клиент-серверные системы компьютеризации организационного управления

Оба лучше

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

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

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

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

На практике, в промышленности чаще всего реализуются смешанные варианты. Это связано, прежде всего, с тем, что любая стандартная система покрывает, в лучшем случае, 50 - 60 % общего объема задач автоматизации промышленного предприятия, с учетом его специфики. Это задачи, которые являются наиболее стандартными. Оставшиеся 40 -50 % составляют задачи настолько индивидуальные, что их компьютеризация все равно требует разработки на заказ.

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

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

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

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

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

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

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

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

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

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

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