Разработка интерфейса в виде веб-сервиса для федеральной службы

Размещено на http://www.allbest.ru/

Введение

веб сервис федеральный интерфейс

Управлением Федеральной Службы Судебных Приставов России по Омской области было предоставлено место для прохождения производственно - технологической практики с 20 июня по 16 июля 2011 года. Весь период этой практики можно разделить на несколько этапов:

1. знакомство со структурой предприятия и изучение техники безопасности;

2. общий обзор АИС ФССП;

3.составление индивидуального задания на разработку Интерфейса Пристава для удаленного просмотра соединений таблиц из единой БД (БД с которой работают клиенты АИС ФССП);

4. разработка Интерфейса Пристава в качестве Автоматизированной Системы, а так же составление ТЗ на данную АС.



1. Цели и задачи практики

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

Основные задачи практики [1]:

- ознакомление с принципами разработки АСОИУ;

- проведение предпроектной стадии создания АСОИУ, заключающейся в обследовании организации и выявлении возможностей, за счет которых возможно улучшение работы организации;

- разработка технического задания (ТЗ) предлагаемого решения задачи автоматизации.



2. Общее знакомство с предприятием

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

Основными задачами ФССП России являются:

- обеспечение установленного порядка деятельности Конституционного Суда Российской Федерации, Верховного Суда Российской Федерации, Высшего Арбитражного Суда Российской Федерации, судов общей юрисдикции и арбитражных судов; - организация принудительного исполнения судебных актов судов общей юрисдикции и арбитражных судов, а также актов других органов, предусмотренных законодательством

Российской Федерации об исполнительном производстве;

- исполнение законодательства об уголовном судопроизводстве по делам, отнесенным уголовно-процессуальным законодательством Российской Федерации к подследственности Федеральной службы судебных приставов;

- управление территориальными органами ФССП России.

ФССП России в своей деятельности руководствуется Конституцией Российской Федерации, федеральными конституционными законами, федеральными законами, актами Президента Российской Федерации и Правительства Российской Федерации, международными договорами Российской Федерации, актами Минюста России.

Ниже, на рисунке 1 представлена структура ФССП.

В качестве объекта прохождения практики был предоставлен отдел информатизации в отделении УФССП в САО г. Омска.

Отдел информатизации занимается поддержанием работы ЛВС в пределах каждого отдела по Омску и Омской области, обслуживанием БД, с которой работают приставы для составления производств.

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

Рисунок 1 - Структура ФССП



3. Характеристика предприятия

3.1 Структура сети

Для работы с АИС ФССП в каждом отделении службы приставов организована ЛВС, включающая несколько десятков машин и выделенная серверная машина с хранимой БД. Так же к серверу приставлена машина администратора для управления рабочими группами сети, общим мониторингом сети и для взаимодействия с сервером.

По устройствую сеть является простейшей одноранговой сетью. В такой сети отсутствуют выделенные серверы (однако, выделенная серверная машина в пределах ЛВС данной службы условно считается сервером), а каждый узел (peer) является как клиентом, так и сервером. В отличие от архитектуры клиент-сервера, такая организация позволяет сохранять работоспособность сети при любом количестве и любом сочетании доступных узлов.

Наиболее полно преимущества такой организации не используются на данном предприятии, в основном все запросы и взаимодействия идут между серверной машиной и машинами приставов, где установлены клиенты АИС ФССП. На серверной машине установлен сервер Базы Данных «Ред База Данных» и весь комплекс программ для работы АИС ФССП, то есть серверная часть АИС.

3.2 ПО, используемое на предприятии

3.2.1 АИС ФССП

АИС ФССП России представляет собой единую информационную систему Федеральной службы служебных приставов Российской Федерации и состоит из следующих компонентов:

- ПК ОСП;

- подсистема ведомственной статистики и аналитики;

- подсистема нормативно-справочной информации;

- подсистема межведомственного взаимодействия.

Программный комплекс территориального отдела судебных приставов (далее _ ПК ОСП) состоит из трех компонентов: непосредственно ПК ОСП, реализующий автоматизацию основных функций ОСП, серверная часть ПК ОСП - отвечает за автоматизацию выполнения периодических задач, таких как пересчет сроков отложения ИП или задачи обслуживания БД и сервер статистики ПК ОСП, который предоставляет веб-интерфейс для построения и выгрузки статистических отчетов.

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

