Модели обработки запросов пользователя.
- Введение.
- Функциональность системы
- Использованные технологии и инструменты
- Взаимодействие клиента с системой
- Система обработки запросов пользователей в проекте "Интернет-магазин".
- Заключение.
Приложение 2. Класс Handler.
Приложение 3. Класс ItemDispatcher.
Приложение 4. Класс ShopResponse.
Введение.
Если на начальном этапе своего развития Интернет служил лишь для общения и распространения некоммерческой информации, сегодня уже очевидно, что сетевые технологии могут успешно использоваться и в коммерческих целях. Как показывает статистика, в 1999 году около 600 тыс. фирм продавали свои товары и услуги через Интернет, что на 65% больше, чем в 1998 году.
Первыми в сети несколько лет назад появились розничные электронные магазины типа B2C (business-to-customers), нацеленные на конечного потребителя. Затем быстро стали развиваться сайты B2B (business-to-business), предназначенные для корпоративных покупателей. В настоящее время объемы заказов на покупку через Интернет уже значительны и растут стремительными темпами.
К настоящему моменту около 40% всех Интернет-пользователей (более 100 млн. человек) совершили хотя бы одну покупку в онлайновых магазинах. В 1999 году объем розничных продаж в Сети составил около 40-50 млрд. долл. Сейчас наибольший прирост имеет категория сайтов розничной продажи в Интернет (52% за полгода). Увеличивается также доля пользователей, посещающих эти сайты (в первой половине 1999 года - 31%, во второй - 41%).
В 2000 году клиентами электронных магазинов стали около 75% всех постоянных пользователей. Покупки в сети сделали около 28,4 млн. семей, из них 11 млн. - впервые. Общие доходы электронной коммерции, с учетом корпоративных продаж, достигли 130 млрд. долл., что составило около 0,4% от всех мировых продаж (31 трлн. долл.). Данному росту, помимо увеличения числа пользователей сети, способствует и появление большого количества новых Интернет-магазинов.
Несмотря на кризис в области высоких технологий, в России развитие электронной коммерции продолжается значительными темпами. В начале этого года в Саратове начал функционировать проект интернет-ряда, включающий в себя шесть магазинов различных компаний.
В конце прошлого года в рамках курса маркетинга нашей группой было проведено исследование перспектив развития электронной коммерции в Саратове. На основании этого исследования был сделан вывод о недостаточном распространении интернет-торговли, причем одним из основных факторов этого (главным, конечно, является низкий уровень интернетизации общества) было выделено отсутствие широкого предложения на этом рынке. То есть покупатели готовы попробовать покупать товар через интернет, но инфраструктура, обеспечивающая такую возможность, находится в зачаточном состоянии.
На основании статистики о развитии систем электронной коммерции и прогнозов специалистов о значительном увеличении спроса на подобные системы и родилась идея сделать проект, посвященный торговле через Интернет. При реализации этого проекта преследовалось несколько целей:
- изучение и практическое применение современных технологий проектирование и программирования сложных информационных систем
- накопление опыта и наработок в области интернет-программирования
- расширение портфолио нашей команды.
Функциональность системы.
Модуль редактирования.
Содержимое Интернет-магазина не остается неизменным - появляются новые товары, новые категории товаров, изменяются существующие товары или товары снимаются с продажи. Для внесения требуемых изменений в информационное наполнение Интернет-магазина необходима должность редактора, а также набор инструментов для его работы.
Взаимодействие редактора с содержимым базы данных Интернет-магазина осуществляется через Web-интерфейс. Редактор, используя обычный браузер (например, Internet Explorer, Netscape Navigator), получает доступ к просмотру и изменению всей необходимой информации. Доступ может осуществляться либо прямо на сервере Интернет-магазина, либо удаленно через Интернет.
Модуль редактирования предоставляет редактору набор инструментов для обработки базы данных Интернет-магазина. При помощи инструментов управляющий регистрирует редактора в системе. При входе редактора в систему происходит авторизация доступа с целью предотвращения несанкционированного редактирования базы данных.
Необходимые навыки редактора.
Для управления базой данных редактор должен обладать следующим набором
знаний:
- Профессиональное использование персонального компьютера.
- Профессиональное машинное печатание.
- Общие знания в области сетевых технологий и особенно Интернет.
- Общие знания о структурах баз данных, сущностях и их взаимосвязях.
- Умение использовать прикладное программное обеспечение, в частности - Web-браузер, текстовый редактор, электронные таблицы.
- Общие знания в тематической сфере Интернет-магазина.
- Общие знания по иерархическим структурам данных
Основные функции редактора.
Основными функциями, выполняемыми редактором, являются следующие:
- Редактирование товаров
- Добавление нового товара
- Изменение существующего товара
- Удаление товара
- Присоединение товара к определенной категории
- Перемещение товара из одной категории в другую
- Исключение товара из категории
- Копирование или вырезание товара с последующей вставкой его из буфера
- Редактирование категорий
- Добавление новой категории
- Изменение существующей категории
- Удаление категории
- Включение в категорию определенного товара
- Исключение товара из категории
- Перемещение категории по каталогу
- Копирование или вырезание категории с последующей вставкой её из буфера
Ниже эти функции будут рассмотрены подробнее.
Добавление нового товара (категории).
Добавление в базу данных информации о новом товаре или категории происходит
путем заполнения формы в окне Web-браузера. Заполненная форма проверяется
на грамматическую правильность заполнения, а также на наличие в базе данных
этого товара (категории).
Изменение информации в базе данных.
В случае неверного ввода информации в базу данных или её изменения необходимо
произвести модификацию базы данных. Для этой цели редактору предоставляется
специальный инструмент. Редактор может, выбрав товар или категорию, получить
из базы данных полную информацию о них, внести в неё необходимые изменения
и обновить сведения в базе данных.
Удаление товара (категории).
В процессе работы Интернет-магазина товар может быть снят с продажи или
закончиться на складе. В этот момент необходимо изменить информацию, предоставляемую
пользователю.
Изменение структуры каталога.
В процессе развития системы необходимо модифицировать структуру каталога
товаров - переносить подкатегорию из одной категории в другую, переносить
товар в нужную категорию. Для этого также предусмотрены специальные инструменты
редактора.
Возможности несанкционированного доступа и их предотвращение.
При работе редактора возможны следующие области несанкционированного доступа:
- Вход в систему постороннего пользователя как редактора.
С целью уменьшения возможности такого доступа система регистрации и авторизации редакторов отделена от системы регистрации и авторизации пользователей-клиентов Интернет-магазина. Возможно обеспечение работы этой системы только на определенных рабочих станциях. В случае если взломщик системы получил доступ ко входу в систему, существует дополнительная защита в виде шифровки его пароля, а также ограниченного числа возможностей ввода пароля. Эти и другие системы защиты описаны более подробно и реализованы в модуле безопасности. Кроме этих систем безопасности существует возможность отслеживать действия редактора и делать их откат, что позволяет вовремя обнаружить несанкционированный доступ в систему и вычислить взломщика. - Передача данных по сети.
При передаче данных через Интернет возможен их перехват, перенаправление или изменение. Для предотвращения этого существует система кодирования передаваемых данных, а также система проверки контрольных сумм передаваемых данных.
Система отслеживания действий редактора.
Для обеспечения безопасности изменений базы данных и создания отчетов по действиям редактора в систему введена функция протоколирования действий редактора. Каждое действие редактора сохраняется в базе данных. По этой записи можно установить редактора, который произвел действие, тип действия, дату и время действия. На основании этих записей системой создаются отчеты о деятельности редакторов, а также производится откат ненужных действий на основе использования резервных копий базы данных.
Матрица ELM (матрица списка событий), построенная для редактора информационной системы имеет следующий вид:
| № | Описание события | Реакция на событие |
|---|---|---|
| 1 | Редактор желает добавить товар | Предоставить форму для добавления товара |
| 2 | Редактор добавляет товар | Проверить правильность заполнения формы, добавить товар в базу данных, выдать подтверждение |
| 3 | Редактор желает добавить категорию | Предоставить форму для добавления категории товаров |
| 4 | Редактор добавляет категорию | Проверить правильность заполнения формы, добавить категории товаров в базу данных, выдать подтверждение |
| 5 | Редактор включает товар или подкатегорию в категорию | Предоставить выбор категории, произвести изменения в базе данных |
| 6 | Редактор удаляет товар | Предоставить выбор товара, произвести изменения в базе данных |
| 7 | Редактор удаляет категорию | Предоставить выбор категории, проверить категорию на пустоту, произвести изменения в базе данных |
| 8 | Редактор изменяет товар | Предоставить выбор товара, форму его редактирования и произвести изменения в базе данных |
| 9 | Редактор изменяет категорию | Предоставить выбор категории, форму её редактирования и произвести изменения в базе данных |
| 10 | Редактор скрывает товар | Предоставить выбор товара, произвести изменения в базе данных |
| 11 | Редактор скрывает категорию | Предоставить выбор категории, произвести изменения в базе данных |
| 12 | Управляющий регистрирует редактора | Предоставить форму регистрации редактора, проверить на наличие такового в системе, зарегистрировать редактора в системе |
| 13 | Управляющий требует отчеты (о деятельности редактора, о добавленных, удаленных, измененных и скрытых товарах и категориях) | Предоставить выбор отчета, его формы, вывести на экран компьютера или на печать. |
Модуль управления.
Кроме редактора в системе электронной коммерции нами была выделена ещё одна роль - менеджер. Менеджер осуществляет управление магазином, ценами и выставленным набором товаров. Его деятельность отличается от работы редактора, который отвечает за наполнения базы данных магазина, оформление товаров и т.п. Роль менеджера подразумевает другой уровень ответственности и объем работы. По этим причинам роли менеджера и редактора были разделены.
Основными функциями менеджера являются следующие:
- Изменение цены товара, определение скидок. Динамично меняющаяся рыночная ситуация накладывает необходимость в возможности быстро управлять ценами на товары. Кроме того, менеджер должен иметь возможность устанавливать отдельную ценовую схему для каждого пользователя
- Управление выставленным товарным рядом. Часто необходимо, чтобы товар остался в системе, но был скрыт от покупателя (например, фирма хочет "придержать" товар пару недель, а потом выставлять на продажу). В этом случае менеджер может просто отключить предоставление информации о товаре и его наличии пользователю, не удаляя товар из системы. Соответственно, в нужный момент менеджер снова может выставить товар на сайте. При работе возможно появление необходимости в удалении или скрытии целой категории товаров. Скрытие категории возможно при наличии в ней товаров, при этом товары, которые входят только в эту категорию тоже становятся недоступными пользователю.
Доступ менеджера к системе должен быть обеспечен продуманной системой безопасности.
Использованные технологии и инструменты.
Использованные технологии.
В процессе разработки интернет-магазина был использован ряд технологий разработки и программирования информационных систем. Все они основаны на Java-технологии и обладают рядом её преимуществ. К ним относятся:
- объектная ориентированность
- кроссплатформенность
- компонентная модель
Язык Java 2 полностью поддерживает технологию Java. Он использовался для написания всех модулей программы. Благодаря его использованию удалось абстрагироваться от низкоуровневого программирования и сосредоточится на проектировании системы, методах обработки запросов пользователя и других абстракциях высокого уровня. Язык является полностью объектно-ориентированным, строго типизированным языком. Когда говорят об объектно-ориентированном языке программирования, предполагают поддержку трех механизмов:
- инкапсуляция
- наследование
- полиморфизм.
Инкапсуляция и наследование в языке Java реализуются с помощью понятия класса. С развитием Web-технологий особенности языка Java сделали его одним из наиболее популярных как для разработки клиентских приложений, так и для серверных классов. Более подробное описание использованного языка выходит за пределы данной курсовой работы.
JSP1.1 - это основанная на Java технология, которая позволяет создавать Web-приложения, содержащие странички HTML, DHTML или XML с динамически создаваемым содержанием. JSP позволяет создавать подобные проекты максимально просто, но в то же время гибко и легко масштабируемо. Технология имеет ряд особенностей, дающих ей преимущества при разработке крупных информационных систем:
- WORA(Write Once Run Anywhere). Странички, созданные с использованием технологии JSP, могут быть легко перенесены с одного сервера на другой, либо быть доступны с любого браузера.
- Разделение статичного и динамического содержания. JSP-технология позволяет отделить статическое и динамическое наполнение документов, что упрощает взаимодействие между дизайнерами и разработчиками и позволяет более просто модифицировать существующие наработки.
- Поддержка компонентной технологии. JSP поддерживает использование таких технологий, как Java Beans, Enterprise Java Beans и библиотеки тегов.
Сервлеты - это компоненты Web-приложений, генерирующие динамический контекст. Они представляют собой небольшие платформенно-независимые Java-классы, скомпилированные в байт-код, динамически загружаемые и выполняющиеся на Web-сервере. Сервлеты взаимодействуют с клиентом по схеме запрос-ответ. Эта модель основана на спецификации протокола HTTP. Сервлеты имеют ряд преимуществ перед другими технологиями генерирования динамического контента. Вот некоторые из них:
- сервлеты быстрее CGI скриптов из-за поддержки многопроцессовой модели обработки запросов.
- Сервлеты основаны на стандартном API, поддерживаемом многими серверами.
- Сервлеты имеют весь комплекс преимуществ технологии Java.
- Сервлеты имеют доступ и могут свободно взаимодействовать с любыми другими Java-приложениями.
Для доступа к данным в системе использовался мост JDBC-ODBC. JDBC (Java Database Connectivity) является не протоколом, а интерфейсом и основан на спецификациях SAG CLI (SQL Access Group Call Level Interface - интерфейс уровня вызова группы доступа SQL).Сам по себе JDBC работать не может и использует основные абстракции и методы ODBC. Хотя в стандарте JDBC API и предусмотрена возможность работы не только через ODBC, а и через использование прямых линков к базам данных по двух- или трехзвенной схеме, эту схему используют гораздо реже, чем повсеместно используемый JDBC-ODBC-Bridge занимающий центральное место в общей схеме взаимодействия интерфейсов. Существует ряд причин, по которым нежелательно использовать непосредственный доступ к ODBC из Java программ.
- ODBC нельзя использовать непосредственно из Java, поскольку он основан на C-интерфейсе. Вызов из Java C-кода нарушает целостную концепцию Java, пробивает брешь в защите и делает программу труднопереносимой.
- Перенос ODBC C-API в Java-API нежелателен. К примеру, Java не имеет указателей, в то время как в ODBC они используются.
- ODBC слишком сложен для понимания. В нем смешаны простые и сложные вещи, причем сложные опции иногда применяются для самых простых запросов.
- Java-API необходим, чтобы добиться абсолютно чистых Java решений. Когда ODBC используется, то ODBC-драйвер и ODBC менеджер должны быть инсталлированы на каждой клиентской машине. В то же время, JDBC драйвер написан полностью на Java и может быть легко переносим на любые платформы от сетевых компьютеров до мэйнфреймов.
JDBC API - это естественный Java-интерфейс к базовым SQL абстракциям и, восприняв дух и основные абстракции концепции ODBC, он реализован, все-таки, как настоящий Java-интерфейс, согласующийся с остальными частями системы Java.
При обработке запросов пользователей использовалась модель MVC. Более подробному описанию взаимодействия клиента с системой на основе этой модели и посвящена данная курсовая работа.
Использованные СУБД и ПО.
Использовалась в качестве СУБД. Осуществляет поддержку основных типов данных, каскадные операции и обработку транзакций.
Использовалась в процессе разработки и для создания отдельной версии. Обладает более быстрым по сравнению с MS Access способом доступа (через "родные"(native) методы), но не поддерживает ряд особенностей, таких как логический тип данных и обработку транзакций.
Использовался как самостоятельный web-сервер для приема и обработки запросов. Обладает рядом особенностей, среди которых наиболее важными для нас являются следующие:
- полностью поддерживает спецификацию JSP 0.92
- самостоятельно компилирует скрипты в байт-код для JVM.
- позволяет настраивать переменные Web-окружения для работы сервлетов.
- поддерживает многопоточные приложения (в том числе JSP) на основе модели синхронизации Java.
- сохраняет в пуле соединения с базой данных (через JDBC) и предоставляет их приложениям.
Кроме этих объективных факторов, определивших выбор данного сервера, была учтена также хорошая скорость обработки запросов и общей работы Resin.
Стандартный набор инструментов, применяемый при разработке Java-приложений. Разработан компанией Sun и полностью поддерживает всю функциональность языка Java. Содержит компилятор, виртуальную машину, инструмент для генерации документации и ряд других необходимых программ. Кроме того, включает в себя замечательную документацию Java API. В процессе разработки использовался компилятор jikes, не входящий в состав JDK 1.3. Он существенно быстрее выполняет компиляцию в байт-код и создает файлы лишь немного большего размера.
Инструмент для разработки и отладки Java приложений от компании Omnicore. Поддерживает большинство необходимых для написания классов функций, выделяет синтаксис и осуществляет проверку правильности программы непосредственно по время её написания (как MS Word грамматику и орфографию). Работает на Windows (95/98/NT SP3.0/2000), Linux (kernel 2.2 и glibc 1.1), Solaris-Intel.
Всё программное обеспечение использовалось в виде бесплатных релизов, разрешенных для некоммерческого использования.
Взаимодействие клиента с системой.
Система взаимодействия клиента и системы занимает важное место в общей структуре любой информационной системы. От правильности разработки этой части зависит жизнеспособность системы в целом, возможность её поддержки и расширения. При разработке Web-систем получение, обработка запросов клиента, генерация ответа становятся ещё более значимыми частями проекта. Существует ряд факторов, которые влияют на разработку системы взаимодействия и которые необходимо учитывать при проектировании. К ним относятся:
- множество альтернативных программных продуктов, используемых для взаимодействия с системой и, как следствие, неопределённость в представлении информации клиенту. В связи с этим при проектировании необходимо делать подсистему внешнего управления более мобильной и независимой от остальных частей системы. Правильно спроектированная система может быть быстро модифицирована под изменяющиеся требования и стандарты пользовательского интерфейса.
- Существование нескольких ролей пользователей одной и той же системы.
Так, например, в интернет-магазине возможно выделение ролей пользователя,
редактора, администратора, менеджера и оператора приема заказов. Каждой
из этих ролей соответствует свои особенности, влияющие на проектирование
и реализацию интерфейсов
- Приоритетные показатели системы. Для клиента основными показателями являются удобство использования, эстетическая привлекательность, а также соответствие общим стандартам управления, в то время как для редактора приоритетным можно считать время доступа и возможность удобного и полнофункционального управления системой.
- Различные уровни безопасности доступа. Все пользователи системы взаимодействуют с одними и теми же данными, поэтому разделение прав и авторизация при доступе к просмотру и модификации данных имеют большое значение для устойчивости и безопасности системы. Более подробно аспекты безопасности системы рассмотрены в работе Константина Шуткина. Здесь ещё хотелось бы отметить значительное влияние системы безопасности на проектирование интерфейсных элементов и моделей обработки запросов пользователей.
- Распределённость пользователей и их удаленность от ядра системы. Здесь поднимаются вопросы об идентификации пользователей и обеспечение быстрой и безопасной транспортировки данных между пользователем и системой.
На стадии анализа системы необходимо учесть множественность клиентских интерфейсов. Кроме того, затраты на введение в систему новой роли со своими правами и функциональными возможностями должны быть сведены к минимуму.
Модель Model-View-Controller.
Для уменьшения количества дублирующегося кода, снижения вероятности ошибок реализации принято разделять три основные уровня систем подобного типа - Модель - Представление -Обработчик (Model-View-Controller - MVC). При реализации системы использовалась одна из модификаций данной парадигмы, разработанная с учетом специфики системы. Мною реализовывались интерфейсы и системы взаимодействия для ролей редактора и менеджера, которые отличаются значительным количеством операций с системой, поэтому применение модели было необходимо и сильно упрощало расширение и поддержку системы.
Таким образом, система было распределена между тремя уровнями:
Рассмотрим подробнее каждый уровень и его реализацию в представляемом проекте. Особое внимание будет уделено обработке запросов пользователей. Это связано с его важностью именно в реализованных мною интерфейсах редактора и менеджера, а также со спецификой его реализации в данной системе.
Модель представляет собой набор классов, разделяемых всеми интерфейсами системы. Модель - эта абстракция реальной области системы, включающая в себя данные системы и набор правил бизнес-логики для изменения этих данных. Модель данных не зависит от возможных клиентских интерфейсов и вариантов предоставления информации пользователю. Хотя доступ к данным может осуществляться различными путями, обычно классы модели реализуют один способ доступа к хранилищу данных, который разделяется между пользователями системы. В нашей системе непосредственный доступ к данным осуществляется классами DAO.
Пользователь абстрагируется от особенностей доступа к данным, что дает возможность более простого переноса системы с одной среды на другую и смены типа хранилища данных. С этой целью были реализованы классы Bean, через которые и осуществляется доступ пользователя к данным.
Так как различные пользователи имеют различный уровень доступа к возможностям управления данными, то возможна реализация "оболочек" для классов доступа к данным, которые обеспечивают авторизацию пользователей, проверку прав доступа и валидацию изменений данных. В качестве последних в системе применялись классы CheckBean, осуществляющие проверку правильности заполнения полей сущности.
Представление данных является одной из наиболее значимых для пользователей частей системы. Эта часть наиболее сложно поддается совместному использованию различными ролями пользователей системы. Это обусловлено различием в функциональных возможностях ролей клиентов и смещением приоритетов для каждой роли. Однако, несмотря на это возможно выделение сходных частей интерфейсов пользователей системы. Например, хотя роли редактора, менеджера и клиента очень сильно различаются по функциональным возможностям, но все они в интернет-магазине основаны на Web-интерфейсе, что обеспечивает их сходство и дает возможность повторного использование каких-либо компонентов и блоков дизайна.
При разработке интернет-магазина для реализации представления данных пользователю использовались технологии Servlets и Java Server Pages (JSP). С помощью этих java-технологий возможно легкое представление динамически меняющегося контента данных и осуществление приема запросов пользователя на изменение данных. Более подробно технологии описаны в работе Николая Малеванного.
Контроллер определяет поведение всей системы и для каждой функциональной роли необходимо создание своего собственного контроллера. Например, абсолютно обоснованно разделение контроллеров для редактора и клиента. Однако в отличие от уровня view контроллер часто подвержен использованию несколькими ролями в системе. Это обусловлено возможностью выполнения одних и тех же функций несколькими ролями. В таком случае возможно разделение функциональности контроллера.
Правильно спроектированная система отделяет процесс обработки запросов от представления данных пользователю. Это позволяет увеличить коэффициент повторного использования для элементов контроллера.
Основными направлениями работы контроллеров являются следующие:
- интерпретация запросов пользователя, сгенерированных с помощью уровня представления.
- выбор представления для ответа (response), выданного моделью.
Интерпретация запросов пользователя имеет ряд особенностей. Для работы с системой могут применяться различные интерфейсы пользователей и, соответственно, различные события, отсылаемые на обработку контроллеру. Так, например, для обычных приложений, такими событиями могут быть "нажатие клавиши" или "клик мышкой", а для Web-приложений - запросы (request) пользователя, направленные методом POST, GET или PUT на определенный порт сервера. Естественно, необходимо отделить процесс обработки запроса от типа его передачи. Для этого приходящие запросы перед обработкой транслируются во внутренние запросы - бизнес-события, которые уже и обрабатываются. Данная схема была применена и в рассматриваемом проекте, что позволило более четко распределить функции элементов системы и оставило возможность для легкого расширения. Более подробно схема обработки запроса будет рассмотрена ниже.
Таким образом, примененная схема MVC выглядит следующим образом. Схема
отображает основные функции каждой из частей системы, основные технологии
и типы классов, использованные на данном уровне.
Модульность архитектуры
Одним из главных преимуществ использования архитектуры MVC является возможность осуществить модульное построение программной системы. Модульность построения обеспечивает ряд преимуществ, таких как
- расширяемость
- большая управляемость
- гибкость
- возможность повторного использования
- возможность интеграции
Все эти преимущества являются первостепенно важными для программных систем в области Web, работающих в распределенных гетерогенных средах в условиях быстрого изменения состояние окружения.
В разработанной системе электронной коммерции применение модульной структуры позволило без линейного увеличения сложности увеличивать функциональность системы, использовать разделяющиеся (shared) модули для организации различных пользовательских функций, а также контролировать уровень доступа к системе. Модульная структура системы имеет следующий вид:
Обработка запросов пользователя.
Система обработки запросов пользователя позволяет отделить бизнес-логику программного продукта от использования и внешнего представления данных. С увеличением системы, расширением её функциональных возможностей необходимость в правильно спроектированной системе обработки запросов резко возрастает. Для серьёзных программных систем с большим количеством ролей пользователей, разнообразными интерфейсами и развитыми возможностями взаимодействия с пользователем обработка запросов выходит на первый план при проектировании. В разрабатываемом интернет-магазине модулями, наиболее нуждающимися в системе обработки запросов, являются мои модули редактора и менеджера. Это обусловлено следующими их особенностями:
- значительное количество реализуемых функций
- необходимость авторизации каждого запроса
- необходимость в сохранении данных и их перенос между запросами и между сеансами работы
- требования динамического представления данных и определения шаблонов выдачи данных
- возможность развития функциональных модулей системы в процессе разработки и дальнейшего сопровождения
В процессе проектирования мною были выделены особенности, которые необходимо учитывать при разработке системы обработки пользовательских запросов. Основными задачами данной системы являются:
- отделить бизнес-логику системы от внешнего представления данных
- обеспечить пользователю устойчивый механизм приема и выполнения запросов
- отделить представление данных и интерфейсную часть системы от принципов обработки запросов
- обеспечить простую возможность для расширения или модификации функциональности системы
- обеспечить возможность контроля над доступом к системе
- обеспечить переносимость и возможность распределения сервера бизнес-логики без изменения представления данных
При принятии решения о той или иной модели обработки запросов было рассмотрено несколько существующих систем. Наиболее интересными представлялись два варианта - momento pattern и модель разработки приложений на основе EJB, предлагаемая Sun.
Стиль обработки запросов клиента Momento pattern предназначен для простого управления взаимодействием между клиентом и моделью данных. Модель отличается простотой реализации и наличием начальных элементов контроля над взаимодействием. Данная модель обычно применяется в системах с небольшим числом возможных действий пользователя и одной-двумя точками входа для запросов.
Система состоит из четырех основных компонентов:
- модель
- форма запроса
- обработчик запросов
- форма повторного ввода
- подтверждение изменений
Взаимодействие происходит по следующей схеме:
- клиент формирует запрос и отправляет его на обработку
- обработчик, получив запрос, осуществляет с помощью классов типа Check проверку правильности и полноты переданных данных для изменения модели. В случае подтверждения возможности модификации модели осуществляется вызов классов Bean для выполнения действий, после чего клиенту выдается подтверждение. Если данные неполные или неправильные, то осуществляется запись сообщений об ошибках во временный буфер (в Web приложениях обычно используются сессия (session) или запрос (request)), после чего управление передается на форму повторного ввода.
- Страничка повторного ввода выводит клиенту сообщения об ошибках, позволяет осуществить новый ввод и процесс повторяется.
Рассмотрим более подробно функции каждого из компонентов модели.
Форма предоставляется клиенту для создания запроса на изменения модели данных. Может быть представлена в виде обычной html или jsp странички с включением элементов управления или обычной гипертекстовой ссылкой. Должна иметь интуитивно понятный интерфейс и быть удобной в использовании и неизбыточной.
Предназначен для проверки правильности запроса и, в зависимости от результата проверки, либо выполняет изменения данных и выдает клиенту подтверждение, либо записывает в буфер сообщения об ошибках и передает управление форме повторного ввода. Может быть реализован либо в виде jsp странички, либо как servlet. Не имеет визуального представления, поэтому использование сервлета более предпочтительно с точки зрения времени выполнения запроса. Однако представление обработчика в виде jsp странички делает более понятным логику переходов между страничками для дизайнера и позволяет изменять направления переходов в процессе дизайна без непосредственной перекомпиляции классов.
Форма берет из буфера сообщения об ошибках, выводит их клиенту и позволяет ему осуществить повторный ввод. Обычно имеет однотипный дизайн с формой начального запроса. Иногда формы повторного и первичного запроса объединяются, а вывод сообщений об ошибках производится только в случае наличия ключа повторного ввода.
Страница подтверждений изменений.
Страница предназначена для уведомления пользователя о произошедших изменениях в данных. Обычно выводит измененные данные или представление верхнего по сравнению с измененным уровня в иерархии данных.
Модель имеет ряд недостатков, которые ограничивают её применение в сложных системах:
- Недостаточная гибкость модели
- Слабое разделение представления данных от их обработки
- Линейное возрастание сложности системы с увеличением функциональных возможностей
- Трудоемкость модификации системы при изменении бизнес-логики или представления данных
Однако, несмотря на эти недостатки, модель достаточно распространена из-за своей простоты и возможностей быстрой разработки обработчиков для небольшого количества функций. В системе интернет-магазина эта модель использовалась для создания первого варианта системы. По мере усложнения системы в модулях редактора и менеджера по описанным выше причинам, мною было решено перейти на другую модель обработки данных, которая представляет собой модификацию модели J2EE компании Sun.
Модель Java 2 Enterprise Edition компании Sun.
Модель представляет собой систему взаимодействующих компонент, основанных на технологии Enterprise Java Beans (EJB). Модель спроектирована специально под EJB, и её применение для иных программных систем является более тяжелым и менее оправданным. Основная структура модели имеет следующий вид:
Рассмотрим назначение компонентов системы.
Front Component (первый компонент).
Компонент, с которым непосредственно работают пользователи. Он принимает все HTTP-запросы к системе. Основными функциями этого компонента является проверка инициализированности всех компонентов системы, необходимых для обработки данного запроса. После подтверждения возможности выполнения запроса, фронт компонент передает его на выполнение обработчику (RequestProcessor).
Request Processor(обработчик запросов).
Связывает приложение и клиента HTTP. Преобразует HTTP-запросы пользователя во внутренние события системы, которые и обрабатываются в дальнейшем. Этот компонент позволяет разработчику сосредоточить все HTTP-запросы в одном месте, транслировать их и производить дальнейшую обработку уже внутренних событий системы. В результате этого EJB уровень оказывается отделенным от типов клиентских запросов.
Web Controller (управляющий Web представлением).
Задачей этого компонента является передача событий, полученных от RequestProcessor, на уровень EJB. Этот компонент следит за уведомлениями EJB-уровня о произошедших изменениях системы и перестраивает пользовательское представление в случае необходимости.
EJB Controller (управляющий EJB уровнем).
Принимает события, переданные Web Controller, и осуществляет вызовы необходимых бинов (beans) для изменения модели согласно произошедшему событию. Компонент также осуществляет контроль над пользовательской сессией и состоянием приложения. После обработки каждого события контроллер возвращает Web контроллеру набор моделей, измененных данным событием, для перестроения представления пользователя. Таким образом, уровень EJB полностью отделен от клиентского представления и только манипулирует данными модели. Это позволяет легко обрабатывать запросы и от Web клиентов, и от обычных приложений.
Данная модель соответствует парадигме MVC и позволяет более просто разрабатывать многофункциональные проекты.
При изучении этой модели очевидна её значительная гибкость и расширяемость. Однако модель "заточена" под EJB, и её применение в других технологиях может быть неоптимальным. Главным недостатком модели в случае применения её к построению нашего интернет-магазина, является, на мой взгляд, подсистема слежения за состоянием модели и изменения её представления. Изменение реализуется следующим образом:
- Клиент делает запрос на изменение
- Запрос конвертируется во внутренне событие и отправляется на обработку
- После обработки осуществляется перестроение всей модели и её представления.
Перестроение всей системы в данной модели является необходимым, так как представление организовано таким образом, что модель представляется целиком, как один неделимый объект, который хранится в приложении. Однако в случае нашего интернет-магазина есть возможность менять представление только той части модели, которая в этом нуждается. Это экономит оперативную память сервера и уменьшает время предоставления данных пользователю. Поэтому применил эту модель для создания системы обработки запросов модулей редактора и менеджера интернет-магазина, модифицировав её под конкретную ситуацию. Таким образом, получалась модель, столь же гибкая и расширяемая, как описанная выше, и, в то же время, более экономичная в отношении серверных ресурсов. В следующем пункте эта модель описывается более подробно.
Система обработки запросов пользователей в проекте "Интернет-магазин".
После рассмотрения описанных выше моделей обработки запросов пользователей мною была разработана собственная модификация этих моделей. Получившаяся модель соответствует стилю MVC и является несколько видоизмененным типом модели J2EE. Модель поддерживает разделение всех модулей на три основные группы - представление, обработка и бизнес-модель.
Общая схема данной модели имеет следующий вид:
Рассмотрим назначение каждого компонента модели:
Translator. Преобразует запросы клиента (в данной системе реализован только прием запросов HTTP посредством интернет) во внутренние бизнес-события системы (query)
Query. Представляет собой внутренние бизнес-события системы. Являются независимыми от клиентского интерфейса и типов взаимодействия клиента с системой.
Handler. Обрабатывает события системы, используя классы, осуществляющие доступ к данным и реализующие бизнес-логику системы.
Response. Ответ системы на запрос пользователя. Генерируется обработчиком событий и является независимыми от интерфейса пользователя. Являются аналогом query на возвратном отклике системы.
Dispatcher. Осуществляет преобразование внутреннего отклика системы на запрос пользователя в представление, соответствующее пользовательскому интерфейсу.
Таким образом, взаимодействие пользователя с системой осуществляется по следующей схеме:
- Пользователь отправляет запрос на просмотр или модификацию данных системы.
- Транслятор принимает запрос пользователя, определяет его тип, осуществляет проверку правильности заполнения данных, необходимых для запроса, после чего преобразует запрос пользователя в одно или несколько последовательных событий системы и передает его на обработку.
- Обработчик получает последовательность внутренних событий системы, посредством классов модели системы обрабатывает события и генерирует отклик. Отклик может содержать результат выполнения операции и информацию, необходимую для выбора следующего представления пользователя.
- Менеджер представления, получив отклик системы, осуществляет выбор и генерацию представления пользователю.
Рассмотрим подробнее функции каждого уровня и их реализацию для системы электронной коммерции.
Транслятор.
Транслятор осуществляет преобразование запросов пользователей во внутренние события системы. В реализованной системе трансляция осуществляется простым "обертыванием" запроса пользователя в оболочку внутренних событий.
Несмотря на своё простое устройство, транслятор осуществляет важную функцию - позволяет отделить обработку запроса пользователя от формы, в которой этот запрос был получен. Если использовать в системе непосредственно HTTP-запросы, то это делает приложение менее гибким и тяжело модифицируемым. Кроме того, если использовать в системе HTTP-запросы, то неизбежно придется ориентироваться на специфическое представление данных в них. В результате такого решения систему станет практически невозможно адаптировать под иной, не HTTP, интерфейс пользователя. Однако сейчас все меньший процент систем имеет единственный путь управления. Более того, быстрое развитие интернета и принципов передачи данных сделает прием и обработку запросов HTTP неактуальными и системы, ориентированные исключительно на их обработку, будет необходимо модифицировать. Перепроектирование систем под новое управление подчас требует больших затрат, чем создание новой подобной системы.
Для упрощения модификации системы и возможности применения одновременно нескольких типов управляющих запросов и производится преобразование запросов пользователя во внутренние события системы.
Авторы некоторых моделей предлагают осуществлять на уровне трансляции первичную проверку правильности данных, пришедших в запросе. Это несколько ускоряет работу системы, однако подобное разделение проверки правильности запроса усложняет систему и делает выполнение правильных запросов более долгим, а правила составления запроса распределенными и более тяжело изменяемыми. Поэтому в разработанной системе реализовывался другой подход. На уровне трансляции проверка правильности не осуществляется. Весь комплекс проверки правильности запроса сосредоточен в их обработчиках. Обработчики проверяют правильность заполнения полей запроса с помощью классов Check. На этом уровне осуществляется проверка не только заполнения обязательных полей и использование допустимых символов, но и контроль над целостностью базы данных. Например, при регистрации проверяется, нет пользователя с данным логином в системе.
У транслирования запроса пользователя во внутренние события системы имеет одну важную особенность. Дело в том, что один запрос пользователя может преобразовываться в несколько внутренних событий. Например, при добавлении новой категории товаров, сначала осуществляется событие - проверка правильности запроса, событие - проверка прав доступа, а потом событие - добавление категории. Такое подробное разделение событий дает большую возможность повторного использования их самих и их обработчиков. Так, например, событие - проверка прав обрабатывается практически одинаково и для менеджера, и для редактора системы. В результате такого подхода транслятор из одного запроса пользователя генерирует упорядоченный набор событий системы. Кроме перечисленных выше, данный подход дает ещё одно преимущество - позволяет отслеживать более мелкие события в системе и фиксировать их. Подобная информация может быть полезна управляющему или владельцу системы. Например, ценность представляет информацию о проценте изменений системы, отклоненных из-за неправильности составления запроса и из-за несоответствия прав доступа.
Сгенерированные транслятором события имеют специальное внутреннее представление, которое будет подробнее рассмотрено ниже.
Событие (query).
Как было рассмотрено выше, запросы пользователей преобразовываются во внутренние события системы. На представление этих событий влияют два основных требования к ним:
- события должны содержать всю информацию, необходимую для выполнения данной операции
- события должны быть абсолютно независимы ни от типа запроса пользователя, ни от платформы, на которой установлена система
Таким образом, все события в системе должны представлять собой экземпляры классов (в терминологии Java), позволяющие однозначно идентифицировать тип события и получить все данные для выполнения операции. В разработанной системе все события (пакет query) должны реализовывать интерфейс Query, имеющий следующий вид:
package im.control.query;
import im.control.buffer.ApplicationBuffer;
import im.control.buffer.SessionBuffer;
public interface Query
{
public String getParameter(String name);
public Object getAttribute(String name);
public SessionBuffer getSessionBuffer();
public ApplicationBuffer getApplicationBuffer();
public byte[] getFile(String name);
}
Данный интерфейс спроектирован на основе обычного Web-запроса, поэтому его методы и названия соответствуют интерфейсу HttpServletRequest пакета javax.servlet.http, однако интерфейс Query абсолютно не привязан к какому либо типу запросов.
Основными методами интерфейса являются методы доступа к данным - getParameter и getAttribute. Различие этих методов заключается в следующем. В качестве параметров обычно передаются открытые, не подлежащие кодированию данные, имеющие отношение непосредственно к операции, которую инициирует запрос. В виде атрибутов запроса обычно передаётся закрытая информация, относящаяся либо к самому клиенту (логин), либо к другим требующим безопасной передачи данным.
В некоторых публикациях, в том числе и в модели J2EE, предлагается для различия между этими типами передачи информации создавать два отдельных интерфейса. Однако, на мой взгляд, это связано с некоторыми издержками, не давая существенных преимуществ. Разделение между атрибутами и параметрами не составляет труда для Web-запросов, так как каждому запросу явно сопоставлен его тип POST или GET (или любой другой тип передачи из оговоренных в спецификации HTTP 1.1). Однако, во-первых, данные часто передаются тем или иным методом независимо от их реального содержания, а во-вторых, разделение на подобные типы запросов осложнено при использовании не Web-запросов. На основании этого мной было принято решение об агрегировании этих типов клиентских запросов в один интерфейс.
Метод getFile является особым аксессором, позволяющим получения из запроса двоичных данных.
Кроме доступа к данным, интерфейс Query описывает два метода для осуществления возможности сохранять и загружать данные из специальных буферов. Более подробно система буферов будет описана ниже.
Разработанная система в данный момент способна принимать только Web-запросы, однако существует возможность простого расширения видов доступа к системе. Для внутреннего представления Web-запроса написан класс RequestQuery (приложение 1), полностью реализующий интерфейс Query.
Таким образом, транслятор генерирует событие RequestQuery и передает его на дальнейшую обработку. Все последующие модули обработки запроса не зависят от переданного им объекта-события, главное - чтобы он реализовывал интерфейс Query.
Обработчики событий (handler).
Обработчик событий получает Query и выполняет непосредственную обработку запроса. При этом он использует классы Bean, реализующие возможность доступа и модификации базы данных. Кроме того, он производит основную проверку правильности заполнения полей, а также проверку логической целостности данных.
Система обработчиков в интернет-магазине выглядит следующим образом. Все запросы поступают на основной обработчик - Handler (приложение 2). В своем методе handleQuery() обработчик определяет тип запроса и отправляет его на дальнейшую обработку более специфическим классам. В разработанной системе таковыми являются классы CatalogHandler и ItemHandler. Они отвечают за обработку запросов к категории товаров и конкретному товару соответственно. Обработчики реализуют все функции системы, описанные выше. Функциям соответствуют частные методы классов-обработчиков.
При проектировании обработчиков следует решать вопрос о степени разветвленности иерархии. Так, существуют два крайних случая:
- каждая функция имеет собственный класс-обработчик
- вся обработка сконцентрирована в одном классе.
Выбор разумного решения зависит от количества функций, реализовываемых системой, и от сложности этих функций. В данном случае была создана двухуровневая иерархия с двумя классами на нижнем уровне. Это позволило разделить различные по содержанию функции и не усложнять систему большим количеством классов.
Часто при обработке того или иного запроса пользователя необходимо поместить данные в области памяти, хранящиеся дольше выполнения запросов. Такими данными могут быть объект - авторизованный пользователь, настройки среды пользователя или любые сущности, нуждающиеся в буферизации. Так, в системе реализуется возможность работы с долговременным буфером - копирование, вырезание и вставка данных из буфера. В Web-приложениях используется три основных типа областей сохраняемости объектов:
- application (приложение). Данные сохраняются на протяжении всей работы приложения.
- session (сеанс, сессия). Данные сохраняются на протяжении сеанса работы пользователя. Индивидуален для каждого пользователя.
- request (запрос). Данные сохраняются в процессе одного запроса.
Однако при использовании этих областей сохраняемости в обработчиках напрямую происходит привязка обработчиков к типу запросов, что практически лишает смысла всю систему. Поэтому была разработана системы буферов, позволяющих сохранять данные на определенный период без прямого доступа к приложению или сессии. Все буферы системы должны реализовывать следующий интерфейс:
package im.control.buffer;
public interface Buffer
{
public void add(String name,Object obj);
public Object getObject(String name);
public void remove(String name);
}
Интерфейс определяет три метода - добавления объекта в буфер, извлечение объекта из буфера и удаление объекта из буфера. Набор методов можно расширить (например, очистка буфера), однако существующие методы полностью обеспечивают функциональность буфера. В системе создано два буфера, реализующих данный интерфейс - ApplicationBuffer и SessionBuffer. Их название и период сохраняемости данных соответствуют объектам Web-приложений. Так как система на данном этапе система реализует обработку только Web-запросов, то эти классы просто "обертывают" существующие объекты. Однако при расширении системы для обработки других типов запросов достаточно просто реализовать дополнительные буферы без изменения системы обработки запросов.
После того, как обработчик завершит выполнение необходимых действий для полученного запроса, он должен вернуть результат операции. Для этого он создает внутрисистемные ответы, которые передаются далее для преобразования в вид, необходимый пользователю.
Ответы (response).
Ответы системы (отклики) являются функциональными дополнениями Query и предназначены для обратной функции - преобразование результатов работы системы в специфический пользовательский вид. Отклики разработанной системы имеют следующий вид:
Все отклики системы являются наследниками класса ShopResponse (приложение 4). Отклики содержать ссылку на внутренний запрос системы, который вызвал данную реакцию, и результат обработки данного запроса. Запрос может быть выполнен успешно или вызвать исключительную ситуацию по той или иной причине. В данной системе реализовано два класса наследника основного отклика - EditResponse и VerifyResponse. Кроме общих параметров откликов системы они содержат специальные поля. EditResponse генерируется при обработке запросов на модификацию сущности в базе данных и содержит уникальный идентификатор сущности. VerifyResponse генерируется при проверке правильности запроса и содержит результат проверки. Возвращается пользователя только в случае обнаружения ошибки, в противном случае осуществляется выполнение непосредственно запрошенного действия, и пользователь получает EditResponse.
Диспетчеры видов (dispatcher).
После генерации системой отклика необходимо преобразовать его в удобное для пользователя представление. Для этого я и использовал систему диспетчеров. В обязанности объектов-диспетчеров входит определение типа результата, возвращаемого системой пользователю, и генерация представления результата.
Тип возвращаемого результата зависит от типа запроса пользователя и полностью соответствует ему, однако в случае необходимости возможно явное указание пользователем типа ожидаемого результата. Это может понадобиться в случаях с разделенными интерфейсами отправки запроса и получения результата. Примером такого запроса может служить заказ клиента на ещё не поступивший товар с условием, что при поступлении товара клиенту будет отослано сообщение по электронной почте и в виде SMS.
Другой важной функцией диспетчера является формирование окончательного представления данных пользователю. Представление может зависеть от роли пользователя в системе или от его персональных настроек. Диспетчер на основании набора данных, предназначенных для передачи пользователю, и определенного шаблона их представления компонует окончательных результат. В качестве компонентов такой схемы могут использоваться наборы включаемых друг в друга JSP-страничек или комбинации XML документов с XSL шаблонами.
В разработанной системе существует два вида диспетчеров, соответствующих обработчикам запросов, - диспетчер категорий и диспетчер товаров. На основании полученного отклика системы диспетчеры выдают название JSP-странички, к которой следует перейти. Внутри JSP-странички осуществляется получение информации о состоянии модели, а также чтение необходимых параметров из сессии, запроса или приложения.
RequestProcessor.
Таким образом, получившаяся система представляет собой набор компонентов, последовательно преобразующих запрос пользователя в ответную реакцию системы. Для общего управления работой системы предназначен класс RequestProcessor.
public class RequestProcessor{
public void processRequest(HttpServletRequest req){
ShopResponse response;
Handler handler = new Handler();
response = handler.handleQuery(new RequestQuery(req));
Dispatcher dispatcher = new Dispatcher(response);
setNextURL(dispatcher.getNextScreen());
}
}
Класс осуществляет последовательных вызов трансляторов, обработчиков и диспетчеров. Метод processRequest() получает запрос пользователя, обрабатывает его и устанавливает имя JSP-странички, к которой необходимо перейти.
Использование данной разработанной мной модели дало нашей команде следующие преимущества:
- централизованный контроль. Сосредоточенность всей обработки в одном месте и отделение её от внешнего представления позволяет легче расширять функциональность системы и контролировать доступ к ней.
- Увеличение повторного использования. Бизнес-логика системы может использоваться всеми компонентами системы, а многие роли пользователей имеют пересекающиеся наборы функций.
- Возможность протоколирования воздействий на систему. Позволяет фиксировать, сохранять и статистически обрабатывать все запросы пользователей к системе. Предоставляет инструменты для отслеживания деятельности пользователей.
- Проверка и обработка исключительных ситуаций. Ошибки, возникающие при обработке запросов, сконцентрированы и могут быть легко обнаружены и обработаны.
- Разделение проекта. Позволяет разрабатывать и изменять отдельные части проекта независимо друг от друга. Это особенно важно при разработке крупных проектов командой из нескольких человек и подразделений.
- Разделение ролей разработчиков. Позволяет раздельно и параллельно работать проектировщикам, разработчикам и дизайнерам с возможностью быстрой компоновки результатов работы.
Заключение.
В результате совместной работы нашей команды была разработана и реализована система электронной коммерции. Мы приобрели опыт разработки подобных систем, овладели практическими навыками программирования сложных информационных систем. Кроме того, данная работа позволила более подробно изучить и прочувствовать преимущества и недостатки применяемых технологий и инструментов.
Лично мною были реализованы модули редактирования информационного наполнения интернет-магазина и управления торговлей. Программные модули, позволяющие удаленно управлять содержимым того или иного информационного ресурса, являются в настоящий момент неотъемлемой частью любой более-менее сложной интернет-системы. Трудно представить управление интернет-магазином, новостной лентой, системой управления разработками и многими другими популярными интернет-ресурсами без возможности удаленного управления контентом системы. Поэтому разработанные и реализованные мной механизмы управления ресурсом через интернет, безусловно, будут полезны в дальнейших разработках.
Кроме полной реализации функциональности модулей, передо мной стояла ещё одна очень важная задача - разработка системы взаимодействия клиента с системой. По мере увеличения функциональности проекта при применении обычных сервлетов - обработчиков запросов сложность системы и размеры программного кода нелинейно увеличивались. Мной было рассмотрено несколько различных моделей обработки запросов клиентов, и после их компиляции была спроектирована собственная модель, наиболее удовлетворяющая требованиям нашей системы. Применение этой модели существенно упростило расширение функциональности системы, понятность и модифицируемость программного кода.
Спроектированная мной модель оказалась достаточно удобной и гибкой, и наша команда успешно применяет её во всех разрабатываемых проектах.
Приложение 1. Класс RequestQuery.
package im.control.query;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpSession;
import javax.servlet.ServletContext;
import im.control.buffer.ApplicationBuffer;
import im.control.buffer.SessionBuffer;
import im.control.ParameterNames;
import im.util.PostedRequest;
public class RequestQuery implements Query
{
private HttpServletRequest request;
private ApplicationBuffer appbuffer;
private SessionBuffer sessionbuffer;
private PostedRequest postreq;
public RequestQuery(HttpServletRequest request){
this.request = request;
if (request.getMethod().toUpperCase().equals("POST"))
postreq = new PostedRequest(request);
}
public void setRequest(HttpServletRequest request){
this.request = request;
}
public String getParameter(String name){
if (request.getMethod().toUpperCase().equals("POST"))
return postreq.getParameter(name);
else return request.getParameter(name);
}
public byte[] getFile(String name){
if (request.getMethod().toUpperCase().equals("POST"))
return postreq.getFile(name);
else return null;
}
public Object getAttribute(String name){
return request.getAttribute(name);
}
public SessionBuffer getSessionBuffer(){
if (sessionbuffer==null){
sessionbuffer = (new SessionBuffer(request.getSession()));
}
return sessionbuffer;
}
public ApplicationBuffer getApplicationBuffer(){
if (appbuffer == null) {
appbuffer=(new ApplicationBuffer
((ServletContext)request.getAttribute
(ParameterNames.APPLICATION)));
}
return appbuffer;
}
}
Приложение 2. Класс Handler.
package im.control.handler;
import java.util.Collection;
import java.util.Iterator;
import im.control.response.*;
import im.control.ParameterNames;
import im.control.query.Query;
public class Handler
{
public Handler(){
}
public ShopResponse handleQuery(Query query){
ShopResponse response = new ShopResponse();
String objecttype = query.getParameter
(ParameterNames.OBJECTTYPE);
if (objecttype.equals(ParameterNames.GROUP)){
response =
(new CatalogHandler()).handleCatalog(query);
}
else if (objecttype.equals(ParameterNames.ITEM)){
response = (new ItemHandler()).handleItem(query);
}
return response;
}
}
Приложение 3. Класс ItemDispatcher.
package im.control.dispatcher;
import im.control.response.*;
import im.control.ScreenNames;
import im.control.ParameterNames;
public class ItemDispatcher
{
public ItemDispatcher(){
}
public String getItemScreen(ShopResponse response){
String action = response.getQuery().
getParameter(ParameterNames.ACTION);
String result="";
if ((action.equals(ParameterNames.CHANGEPRICE))
||(action.equals(ParameterNames.CHANGESTATUS))){
result = ScreenNames.MANAGETOOLS+
ScreenNames.GROUP+"?"+ParameterNames.ID+"="+
response.getQuery().getParameter(ParameterNames.GROUPID);
return result;
}
if (response instanceof VerifyResponse) {
try{
result = ScreenNames.EDITTOOLS+
ScreenNames.ITEMFORM+"?"+
ParameterNames.OBJECTTYPE+"="+ParameterNames.ITEM+"&"+
ParameterNames.ACTION+"="+response.getQuery().getParameter(ParameterNames.ACTION)+"&"+
ParameterNames.ID+"="+response.getQuery().getParameter(ParameterNames.ID)+"&"+
ParameterNames.NAME+"="+response.getQuery().getParameter(ParameterNames.NAME)+"&"+
ParameterNames.COUNTRY+"="+response.getQuery().getParameter(ParameterNames.COUNTRY)+"&"+
ParameterNames.FIRM+"="+response.getQuery().getParameter(ParameterNames.FIRM)+"&"+
ParameterNames.PRICE+"="+response.getQuery().getParameter(ParameterNames.PRICE)+"&"+
ParameterNames.GROUPID+"="+response.getQuery().getParameter(ParameterNames.GROUPID)+"&"+
ParameterNames.DESCRIPTION+"="+response.getQuery().getParameter(ParameterNames.DESCRIPTION);}catch (Exception e){
}
return result;
}
if (response instanceof EditResponse){
if (response.getResult()){
String type = ScreenNames.ITEM;
if ((action.equals(ParameterNames.DELETE))||(action.equals(ParameterNames.CUT))
||(action.equals(ParameterNames.COPY))||(action.equals(ParameterNames.PAST))){
type = ScreenNames.GROUP;
}
result = ScreenNames.EDITTOOLS+type+"?"+
ParameterNames.ID+"="+String.valueOf(((EditResponse)response).getId())+"&"+
ParameterNames.GROUPID+"="+response.getQuery().getParameter(ParameterNames.GROUPID);
}
else
result = ScreenNames.EDITTOOLS+ScreenNames.ABOUT;
}
return result;
}
}
Приложение 4. Класс ShopResponse.
package im.control.response;
import im.control.query.Query;
public class ShopResponse
{
private Query query;
private boolean result;
public ShopResponse(){
}
public ShopResponse(Query query, boolean result){
this.query = query;
this.result = result;
}
public Query getQuery(){
return this.query;
}
public void setQuery(Query query){
this.query = query;
}
public boolean getResult(){
return this.result;
}
public void setResult(boolean result){
this.result = result;
}
}
