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

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

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

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

(Здесь опять проявляются недостатки в терминологии. Обычно, когда компания объявляет о выпуске очередного сервера баз данных, то неявно понимается, что имеется и клиентская составляющая этого продукта. Сочетание "клиентская часть сервера баз данных" кажется несколько странным, но нам придется пользоваться именно этим термином.)

Рис. 2.3. Общее представление информационной системы в архитектуре "клиент-сервер"

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

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

Здесь необходимо сделать еще два замечания.

Обычно компании, производящие развитые серверы баз данных, стремятся к тому, чтобы обеспечить возможность использования своих продуктов не только в стандартных на сегодняшний день TCP/IP-ориентированных сетях, но в сетях, основанных на других протоколах (например, SNA или IPX/SPX). Поэтому при организации сетевых взаимодействий между клиентской и серверной частями СУБД часто используются не стандартные средства высокого уровня (например, механизмы программных гнезд или вызовов удаленных процедур), а собственные функционально подобные средства, менее зависящие от особенностей сетевых транспортных протоколов.

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

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

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

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

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

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

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

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

  Особый класс операторов языка SQL составляют операторы вызова ранее определенных и сохраненных в базе данных хранимых процедур. Если хранимая процедура определяется с помощью достаточно развитого языка, включающего и непроцедурные операторы SQL, и чисто процедурные конструкции (например, языка PL/SQL компании Oracle), то в такую процедуру можно поместить серьезную часть приложения, которое при выполнении оператора вызова процедуры будет выполняться на стороне сервера, а не на стороне клиента.

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

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

Рис. 2.4. "Тонкий" клиент и "толстый" сервер в клиент-серверной архитектуре

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

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

Рис. 2.5. "Потолстевший" клиент и "толстый" сервер в клиент-серверной архитектуре с поддержкой локального кэша на стороне клиентов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

.

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

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

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

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

Client-server ) - сетевая архитектура, в которой устройства являются либо клиентами , либо серверами . Клиентом (front end) является запрашивающая машина (обычно ПК), сервером (back end) - машина, которая отвечает на запрос. Оба термина (клиент и сервер) могут применяться как к физическим устройствам, так и к программному обеспечению.

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

Wikimedia Foundation . 2010 .

Смотреть что такое "Клиент-серверное приложение" в других словарях:

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

Веб приложение клиент серверное приложение, в котором клиентом выступает браузер, а сервером веб сервер. Логика веб приложения распределена между сервером и клиентом, хранение данных осуществляется, преимущественно, на сервере, обмен… … Википедия

Тип Общество с ограниченной ответственностью Год основания … Википедия

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

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

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

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

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

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

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

При работе в архитектуре "клиент-сервер" приложение должно:

· устанавливать соединение с сервером и завершать его;

· формировать и отсылать запрос серверу, получая от него результаты выпол­нения запроса;

· обрабатывать полученные данные.

При этом обработка данных не имеет принципиальных отличий по сравнению с обработкой данных в локальных БД.

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

· триггеры;

· генераторы;

· хранимые процедуры;

· функции, определяемые пользователем;

· механизм транзакций;

· механизм кэшированных изменений;

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

Система Delphi обеспечивает разработку приложений для различных серверов, предоставляя для этого соответствующие средства. Отметим, что многие опи­санные ранее принципы разработки приложений и средства для работы с ло­кальными БД относятся и к работе с удаленными БД. В частности, для разра­ботки приложений используются такие компоненты, как источник данных DataSource,_наборыданныхTable,ADOTable, SQLTable, IBTable, Query, ADOQuery, SQLQuery, сетка DBGrid и др.

Для реализации реляционного способа доступа к удаленной БД с помощью BDE не­обходимо использовать только средства языка SQL. Поэтому в качестве компонен­тов должны выбираться такие как Query, StoredProc, UpdateSQL. Кроме того, для набора данных нельзя использовать методы, характерные для навигационного способа доступа.

Напомним, что если при выполнении модифицирующего БД запроса с помо­щью компонента Query не нужен результирующий набор данных, то этот за­прос предпочтительнее выполнять с помощью метода ExecSQL. Для работы с таблицами и запросами по-прежнему можно использовать такие программы, как Database Desktop и SQL Explorer.

Средства Delphi, предназначенные для работы с удаленными БД, можно разде­лить на два вида: инструменты и компоненты.

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

· InterBase Server Manager - программа управления запуском сервера InterBase;

· IBConsole - консоль сервера InterBase;

· SQL Monitor - программа отслеживания порядка выполнения SQL-запросов к удаленным БД.

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

· Database (соединение с БД);

· Session (текущий сеанс работы с БД);

· StoredProc (вызов хранимой процедуры);

· UpdateSQL (модификация набора данных, основанного на SQL-запросе);

