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

5 Особенности и преимущества архитектуры "клиент/сервер"

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

Рис.5. Этап 4: обработка данных в архитектуре "клиент/сервер"

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

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

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

Кроме того, для описания серверных бизнес-правил, в наиболее типичных ситуациях (как в примере с заказчиками и заказами) существуют весьма удобные инструменты - так называемые CASE-средства (CASE означает Computer-Aided System Engineering), позволяющие описать подобные правила и создавать реализующие их объекты базы данных (индексы, триггеры), буквально рисуя мышью связи между таблицами, без какого бы то ни было программирования. В этом случае клиентское приложение будет избавлено от значительной части кода, связанного с реализацией бизнес-правил непосредственно в приложении. Отметим также, что часть кода, связанного с обработкой данных, также может быть реализована в виде хранимых проце дур сервера, что позволяет еще более "облегчить" клиентское приложение, г это означает, что требования к рабочим станциям могут быть не столь высоки. Это в конечном итоге удешевляет стоимость информационной системы даже при использовании дорогостоящей серверной СУБД и мощного сервера баз данных.

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

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

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

Итак, клиент-серверная информационная система состоит в простейшем случае из трех основных компонентов:

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

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

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

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

1.6. Компоненты системы

Клиент

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

Сервер

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

Сеть

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

Приложения

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

Есть два различного рода программного обеспечения для технологии клиент-сервер. Программное обеспечение, установленное на сервере (back-end tool), обеспечивает сбор, хранение и обработку данных. Примером подобных программ может служить Oracle, Sybase и Ingres.

Программное обеспечение на компьютере-клиенте (front-end application, фронтальное, предварительной обработки данных) более интерактивное, простое в использовании и более дружественное к пользователю. В качестве примера можно привести такие программы, как Developer 2000, Power Builder и Designer 2000.

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

Каждая машина обработки данных имеет свое фронтальное программное обеспечение. Для Oracle это Developer 2000, а для Sybase – Power Builder. Особенностью системы является то, что каждый фронтальный компьютер может общаться с компьютером базы данных. Так, в случае базы данных Oracle, может использоваться приложение Power Builder с небольшими изменениями.

1.6.1 Соберем все части вместе

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

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

Рис.6. Устройство системы «клиент-сервер»

1.7 Многозвенные информационные системы Internet

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

Эти проблемы решаются путем создания многозвенных информационных систем с "тонким" клиентом (рис.7).

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

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

Рис.7. Этап 5: обработка данных в многозвенной архитектуре

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

Говоря об использовании Internet/Intranet, нельзя не остановиться на возможностях создания приложений для Web-серверов. Такие приложения, с одной стороны, могут являться клиентами серверных СУБД, а с другой стороны, обычно генерируют динамические HTML-страницы (в том числе с данными из этих СУБД) по запросу клиентского приложения, роль которого в данном случае выполняет Web-браузер (называемый в этом случае "ультратонким" клиентом, рис.8). Отметим, что в последнее время такие приложения получают все большее распространение.

Рис.8. Принципы работы Web-приложения

1.8 Зачем нужны многозвенные информационные системы

Информационные системы, созданные на основе классической архитектуры "клиент/сервер", называемые двухзвенными системами или системами с "толстым" клиентом, состоят из сервера баз данных, содержащего сгенерированные тем или иным способом таблицы, индексы, триггеры и другие объекты, реализующие бизнес-правила данной информационной системы, и одного или нескольких клиентских приложений, предоставляющих интерфейс пользователя и производящих проверку допустимости и обработку данных, согласно содержащимся в них алгоритмам. Если говорить о клиентских приложениях, созданных для доступа к источникам данных они применяют вызовы функций прикладных программных интерфейсов клиентских частей соответствующих серверных СУБД. Эти вызовы осуществляются например посредством использования библиотеки Borland Database Engine (BDE), хотя в целом это не является обязательным (например, некоторые пользователи Oracle непосредственно вызывают функции Oracle Call Interfase в своих приложениях). Соответственно подобное клиентское приложение требует наличия на компьютере Конечного пользователя клиентской части применяемой серверной СУБД (и наличия лицензии на ее использование) и присутствия в оперативной памяти набора динамически загружаемых библиотек как из клиентской части, так и из ВDE (либо иной заменяющей ее библиотеки), таких, как драйверы баз данных, библиотеки, содержащие функции API клиентских частей и др. При использовании доступа посредством ООВС требуется также наличие на рабочей станции соответствующего ODBC-драйвера и ODBC администратора. Это усложняет технические требования, предъявляемые аппаратной части клиентской рабочей станции, и в конечном итоге приводит к удорожанию всей системы в целом (рис.9).

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

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

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

