Переход с управляемой контейнером персистентности EJB 2 на pureQuery для IBM Master Data Management Server: Часть 1. Оценка технологии pureQuery

Эта серия статей предназначена для тех, кто заинтересовался новой версией WebSphere Customer Center (теперь это IBM InfoSphere Master Data Management Server) или что-то недопонимает в ней. Эта серия посвящена тому, как и почему в новой версии применяется технология pureQuery, как внедрять pureQuery и проводить миграцию на нее. Приводятся результаты тестирования производительности и функциональности, обосновывающие это важное решение. В части 1 содержится оценка механизмов персистентности (persistence) и наш план оценки этой технологии.

Вэй Чжэн, архитектор продуктов MDM Server, IBM  

Вэй Чжэн (Wei Zheng) является членом группы Master Data Management Server Architecture. Он пришел в IBM в 2005 году в результате приобретения компании DWL и работал над разными аспектами продукта. Он закончил Чжэцзянский университет в Китае с дипломом магистра электротехники.



Пол ван Рун, старший специалист по архитектуре MDM, IBM  

Пол ван Рун (Paul van Run) является ведущим архитектором и STSM в группе IBM Master Data Management. Он оказался в IBM в результате приобретения компании DWL в 2005 году. Паул возглавляет группу передовых технологий при MDM. Он получил диплом магистра математики (по искусственному интеллекту) в Университете Ватерлоо (Канада) и диплом магистра естественных наук в Техническом университете Эйндховена (Нидерланды).



Кэти Зейденстайн, старший инженер-программист, IBM  

Кэти Зейденстайн (Kathy Zeidenstein) работает в IBM с незапамятных времен. Сейчас она член группы предпродажной подготовки IBM Data Studio, до этого была менеджером по маркетингу IBM OmniFind Analytics Edition.



31.08.2009

Предыстория

В 2007 году группа IBM Master Data Management планировала новый крупный выпуск своего продукта WebSphere® Customer Center, который хотели переименовать в IBM InfoSphere Master Data Management Server. Одно из важных архитектурных решений, принятых группой, касалось существования устаревшего механизма персистентности, основанного на сочетании управляемого контейнером механизма персистентности (CMP) компонентов-сущностей Enterprise JavaBeans (EJB) 2 и стандартных вызовов JDBC. В этой серии из двух частей описывается, как и почему мы приняли решение предложить технологию pureQuery; приводится наш план внедрения и миграции на pureQuery; и, наконец, изложены результаты тестирования производительности и функциональности для обоснования этого решения.

Обзор сервера InfoSphere Master Data Management

Сервер IBM InfoSphere Master Data Management (MDM) управляет объектами мастер-данных, которые определяют наиболее важные бизнес-процессы на предприятии (заказчиками, счетами и продуктами). IBM предлагает комплексное решение MDM с широкими функциональными возможностями, которое обслуживает все подходы к управлению мастер-данными. При помощи MDM Server организация может централизовать свои наиболее критические данные в единый надежный источник — что помогает выявить самых ценных заказчиков, повысить доходы и сократить расходы. Эти возможности позволяют извлекать больше выгод из существующих систем, повысить степень удовлетворенности заказчиков и ускорить выход на новые рынки.

Мастер-данные обычно применяются во многих местах (операционные системы, хранилища данных, бизнес-процессы, обеспечение управляемости данных и т.п.), и к ним предъявляются очень разные требования. Однако во всех этих случаях к системе MDM имеются некоторые общие ключевые требования. Такая система должна:

  • Предоставлять единую многодоменную (организация, счет, продукт) главную базу данных — уровень знаний
  • Обеспечивать бизнес-сервисы SOA для манипулирования этими данными и запросов к ним
  • Управлять качеством и точностью данных
  • Предоставлять интеллектуальную, упреждающую бизнес-логику, чтобы сделать MDM активным участником жизненного цикла данных
  • Обеспечить возможности по управлению данными, чтобы проводить и контролировать транзакции и в то же время обеспечить безопасный доступ к данным

Следующий обзор продукта MDM иллюстрирует, как выполняются эти требования:

Рисунок 1. Обзор продукта MDM
Обзор продукта MDM

Итак, в общих чертах, IBM InfoSphere MDM Server — это приложение SOA с большим набором предопределенных бизнес-сервисов для управления основными данными (или ссылками на основные данные) в своей базе данных. Например, запрос на обновление принимается сервером MDM в формате XML и преобразуется в объектную форму; затем проверяется его безопасность; подтверждается его содержание; производится стандартизация и исключение дубликатов, после чего вносятся изменения через уровень персистентности. Данная статья как раз и посвящена этому уровню персистентности..