· DCOMConnection(DСОМ-соединение);

· компоненты страниц АDО, dbExpress, Interbase Палитры компонентов.

Отметим, что многие из названных компонентов, например, Database, Session, UpdateSQL, используются также при работе с локальными БД. Так, компонент Database позволяет, реализовать механизм транзакций при навигационном способе доступа к данным с помощью механизма ВDЕ. Однако наиболее часто эти компоненты применяются именно при работе с удаленными базами. Часть компонентов, например, клиентский набор данных ClientDataSet и со­единение с сервером DCOMConnection, предназначена для работы в трехуровне­вой (трехзвенной) архитектуре "клиент-сервер" ("тонкий" клиент) и используется для построения сервера приложений.

В основе операций, выполняемых с удаленными БД как с помощью инструмен­тов, так и программно, лежит язык SQL. Например, при создании таблицы с помощью программы IBConsole необходимо набрать и выполнить SQL-запрос (инструкцию) Create Table. Если создание таблицы с помощью механизма ВDЕ осуществляется из приложения пользователя, то для этой цели используется набор данных Query, который выполняет такой же за­прос. Основное различие заключается в том, каким образом выполняется SQL-запрос к удаленной БД.

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

Сервер InterBase. Все серверы имеют похожие принципы организации данных и управления ими. В качестве примера рассмотрим работу с сервером InterBase 6.x, который явля­ется "родным" для_Delphi. Совместно с Delphi поставляются две части сервера InterBase 6.x: серверная и клиентская. Серверная часть InterBase является локальной версией сервера InterBase и ис­пользуется для отладки приложений, предназначенных для работы с удаленны­ми БД, позволяя на одном компьютере проверить их в сетевом варианте. После отладки на локальном компьютере приложение можно перенести на сетевые компьютеры без изменений, для чего нужно:

· скопировать БД на сервер;

· установить для приложения новые параметры соединения с удаленной БД.

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

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

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

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

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

Информация всей БД сервера InterBase хранится в одном файле с расширением gdb. Размер этого файла может составлять единицы и даже десятки гигабайт. Отметим, что аналогичный размер БД имеет СУБД Microsoft SOL Server, в то время как для более мощных СУБД Oracle и SyBase размер БД достигает десят­ков и сотен гигабайт.

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

Элементы структуры удаленной БД также называют метаданными. Слово "мета" имеет смысл "над", т. е. метаданные представляют собой данные, которые опи­сывают структуру БД. Для InterBase максимальное число таблиц в БД равно 65 536, а максимальное число столбцов в таблице - 1000. Отметим, что таблицы InterBaseимеют мень­шее число допустимых типов столбцов (полей), чем таблицы локальных БД Paradox.

Домен представляет собой именованное описание столбца. После определения домена его имя можно использовать для описания других столбцов.Аналогом домена является тип данных.

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

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

· вместо текста запроса серверу передается по сети короткое обращение к хранимой процедуре;

· хранимая процедура не требует предварительной синтаксической проверки.

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

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

Механизм кэшированных изменений заключается в том, что на компьютере клиента в кэше (буфере) создается локальная копия данных, и все изменения в данных выполняются в этой копии. Для хранения локальной копии используется специальный буфер (кэш). Сделанные изменения можно подтвердить, перенеся их в основную БД, хранящуюся на сервере, или отказаться от них. Этот меха­низм напоминает механизм транзакций, но, в отличие от него, снижает нагрузку на сеть, т. к. все изменения передаются в основную БД одним пакетом. Следует иметь к виду, что для всех записей локальной копии отсутствуют блокировки на изменение их значений. Блокировки могут быть установлены другими приложе­ниями для основной БД, находящейся на сервере.Механизм кэшированных изменений реализуется в приложении, для чего компоненты, в первую очередь Database, Table и Query (используемые при доступе с помощью BDE), имеют соответствующие средства. Кроме того, механизм кэшированных изменений поддерживается предназначенным для этого компонен­том UpdateSQL.Основные достоинства рассматриваемого механизма проявляются для удален­ных БД, но его можно использовать и при работе с локальными БД.

Привилегии представляют собой права доступа к БД. Управление привилегиями заключается в их установке и удалении. После создания объекта БД (например, таблицы) доступ к ней разрешен только создателю и системному администрато­ру, имеющему имя SYSDBA. Для доступа к БД остальных пользователей им нуж­но назначить соответствующие привилегии. Сразу после появления нового пользователя, созданного например, с помощью программы InterBase Manager Server , этот пользователь имеет минимальные права доступа: ему разрешено только войти в БД (соединиться с ней), указав свое имя и пароль, однако ни один объект этой БД ему не доступен. Чтобы обеспечить возможность активной работы с БД, нужно определить (переопределить) привилегии.

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