Кроме того ПК ОСП на уровне ОСП позволяет осуществлять:

- подъем данных из ОСП на уровень ТО и ЦА;

- выполнение регламентных работ по администрированию и обслуживанию БД;

- получение указаний из территориального органа УФССП по региону.

На уровне территориального органа ПК ОСП позволяет осуществлять:

- отправку указаний в ОСП;

- просмотр информации из баз данных ОСП в центральной базе данных;

- построение аналитических и статистических отчетов в целом по региону.

Для работы ПК ОСП необходимо следующее программное обеспечение:

- сервер СУБД -- Ред База Данных 2.1.3 32 бита;

- средство репликации данных RedReplicator;

- среда исполнения Java - JRE 1.6.21 32 бита;

- веб-сервер Apache Tomcat версии не ниже 6.0.29;

- текстовый процессор OpenOffice.org не ниже версии 3.2;

3.2.2 Работа с СУБД Ред База Данных

Инсталляция СУБД «Ред База Данных» осуществляется с помощью стандартного мастера установки программ. В ходе установки мастер собирает всю необходимую для установки сервера информацию, производит копирование файлов и регистрацию программных модулей в реестре Windows.

Типы установки Super, Classic, SuperClassic и клиентская инсталляция. При последнем способе установки сервер не будет сконфигурирован. Может быть сконфигурирован позже с помощью утилит командной строки.

Ред База Данных распространяется с открытым исходным кодом и является надстройкой над СУБД Firebird. Весь синтаксис SQL, присущий Firebird справедлив и для Ред База Данных.

Настройка работы сервера осуществляется через файл конфигурации firebird.conf, расположенный в каталоге установки сервера.

При установке сервера «Ред База Данных» в системе регистрируется и запускается служба сервера, которая называется Red Database server. Однако, если выбран вариант клиентской инсталляции, то в этом случае служба сервера не будет сконфигурирована и запущена. Кроме того, при любом варианте установки создается ветвь в системном реестре (HLKM\SOFTWARE\Firebird Project), в которой хранятся параметры установки, необходимые для корректной работы сервера.



3.2.3 Утилиты СУБД Ред База Данных

3.2.3.1 ISQL

ISQL это утилита командной строки для работы с базами данных «Ред Базы Данных» при помощи языка структурированных запросов (Structured Query Language) - SQL. Утилита может быть использована для создания БД, создания и изменения метаданных, и для выполнения различных запросов к БД. Уитилита может работать в двух режимах: пакетном и интерактивном.

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

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

Запуск утилиты производится следующим образом:

isql [-u[ser] <user_name>] [-p[assword] <password>] [database_name],

где

user_name - имя пользователя СУБД;

password - пароль пользователя;

database_name - спецификация базы данных в формате <адрес сервера>:<путь к БД>

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

Извлечение метаданных производится с помощью команды SHOW. При этом ISQL запускает транзакцию с уровнем изоляции READ COMMITED, что дает возможность видеть все изменения метаданных, подвтержденные другими пользователями:

SHOW <object|ALL> [<name>|<mask>]

Ключевое слово ALL будет соответсвовать всем типам объектов. Задание имени объекта <name> по маске производится с помощью группового символа «%», который будет задавать маску имен объектов подобно LIKE в SQL-запросах, то есть обозначает любое количество любых символов в именах объектов.

Пример:

show tables my%,

покажет все таблицы, начинающиеся с my. Команда show all -- покажет все метаданные.

Ниже приведены различные опции исполения команд в ISQL.

Таблица 1 -- Опции ISQL

