Распределение функций в архитектуре "клиент-сервер"


Процесс разработки таких систем достаточно сложен и одной из наиболее важных задач является как раз решение о том, как функциональность приложения должна быть распределена между клиентской и серверной частью. Пытаясь решить эту задачу, разработчики получают двух-звенные, трехзвенные и многозвенные архитектуры. Все зависит от того, сколько промежуточных звеньев включается между клиентом и сервером.
Основная задача, которую решает клиентское приложение, — это обеспечение интерфейса с пользователем, т. е. ввод данных и представление результатов в удобном для пользователя виде, и управление сценариями работы приложения.
Основные функции серверной СУБД — обеспечение надежности, согласованности и защищенности данных, управление запросами клиентов, быстрая обработка SQL-запросов.
Вся логика работы приложения — прикладные задачи, бизнес-правила — в двух-звенной архитектуре распределяются разработчиком между двумя процессами: клиентом и сервером (рис. 17.1).
Сначала большая часть функций приложения решалась клиентом, сервер занимался только обработкой SQL-запросов. Такая архитектура получила название "толстый клиент — тонкий сервер". Появление возможности создавать на сервере хранимые процедуры, т. е. откомпилированные программы с внутренней логикой работы, привело к тенденции переносить все большую часть функций на сервер. Сервер становился все более "толстым", а клиент — "утоньшался". Такое решение имеет очевидные преимущества, например его легче поддерживать, т. к. все изменения нужно вносить только в одном месте — на сервере. Однако язык, на котором пишутся хранимые процедуры, не является достаточно мощным и гибким, чтобы на нем было удобно реализовывать сложную логику приложения.
Тогда возникла тенденция поручить выполнение прикладных задач и бизнес-правил отдельному компоненту приложения (или нескольким компонентам), которые могут работать как на специально выделенном компьютере — сервере приложений, так и на том же компьютере, где работает сервер базы данных. Так возникли трехзвенные и многозвенные архитектуры "клиент-сервер". Появилось специальное программное обеспечение (ПО) промежуточного слоя, которое должно обеспечить совместное функционирование множества компонентов такого многокомпонентного приложения. Такие приложения являются гибкими, масштабируемыми, но сложными в разработке.
Далее в данной главе мы будем говорить только о двухзвенных приложениях "клиент-сервер", в которых клиент, реализованный на базе Access 2010, непосредственно обращается с запросами к серверу базы данных. Промежуточное ПО в данном случае только транслирует эти запросы и результирующие наборы записей между клиентом и сервером и не реализует никаких функций приложения.
 
Универсальный доступ к данным через OLE DB
Интерфейс ODBC был первым средством, которое обеспечило универсальный доступ к данным реляционного типа посредством SQL-запросов. Однако реляционные базы данных не единственный формат хранения данных, а современные приложения требуют интеграции информации из разных источников, не только SQL-ориентированных. Отсюда возникает потребность либо перевести все данные в единый формат, т. е. создать универсальную базу данных, что очень-дорого и неэффективно, либо обеспечить универсальный доступ к данным разных типов без необходимости их преобразовывать и реплицировать.
OLE DB представляет собой разработанный фирмой Microsoft набор интерфейсов OLE, обеспечивающих унифицированный доступ приложений к данным из разнообразных источников, включая текстовые файлы, файлы электронной почты, электронные таблицы, данные мультимедиа и пр.
Основные отличия OLE DB от ODBC состоят в следующем:

  • OLE DB обеспечивает доступ к данным произвольных типов, а не только реляционным;
  • OLE DB не является набором функций, а представляет собой набор интерфейсов, построенных в соответствии с компонентной моделью объектов (СОМ).