Acceso a datos con Service DataObjects, API versiones 1.0 y 2.01

La infraestructura SDO (Service Data Objects - Objetos de datos de servicio) es un mecanismo de acceso a datos desconectado, centrado en los datos e integrado en XML, que proporciona un conjunto de resultados independientes del origen.

  • SDO está centrado en datos porque elimina la necesidad de que las aplicaciones cliente trabajen con formatos especiales de datos, por ejemplo las representaciones de objetos de la API de EJB (Enterprise JavaBeans). En su lugar, los clientes trabajan con gráficos de fácil transversalidad de DataObjects.
  • SDO está desconectado porque el resultado recuperado es independiente de las transacciones o conexiones del almacén de datos de programa de fondo.
  • SDO está integrado en XML porque proporciona servicios para convertir fácilmente los datos recuperados a y desde el formato XML.
Básicamente, SDO es una infraestructura para el desarrollo de aplicaciones de datos, que incluye una arquitectura y una API. SDO tiene las siguientes características:
  • Simplifica el modelo de programación de datos de Java™ Platform, Enterprise Edition (Java EE).
  • Resume datos en una arquitectura orientada a servicios (SOA).
  • Unifica el desarrollo de aplicaciones de datos.
  • Da soporte a XML y lo integra.
  • Incorpora patrones Java EE y procedimientos recomendados.

La infraestructura Service Data Objects proporciona una infraestructura unificada para el desarrollo de aplicaciones de datos. Con SDO, no necesita estar familiarizado con una API específica de tecnología a fin de acceder y utilizar los datos. Sólo tiene que conocer una API, la API de SDO, que permite trabajar con datos de varios orígenes de datos, incluidas bases de datos relacionales, componentes de EJB de entidad, páginas XML, servicios web, JCA (Java Connector Architecture), JSP (JavaServer Pages) y más.

A diferencia de algunos de los otros modelos de integración de datos, SDO no se detiene en la abstracción de datos. La infraestructura SDO también incorpora numerosos patrones de Java EE y procedimientos recomendados, lo que facilita la incorporación de arquitecturas y diseños probados en las aplicaciones. Por ejemplo, la mayoría de las aplicaciones web actuales no están (y no pueden estar) conectadas a sistemas de fondo el 100 por cien del tiempo; por lo tanto, SDO soporta un modelo de programación desconectado. De la misma manera, muchas aplicaciones tienden a ser muy complejas, con varias capas de complejidad. ¿Cómo se almacenarán los datos? ¿Cómo se enviarán? ¿Se presentarán a los usuarios en una infraestructura de GUI? El modelo de programación SDO prescribe patrones de uso que permiten una separación nítida de cada una de estas cuestiones.

Componentes SDO

Una visión general de la arquitectura de SDO describe cada uno de los componentes que conforman la infraestructura y explica cómo pueden trabajar conjuntamente. Los tres primeros componentes que aparecen son características "conceptuales" de SDO: no tienen una interfaz correspondiente en la API.

Clientes SDO

Los clientes SDO utilizan la infraestructura SDO para trabajar con los datos. En lugar de utilizar infraestructuras y API específicas de cada tecnología, utilizan la API y el modelo de programación SDO. Los clientes SDO trabajan en DataObjects SDO y no necesitan saber cómo persisten o se serializan los datos con los que trabajan.

Data Mediator Services
Los DMS (Data Mediator Services) son los responsables de crear un DataGraph a partir de los orígenes de datos, y actualizar los orígenes de datos basándose en los cambios realizados en un DataGraph. (Un DataGraph es un objeto de sobre que contiene objetos de datos de servicio.)

El DMS proporciona un mecanismo para trasladar datos entre un cliente y un origen de datos. Se crea con metadatos específicos del programa de fondo. Los metadatos definen la estructura del DataGraph que el DMS produce, así como la consulta que se va a utilizar en el programa de fondo. Cuando DMS debe producir un DataGraph, consulta el programa de fondo de destino y transforma el conjunto de resultados original en el formato del DataGraph. Una vez devuelto el DataGraph, DMS ya no incluye ninguna referencia a él, lo que lo deja sin estado con respecto al DataGraph. Cuando DMS debe vaciar las modificaciones de un DataGraph existente en el programa de fondo, extrae los cambios realizados desde el estado original del DataGraph y los vacía en el programa de fondo. Un DMS utiliza normalmente algún tipo de estrategia de control de simultaneidad optimista para detectar colisiones de actualizaciones.

WebSphere Application Server ofrece funciones para dos Data Mediator Services independientes. Si sólo tiene que recuperar datos de un origen de datos relacional y devolver un DataGraph, es una buena opción el uso de Java Database Data Mediator Service. No obstante, si dispone de lógica empresarial, es probable que desee una representación orientada a objetos (OO) de los datos en beans de entidad. Los SDO se pueden considerar como una representación de objetos de datos similar a los beans de entidad. Pero los beans de entidad tienen mejores herramientas de correlación relacional de objetos (OR) y el contenedor de EJB y el gestor de persistencia para los beans de entidad ofrecen políticas de colocación en memoria caché más sofisticadas. Por lo tanto, la mejor opción es EJB Data Mediator Service. El mediador EJB puede funcionar con estas memorias caché. Asimismo, el modelo de programación de beans de entidad es un modelo de un único nivel de almacenamiento. Puede navegar de entidad a entidad y el contenedor y el gestor de persistencia busca previamente o busca vagamente en los datos según sea necesario. Al actualizar, el programador compromete la transacción y el contenedor y el gestor de persistencia llevan a cabo el trabajo de rastrear los beans actualizados y escribirlos de nuevo en el almacén de datos y en la memoria caché en memoria.