Опция	Описание
-a(ll)	Извлечение всех метаданных, включая не-SQL объекты (например внешние функции). Исп. совместно с командой extract
-c(ache)<num>	Задать число страниц, которые будут кэшироваться при соединении с БД
-ch(arset)<charset>	Задать набор кодировок для текущего соединения
-d(atabase)<database>	Задать имя и путь к БД, которое будет записано в выходной поток
-e(cho)	Включает или подавляет дублирование команд на указанное устройство вывода (монитор, файл и т.д.)
-ex(tract)	Извлечь метаданные
-i(nput)<file>	Задать файл с SQL-запросами для выполнения
-merge diagnostic	Отключить автоматическое подвтерждение DDL-операций
-nod(btriggers)	Не запускать триггеры базы данных
-now(arnings)	Не показывать предупреждения
-o(utput)<file>	Задать файл для вывода результата выполнения запросов. Без аргументов перенаправляет вывод на станд. уст. вывода (monitor)
-pag(elength)<size>	Размер страницы
-p(assword)<password>	Пароль пользователя
-q(uiet)	Не показывать сообщение «Use CONNECT..»
-r(ole)<role>	Имя роли
-s(qldialect)<dialect>	SQL-диалект (set sql dialect)
-t(erminator)<term>	Команда терминатора (разделитель строк)
-tr(usted)	Использовать доверительную аутентификацию
-u(ser)<user>	Имя пользователя
-z	Показать версии утилиты сервера
-certificate	Использовать сертификат подлинности пользователя для многофакторной аутентификации
-repository	Задать имя репозитария, в котором хранится ключевая пара, соответствующая предъявляемому пользователем сертификату

3.2.3.2 GBAK

Наиболее универсальным инструментом, позволяющим осуществить резервное копирование базы данных на любой платформе, является gbak -- утилита командной строки, входящая в поставку «Ред База Данных». С помощью gbak можно обратиться к серверу и произвести считывание данных и получение на их основе резервной копии, а также восстановить базу данных из резервной копии.

В gbak действует принцип «обратной совместимости». Это значит, что созданные резервные копии в более ранних версиях «Ред База Данных» могут быть восстановлены в более поздних, но не наоборот.

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

gbak [-B][options]<база_данных-источник><файл резервной копии>

Ключ -B означает, что необходимо выполнить резервное копирование базы данных, путь к которой указан как <база_данных-источник>, а результаты резервного копирования сохранить в файл, указанный как <файл резервной копии>.

3.2.3.3 NBACKUP

Nbackup позволяет создавать резервные копии и восстанавливать из резервныых копий, так же, как gbak и дополнительно позволяет создавать инкрементные копии и восстанавливать из них БД. Инкрементная резервная копия содержит только изменения со времени создания определенной, ранее созданной резервной копии.

Nbackup позволяет блокировать файл базы данных. Таким образом, после этого можно сохдавать обычные копии или резервные копии с помощью сторонних утилит.

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

Синтаксис nbackup для создания резервной копии всей базы данных:

nbackup [-U <пользователь> -P<пароль>] -B 0 <база_данных> [<резервный_файл>]

Параметр -B означает создание резервной копии. Уровень резервной копии 0 означает создание резервной копии всей базы данных.

Резервная копия всей базы данных восстанавливается следующим образом:

nbackup [-U<пользователь> -P<пароль>] -R <база_данных>[<резервный_файл>]

3.2.3.4 GSTAT

Утилита gstat предназначена для получения полной информации о базе данных. Gstat даёт информацию о дате создания базы данных, размере страниц базы данных, количестве теневых копий, таблицах и другую.

Синтаксис gstat:

gstat [-U <пользователь> -P <пароль>] <переключатель> <база_данных>

Ниже приведены возможные значения переключателя



Таблица 2 -- Опции GSTAT

Переключатель	Описание переключаетля
-a	Статистика страниц данных и индексов
-d	Статистика страниц данных
-h	Статистика заголовочной страницы
-i	Статистика индексов
-s	Статистика системных таблиц
-u	Имя Пользователя
-p	Пароль пользователя
-t	Название таблицы
-z	Показать версию сервера и утилиты
-tr	Использовать доверительную аутентификацию



4. Сведения о выполненной работе

Руководством отдела информатизации УФССП было предложено задание реализовать в виде веб-сервиса интерфейс взаимодействия пристава с удаленной централизованной базой данных.

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

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

- данные из удаленной БД (далее именуемой АИС, по аббревиатуре клиентского программного комплекса (ПК), для работы с удаленной БД) поступают в качестве наборов записей в новую чистую БД. Эта новая БД будет являться основной (рабочей, далее именуется как рабочая БД - РБД) для вывода данных поиска в окно браузера, на печать, по электронно почте и так далее. Решение обосновывается, тем что с легковесной БД операции поиска будут выполняться гораздо быстрее, к тому же данная БД будет наполняться только актуальными данными из АИС, допуская минимальную избыточность;