Рис.-9. Классическое клиентское приложение («толстый» клиент).

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

Рис.10. Решение проблем: "тонкий" клиент и сервер приложении

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

1.9 ТЕРМИНОЛОГИЯ РАСПРЕДЕЛЕННЫХ СУБД

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

На сегодняшний день существуют три параллельно развивающиеся и конкурирующие технологии взаимодействия объектов и программ: MIDAS (Multitier Distributed Application Srevices Suite), СОМ (Common Object Model - компонентная модель объектов) корпорации Microsoft, CORBA (Common Object Require Broken Architecture - архитектура с поставщиком требуемых общих объектов) независимой группы OMG. Основные принципы этих технологий и использующиеся в них термины описываются ниже.

1.10 Технология MIDAS

Midas (Multitier Distributed Application Srevices Suite) - новый продукт компании Inprise (Borland), предназначенный для эксплуатации сервера приложений, созданных с помощью C++ Builder 3 и Delphi 3. Этот продукт расширяет возможности, предоставляемые разработчикам технологией Microsoft DCOM (Distributed Component Object Model). Этот продукт позволяет обеспечить высокую производительность, надежность и защиту от сбоев при эксплуатации подобных систем.

Архитектура трехзвенной информационной системы, построенной с использованием MIDAS, представлена на рис. 11.

Рис.11. Архитектура трехзвенной информационной системы с использованием MIDAS

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

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

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

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

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

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

Отметим также, что удаленные модули данных (объекты Remote Data Module), входящие в состав серверной части Remote Data Broker, позволяют предоставить DCOM-интерфейс для| соответствующих объектов, делая их управляемыми извне и превращая, таким образом, сервер приложений в DCOM-сервер. Осуществляется такая публикация объектов путем выбора опции экспорта из удаленного модуля данных та контекстного меню соответствующего компонента при разработке сервера приложений.

Business Object Broker осуществляет для "тонкого" клиента поиск нужного сервера приложений среди доступных извне серверов, опубликованных в глобальном реестре - global registry, представляющем собой открытые части реестров компьютеров, содержащих серверы приложений. Применяется он в случае, когда требуется дублирование серверов приложений и возможность при сбое работы используемого сервера приложений подключить Клиентское приложение к другому серверу, либо при необходимости равномерного распределения клиентов по серверам приложений. Еще одной важной составляющей частью MIDAS является ConstraintBroker, дающий возможность использовать бизнес-правила сервера баз данных "тонким" клиентом. Обычно при проектировании баз данных бизнес-правила и правила ссылочной целостности реализуются в виде объектов базы данных, таких, как индексы, триггеры, хранимые процедуры. Такой подход к проектированию данных позволяет использовать эти объекты различными клиентскими приложениями без написания дополнительного кода.

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

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

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

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

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

Но это еще не все. Именно трехзвенная архитектура позволяет реально осуществить централизацию хранения и обработки данных с одновременным доступом к актуальной информации I случае, когда рабочая станция находится на значительном расстоянии от сервера приложений исключающем прокладку локальной сети, так как доступ к серверу приложений может осуществляться » иными способами, такими, как модемное соединение или доступ через Internet. Требования к надежности такого соединения невысоки, так как при использовании подобной архитектуры активно применяется кеширование данных на рабочей станции, и при этом применение ConstraintBroker позволяет проверять соответствие изменяемых данных правилам сервера непосредственно на рабочей станции, поэтому применение "тонких" клиентов и серверов приложений, управляемых MIDAS, является одним из решений для территориально разбросанных предприятий, организаций с удаленными филиалами, в том числе в других городах и странах.

1.11 Технология СОМ

Технология СОМ разрабатывается корпорацией Microsoft и предназначена для того, чтобы одна программа (клиент) смогла заставить работать объект, являющийся частью другой программы (частью сервера), так, как если бы этот объект был частью клиента, причем обе программы в общем случае могут быть расположены на разных компьютерах (в том числе - находящихся в разных частях света), написаны на разных языках и исполняться под управлением разных операционных систем. Более того, сами компьютеры могут быть разного типа - например, IBM-совместимый ПК и рабочая станция SUN.

