Сетевое решение в реализации архитектуры приложения

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

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

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

Замечание

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

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

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

Access предоставляет две возможности для реализации приложений с такой архитектурой:

• в виде сетевых баз данных (одна или несколько связанных баз данных, размешенных в сети);
  
• в виде проектов баз данных, соединенных с данными на SQL Server (о клиент-серверной архитектуре в приложениях, связанных с SQL Server, см. гл. 17).
  

Замечание

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

В этой главе мы говорим о первом способе — сетевых базах данных.

Сетевое приложение Access "Игра в доминирование" должно будет обслуживать нескольких игроков — разных пользователей в сети. Предположим, пользователи работают в одноранговой сети. Рабочие станции пользователей, принимающих участие в игре, можно разделить на две категории: клиенты и серверы. На сервере выполняется ядро игры — управляющий компонент приложения. На клиентских рабочих станциях устанавливается компонент, предоставляющий пользователю интерфейс для участия в игре. Таким образом, приложение "Игра в доминирование" представляет собой распределенную базу данных Access с архитектурой "клиент-сервер", которая может быть использована даже в одноранговой сети. Все участники одной игры подключаются к одному серверу по схеме "звезда" (рис. 16.2).

Рис. 16.2. Архитектура приложения "Игра в доминирование"

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