- на отрезке между АИС и РБД, данные с помощью специальных методов (хранимые в СУБД процедуры, пользовательские функции) будут проверяться на предмет их оригинальности для РБД (исключается добавление уже запрашиваемых записей);

- запросами от клиента интерфейса (форма, аплет, командная строка) к РБД, данные будут поступать на вывод, отображаться пользователю (пристав);

- существует обратная связь (ОС), в виде управляющих воздействий со стороны панели управления клиентом интерфейса (главная страница с аплетом, либо реализованная на языке PHP динамически обновляемая). ОС влияет на результаты выборки из АИС, задаёт критерии проверки оригинальности данных для РБД.

Ниже представлена схема описанного интерфейса

Рисунок 2 - Схема интерфейса «Пристав»

4.1 Разработка интерфейса

Для организации интерфейса как АС выделим следующие уровни функционирования:

- уровень СУБД. Здесь выполняются основные работы по соединению таблиц в необходимые наборы записей, последующая вставка новых записей в РБД. Частично СУБД реализует и авторизацию пользователей, т.к. доступ к БД предоставляется только заведенным в системных таблицах БД пользователям;

- программный уровень. Разрабатываемый клиент для взаимодействия с СУБД должен осуществлять основные функции по взаимодействию с пользователем и обработкой поступающих данных в качестве выборок из БД, отображение этих данных пользователю (пристав).

Такое разделение на уровни позволяет разделить работу на ряд работ, предписанных администратору и проектировщикам БД, т.к. именно они знают структуру БД и определяют набор хранимых процедур и просмотров (объекты View базы данных), и ряд работ, выполняемых программистом, разработчиком клиента.

4.2 Работа с СУБД. Определение набора процедур

Проектировщики БД и администратор предоставляют готовый набор скриптов и процедур на языке SQL, которые затем разработчик клиента внедряет как пользовательские функции. Работой по написанию и отлаживанию процедур занимается проектировщик БД.

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

Работа велась с СУБД Firebird. Вспомогательное ПО для создания и модификации БД: утилита Firebird - isql, а так же IBExpert.

Разрабатываемая БД имеет 4 таблицы:

- основания (CAUSES). Содержит описание оснований к аресту, применению санкций и так далее;

- сотрудники (EMPLOYEES). Содержит перечень приставов с необходимой информацией. При регистрации в СУБД пользователя, данные из таблицы поступают во все необходимые отчеты и документы в качестве информации о лице, которое вело производство;

- производства (FABRICATIONS). Информация о производствах, которые ведет каждый пристав. Имеет поля субъект производства(SUBJ_FIO) , основание к производству, дату начала производства;

- отчеты (REPORT). По завершении производства сюда регистрируется вся необходимая информация.

Таблица FABRICATIONS имеет внешний ключ, ссылающийся на первичный ключ таблицы CAUSES по полю «Идентификатор Основания». Так же таблица REPORT имеет два внешних ключа, ссылающихся на первичный ключ FAB_ID таблицы FABRICATIONS и первичный ключ EMP_ID таблицы EMPLOYEES.

В качестве схемы для данных вывода была составлено отношение REPLY (Резюме, Оюзор), выполняющее сложное соединение по ключам 4 таблиц.

Отношение было организовано в виде просмотра (View), специального объекта СУБД Firebird (поддерживается и во многих других СУБД).

Код просмотра REPLY на языке SQL представлен ниже.

CREATE VIEW REPLY(

REPLY_REPORT_ID,

REPLY_CAUSE,

REPLY_SFIO,

REPLY_EMPFIO,

REPLY_FABDATE,

REPLY_REPDATE,

REPLY_SUMMARY)

AS

select rep_reply.report_id,fab_reply.fab_reply_cause, fab_reply.fab_reply_subject, rep_reply.fab_empfio, fab_reply.fab_reply_dat,

rep_reply.rep__reply_date, rep_reply.reply_summary from fab_reply JOIN rep_reply ON fab_reply.fab_reply_fab_id=rep_reply.fab_id;

Здесь исползуется соединение двух просмотров по общему полю fab_id. Два задействуемых просмотра выполняют попарные соединения (JOIN) таблиц FABRICATIONS, CAUSES и REPORT, FABRICATIONS соответственно.