Ключевым аспектом СОМ является так называемый интерфейс. Интерфейс имеет уникальный идентификатор и набор параметров, описывающих методы, события и свойства общего объекта. Идентификатор интерфейса ID (Interface Identifier) является частным случаем GUID (Global Unique Identifier - глобально уникальный идентификатор). В состав Windows32 включены функции, генерирующие GUID, причем вероятность совпадения двух GUID ничтожно мала. Параметры интерфейса в общем случае описывают некоторый класс с идентификатором CLSID (Class ID реализуется как GUID), т. е. типы и имена используемых в нем полей, количество и типы параметров обращения к доступным методам и свойствам, имена методов и свойств и т. д. Получив интерфейс внешнего СОМ-объекта, клиент может его использовать так же, как свои собственные объекты. Любой СОМ-объект имеет интерфейс IUnknow, с помощью которого он может получить доступ к основному интерфейсу объекта.

Сервер СОМ представляет собой исполняемую программу или DLL, содержащую один или несколько объектов СОМ.

В зависимости от местоположения клиента и сервера возможны три варианта:

Клиент и сервер располагаются на одной машине и запускаются в одном процессе (именно так взаимодействует программа Delphi с компонентами ActiveX)", в этом случае сервер представляет собой DLL; клиент и сервер располагаются на одной машине, но запускаются в разных процессах (например, таблицы Exel вставлены в документ Word); в этом случае сервер представляет собой программу;

Клиент и сервер располагаются на разных машинах; сервером может быть как программа, так и DLL, используется распределенный вариант СОМ, который называется DСОМ (DСОМ).

В первом случае клиент с помощью интерфейса объекта непосредственно обращается к методам объекта в своем собственном адресном пространстве (рис.12).

Рис.12 Взаимодействие клиента и сервера в одном процессе.

Если сервер запускается в другом процессе или на другой машине, между объектом и клиентом располагаются два посредника - Proxy (уполномоченный) и Stub (заглушка) (рис.13). Клиент помещает параметры вызова в стек и обращается к методу интерфейса объекта. Однако это обращение перехватывает Proxy, упаковывает параметры вызова в пакет СОМ и направляет его в Stub другого процесса, возможно, на другой машине. Stub распаковывает параметры, помещает их в стек и делает вызов нужного метода объекта. Таким образом, метод объекта выполняется в собственном адресном пространстве процесса сервера.

1.12 Технология CORBA

Подобно СОМ, в CORBA активно используется интерфейс объекта. Главным отличием CORBA от СОМ является интегрированный в нее слой, реализующий доступ к удаленным объектам.

В соответствии с этой технологией схема взаимодействия клиента и сервера выглядит следующим образом (рис.14).

На машине клиента создаются два объекта-посредника: Stub (заглушка) и ORB (Object Require Broker - брокер требуемого объекта). Stub выступает как полномочный представитель объекта: с помощью интерфейса объекта клиент обращается к Stub так, как если бы это был сам объект.

Рис.13. Взаимодействие клиента и сервера в разных процессах.

Рис. 14. Взаимодействие клиента и сервера в CORBA.

