Java Data Objects

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 17:06, 7 июня 2018.

Объекты данных Java (JDO) – это спецификация сохранения Java-объектов. Одной из его особенностей является прозрачность служб сохранения для модели домена. Постоянными объектами JDO являются обычные классы языка программирования Java (POJO); им не требуется внедрять определенные интерфейсы или распространяться от специальных классов.

История версий

  • JDO 1.0 был разработан в рамках Java Community Process как JSR 12.
  • JDO 2.0 был разработан под JSR 243 и был выпущен 10 мая 2006 года.
  • JDO 2.1 был завершен в феврале 2008 года, разработанный проектом Apache JDO.
  • JDO 2.2 был выпущен в октябре 2008 года.
  • JDO 3.0 был выпущен в апреле 2010 года.

Особенности

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

Поставщики JDO предоставляют разработчикам энтузиастам, модифицированные скомпилированные файлы класса Java, для того чтобы они могли быть прозрачно сохранены. Необходимо обратить внимание, что усиление байт-кода не предусмотрено спецификацией JDO, хотя оно является широко используемым механизмом для реализации требований спецификации JDO. В настоящее время поставщики JDO предлагают несколько вариантов сохранения, например, к РСУБД, к OODB или к файлам.

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

JDO интегрирован с Java SE несколькими способами. Прежде всего, реализация поставщика может быть предоставлена ​​как JEE Connector. Во-вторых, JDO может работать в контексте транзакций JEE.[Источник 1]

Если вы программист приложений, вы можете использовать технологию JDO для непосредственного хранения экземпляров модели домена Java в постоянном хранилище (базе данных). Альтернативы JDO включают в себя прямые файловые операции ввода-вывода, сериализацию, JDBC, Enterprise JavaBeans (EJB) , бинарные управляемые стойки (BMP) или контейнеры с контролируемым контейнером (CMP) и Java Persistence API.

Проект Apache JDO ориентирован на создание JDO API и TCK для тестирования совместимости JDO-реализаций. Коммерческие и открытые версии JDO, предоставляющие API-интерфейсы, используемые разработчиками приложений и их клиентами, доступны для реляционных баз данных, баз данных объектов и файловых систем.

Преимущества

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

Переносимость: приложения, написанные с помощью JDO API, можно запускать на нескольких реализациях без перекомпиляции или изменения исходного кода. Метаданные, описывающие поведение настойчивости, внешние по отношению к исходному коду Java, включая наиболее часто используемые функции отображения O/R, очень переносимы.

Независимость базы данных. Приложения, написанные с помощью JDO API, не зависят от базовой базы данных. Реализации JDO поддерживают множество различных хранилищ транзакционных данных, включая реляционные и объектные базы данных, XML, плоские файлы и другие.

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

Интеграция с EJB: приложения могут использовать преимущества функций EJB, таких как удаленная обработка сообщений, автоматическая распределенная координация транзакций и безопасность, используя те же объектные модели домена на предприятии.[Источник 2]   Сохранение, долговременное хранение информации после выхода программы, может быть достигнуто с использованием различных вариантов языка Java. Самый простой - это ввод-вывод файлов, но этот параметр не подходит для хранения на уровне предприятия (по понятным причинам). Другие варианты включают следующее:

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

Программное обеспечение Java DataBase Connectivity (JDBC). Полный доступ к функциональности базы данных SQL. JDBC требует, чтобы разработчик явно управлял значениями полей и сопоставлял их в таблицы реляционной базы данных. В этом случае разработчику необходимо будет знать другой язык (например, язык запросов, такой как SQL).

Архитектура Enterprise JavaBeans (EJB) контейнер управляемой стойкости (CMP). В составе платформы Java Platform, Enterprise Edition (JavaEE, ранее известной как J2EE), CMP предоставляет переносимую службу сохранения объектов для контейнеров EJB. Тем не менее, это не универсальное средство сохранения на платформе Java.

Жизнеспособной альтернативой является JDO API, который обеспечивает стандартный подход для достижения стойкости объекта в технологии Java, используя комбинацию метаданных XML и усовершенствования байт-кода, чтобы облегчить сложность разработки и накладные расходы.

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

Простота использования. API JDO позволяет разработчикам приложений сосредоточиться на объектной модели домена (DOM) и оставить информацию о сохранении реализации JDO.

  • Высокая производительность. Разработчикам приложений Java не нужно беспокоиться о оптимизации производительности для доступа к данным, поскольку эта задача делегируется реализации JDO, которые могут улучшить возможности доступа к данным для обеспечения максимальной производительности.
  • Интеграция с EJB. Приложения могут использовать преимущества функций EJB, таких как удаленная обработка сообщений, автоматическая распределенная координация транзакций и безопасность с использованием тех же DOM на предприятии.

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

