Скачать 176.52 Kb.
Дата04.09.2019
Размер176.52 Kb.

Об одной технологии создания web-интерфейса к программному обеспечению



ОБ ОДНОЙ ТЕХНОЛОГИИ СОЗДАНИЯ WEB-ИНТЕРФЕЙСА К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ

Гудов А.М., Ростовцев Е.А.

Кемеровский государственный университет, Региональный центр новых информационных технологий

good@kemsu.ru, real@kemsu.ru
Введение

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

Перспективность разработки интерфейса к программному обеспечению при помощи web-технологий обеспечивается не только удобством для пользователя (нет необходимости устанавливать и обновлять клиентское программное обеспечение, необходимо лишь наличие web-броузера), но и простотой разработки. Например, для выдачи информации пользователю достаточно использовать такие простые языки, как (X)HTML и CSS2. К сожалению, этих языков недостаточно для создания полноценных приложений в виду их статической природы (нет возможности менять содержимое страниц в зависимости от некоторых условий, а также легко изменять их внешний облик). Для придания web-приложению динамичности (что даст возможность таким приложением ничем не уступать обычным приложениям, основанным на клиент-серверных решениях) необходимо использование более сложных технологий (таких как CGI, JSP, Servlets, ASP...), что может существенно повысить сложность разработки.

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


Архитектура пакета

Архитектура приложений, разрабатываемых с помощью пакета KemsuWeb, состоит как минимум из трех уровней:



  • клиент (web-броузер);

  • промежуточный слой (web-сервер на Java со встроенным пакетом KemsuWeb);

  • сервер базы данных или сервер приложений (например, СУБД Oracle либо IBM WebSphere).

В простейших случаях третий слой отсутствует и приложение «вырождается» до обычного web-сайта.

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

При старте web-сервера происходит инициализация пакета KemsuWeb: считывание и загрузка данных о допустимых переменных сессии для каждого web-приложения, инициализация пулов соединений с СУБД, а также подготовка окружения для взаимодействия с подсистемой защиты.