IBM InfoSphere Master Data Management Server является преемником IBM WebSphere Customer Center. Он дополняет функциональность WebSphere Customer Center, добавляя дополнительные домены данных Account (счет) и Product (продукт). Так что везде, где в настоящей статье упоминается WebSphere Customer Center, речь идет о предыдущей архитектуре, а там, где используется MDM Server, — о новой.

Обзор Data Studio Developer и pureQuery

Семейство IBM Data Studio представляет собой интегрированную модульную среду управления данными для проектирования, разработки, внедрения и управления данными, базами данных и приложениями в течение всего жизненного цикла управления данными. Главной темой настоящей статьи является технология pureQuery, которая применяется в Data Studio Developer и Data Studio pureQuery Runtime. pureQuery — это высокопроизводительная технология доступа к данным на основе Java™, реализованная поверх JDBC, которая облегчает разработку и внедрение приложений и сервисов баз данных. Технология pureQuery была разработана для наведения мостов между Java и СУБД. Именно на стыке этих миров обычно возникают проблемы производительности и продуктивности.

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

Сложность JDBC-разработки привела к созданию структуры object relational mapping (ORM), которая обеспечивает уровень абстракции доступа к данным. Для создания уровня доступа к данным на структурах ORM обычно требуется меньше усилий. Однако эти структуры могут создавать дополнительные сложности при диагностике проблем производительности времени выполнения. Отладка и диагностика усложняются, так как разработчик больше не контролирует, что SQL отправляет в базу данных; в результате бывает трудно изменить запрос SQL или определить, от какого приложения он исходит. Для решения этих и других проблем разработки Java-программ доступа к данным IBM и создала pureQuery. pureQuery представляет собой новый API, простой и интуитивно понятный разработчикам Java, которые ищут возможности для стандартизации JDBC. К тому же pureQuery позволяет в полной мере использовать возможности коллекций и буферов базы данных SQL на Java.

Инструментарий pureQuery упрощает решение наиболее сложных задач, в том числе предлагая встроенную поддержку сохранения компонентов и образов в базе данных и их извлечения из нее. Это не удивительно, так как SQL является целиком настраиваемым. И наращиваемым, что означает возможность добавления специальных алгоритмов обработки результатов. Расширенный редактор Java содержит встроенный редактор SQL, предоставляя разработчикам тот же уровень помощи по компиляции, проверке и исполнению кода SQL, каким они пользуются для Java. Это способствует применению лучших приемов работы с Java и SQL.

Главным отличием pureQuery-программирования от DB2 является возможность программировать в едином API и исполнять программы с использованием как статического, так и динамического исполнения SQL. Статический SQL в применении к СУБД DB2 давно пользуется признанием за его способность повышать производительность, стабильность и безопасность, но для его применения традиционно требуется специальное программирование. Хотя мы еще не использовали эту возможность, нам известно о ее преимуществах, и мы рассмотрим ее при дальнейших усовершенствованиях.

Будущая версия pureQuery также позволит администраторам или разработчикам прослеживать SQL назад до исходного приложения, что упростит диагностику и поможет выполнять анализ влияния.

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

IBM pureQuery — не полноценный уровень персистентности. Он не обеспечивает поддержку управляемых объектов. Если нужен полноценный уровень персистентности и/или поддержка управляемых объектов, то вам, возможно, потребуется что-нибудь типа openJPA. В будущей версии pureQuery планируется реализовать многие из этих преимуществ для всех Java-приложений, а не только для тех, что написаны с применением API pureQuery.


Механизмы персистентности из WebSphere Customer Center

В WebSphere Customer Center применяется два механизма персистентности. Ввиду проблем производительности при использовании запросов EJB2 мы давно решили использовать прямые вызовы JDBC для операций запроса и EJB2 CMP для операций создания, извлечения, редактирования и удаления (CRUD).

Уровень ORM в компонентах-сущностях EJB2 CMP скрывает детали операций JDBC от объектных операций. Этот уровень также помогает генерировать подходящие операторы SQL для извлечения, изменения и сохранения записи в таблице. В нашем случае этот уровень ORM получается простым и легким, потому что нам не нужны все его возможности:

  • Он отображает только взаимно однозначное отношение между объектом-сущностью СМР и таблицей.
  • Он не отображает отношение таблицы на отношение объекта-сущности СМР.
  • Он не отображает наследование таблицы на наследование объекта-сущности СМР.

