Пример сетевого приложения
Рассмотрим в качестве примера сетевого приложения Access приложение "Игра в доминирование". Далее в этой главе на данном примере будут проиллюстрированы основные особенности разработки и использования сетевых приложений. Готовое приложение приложение "Игра в доминирование" находится на компакт-диске с примерами к комплекту книг о Microsoft Office 2002 издательства "БХВ – Петербург". Полное описание приложения, в том числе и руководство по его установке, содержится в приложении 2.
Демонстационный пример сетевого приложения "Игра в доминирование" был разработан нами (конкретно В. Михеевой) еще в предыдущей версии Access 2000, и для иллюстрации этой главы в новом издании книги он был сохранен полностью. Тому есть две причины. Во-первых, в новой версии Access 2002 реализована полноценная поддержка формата баз данных предыдущей версии. Во-вторых, в новой версии Access 2002 не появилось особых новшеств, касающихся совместной работы с приложениями Access в сети. Основным новшеством в этом аспекте является введение широкой поддержки формата XML, в который могут быть преобразованы практически все виды объектов базы данных и проектов Access 2002. Но формат XML не является частью баз данных. Скорее, его можно назвать альтернативным представлением данных в универсальном формате для их использования в Web в масштабах глобальных и корпоративных сетей. (Об XML подробно рассказано в гл. 12.)
Рассмотрим здесь кратко, в чем заключается суть приложения "Игра в доминирование". Общая идея в реализации этого приложения является типичным примером проектирования сетевых приложений.
Правила игры
"Игра в доминирование" – это состязание между несколькими игроками за захват максимальной части игрового поля. Поле состоит из клеток. Каждая клетка может быть занята одним из игроков на некоторых определенных игрой условиях. Чтобы занять некоторый участок поля, игрок делает ход. Ход может быть принят или отвергнут, в зависимости от того, занята ли эта или смежные клетки другим игроком в соответствии с принятыми правилами. Все игроки имеют общий доступ к полю и стремятся занять клетки одновременно. За занятые клетки игроку присуждаются очки. Кто успеет набрать большее число очков, тот и победитель.
Сетевое решение в реализации архитектуры приложения
Даже из столь абстрактного описания логики игры можно сделать выводы о том, что архитектура приложения должна представлять собой несколько компонентов, взаимодействующих между собой в сети. Вот основные характеристики задачи, которые являются аргументами в пользу сетевого решения:
- у приложения несколько пользователей, работающих с общими данными (игровым полем), т. е. в задаче требуется многопользовательский доступ к общим данным;
- всю задачу можно разделить на относительно независимые подзадачи (ход игрока, решение о принятии или непринятии хода, ведение счета очков т. п.), которые могут выполняться параллельно или последовательно (по очереди);
- каждая из выделенных подзадач – это отдельный компонент приложения;
- каждый компонент может выполняться на отдельном вычислительном узле в сети, при этом некоторые компоненты могут быть объединены на одном узле сети, т. е. приложение может быть распределено по узлам сети.
Таким образом, наше приложение имеет многокомпонентную, или так называемую многоуровневую архитектуру. Для таких задач типичным решением бывает обычно двух- или трехуровневая архитектура, когда приложение состоит из двух или трех типов взаимодействующих компонентов, среди которых выделяются: "обслуживающие" и "потребляющие" компоненты (серверы и клиенты). Серверный компонент может обслуживать от одного до нескольких клиентов одновременно. При необходимости вводят третий тип компонента – "промежуточный" серверный компонент между клиентским компонентом и основным серверным компонентом, чтобы разгрузить слишком нагруженный логикой обработки данных основной серверный компонент.
Замечание
Большее количество уровней встречается реже, обычно в области специализированных сетевых и коммуникационных задач.