В терминологии SQL-89 и SQL-92 просмотр явлется стандартным типом таблицы, он также называется «просматриваемой» или «виртуальной таблицей». Он характеризуется как «виртуальный», потому что вместо того, чтобы хранить табличный объект и выделять страницы для хранения данных, сервер Firebird сохраняет только описание метаданных объекта. Оно содержит уникальный идентификатор, список спецификаций столбцов и компилированный оператор SELECT для поиска описанных в этих столбцах данных во время выполнения [2].

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

Просмотр является зависимым объектом от используемых для его составления таблиц и других просмотров. Таким образом, задействуемый в составлении просмотр нельзя удалить, вызовется исключение.

Преимущества использования просмотров:

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

- безопасность данных. Просмотры позволяют ограничить доступ важным или не относящимся к делу частям таблиц.

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

Далее, на основе просмотров строятся хранимые процедуры (PROCEDURE) для выборки данным по полям (ФИО пристава, основание, дата начала, дата завершения и так далее).

Процедура является самостоятельной программой, написанной на языке PSQL Firebird, скомпилированной интерпретатором во внутренний двоичный язык Firebird и сохраненной как исполняемый код в метаданных базы данных. Однажды скомпилированная, хранимая процедура может быть вызвана непосредственно из приложения или другого модуля PSQL с использованием оператора EXECUTE PROCEDURE или SELECT в соответствии с заданным стилем процедуры[2].

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

Ниже приведен код процедуры выбора резюме по задаваемому диапазону даты начала производства (reply_fab_date):

begin

FOR

SELECT reply.reply_report_id

from reply WHERE (reply.reply_fabdate>=:low_date AND reply.reply_fabdate<=:high_date) INTO:IDLIST_REP_ID

DO

BEGIN

suspend;

end

end

Процедура использует в качестве источника данных предопределенный ранее просмотр REPLY. Позже данные выборки поступают в рабочую базу данных в таблицу с такой же структурой и типом полей, как у просмотра REPLY, если являются огиниальными по полю reply_rep_id.



4.3 Разработка серверной части

В качестве клиента выступает веб-страница JSP (Java Server Page) .

JSP страницы загружаются на сервере и управляются из структуры специального Java server packet, который называется Java EE Web Application, в большинстве своём упакованная в файловые архивы .war и .ear.

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

Всю работу по взаимодействию с СУБД, отправление и обработка запросов, выполняет специальный объект на сервере, так называемый сервлет.

Сервлет является Java-программой, выполняющейся на стороне сервера и расширяющей функциональные возможности сервера. Сервлет взаимодействует с клиентами посредством принципа запрос-ответ.

Сервлеты должны реализовывать Servlet интерфейс, который определяет методы жизненного цикла.

Хотя сервлеты могут обслуживать любые запросы, они обычно используются для расширения веб-серверов. Для таких приложений технология Java Servlet определяет HTTP-специфичные сервлет классы.

Пакеты javax.servlet и javax.servlet.http[3] обеспечивают интерфейсы и классы для создания сервлетов.

Жизненный цикл сервлета состоит из следующих шагов:

- в случае отсутствия сервлета в контейнере;

- класс сервлета загружается контейнером;

- контейнер создает экземпляр класса сервлета;

- контейнер вызывает метод init(). Этот метод инициализирует сервлет и вызывается в первую очередь, до того, как сервлет сможет обслуживать запросы. За весь жизненный цикл метод init() вызывается только однажды;

- обслуживание клиентского запроса. Каждый запрос обрабатывается в своем отдельном потоке. Контейнер вызывает метод service() для каждого запроса. Этот метод определяет тип пришедшего запроса и распределяет его в соответствующий этому типу метод для обработки запроса. Разработчик сервлета должен предоставить реализацию для этих методов. Если поступил запрос, метод для которого не реализован, вызывается метод родительского класса и обычно завершается возвращением ошибки инициатору запроса;

- в случае если контейнеру необходимо удалить сервлет, он вызывает метод destroy(), который снимает сервлет из эксплуатации. Подобно методу init(), этот метод тоже вызывается единожды за весь цикл сервлета.

Для исполнения сервлета требуется так называемый контейнер сервлета.