Мы использовали события жизненного цикла объекта-сущности СМРEJB2 перед вставкой записи в таблицу и ее обновлением.

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

Как уже говорилось, мы использовали прямые вызовы JDBC для своих операций сложных запросов во избежание излишней нагрузки при обработке запросов EJB2. К сожалению, из-за этого мы не могли многократно использовать код, взятый из EJB2 CMP ORM, и нам пришлось вручную программировать объектно-реляционное преобразование запросов JDBC.

Архитектура объектов-сущностей CMP в WebSphere Customer Center

На рис. 2 показана архитектура механизма персистентности для операций CRUD с применением объектов-сущностей СМР в WebSphere Customer Center.

Рисунок 2. Объекты-сущности CMP в службах Add/Update/Delete
Объекты-сущности CMP в службах Add/Update/Delete

WebSphere Customer Center представляет собой приложение J2EE, которое работает внутри сервера приложений. Оно состоит из следующих уровней (расположенных на рисунке слева на право):

  • Среда запросов манипулирует запросами и преобразует запросы и ответные сообщения.
  • Контроллер Tx управляет всей логикой транзакционного уровня и может вызывать один или более бизнес-компонентов логики компонентного уровня.
  • Бизнес-компонент управляет всей логикой компонентного уровня и может использоваться для создания разных транзакций.
  • Уровень персистентности (объекты-сущности CMP) вызывается бизнес-компонентом для выполнения любых операций CRUD.

Объект-сущность (EObj) извлекается из бизнес-объекта на уровне бизнес-компонента и передается на уровень персистентности (объекты-сущности CMP) для выполнения операций CRUD. По возвращении с уровня персистентности объект-сущность (EObj) вновь упаковывается в бизнес-объект. Объект-сущность взаимно однозначно отображается на таблицу и является объектом обмена, который используется для передачи данных между уровнем персистентности и уровнем бизнес-компонента.

Архитектура прямого вызова JDBC в WebSphere Customer Center

На рис. 3 изображена архитектура механизма персистентности для операций запроса, использующих прямые вызовы JDBC в WebSphere Customer Center. Уровни кода те же, что показаны на рис. 2, за исключением того, что уровень персистентности поддерживается нашим собственным кодом среды для выполнения прямых вызовов.

Рисунок 3. Прямые вызовы JDBC в службах запросов
Прямые вызовы JDBC в службах запросов
  • Среда запросов манипулирует запросами и преобразует запросы и ответные сообщения
  • Контроллер поиска управляет всей логикой транзакционного уровня и может вызывать один или более бизнес-компонентов логики компонентного уровня.
  • Бизнес-компонент управляет всей логикой компонентного уровня и может использоваться для создания разных транзакций.
  • Уровень персистентности (Direct JDBC) вызывается бизнес-компонентом для выполнения любых операций запросов.

Параметры запросов передаются через разные программные уровни в BObjQuery. Класс BObjQuery имеет разные реализации для разных бизнес-компонентов. Для получения SQL ResultSet BObjQuery вызывает общий класс SQLQuery. Этот ResultSet передается в ResultSetProcessor для создания бизнес-объектов. Каждый бизнес-компонент имеет свою реализацию ResultSetProcessor.

Проблемы механизмов персистентности WebSphere Customer Center

Описанные выше механизмы персистентности успешно использовались в нашем продукте в течение нескольких лет. Мы смогли масштабировать приложение WebSphere Customer Center для крупного заказчика с большим количеством пользователей, транзакций и данных и предложить своим клиентам множество механизмов. Однако по ходу дела мы столкнулись с несколькими недостатками, от которых решили избавиться.

Проблемы объектов-сущностей CMP EJB2