Типичный процесс выполнения выглядит следующим образом (на примере команды получения данных от СУБД). Клиент посылает запрос на web-сервер (вводит URL в web-броузере). Контроллер запросов находит XML-файл по указанному URL (если такого файла нет, вместо него используется файл 404.htm со стандартным сообщением – "Файл не найден"), извлекает параметры запроса, настраивает нужным образом новый экземпляр анализатора и передает ему управление. Анализатор «проходит» по структуре XML-файла, и, если встречает специальные команды, которые необходимо выполнить за первый «проход» (префикс req, пространство имен http://www.kemsu.ru/xml-request), создает экземпляр соответствующего адаптера и передает ему управление. Адаптер берет соединение из пула (имя соединения указывается в команде) и выполняет запрос (SQL-выражение либо вызов хранимой процедуры). Полученный результат оформляется как XML-фрагмент, который возвращается анализатору вместе с потоком управления. После того, как процесс анализа XML завершается, управление возвращается контроллеру. Контроллер отправляет полученный результат (преобразованный XML) на второй «проход»: XSLT-преобразование. XSLT преобразовывает XML в XHTML, оставляя обычные XHTML-конструкции без изменений. При этом XSLT (main.xsl) может встретить команды «второго прохода» (префикс res, пространство имен http://www.kemsu.ru/xml-response), которые анализируются и выполняются специальным XSLT (default.xsl). Также в основном XSLT могут встречаться запросы к шаблонам структуры приложения для формирования меню, отображения пути к текущей позиции в приложении и т.д. (информация о структуре приложения и функции для доступа к ее элементам хранятся в файле tree.xsl).

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

Рис. 1. Схема выполнения запроса в архитектуре пакета KemsuWeb.
Команды, поддерживаемые пакетом KemsuWeb
Команды «первого прохода»:

Команды доступа к СУБД Oracle. Команда Query предназначена для выполнения SQL-запроса SELECT. Команда Rowset предназначена для выполнения хранимой процедуры. Результатом выполнения обеих команд является набор записей, которыми можно манипулировать как при помощи команд второго прохода, так и при помощи макросов. Команда Call предназначена для выполнения хранимой процедуры, которая возвращает в OUT-параметре некоторое строковое значение.

Пример команды Rowset:







ora_web_test.get_web_test(?)








ID =

NAME =






Команды условного выполнения. Команда If предназначена для выполнения других команд только в случае истинности указанного в команде выражения. Есть возможность составлять сложные логические выражения при помощи дополнительных команд And и Or. Если указанное выражение ложно, есть возможность в таком случае выполнить команды, указанные после дополнительно команды Else.

Пример:












Команда задания Cookie. Команда Cookie предназначена для задания значения Cookie с указанным именем. Все Cookie делаются доступными для всех web-приложений в рамках домена kemsu.ru. Доступ к Cookie осуществляется при помощи соответствующего макроса.

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

Пример:




Команда задания параметров сессии. Команда Session предназначена для задания значения параметра сессии с указанным именем. Имена всех допустимых параметров содержатся в файле session.xml приложения. Доступ к параметрам осуществляется при помощи соответствующего макроса.

Команда рассылки E-Mail. Команда SendMail предназначена для обеспечения простой массовой рассылки сообщений по E-Mail. Для этого соответствующий адаптер подключается к подсистеме почтовых рассылок, откуда берет список адресов, по которым должны быть доставлены сообщения. Обратный адрес и тело сообщения указываются в самой команде либо могут быть извлечены из подсистемы почтовых рассылок.

subject="[{{forum_name}}] {{subject}}"

content="От {{login}} ({{email}}) {{__text__}}"

test="0">



public_news.get_news_emails('{{news_name}}',?)



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

Команды для форума. Данная группа команд предоставляет простой способ ведения форума в приложении путем взаимодействия с подсистемой форумов. При этом есть 2 типа команд: команды вывода и команды ввода. К первому типу относятся команды Forum, ForumSection и ForumThread. Ко второму типу относятся команды AddForumThread и AddForumMessage. Команда Forum предназначена для вывода всех секций указанного форума. Добавление секций не допускается. Команда ForumSection предназначена для вывода всех ветвей заданной секции форума. Новые ветви добавляются при помощи команды AddForumThread. Команда ForumThread предназначена для вывода всех сообщений заданной ветви. Новые сообщения добавляются при помощи команды AddForumMessage.

Команды для разграничения доступа. Команда Secure предназначена для разграничения доступа (путем взаимодействия с подсистемой защиты) к указанному объекту, причем, поскольку с объектами возможно производить несколько операций, то также указывается конкретная операция. При необходимости детализировать разграничение с помощью команды Restriction указываются именованные параметры с конкретными значениями. Значения указываются либо явно, либо при помощи различных макросов.
Команды «второго прохода»:

Команды для работы с результатами команд первого прохода. Когда команды первого прохода возвращают набор записей из СУБД, каждому полю ставится в соответствие имя, обязательно записываемое прописными буквами. Таким образом, имена команд совпадают с именами полей. Для данного случая есть одна особенность: поскольку возвращенных записей может быть несколько, введена возможность организации цикла по всем записям при помощи XML-элемента Execute и вложенных элементов команды первого прохода и команды Result. Именно содержимое элемента Result выступает как тело цикла. Существует возможность древовидного вывода результата, для чего используются дополнительные параметры и команда NextRow. Также есть возможность не указывать имена полей, а работать с ними однотипно, что обеспечивается командами ForEach (внутри помещаются конструкции для каждого поля) и This (сюда будет подставлено значение поля). Номера строк можно вывести при помощи команды RowNum. Если же команда первого прохода возвращает лишь строковое значение, то для вывода результата используется команда RESPONSE. При этом цикл вырождается в обычный блок. Для указанных команд определены необязательные атрибуты: substr для вывода подстроки указанной строки и tidy для преобразования строки в XHTML-фрагмент (поскольку по умолчанию в строке все символы форматирования экранируются, так что клиент будет видеть не сам XHTML-фрагмент, а его исходный код). Для большинства указанных команд существуют варианты для использования внутри XHTML-атрибутов, что часто бывает необходимо.

Пример см. в описании команды первого прохода Rowset.



Команды условного выполнения. Так же, как и в случае команд первого прохода, здесь предусмотрено условное выполнение по принципу if..then..else...




ID не больше 2







ID больше 2








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

Команда задания атрибута. Для явного задания атрибута некоторого XHTML-тэга служит команда Attribute. Она бывает необходима в более простых случаях в сравнении с предыдущим.

Команда перенаправления. Команда Redirect предназначена для автоматического перенаправления броузера на другой URL.

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

Команды включения фрагментов из внешних файлов. Для включения фрагментов из внешних файлов есть две команды: Include и Import. Команда Include предназначена для простого включения внешнего файла, в то время как команд Import включает файл через протокол HTTL, что позволяет указать дополнительные HTTP-параметры.

Пример:








Команда вывода ссылки. Команда Link предназначена для вывода ссылки из файла tree.xsl по заданному имени.
Макросы

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



  1. {{имя}} – подставляет значение параметра HTTP-запроса с указанным именем.

  2. ##имя## – подставляет значение результата выполнения запроса к СУБД. При этом, если было возвращено несколько записей, подставляется значение поля из первой записи.

  3. %%имя%% – подставляет значение Cookie с указанным именем.

  4. $$имя$$ – подставляет значение параметра сессии с указанным именем.

  5. ~~имя~~ – подставляет значение переменной документа с указанным именем.

Помимо всего вышеизложенного, в рамках KemsuWeb определены шаблоны для вывода часто встречающихся XHTML-конструкций, таких как блоки закладок (для многостраничных диалогов) и деревья с возможностью сворачивания-разворачивания ветвей (как в проводнике Windows). Эти возможности реализованы при помощи CSS и JavaScript.
Система защиты

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



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

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

Права. Право (или привилегия) есть объединение двух сущностей: «объект» и «действие». Это подразумевает наличие права на определенное действие над определенным объектом. Кроме того, чаще всего необходимо производить группировку прав для создания ролей. Но намного удобней построить иерархию ролей, следствием чего становится объединение понятий «привилегия» и «роль». Это объединение и подразумевается под «ролью», а «привилегия» - частный случай роли, у которой нет вложенных ролей. Также предусматривается возможность введения дополнительных ограничений (например, пользователь имеет право на выборку данных из таблицы только тех строк, поле ID которых равно 1).

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

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

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

Модель данных. Приведенные выше определения основаны на расширении шаблона модели данных защиты (шаблон используется, в частности, в Windows 2000 или СУБД Oracle) и позволяют построить адаптированную под конкретную компанию модель хранения данных защиты в СУБД.
Архитектура системы.

Несмотря на то, что подсистемы «Разграничение доступа» и «Управление защитой» пользуются одной моделью данных (схема SECURITY), ядро одной из них независимо от другого. «Управление защитой» в качестве стандартного интерфейса предоставляет интерфейс пользователя, основанный на WEB. Подсистема «Разграничение доступа» предоставляет два типа интерфейса: для WEB-приложений (основанных, например, на технологии Java Servlets) с высокой степенью доверительности с системой защиты; для прочих приложений интерфейс в виде пакета процедур СУБД PUBLIC_SECURITY для свободного доступа (шаблон «Фасад»). В последнем случае сессия пользователя обслуживается внутри этого пакета. WEB-приложения с высокой степенью доверительности и «Управление защитой» (также попадающее в данную категорию) обращаются к ядру подсистемы «Разграничение доступа» напрямую (используя основной пакет SECURITY ядра подсистемы в качестве интерфейса), для чего задействуется пакет JAVA-классов SecurityWeb многократного использования; в этом случае сессия пользователя обслуживается пакетом SecurityWeb. Схематически архитектура системы представлена на рис. 2.






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