Контейнер представляяет собой сервер, который занимается системной поддержкой сервлетов и обеспечивает их жизненный цикл в соответствии с правилами, определёнными в спецификациях. Может работать как полноценный самостоятельный веб-сервер, быть поставщиком страниц для другого веб-сервера, например Apache, или интегрироваться в Java EE сервер приложений. Обеспечивает обмен данными между сервлетом и клиентами, берёт на себя выполнение таких функций, как создание программной среды для функционирующего сервлета, идентификацию и авторизацию клиентов, организацию сессии для каждого из них.

Для написания и тестирования сервлета был установлен специальный модуль Apache - Tomcat.

Tomcat (в старых версиях -- Catalina) -- контейнер сервлетов с открытым исходным кодом, разрабатываемый Apache Software Foundation. Реализует спецификацию сервлетов и спецификацию JavaServer Pages (JSP). Написан на языке Java.

Tomcat позволяет запускать веб-приложения, содержит ряд программ для самоконфигурирования.

В связи со специфическими особенностями языка Java состав клиентского приложения представляет собой пакет классов, реализующих работу сервлета (обработка запросов пользователя, отображение данных в браузер), и пакет классов для подключения и отправки запросов к БД.

В Java для работы с СУБД определен интерфейс JDBC. Этот инерфейс реализуется драйверами для конкретных СУБД. А драйвер, как известно, занимает место между базой данных и приложением.

Ниже на рисунке 3 представлена схема, как драйвер конкретной СУБД реализует интерфейс JDBC при построении приложения.

Рисунок 3 - драйвер СУБД в приложении Java

С сайта разработчика СУБД Firebird были взяты драйверы JayBird для взаимодействия посредством интерфейса JDBC с СУБД.

Ниже приведен код, осуществляющий подключение к Базе Данных, реализован как конструктор FBConnect:

public FBConnect(String driver, String url, String login, String pass)

{

try

{

Class.forName(driver);

conn = DriverManager.getConnection(url, login, pass);

result=problem_none;

} catch (ClassNotFoundException ex)

{

System.err.println("FBConnect.Cannot find this db driver classes.");

ex.printStackTrace();

result=driver_problem;

} catch (SQLException e)

{

System.err.println("FBConnect.Cannot connect to this db.");

e.printStackTrace();

result=conn_problem;

}

}

В лог ошибок выводятся ошибки подключения, связанные с проблемой драйвера, или самой БД (неправильное имя пользователя и пароль).

Ниже представлены страницы .jsp, запускающие стандартными HTTP-запросами POST/GET соответствующие классы сервлетов авторизации пользователя, поиска, добавления в РБД и так далее.

При вводе адреса интерфейса пользователь попадает на стартовую страницу входа (рисунок 4), где требуется ввести логин и пароль пользователя. Все пользователи зарегистрированы СУБД, поэтому и проверка правильности проводится на стороне СУБД, однако сервлет возвращает соответствующие сообщения о правильности ввода в вызвавший его узел.

При удачном входе пользователь регистрируется в системе и может осуществлять поиск по полям, задавая ключевые слова, либо определяя дату. Процесс поиска показан на рисунке 5.

По мере работы с интерфейсом могут возникать различные ошибки, как на стороне сервера (непредвиденное отключение БД, неотлаженные ошибки методов, различные исключения методов классов). Предусмотрен вывод страницы с сообщением ошибки и указанием обратиться за помощью к специалистам и разработчикам. Пример вывода сообщения об ошибке показан на рисунке 6.

Рисунок 4 - Стартовое окно входа в систему

Рисунок 5 - Пример поиска отчетов по полю

Рисунок 6 - Страница с сообщением об ошибке выполнения операции



Заключение

В ходе производственно-технологической практики было проведено знакомство со структурой предприятия, общее ознакомление с администрированием сети в отделе. Было получено индивидуальное задание на разработку Интерфейса Пристава для выборки отчетов из БД.

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



Список использованных источников

1.Положение о практике студентов ОмГТУ. - Омск: Изд-во ОмГТУ, 2001. - 43 с.

2. Борри Х. Firebird: Руководство разработчика баз данных. - СПб.: БХВ-Петербург. 2006 - 1104 с.: ил.

3.Ноутон П., Шилдт. Г. Java 2. - СПб.: БХВ-Петербург. 2001 - 1102 с.:ил.

Размещено на Allbest.ru