Вот проблемы объектов-сущностей CMP EJB2, которые мы обнаружили:

  • CMP решает только часть наших задач по ORM. Объекты-сущности — это не простые Java-объекты (POJO), и их нельзя обойти, поэтому мы создали свой собственный объект-сущность. Это вынудило нас вручную переносить значения атрибутов из объекта-сущности СМР в наш собственный объект-сущность и обратно.
  • Как уже говорилось, ORM, выполненный в СМР, не допускает многократного использования в запросах JDBC. ORM в СМР генерирует код отображения между объектом-сущностью СМР и таблицами. Так как объект-сущность СМР нельзя рассматривать в качестве POJO, эти отображения оказываются бесполезными в запросах JDBC.
  • Разработка СМР остается достаточно сложной, даже при помощи IDE. Всего для одного объекта-сущности СМР нужно создать шесть классов: Local Home, Remote Home, Remote Interface, Local Interface, Key Class и Bean Class. К тому же нужны дескрипторы разработки объекта-сущности EJB, а также файл соответствия и схема базы данных. Даже простое обращение к объекту-сущности СМР требует множества шагов. Например, для операции обновления нужно взять контекст JNDI, найти местонахождение EJB, найти объект-сущность EJB, а затем обновить объект.
  • Объекты-сущности СМР зависят от сервера J2EE. Разные серверы требуют разного кода реализации и разных дескрипторов реализации. Все это приводит к дополнительной работе по управлению кодом и распространению продукта.

Проблема прямого вызова JDBC

При написании запросов JDBC ORM требуется ручное кодирование. Это утомительный, подверженный ошибкам процесс, который снижает производительность труда.

Проблемы комбинирования JDBC и EJB2 CMP

Доступ к базе данных с использованием одновременно JDBC и EJB2 CMP может вызвать проблемы синхронизации при обновлении и совместном выполнении запросов в одной транзакции. В процессе транзакции обновление через объект-сущность CMP EJB2 не передается в базу данных до окончания транзакции, поэтому обновленные данные не видны последующему запросу JDBC, который является частью той же транзакции.

Проблемы производительности

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

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

Проблемы развития технологии

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

  • Мы планируем использовать тип данных XML, который не является стандартным типом JDBC SQL. Наш продукт может работать на СУБД DB2 и Oracle, каждая из которых по-своему интерпретирует тип данных SQL. Это означает, что нам придется модифицировать операторы SQL CRUD для каждой СУБД. Однако базовые операторы SQL CRUD, генерируемые объектами-сущностями СМР, модифицировать нельзя, что исключает для нас возможность принятия типа данных XML.
  • Рабочая группа JEE5 забраковала EJB2/CMP и заменяет их на EJB3/Java Persistence API (JPA). Внедрение EJB3/JPA призвано упростить разработку и обеспечить повышенную гибкость в сложных сценариях запросов. EJB3/JPA по-прежнему основаны на концепции управления сущностями.

Чего мы ждем от нового механизма персистентности

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

  • Требуются только простые возможности объектно-реляционного преобразования, в частности:
    • Преобразование имени атрибута компонента Java в имя столбцы таблицы, но не преобразование отношений сущности или наследования
    • Поддержка преобразования суперкласса; преобразование атрибута в столбец, определяемое в суперклассе, должно быть доступно для его дочернего класса. Однако сам суперкласс не преобразуется в таблицу. Это сэкономит усилия по преобразованию, необходимые для многих общих атрибутов и столбцов.
    • Генерация SQL для основных операций с сущностями CRUD
    • Обратный вызов событий жизненного цикла сущности для управления некоторой логикой до и после вставки, редактирования и удаления
  • Весь генерируемый код должен быть переносимым на разные серверы приложений.
  • Процесс разработки по реализации механизма персистентности должен быть простым, чтобы уменьшить стоимость разработки, связанной с модернизацией. Это предусматривает поддержку инструментов разработки для реализации подхода «от обратного», так и подхода «встречи в середине».
    • Подход «от обратного» предполагает, что схема таблицы базы данных уже есть, и требуется разработать объектный уровень и объектное реляционное преобразование, исходя из схемы таблицы.
    • Подход «встречи в середине» предполагает, что уже есть схема таблицы базы данных, плюс объектный уровень, и нужно разработать ORM между ними.
  • Расширяемость и гибкость, включая доступ к полным возможностям SQL и способность менять любые сгенерированные операторы CRUD SQL.
  • Выбранный нами механизм персистентности должен хорошо работать по сравнению с нашим существующим механизмом.
  • Гладкий путь перехода для нашего существующего кода
  • Клиенты могут дополнять наш продукт новыми сущностями и атрибутами, и механизм должен быть обратно совместим с существующим кодом наших клиентов.
  • Должна существовать технология для реализации плана выпуска следующей версии нашего продукта, и риски, связанные с ее освоением, должны быть минимальными.
  • Технология должна иметь твердый план развития, согласованный с нашими директивами, который со временем будет давать нам новые преимущества. Кроме того, технология должна быть доступной в течение минимум пяти лет.

Сравнение управляемой персистентностис pureQuery

