МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ КЕМЕРОВСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ Математический факультет Кафедра вычислительной математики ДИПЛОМНАЯ РАБОТА «Хранилище данных» студента 5 курса Линник Константина Станиславовича Специальность 010503 – «Математическое обеспечение и администрирование информационных систем» Научный руководитель: Зав. кафедрой, д.ф.-м.н., профессор Ю.Н. Захаров _____________________ Работа допущена к защите: Работа защищена: "____"_______________2010г. Зав. кафедрой д.ф.-м.н., “____” _____________2010г. профессор Ю.Н. Захаров __________________________ с оценкой _________________ Председатель ГАК:______________ __________________________ __________________________ Кемерово 2010 Содержание Содержание ................................................................................................................................................. 0 Введение ...................................................................................................................................................... 3 Постановка задачи ...................................................................................................................................... 4 Анализ .......................................................................................................................................................... 4 Проектирование .......................................................................................................................................... 7 Репозиторий............................................................................................................................................. 7 Лицензия .................................................................................................................................................. 7 Выбор платформы ................................................................................................................................... 7 Выбор хранилища данных ...................................................................................................................... 8 Map-Reduce .......................................................................................................................................... 9 Клиент ....................................................................................................................................................... 9 FTP Сервер ................................................................................................................................................ 9 Реализация .................................................................................................................................................10 Архитектура ............................................................................................................................................10 Ядро системы .....................................................................................................................................10 IoC контейнер.................................................................................................................................10 Авторизация и аутентификация ...................................................................................................11 Представительский слой...................................................................................................................11 Модель ...............................................................................................................................................12 Данные ...............................................................................................................................................12 Шаблон ...........................................................................................................................................12 Пакет ...............................................................................................................................................13 Пользователь .................................................................................................................................13 Системный документ ....................................................................................................................13 Конфигурация ИС ...............................................................................................................................13 application.properties .....................................................................................................................13 1 applicationContext.xml ...................................................................................................................14 web.xml ...........................................................................................................................................14 Расширение ИС ..................................................................................................................................15 Подготовка интерфейса модели ..................................................................................................15 Реализация интерфейса ................................................................................................................16 Реализация контроллера ..............................................................................................................16 Регистрация в диспетчере ............................................................................................................17 Создание страницы-представления ............................................................................................17 Настройка прав доступа ................................................................................................................17 Пользовательский интерфейс ..............................................................................................................17 Конструктор........................................................................................................................................17 Элементы........................................................................................................................................18 Представления ...............................................................................................................................19 Шаблоны ............................................................................................................................................19 Пакеты ................................................................................................................................................19 Поиск ..................................................................................................................................................20 Пользователи .....................................................................................................................................20 Просмотр ............................................................................................................................................20 Заключение ................................................................................................................................................22 Приложение I. Список литературы ..........................................................................................................23 Приложение II. Глоссарий ........................................................................................................................24 2 Введение В процессе моделирования научных задач и дальнейшего исследования полученных результатов, производится большой объем данных. С ростом объема данных, возрастает время доступа. Необходимо постоянно затрачивать время на поддержание порядка и структуры данных. В противном случае, будет невозможно найти нужные данные за приемлемое время. Главной проблемой является невозможность обобщения различных данных и выделения общей структуры ввиду их разной природы. В итоге результаты хранятся отдельно от данных, могут быть разбросаны в нескольких местах и как следствие теряются. Целью данной работы была разработка Информационной Системы, которая сократила бы усилия, направленные на поддержку структуры данных. Немаловажным является централизация данных, что обеспечит однообразность управления и доступность по сети. 3 Анализ Данные, получаемые в результате моделирования и дальнейшего анализа, имеют схожую структуру в пределах одной задачи. Поэтому необходима возможность группировать данные по задачам. При этом каждой задаче сопоставляется некоторый шаблон, по которому заполняются данные. Поскольку данные имеют разную структуру, то и способ представления этих данных тоже различается, необходимо дать возможность ассоциировать представление с определенным классом задач. Пользователь должен иметь возможность редактировать только свои пакеты данных. Был проанализирован типичный процесс работы над задачей: 1. Подготовка расчетной программы 2. Выбор начальных данных 3. Запуск процесса моделирования 4. Анализ сырых данных 5. Визуализация Как правило, сырые данные занимают большой объем на жестком диске и в дальнейшем используются гораздо реже, чем обработанные данные. Обработанные же данные, такие как графики, результаты визуализации должны быть доступны непосредственно при просмотре задачи. Следовательно, необходим инструмент, позволяющий найти нужные данные, и быстро получить доступ к ним, имея только браузер. Рисунок 1. Пакет данных 4 Основная терминология Пакет — набор метаданных определенного шаблона, а также ассоциированные с ними вложения и данные Метаданные — структурированные данные, созданные по определенному шаблону, с возможностью поиска по ним Данные — множество файлов произвольной структуры, без возможности поиска Вложения — небольшое количество файлов малого размера, хранящихся непосредственно в пакете, для быстрого доступа Шаблон — шаблонная структура данных, на основании которой будут заполняться метаданные Роли В ИС были выделены 4 роли: Администратор — управление пользователями и ролями Расширенный пользователь — создание и модификация шаблона Пользователь — создание задачи, заполнение метаданных, загрузка файлов Гость — просмотр данных, поиск по метаданным Пользователь может одновременно иметь несколько ролей. 5 Постановка задачи Функциональные требования к системе: Спроектировать и реализовать систему, позволяющую пользователям: 1. Создавать шаблоны 2. Хранить и изменять как набор файлов, так и метаданные 3. Производить поиск по метаданным 4. Разделять права доступа к различным частям системы 5. Создавать пользовательские представления данных Архитектурные требования к системе 1. Масштабируемость 2. Модульность 3. Расширяемость 4. Сопровождаемость Системные требования Для работы с системой достаточно браузера и канала связи с сервером, на котором развернута ИС. В качестве FTP-клиента можно использовать встроенные средства операционной системы. Требования к серверу в основном касаются памяти: 300 МБ на жестком диске для первичного развертывания и 256 МБ оперативной памяти для запуска. В дальнейшем требования растут пропорционально объему загруженных данных и количеству пользователей. Сервер должен быть обеспечен каналом связи для обмена данными с пользователями. 6 Проектирование Репозиторий В качестве репозитория для проекта был выбран Google Code1 . Он предоставляет систему контроля ревизий Subversion2, удобный редактор документации с wiki-разметкой, багтрекер. Использование репозитория позволяет осуществлять совместную разработку командой программистов, повышает надежность хранения данных и хранит всю историю изменений кода, позволяя откатиться к любой версии. Также исходный код приложения свободно доступен по сети Internet. Современные среды разработки поддерживают интеграцию с репозиторием и предоставляют удобные инструменты для управления кодом. Лицензия Для размещения проекта в репозитории было необходимо выбрать одну из лицензий, по которой будет распространяться исходный код приложения. В качестве таковой была выбрана Apache Software License 23. Данная лицензия является одной из самых свободных, давая пользователю право использовать программное обеспечение для любых целей, свободно распространять, изменять, и распространять изменённые копии. Еще один повод для выбора данной лицензии — большинство компонентов и модулей ИС распространяются под лицензией ASL2. Выбор платформы В качестве базовой платформы была выбрана Java EE 4 . Java EE является промышленной технологией и в основном используется в высокопроизводительных проектах, в которых необходима надежность, масштабируемость, гибкость. Популярности Java EE также способствует то, что Sun предлагает бесплатный комплект разработки, SDK. Данная платформа построена на идеологии открытости, что позволяет подменить реализацию практически любой её части. Альтернативой является платформа .NET от Microsoft. Возможности данной платформы богаче, но главным минусом является значительная закрытость и отсутствие альтернативных реализаций для многих компонентов платформы. В качестве более высокоуровневой надстройки был использован Spring Framework 5 . Spring обеспечивает решение многих задач, с которыми сталкиваются Java разработчики и организации, желающие создать информационную систему, основанную на Java платформе. Из-за широкой 1 http://code.google.com/p/sdast http://subversion.apache.org 3 http://www.apache.org/licenses/LICENSE-2.0 4 http://java.sun.com/javaee/ 5 http://www.springsource.org/ 2 7 функциональности трудно определить наиболее значимые структурные элементы, из которых он состоит. Spring не всецело связан с Java EE платформой, несмотря на его масштабную интеграцию с ней, что является важной причиной его популярности. Spring Framework — вероятно, наиболее известен как источник расширений, нужных для эффективной разработки сложных бизнес-приложений вне тяжеловесных программных моделей, которые исторически были доминирующими в промышленности. Ещё одно его достоинство в том, что он ввел ранее неиспользуемые функциональные возможности в сегодняшние господствующие методы разработки, даже вне платформы Java. Spring предлагает последовательную модель и делает её применимой к большинству типов приложений, которые уже созданы на основе платформы Java. Считается, что Spring Framework реализует модель разработки, основанную на лучших стандартах индустрии, и делает её доступной во многих областях Java. Выбор базы данных Первоначально планировалось использовать RDBMS PostgreSQL6. В связке с ORM библиотекой Hibernate7. Но в процессе реализации понадобилось поддерживать большое количество классов слоя доступа к данным, код оказался слишком неустойчивым (незначительные изменения в постановке задачи приводили к серьезным модификациям исходного кода). Неструктурированная природа данных плохо подходила к реляционной модели данных. Были рассмотрены альтернативные способы хранения данных и найдено NoSQL СУБД CouchDB8, являющаяся документно-ориентированной. Подобно другим документно-ориентированным СУБД, CouchDB не требует описания схемы данных, и предназначена для работы с полу-структурированной информацией. Отличительная особенность данных СУБД в том, что данные сохраняются не в строках и колонках, а в виде документов в формате JSON, моделью которых является не таблица, а дерево. Типизация отдельных полей не поддерживается. Целостность БД обеспечивается исключительно на уровне отдельных документов, но не связей между ними. Языком выборки данных являются Map-Reduce функции, на языке JavaScript. Главным плюсом является отсутствие требований к единству записей (по аналогии с кортежами в реляционной алгебре). 6 http://www.postgresql.org/ http://www.hibernate.org/ 8 http://couchdb.apache.org/ 7 8 Map-Reduce Подход к обработке данных, пришедший из функциональных языков и позволяющий параллельно обрабатывать большие объемы данных. В CouchDB данный подход используется для построения пользовательских представлений поверх распределенных документов. Ход работы состоит из двух этапов: 1. Map — операция предварительной обработки данных, применение некоторой функции к каждому документу. Поскольку отсутствует side-effect, данный этап легко разделяется на независимые потоки. Результаты данного этапа сохраняются в B-дереве, что позволяет в дальнейшем быстро находить нужные документы. На вход поступает документ, на выходе получаются набор пар Ключ-Значение, которые передаются на следующий шаг. 2. Reduce — опциональная операция свертки данных, поступивших из предыдущего этапа. К данным применяются фильтры для отбора данных по некоторым условиям, подсчета групповых функций. Клиент Доступ к функциональным возможностям программы осуществляется через тонкого клиента — веб-браузер. Данные между клиентом и сервером передаются практически без изменений в формате JSON посредством AJAX запросов. Для визуализации пользовательского интерфейса применяется библиотека JQuery 9 и интерфейсная надстройка JQueryUI10. Данные библиотеки предоставляют богатые возможности по работе со страницей в браузере, передачи данных посредством AJAX. Для доступа на запись к основным данным можно использовать любой FTP-клиент. В гостевом режиме можно использовать любой современный браузер. FTP Сервер Доступ к данным предоставляется при помощи встроенного FTP-сервера Mina11. Данный сервер предоставляет интерфейсы для тесной интеграции с приложением на платформе Java, и может быть сконфигурирован при помощи Spring IoC. Также он запускается вместе с ИС и получает информацию о правах доступа из базы данных, что позволяет упростить управление пользователями и правами, а также сократить избыточность данных. 9 http://jquery.com http://jqueryui.com 11 http://mina.apache.org/ftpserver/ 10 9 Реализация Архитектура Ядро системы IoC контейнер Inversion of Control — важный принцип объектно-ориентированного программирования, используемый для уменьшения связанности в компьютерных программах. Использование данного контейнера в системе позволяет заменять модули и компоненты без необходимости пересборки всего приложения. В качестве контейнера была выбрана реализация Spring IoC. Центральной частью Spring Framework является Inversion of Control контейнер, который предоставляет средства конфигурирования и управления объектами Java с помощью обратных вызовов. Контейнер отвечает за управление жизненным циклом объекта: создание объектов, вызов методов инициализации и конфигурирование объектов путем связывания их между собой. Объекты, создаваемые контейнером, также называются Управляемые объекты или Beans. Обычно конфигурирование контейнера осуществляется путем загрузки XML файлов, содержащих Определение Bean’ов и предоставляющих информацию необходимую для создания bean’ов. Объекты могут быть получены либо с помощью Поиска зависимости, либо Внедрения зависимости. Поиск зависимости — шаблон проектирования, когда вызывающий объект запрашивает у объекта-контейнера экземпляр объекта с определенным именем или определенного типа. Внедрение зависимости — шаблон проектирования, когда контейнер передает экземпляры объектов по их имени другим объектам либо с помощью конструктора, либо свойства, либо фабричного метода. 10 Рисунок 2. Последовательность работы Авторизация и аутентификация Для аутентификации и авторизации и применяется модуль Spring Security, позволяющий не только управлять доступом к тем или иным разделам сайта, но и разграничить доступ к тем или иным методам внутренних интерфейсов системы при помощи аннотаций. Представительский слой Возможности, предоставляемые модулем Spring MVC, оказались слишком велики, поэтому был реализован упрощенный вариант диспетчера. Диспетчер пользовательских запросов конфигурируется при помощи бина urlMapping в applicationContext.xml. Отдельные обработчики должны реализовывать интерфейс IProcessable. 11 Модель В основу интерфейсов модели положен принцип Rich Domain, т.е. публично доступны только методы обработки данных, но не сами данные. Это имеет смысл, поскольку в доменных объектах данные не хранятся, а происходит только обмен данными с базой. Каждый доменный объект реализует соответствующий интерфейс. Исключение составляет интерфейс IUsr, являющийся транспортом информации о пользователях и правах между ИС и FTP сервером, и, как следствие, почти не содержащий логики. Интерфейс Реализация Назначение IAttachment Attachments Предоставление доступа к вложениям в пакеты IFiles Files Обработка директорий при создании новых пакетов IFilter Filter Поиск пакетов по критерию IPackages Packages Управление пакетами ITemplates Templates Управление шаблонами IUsers Users Управление пользователями IUsr Usr Транспортный формат данных для описания пользователя Таблица 1. Интерфейсы модели Данные В базе данных находятся документы трех видов: шаблон, пакет, пользователь. Шаблон { "_id": "_design/имя_шаблона", "_rev": "ревизия", "data": {"Шаблон незаполненных данных"}, "desc": "Краткое описание шаблона", "views": [ { "name": "имя представления", "code": "function(данные_пакета){код, возвращающий строку, преобразованную из исходных данных;}" } ] } Листинг 1. Структура шаблона 12 Пакет { "_id": "идентификатор документа", "_rev": "ревизия", "owner": "логин владельца", "description": "краткое описание", "template": "шаблон", "data": {"данные"}, "_attachments": { "файл.вложение": { "content_type": "image/jpeg", "revpos": 2, "length": 103999, "stub": true } } } Листинг 2. Структура пакета Пользователь { "_id": "идентификатор документа", "_rev": "ревизия", "login": "логин пользователя", "password": "пароль", "name": "Имя пользователя", "roles": [ "admin", "user", "anonymous" ] } Листинг 3. Структура пользователя Системный документ Документ _design/default содержит необходимые системные запросы: filterByOwner — поиск пакетов по имени filterByTemplate — список шаблонов filterByUser— список пользователей Конфигурация ИС В ИС имеются несколько конфигурационных файлов разного уровня. application.properties В данном файле настраиваются параметры доступа к СУБД (адрес, порт, название базы), путь к корневой директории FTP сервера, параметры логгера. Данные параметры могут быть изменены администратором системы. 13 #CouchDB configuration db.host=127.0.0.1 db.port=5984 db.name=hydrodynamics #embedded ftp server configuration ftp.path=d:/Stuff/Temp/ftp Листинг 4. Настройка ИС applicationContext.xml В данном файле описываются конкретные реализации интерфейсов и взаимосвязь между ними, права доступа к разделам веб-интерфейса. Данный файл конфигурации используется IoC контейнером. Всего в файле 6 разделов: 1. Подключение файла свойств application.properties 2. Настройка бинов, реализующих интерфейсы модели 3. Настройка контроллеров, обрабатывающих AJAX запросы 4. Настройка диспетчера и сопоставление строки запроса обработчику 5. Настройка FTP сервера, чтение конфигурации из файла application.properties 6. Настройка прав доступа к разделам веб интерфейса для Spring Security Разработчику системы могут быть интересны разделы 2,3,4,6. Далее будет более подробно рассмотрен процесс добавления нового компонента в ИС. web.xml Самый низкоуровневый конфигурационный файл, в котором подключается и контейнер, FTP сервер, Диспетчер запросов, Диспетчер Модифицироваться будет крайне редко. 14 прав доступа, стартует IoC и логгер. Расширение ИС Рисунок 3. Диаграмма классов Подготовка интерфейса модели Все интерфейсы находятся в пакете org.blazer.sdast.model. Создается интерфейс, содержащий необходимые методы, каждый метод описывается средствами JavaDoc. В интерфейсе перед методами можно задать аннотацию с правами доступа, если аннотации нет, то вызов метода будет доступен всем. 15 public interface IAttachments { @Secured({"IS_AUTHENTICATED_ANONYMOUSLY"}) String getAttachment(String doc, String name); @Secured({"ROLE_USER"}) String putAttachment(String doc, String name, String contentType, String string); } Листинг 5. Настройка доменных прав Реализация интерфейса Создается класс, реализующий ранее созданный интерфейс. Все реализации модели находятся в пакете org.blazer.sdast.model.impl. После этого класс описывается во втором разделе файла applicationContext.xml. <bean name="Packages" class="org.blazer.sdast.model.impl.Packages" > <constructor-arg ref="Database"/> <constructor-arg ref="Files"/> </bean> Листинг 6. Задание реализации интерфейса Здесь name — имя класса, по которому он будет создаваться IoC контейнером, class — имя созданного ранее класса, constructor-arg — аргументы, передающиеся в конструктор, ref — ссылка на имя другого объекта. Если объект должен быть НЕ синглтоном, то в бин нужно добавить атрибут scope="prototype". Реализация контроллера Создается класс, реализующий единственный метод process интерфейса IProcessable, где request и response — полученные диспетчером запрос и ответ соответственно. public String process(HttpServletRequest request, HttpServletResponse response); Листинг 7. Сигнатура метода process Все обработчики находятся в пакете org.blazer.sdast.web. Обработчик описывается в третьем разделе файла applicationContext.xml. В большинстве случаев обработчику будет передана ссылка на объект обслуживаемой им модели. <bean name="JsonTemplates" class="org.blazer.sdast.web.JsonTemplates"> <constructor-arg ref="Templates"/> </bean> Листинг 8. Описание обработчика Также обработчик должен сам задать кодировку, поскольку ниже уровнем, в диспетчере, это не сделано по техническим причинам. response.setContentType("text/javascript;charset=UTF-8"); Листинг 9. Задание кодировки 16 Регистрация в диспетчере Для того чтобы обработчик начал принимать запросы от пользователя, он должен быть зарегистрирован в диспетчере. Диспетчеру передается ассоциативный массив, где ключом является начальный фрагмент запроса, а значением — соответствующий обработчик. <bean name="urlMapping" class="java.util.HashMap"> <constructor-arg> <map> <entry key="/packages.json" value-ref="JsonPackages"/> <entry key="/templates.json" value-ref="JsonTemplates"/> … </map> </constructor-arg> </bean> Листинг 10. Настройка диспетчера Создание страницы-представления В корневой директории создается jsp – страница с пользовательским интерфейсом. Данная страница будет обмениваться AJAX-запросами с контроллером. Интерфейс и пользовательская логика создается средствами HTML и JavaScript. Имеет смысл подключить библиотеку JQuery. Настройка прав доступа Заключительный этап — настройка доступа к представлению. Доступ настраивается в шестом разделе файла applicationContext.xml. Настройка аналогична диспетчеру: ключом является перехватываемый запрос, а значением — список ролей. <sec:http auto-config="true"> <sec:intercept-url pattern="/users.jsp" access="ROLE_ADMIN"/> <sec:intercept-url pattern="/constructor.jsp" access="ROLE_ADVANCED"/> <sec:intercept-url pattern="/pkg.jsp" access="ROLE_USER"/> <sec:intercept-url pattern="/templates.jsp" access="ROLE_USER"/> <sec:intercept-url pattern="/*.jsp" access="IS_AUTHENTICATED_ANONYMOUSLY"/> <sec:http-basic /> </sec:http> Листинг 11. Права доступа Пользовательский интерфейс Конструктор Конструктор доступен только пользователям с ролью расширенный. В конструкторе можно создать новый или отредактировать имеющийся шаблон. Также можно задать пользовательские представления. 17 Рисунок 4. Конструктор шаблонов Элементы В шаблоне могут находиться элементы трех типов: Массив — установлена галочка [V] Строка — примитивный объект, если нет подобъектов Объект — составной объект, если имеются подобъекты Кнопкой (+) добавляются новые элементы в соответствующий уровень, а кнопкой (Х) элементы удаляются вместе со всеми подобъектами 18 Представления Представления создаются анонимной функцией, которая на вход получает данные пакета ( Пакет). Данная функция должна вернуть HTML строку. Внутри функции доступна библиотека JQuery. Если не задано ни одного представления в режиме просмотра будет использовано представление по-умолчанию. Шаблоны В данном разделе представлен список доступных шаблонов, с возможностью добавления новых пакетов либо редактирования шаблона в конструкторе. Данный раздел доступен всем пользователям. Рисунок 5. Список шаблонов Пакеты В данном разделе приведен список пакетов со ссылками на просмотр и редактирование. Также можно отфильтровать по имени шаблона. Данный раздел доступен всем пользователям. Рисунок 6. Список пакетов 19 Поиск В данном разделе можно произвести поиск по пакетам данных. Критерий поиска — выражение на языке JavaScript. Для удобства вместо doc.data.a можно заменить на $a. Поиск является неиндексированным и, поэтому, время поиска увеличивается пропорционально размеру базы. Данный раздел доступен всем пользователям. Рисунок 7. Поиск по пакатем Пользователи Данный раздел доступен только пользователям с правами администратора. Окно состоит из двух частей: списка пользователей, доступных для выбора, и свойств пользователя, таких, как имя, логин, пароль и список ролей. Рисунок 8. Управление пользователями Просмотр Представление по-умолчанию Во всех пакетах доступно представление default, которое просто выводит иерархически все поля пакета. 20 Рисунок 9. Представление по-умолчанию Пользовательское представление Данная функция создает следующее пользовательское представление. function(data){ var str = "<b>"+data.data.str+"</b><br/>"; for(var i=0;i<data.data.obj.length;i++){ str+="<i>"+data.data.obj[i].var+"</i><br/>"; } return str; } Листинг 12. Код пользовательского представления Рисунок 10. Пользовательское представление 21 Заключение Функциональные требования В ИС реализованы были реализованы все функциональные требования: управление шаблонами, пакетами данных, пользователями, имеется возможность создать пользовательское представление. Архитектурные требования Прежде всего, интересна горизонтальная масштабируемость, достигаемая возможностью репликации базы данных и файлов между серверами. Положенный в основу ИС принцип инверсии зависимости обеспечивает модульность системы и взаимозаменяемость отдельных элементов с условием удовлетворения интерфейсам. Публичные интерфейсы обеспечивают расширяемость функциональных возможностей системы. В работе была описана типичная последовательность действий по добавлению нового функционала. Размещение кода ИС в открытом репозитории, с возможностью коллективной работы, багтрекера и wiki-документации обеспечит дальнейшее сопровождение и развитие системы. 22 Приложение I. Список литературы 1. Apache FTPServer documentation [В Интернете]. - 2010 г.. - http://mina.apache.org/ftpserver/documentation.html. 2. Beginning CouchDB [Книга] / авт. Lennon Joe. - [б.м.] : Apress, 2009. 3. JQuery documentation [В Интернете]. - 2010 г.. - http://docs.jquery.com. 4. Spring Framework. Reference documentation 3.0 [В Интернете]. - 2009 г.. - 2010 г.. - http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html. 5. Spring Security. Reference documentation 3.0.2 [В Интернете]. - http://static.springsource.org/spring-security/site/docs/3.0.x/reference/springsecurity.html. 6. Version control with Subversion. [В Интернете]. - 2008 г.. - r3305. - http://svnbook.redbean.com/en/1.5/index.html. 23 Приложение II. Глоссарий Java EE — Java Platform, Enterprise Edition JSON — JavaScript Object Notation NoSQL — класс СУБД, не использующих реляционную алгебру ORM — Object-Relational Mapping, отображение объекта в базе данных RDBMS — Relational Database Management System SDK — System Developer Kit Subversion — Система контроля ревизий с централизованным репозиторием Багтрекер — система учета и контроля ошибок, найденных в программах, пожеланий пользователей, а также слежения за процессом устранения этих ошибок и выполнения или невыполнения пожеланий ИС — Информационная Система, в данном случае Хранилище Данных SDaSt Репозиторий — хранилище исходных текстов вместе с историей их изменения и другой служебной информацией СУБД — Система Управления Базой Данных, в данном случае CouchDB 24