JDO предназначен для дополнения EJB. EJB CMP обеспечивает переносимое сохранение для контейнеров, а JDO можно интегрировать с EJB двумя способами: (1) через Session Beans с классами, поддерживающими JDO, для реализации зависимых объектов (постоянные вспомогательные классы для Session Beans) и (2) через Entity Beans с классами совместимости с JDO, которые используются в качестве делегатов как для управляемой персистентности бина (BMP), так и для контроля на основе контейнеров (CMP).

Архитектура

  Высокоуровневый JDO API разработан для обеспечения прозрачного интерфейса для разработчиков для хранения данных без необходимости изучения нового языка доступа к данным (например, SQL) для каждого типа постоянного хранилища данных. JDO может быть реализован с использованием низкоуровневого API (например, JDBC) для хранения данных. Это позволяет разработчикам писать код Java, который прозрачно обращается к базовому хранилищу данных, не используя код, специфичный для конкретной базы данных. JDO был разработан как JSR в программе Java Community Process (JCP): JDO 1.0, существующий с 2002 года, является JSR 12; и JDO 2.0, утвержденный в начале 2005 года и разрабатываемый, является JSR 243.

JDO 2.0 - это богатая и полнофункциональная спецификация JSR для персистентности старых объектов Java ((POJO)), а несколько поставщиков предоставляют конкурирующие реализации. Кроме того, многие поставщики, скорее всего, реализуют JDO 2.0 и EJB 3.0 в одном продукте. Это позволит вам одновременно использовать оба API, предоставляя вам более простой способ постепенной миграции на EJB 3.0 POJO, который станет моделью сохранения.

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

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

Дорога к POJO

  Существенные различия в моделях устойчивости JDO и EJB вызвали некоторую путаницу среди разработчиков. В ответ Sun Microsystems возглавляет усилия сообщества по созданию единой модели устойчивости POJO для сообщества Java-технологий. Это усилие реализуется под эгидой JSR 220 во главе с Линдой Демишиэль. Члены Экспертной группы JDO 2.0 (JSR 243) были приглашены присоединиться к экспертной группе EJB 3.0 (JSR 220).

Целью является создание модели сохранения (POJO), которая обеспечивает единую объектно-реляционную функцию сопоставления для всех разработчиков приложений Java, которые работают с платформами Java SE и Java EE. Стоит отметить, что Oracle присоединяется к Sun в качестве сокаталога для EJB 3.0. Теперь доступен обзорный обзорный проект EJB 3.0.

JSR 243 (JDO 2.0) следует указаниям, изложенным в письме, сообществу разработчиков Java из спецификации, приводящей к JSR 220 и 243.

JDO 2.0 не предлагает конкретную конвергенцию API с постоянством EJB 3.0, а скорее эволюцию JDO 1.0.2. Но сходство между моделью устойчивости POJO JDO и EJB 3.0 позволит клиентам JDO легко охватить новую модель сохранения EJB 3.0 при удовлетворении неотложных потребностей с JDO 2.0. Кроме того, JSR 243 предполагает, что JDOQL будет использоваться в качестве альтернативного языка запросов с сохранением EJB 3.0. Язык был обновлен, чтобы лучше работать с EJB 3.0.

Типы классов JDO

  В JDO есть три типа классов:

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

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

Нормальный. Эти классы не сохраняются и не знают о настойчивости. Они не требуют метаданных JDO.

Жизненный цикл экземпляров

JDO управляет жизненным циклом объекта от создания до удаления. В течение своей жизни экземпляр JDO переходит из разных состояний до тех пор, пока он не станет окончательно мусором, собранным виртуальной машиной Java (JVM). Переход между состояниями достигается с помощью методов класса PersistenceManager, включая TransactionManager, таких как makePersistent (), makeTransient (), deletePersistent () - и фиксации или откат изменений, которые совершаются такими операциями.[Источник 3]

Источники

  1. Java Data Objects // Wikipedia [2001–2018]. Дата изменения: 03.07.2017. URL: https://en.wikipedia.org/wiki/Java_Data_Objects (Дата обращения: 07.06.2018).
  2. Java Data Objects (JDO) // Oracle [2018]. Дата изменения: 04.15.2012. URL: http://www.oracle.com/technetwork/java/index-jsp-135919.html (Дата обращения: 07.06.2018).
  3. Getting Started With Java Data Objects (JDO): A Standard Mechanism for Persisting Plain Java Technology Objects // Oracle [2018]. Дата изменения: 09.08.2005. URL: http://www.oracle.com/technetwork/Java/jdo-138290.html (Дата обращения: 07.06.2018).