С учетом всех ожиданий от нового механизма персистентности мы для сравнения рассмотрели три механизма персистентности: 1) наш существующий механизм персистентности - EJB2 CMP, 2) EJB3/JPA и 3) pureQuery. EJB2/CMP и EJB3/JPA представляют собой решения управляемой персистентности, тогда как pureQuery, как уже говорилось, — нет. Наша оценка этих технологий в соответствии с предъявляемыми требованиями приведена в табл. 1.

Таблица 1. Сравнение механизмов персистентности
EJB 2/CMP (без изменений)EJB3/JPApureQuery
Простое объектно-реляционное преобразованиеЧастичная поддержкаПолная поддержка стиля POJOПолная поддержка стиля POJO
Простота разработки / Работа на разных серверах приложенийСложная

Разный генерируемый код для разных реализаций CMP на разных серверах приложений

Простая

Разный генерируемый код для разных реализаций JPA на разных серверах приложений

Простая

Поддержка SQL встроена в редактор для Java. Генерируется единый код для разных серверов приложений

Гибкость и растяжимостьГенерируемый код CRUD SQL не может быть изменен Генерируемый код INSERT SQL не может быть изменен Генерируемый код CRUD SQL может редактироваться
ПроизводительностьМинимальная
  • Запросы через CMP выполняются плохо
  • Сценарий чтения и редактирования для обновления сущности
  • Дополнительные расходы на управление сущностями
Лучше
  • Запросы выполняются через API JPA
  • Сценарий чтения и редактирования для обновления сущности
  • Дополнительные расходы на управление сущностями
Наилучшая
  • Запросы API или запросы стиля метода выполняются хорошо
  • Сценарий только редактирования для обновления сущности
  • Управление сущностями отсутствует, что снижает расходы
Миграция и обратная совместимостьНикакой миграции не требуется, это исходная точка Требуется миграция. Должна быть обратная совместимость со спецификацией JEE. Требуется миграция. Должна быть обратная совместимость в зависимости от конструкции.
Доступность технологииДоступна Доступна Доступна (хотя мы работаем с предварительным кодом)
План развития технологииОтвергнута
  • План и направление развития в руках JCP
  • Новые функции могут осваиваться медленно
  • Четкий план развития, согласованный со стратегией персистентности IBM
  • Быстрое добавление или освоение новых функций
РискСо временем стоимость может повыситься, если поддержка в серверах приложений будет исключена. Потенциальные проблемы производительности из-за управления сущностями. Потенциальные проблемы производительности из-за управления сущностями Минимальный

Принятие решения и развитие существующего плана

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

С учетом помощи Data Studio Developer по SQL-разработке и его нацеленности на разработку, сфокусированную на данных, естественным выбором для нас стала технология pureQuery. В поддержку своего решения механизма персистентности мы разработали план по проверке этой технологии в следующих областях:

  • Определение среды разработки и реализации pureQuery
    • Исследование модели программирования
    • Исследование программной платформы для реализации продукта
    • Исследование программной платформы для разработки продукта
    • Исследование инструмента разработки для объектно-реляционного преобразования
    • Исследование оптимистичной реализации управления
  • Оценка объема работы по миграции CMP и прямому обращению JDBC к pureQuery
    • Исследование возможности переноса существующих компонентов CMP EJB WebSphere Customer Center
    • Исследование возможности переноса существующих прямых вызовов JDBC
  • Тест функционирования для исключения наших опасений по поводу обратной совместимости
    • Исследование сосуществования pureQuery с EJB2/CMP и прямого вызова JDBC.
    • Исследование в области поддержки Global Transaction (XA).
  • Сравнительный тест для исключения наших опасений по поводу производительности и доказательства того, что производительность нового механизма лучше, чем существующего.

Заключение

В этой статье дается обзор InfoSphere Master Data Management Server и Data Studio Developer/pureQuery. Затем в ней разбирается механизм персистентности, который использовался в WebSphere Customer Center. Перечислены несколько проблем механизма персистентности, которые требуется решить. Учитывая свои ожидания в отношении механизма персистентности, мы провели сравнение EJB2/CMP, EJB3/JPA и pureQuery. Мы выбрали pureQuery и разработали план действий для дальнейшей проверки правильности своего решения.

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

Ресурсы

Научиться

Получить продукты и технологии

Обсудить

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



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

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Information Management, Технология Java
ArticleID=424298
ArticleTitle=Переход с управляемой контейнером персистентности EJB 2 на pureQuery для IBM Master Data Management Server: Часть 1. Оценка технологии pureQuery
publish-date=08312009