Orígenes de datos
Los orígenes de datos no están restringidos a los orígenes de datos de programa de fondo (por ejemplo, bases de datos de persistencia). Un origen de datos contiene datos en su propio formato. En lo referente a la API de SDO 1.0, sólo DMS accede a los orígenes de datos; las aplicaciones SDO no lo hacen. Las aplicaciones sólo funcionan con DataGraphs de SDO 1.0.
Cada uno de los siguientes componentes se corresponde con una interfaz Java en el modelo de programación SDO.
DataObjects

Como componentes fundamentales de SDO, los DataObjects proporcionan una vista común de datos estructurados para clientes SDO. Los DataObjects pueden mantener varios atributos diferentes de cualquier tipo serializable (como, por ejemplo, serie o entero); otros DataObjects complejos también pueden contener DataObjects más simples. Los DataObjects mantienen todos sus datos en propiedades.

Los DataObjects de SDO versión 1.0 están enlazados siempre y contenidos en DataGraphs. La interfaz de DataObject versión 1.0 proporciona métodos simples de creación y supresión (createDataObject() con varias firmas y delete()), y métodos reflectivos para obtener sus tipos (clase de instancia, nombre, propiedades y espacios de nombres). La interfaz también da soporte a tipos de objeto estáticos que se crean a partir de generadores de código externo. Para obtener más información, consulte el artículo "Dynamic and static object types for the JDBC DMS".

DataGraphs

Un DataGraph es un resultado estructurado que se devuelve como respuesta a una solicitud de servicio. DMS transforma los resultados originales de la consulta de programa de fondo en el DataGraph, que es independiente del almacén de datos del programa de fondo original. Esto hace que el DataGraph sea fácilmente transferible entre orígenes de datos diferentes. El DataGraph está formado por nodos interconectados, cada uno de los cuales es un SDO DataObject. Es independiente de las conexiones y las transacciones del origen de datos original. DataGraph realiza un seguimiento de los cambios efectuados en él desde su origen. DMS puede utilizar este historial de cambios para reflejar de nuevo el origen de datos original. Los DataGraphs se puede convertir fácilmente a y desde documentos XML, lo que permite transferirlos entre capas dentro de una arquitectura de sistemas de varios niveles. Se puede acceder al DataGraph "primero a lo ancho" o "primero en profundidad", y proporciona una memoria caché de datos desconectada que se puede serializar para los servicios web.

El DataGraph que devuelve el mediador puede contener DataObjects generados estáticos o dinámicos. El uso de las clases generadas proporciona interfaces seguras de tipo que facilitan la programación y mejoran el rendimiento del tiempo de ejecución. Las clases generadas EMF deben tener un nombre y un tipo coherentes con el esquema que se creará para los DataObjects dinámicos, aunque se pueden definir referencias y atributos adicionales. Sólo se rellenan con datos aquellos atributos y referencias especificados en la consulta. Los atributos y referencias restantes no se establecen.

Resumen de cambios

Los resúmenes de cambios de SDO 1.0 están contenidos en DataGraphs y se utilizan para representar los cambios que se han realizado en un DataGraph devuelto por el DMS. Inicialmente están vacíos (cuando se devuelve el DataGraph a un cliente) y se rellenan a medida que se modifica el DataGraph. El DMS utiliza los resúmenes de cambios durante la actualización de programas de fondo para volver a aplicar los cambios al origen de datos. Los resúmenes de cambios permiten que el DMS actualice de forma eficaz e incremental los orígenes de datos proporcionando listas de las propiedades modificadas (con sus valores antiguos) y los DataObjects creados y suprimidos en el DataGraph. Sólo se añade información al resumen de cambios de un DataGraph cuando se activa el registro cronológico del resumen de cambios. Los resúmenes de cambios proporcionan métodos para que el DMS pueda activar y desactivar el registro cronológico.

Nota: El resumen de cambios de SDO 1.0 no es una API de cliente; sólo lo utiliza el DMS.
Propiedades, tipos y secuencias

Los DataObjects mantienen su contenido en una serie de propiedades. Cada propiedad tiene un tipo, que puede ser un tipo de atributo como un primitivo (por ejemplo, int) o un tipo de dato utilizado normalmente (por ejemplo, Date) o, si es una referencia, el tipo de otro DataObject. Cada DataObject proporciona métodos de acceso de lectura y escritura (getters y setters) para sus propiedades. Se proporcionan varias versiones sobrecargadas de estos accesores, lo que permite acceder a las propiedades pasando el nombre de la propiedad (String), el número (int) o el propio metaobjecto de la propiedad. El accesor String también da soporte a una sintaxis de tipo XPath para acceder a las propiedades. Por ejemplo, puede llamar a get("department[number=123]") en un DataObject de la empresa para obtener el primer departamento cuyo número sea 123. Las secuencias son más avanzadas. Permiten conservar el orden a través de listas heterogéneas de pares propiedad-valor.

Para obtener una introducción más completa

Para ver una buena introducción de SDO 1.0 que también incluya una pequeña aplicación de ejemplo, consulte el documento de IBM® developerWorks "Introducción a Service DataObjects."

Nota: Para entender bien el DMS de EJB, debe conocer el modelo de programación EJB. Para obtener más información, consulte los artículos "Task overview: Using enterprise beans in applications" y "Service Data Objects: Resources for learning."

Icon that indicates the type of topic Concept topic



Timestamp icon Last updated: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cdat_datsdo
File name: cdat_datsdo.html