Если вы полагаете, что модели программирования и API J2EE принуждают разработчиков к затратам слишком большого количества времени на специфическую для технологии настройку, программирование и отладку, тогда эта статья для вас! Многие Java-разработчики скептически относятся к унификации доступа к гетерогенным данным и разочаровались в различных средах программирования, призванных решить проблему. В данной статье Java-разработчики Bertrand Portier и Frank Budinsky познакомят вас с программированием данных следующего поколения с использованием Service Data Objects (SDO).
Содержание
1 Почему SDO?
2 Сравнение технологий
3 SDO-компоненты
4 SDO и пример установки
5 Простое SDO-приложение
6 Клиент
7 Граф данных
8 DMS: Построение графа
9 DMS: обновление источников данных
10 Отладка приложения
11 Заключение
12 Ресурсы
13 Об авторах
Почему SDO?
Первым вопросом, который задаст большинство разработчиков о Service Data Objects (SDO), будет «почему». Не является ли J2EE достаточно большим и сложным (и сложным в изучении)? Кроме того, существуют же другие системы, поддерживающие XML на Java-платформе. К счастью ответ, который должен осчастливить большинство из нас, один: SDO возник как средство упрощения J2EE-модели программирования данных, предоставляя таким образом J2EE-разработчикам больше времени на работу с бизнес-логикой их приложений.
Система Service Data Objects предоставляет унифицированную среду для разработки приложений обработки данных. С SDO вам не обязательно изучать зависящий от используемой технологии API для обращения и обработки данных. Вы должны знать только один API — SDO API, который позволит вам работать с данными из различных источников данных, включая реляционные базы данных, EJB-компоненты управления данными, XML-страницы, Web-службы, Java Connector Architecture, страницы JavaServer Pages и др.
Отметим, что мы используем слово среда (framework). Аналог — среда Eclipse. Eclipse спроектирован так, что инструментальные средства могут быть интегрированы благодаря их цельной и расширяемой природе. SDO является аналогией в том смысле, что предоставляется среда, в которую могут быть интегрированы приложения и эти приложения будут согласованы с SDO-моделью.
В отличие от некоторых других моделей интеграции данных, SDO не останавливается на абстракции данных. Среда SDO содержит также большое количество J2EE-шаблонов и примеров использования, что облегчает включение проверенной архитектуры и дизайна в ваши приложения. Например, большинство современных Web-приложений не связаны (и не могут быть) с системой хранения данных 100% времени; поэтому SDO поддерживает разъединенную модель программирования. Кроме того, современные приложения становятся очень сложными, работающими на нескольких уровнях предприятия. Как будут храниться данные? Передаваться? Представляться конечному пользователю в GUI-программах? Программная модель SDO предписывает шаблоны использования, что дает возможность четкого разделения каждого из этих уровней.
Повсеместно используемым в распределенных приложениях становится стандарт XML. Например, XML Schema (XSD) применяется для определения бизнес-правил в формате данных приложения. Также XML сам по себе используется для облегчения взаимодействия: Web-службы используют основанный на XML протокол SOAP в качестве технологии обмена сообщениями. XML является очень важной сущностью в SDO, поддерживается и интегрируется в нее.
Сравнение технологий
Как было отмечено ранее, SDO не является единственной технологией, предлагаемой для решения проблем интеграции данных в распределенных приложениях. В данном разделе мы рассмотрим, как SDO выглядит на фоне аналогичных сред программирования, таких как JDO, JAXB и EMF.
SDO и WDO
Web Data Objects, или WDO — это название ранней редакции SDO, поставляемой с IBM WebSphere Application Server 5.1 и IBM WebSphere Studio Application Developer 5.1.2. Если вы работали с WebSphere Studio 5.1.2, вы уже должны быть определенным образом знакомы с SDO, хотя возможно привыкли видеть их обозначенными как WDO, например, в названиях библиотек. Забудьте про WDO, они сейчас называются SDO!
SDO и JDO
JDO означает Java Data Objects. JDO был стандартизирован через Java Community Process (JCP) с версией 1.0 и технической версией 1.0.1 в мае 2003. Для версии 2.0 сформировалась экспертная группа JCP. JDO представляет собой программирование данных в среде Java и предоставляет общий API доступа к данным, хранящимся в источниках данных различного типа; например, базах данных, файловых системах или системах обработки транзакций. JDO сохраняет связи между Java-объектами (графами) и одновременно разрешает параллельный доступ к данным.
Назначение JDO аналогично назначению SDO в том смысле, что обе технологии хотят упростить и унифицировать программирование данных Java с тем, чтобы разработчики больше концентрировались на бизнес-логике, а не на используемых технологиях. Однако, главным отличием между ними является то, что JDO рассматривает только вопрос персистентности (на уровне данных J2EE и на уровне корпоративной информационной системы (EIS)), тогда как SDO охватывает более широкий круг вопросов и представляет данные, которые могут передаваться между уровнями J2EE, например, между уровнем представления и бизнес-уровнем.
Интересно что SDO может использоваться совместно с JDO. При этом JDO является источником данных, к которому может обращаться SDO, реализуя модель проектирования Data Transfer Object (DTO). SDO также может использоваться совместно с EJB-компонентами, управляющими данными, и Java Connector Architecture (JCA) для предоставления унифицированного доступа к данным.
SDO и EMF
EMF — это аббревиатура Eclipse Modeling Framework. Основываясь на модели данных, описанной с использованием Java-интерфейсов, XML Schema или диаграмм классов UML, EMF генерирует унифицированную метамодель (называемую Ecore), которая вместе со средой может быть использована для создания высококачественной реализации модели. EMF обеспечивает персистенцию, очень эффективный оригинальный API управления объектами и уведомляющую об изменениях среду. EMF включает также оригинальные повторно используемые классы для построения редакторов EMF-модели.
И EMF и SDO имеют дело с представлением данных. Фактически, справочная реализация SDO от IBM, которую мы будем использовать далее в данной статье, является EMF-реализацией SDO. Генерация кода EMF используется даже при создании некоторых SDO-реализаций, основанных на UML-описании модели SDO. По существу реализация SDO представляет собой тонкий уровень (фасад) над EMF и пакетируется и поставляется как часть EMF-проекта. См. раздел Ресурсы для дополнительной информации по EMF.
SDO и JAXB
JAXB — это аббревиатура Java API for XML Data Binding. JAXB 1.0 был выпущен группой JCP в январе 2003. Экспертная группа JCP уже подготовила проект версии 2.0. JAXB посвящен связыванию XML-данных; т.е. представлению XML-данных в виде Java-объектов в памяти. JAXB освобождает вас от необходимости самостоятельного синтаксического разбора или создания XML-документов, действуя как среда XML-связывания для Java. (Фактически вы освобождаетесь вообще от работы с XML.) JAXB выполняет маршаллизацию/сериализацию (Java в XML) и обратный процесс (XML в Java) вместо вас.
SDO определяет среду Java-связывания и идет на шаг дальше. JAXB уделяет внимание только связыванию Java-to-XML, в то время как XML — не единственный тип данных, связанный с SDO. Как было отмечено выше, SDO предоставляет унифицированный доступ к данным различных типов, одним из которых является XML. SDO определяет также статический и динамический API, а JAXB определяет только статическое связывание.
Примечание: пример приложения в данной статье использует только динамические SDO, хотя генератор кода EMF полностью поддерживает генерацию статического кода объектов данных.
SDO и ADO .NET
Обозначение ADO использовалось как аббревиатура ActiveX Data Objects, но в контексте .NET это уже не так. ADO .NET обеспечивает унифицированный доступ к данным между различными уровнями платформы .NET.
ADO .NET и SDO предназначены для решения одинаковых задач — поддержка XML и распределенных по нескольким уровням приложений. Главным различием между этими двумя технологиями, кроме технических, является то, что ADO .NET предназначена для платформы Microsoft .NET и является проприетарной технологией, в то время как SDO предназначена для платформы Java и стандартизирована через Java Community Process.
SDO-компоненты
В данном разделе мы рассмотрим архитектуру SDO. Мы опишем каждый из компонентов, составляющих платформу, и объясним принципы их совместной работы. Сначала мы рассмотрим три компонента, являющиеся «концептуальными» для SDO. Они не имеют соответствующих интерфейсов в API.
SDO-клиенты
SDO-клиенты используют платформу SDO для работы с данными. Вместо использования различных API и платформ они применяют программную модель и API SDO. SDO-клиенты работают с графами данных SDO (см. рисунок 1) и не нуждаются в знании особенностей хранения и сериализации используемых данных.
Промежуточные службы данных
Промежуточные службы данных (DMS) отвечают за создание графа данных из источника (источников) данных и обновление источников данных, основываясь на изменениях графа данных. Платформа для работы этих служб не является предметом рассмотрения спецификации SDO 1.0. Другими словами, в SDO 1.0 не говорится о конкретных DMS. Примерами DMS являются JDBC DMS, компонент управления данными EJB DMS, XML DMS и т.д.
Источники данных
Источники данных не ограничены базами данных. Данные могут храниться в любом формате. Только DMS обращается к источникам данных, SDO-приложения — нет. SDO-приложения могут работать только с объектами графов данных.
Каждый из следующих компонентов соответствует Java-интерфейсу в программной модели SDO. Справочная реализация SDO (см. раздел Ресурсы) предоставляет EMF-реализации этих интерфейсов.
Объекты данных
Объекты данных являются фундаментальными объектами SDO. Фактически именно они являются объектами данных служб, которые фигурируют в названии самой спецификации. Объекты данных — это SDO-представление структурированных данных. Они являются родовыми объектами и предоставляют общее видение структурированных данных, сформированное службами DMS. Если, например, для JDBC DMS необходимо знать об используемой технологии хранения (например, реляционные базы данных), способах доступа к данным и методах их конфигурирования, то для SDO-клиентов ничего этого не надо. Объекты данных хранят свои «данные» в свойствах (более подробно о свойствах далее) и предоставляют удобные методы создания и удаления (createDataObject() с различными параметрами и delete()), а также методы для получения их типа (класс реализации, название, свойства и пространство имен). Объекты данных связываются вместе и содержатся в графах данных.
Графы данных
Графы данных обеспечивают контейнер для дерева объектов данных. Графы данных создаются службами DMS для работы с ними SDO-клиентов. Если графы данных изменяются, они передаются обратно в DMS для изменения источника данных. SDO-клиенты могут просматривать граф данных, читать и изменять его объекты данных. SDO представляет собой изолированную архитектуру, поскольку SDO-клиенты не связаны с DMS и источниками данных; они видят только граф данных. К тому же, граф данных может состоять из объектов, представляющих данные из разных источников данных. Граф данных содержит корневой объект данных, связанные с ним остальные объекты данных и суммарный отчет по изменениям (более подробно о суммарных отчетах далее). При передаче между компонентами приложения (например, между заказчиком Web-службы и провайдером во время инициирования службы), передаче в DMS, или сохранении на диск графы данных сериализуются в XML. Для сериализации спецификация SDO предоставляет XML Schema. На рисунке 1 изображен граф данных SDO.