Получив вызов метода, Stub транслирует этот вызов объекту ORB, который посылает в сеть широковещательное сообщение. На это сообщение откликается один из объектов Smart Agent((«умный» агент), установленный в сетевом окружении клиента (как в локальной сети, так и в Internet). Smart Agent моделирует сетевой каталог, в котором зарегистрированы известные ему серверы объектов. Он отыскивает нужный сетевой адрес сервера и передает запрос объекту ORB на машине сервера. Заметим, что обмен данными между ORB (клиента и сервера) и Smart Agent осуществляется с использованием специального протокола UDP, который более бережно использует сетевые ресурсы, чем протокол ТСР. Через ВОА (Basic Object Adapter - базовый объектный адаптер) данные получает особый объект сервера, который называется Skeleton (скелет). Skeleton помещает параметры вызова в стек адресного пространства объекта и реализует собственно вызов. Роль объекта ВОА заключается в фильтрации обращений к объекту сервера: с помощью его методов сервер через Skeleton может объявить некоторые свои поля и свойства доступными только для чтения иди вовсе срытыми от данного клиента. (Поскольку в рамках технологии данные, которыми обмениваются клиент и сервер, рассматриваются просто как цепочки байт, клиент должен поместить в буфер вызова свой авторизованный ключ в системах, защищенных от «посторонних» клиентов.)

«Изюминкой» CORBA является способ описания интерфейса объекта. Для этих целей разработан специальный язык IDL (Interface Definition Language - язык описания интерфейса), очень напоминающий язык С++. После описания интерфейса в терминах этого языка компилятор IDL автоматически создает объекты Stub и Skeleton. Обмен информацией об интерфейсе между разработчиками осуществляется в терминах языка высокого уровня, в то время как компилятор описания интерфейса переводит его текст в машинные инструкции конкретного компьютера (клиента или сервера). В результате достигается высокая степень независимости обмена данными от аппаратных средств клиента и пользователя.

Для реализации технологии в сетевом окружении клиента должен существовать хотя бы один Smart Agent. Если обмен данными осуществляется в локальной сети офиса, Smart Agent устанавливается на головную машину (на файл-сервер или машину с SQL-сервером), а при обмене данными по Internet - на одном из ее узлов. При создании сервера осуществляется автоматическая регистрация объектов в одном или нескольких Smart Agent. Таким образом, Smart Agent «знает», по каким сетевым адресам расположены его серверы. Это позволяет системе повысить свою надежность: если в одном из серверов произошел сбой, Smart Agent повторит вызов и при повторном сбое переключится на другой сервер.

1.13 Некоторые выводы

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

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

1.14. Применение систем Клиент/Сервер

Применение систем клиент-сервер в основном сконцентрировано в:

Банковском деле;

Системе продаж авиа билетов;

Сети Интернет.

Банковское дело

Все мы хорошо знакомы с основными банковскими операциями . Вот они:

2. Размещение и снятие с депозита наличных и безналичных денег ;

3. Предоставление займов;

4. Инвестиции;

5. Следование инструкциям банковского клиента.

Это лишь некоторые из многих функций, исполняемых банком в наши дни. Глобализация экономики привела к широкому распределению филиалов банков по стране. Так, например, у клиента банка открыт счет в Нью-Йорке, а оплатить чек он желает в Лос-Анджелесе, или получить наличными из банкомата во Флориде.

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

Как происходит перевод?

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

Система продаж авиабилетов

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

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

Интеренет

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

Известно, что Интернет представляет собой совокупность малых сетей, расположенных по всему миру. Для того, чтобы все сети могли понимать друг друга, необходимо, чтобы они изъяснялись на одном и том же языке, названном ТСР/IР. Вне зависимости от географического расстояния и платформы становится возможным клиентским и серверным машинам разговаривать друг с другом.

Давайте посмотрим, почему Мировая Паутина (WWW) может быть названа наиболее популярным программным приложением к/с в сети Интернет.

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

1.15. Примеры развития серверов индивидуальных баз данных

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

Совместимость между собой;

Оптимизация и производительность;

Контроль за целостностью данных;

Обработка переводов;

Конкурентоспособность, защита от зависаний и контроль многопользовательского доступа;

Защита от несанкционированного доступа и проверка подлинности клиента;

Резервирование, восстановление данных и другие функции базы.

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

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

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

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

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

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

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

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

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

Философия REST

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Объекты

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Запросы

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

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

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

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

GET /api/v1/news?page=1

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

GET /api/v1/news?perPage=100

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

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

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

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

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

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

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

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

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

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

GET /api/v1/articles?authorId=25

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

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

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

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

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

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

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

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

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

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

GET /api/v1/products?filters=recommended

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

GET /api/v1/products?filters=kidds

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Большинство конфигураций клиент-сервер использует двухуровневую модель, в которой клиент обращается к услугам сервера. Предполагается, что диалоговые компоненты PS и PL размещаются на клиенте, что позволяет обеспечить графический интерфейс. Компоненты управления данными DS и FS размещаются на сервере, а диалог (PS, PL), логика BL и DL - на клиенте. Двухуровневое определение архитектуры клиент-сервер использует именно этот вариант: приложение работает у клиента, СУБД - на сервере (рис. 1.4.).

Рис. 6 . Классический вариант клиент-серверной информационной системы

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

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

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

ПРИМЕЧАНИЕ

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

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

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

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

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

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

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

· средний уровень представляет собой сервер приложений, на котором выполняется прикладная логика BL и с которого логика обработки данных DL вызывает операции с базой данных DS;

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

Подобную концепцию обработки данных пропагандируют, в частности, фирмы Oracle, Sun, Borland и др.

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

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

С ростом систем клиент-сервер необходимость трех уровней становится все более очевидной. Продукты для трехзвенной архитектуры, так называемые мониторы транзакций, являются относительно новыми. Эти инструменты в основном ориентированы на среду UNIX, однако прикладные серверы можно строить на базе Мicrosoft Windows NT с использованием вызова удаленных процедур для организации связи клиентов с сервером приложений. На практике в локальной сети могут использоваться смешанные архитектуры (двухуровневые и трехуровневые) с одним и тем же сервером базы данных. С учетом глобальных связей архитектура может иметь больше трех звеньев. В настоящее время появились новые инструментальные средства для гибкой сегментации приложений клиент-сервер по различным узлам сети.

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

Интернет/интранет-технологии

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

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

Области применения и примеры реализации информационных систем

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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