Accès aux données avec SDO (Service Data Objects), versions d'API 1.0 et 2.01

L'infrastructure Service Data Objects (SDO) est un mécanisme d'accès aux données orienté données, hors connexion, intégrant XML et qui fournit un ensemble de résultats indépendant de la source.

  • SDO est centré sur les données car il évite aux applications client de devoir gérer des formats de données spéciaux, tels que les représentations objet de l'API EJB (Enterprise JavaBean). A la place, les clients gèrent des graphiques de DataObjects.
  • SDO est un mécanisme hors connexion parce que le résultat extrait est indépendant de toute connexion au magasin de données dorsal ou de toute transaction avec ce dernier.
  • SDO est un mécanisme intégrant XML en ce sens qu'il fournit des services permettant de convertir facilement les données extraites au format XML ou à partir de ce format.
Plus simplement, SDO est une structure dédiée au développement d'applications de données, incluant une architecture et une API. SDO :
  • simplifie le modèle de programmation de donnéesJava™ Platform Enterprise Edition (Java EE).
  • analyse les données dans une architecture orientée services (SOA),
  • unifie le développement d'applications de données,
  • prend en charge et intègre XML,
  • intègre les meilleures pratiques et les modèles Java EE.

La structure SDO (Service Data Objects) met à disposition une structure unifiée pour le développement d'applications de données. Avec SDO, vous n'avez pas besoin de connaître une API propre à une technologie pour pouvoir accéder aux données et les utiliser. Vous devez uniquement connaître l'API SDO qui vous permet de gérer des données provenant de plusieurs sources de données, y compris de bases de données relationnelles, de composants EJB entity, de pages XML, de services Web, de ressources Java Connector Architecture, de pages JSP, etc.

A la différence de certains modèles d'intégration de données, SDO ne s'arrête pas à l'abstraction des données. La structure SDO comporte également plusieurs valeurs recommandées et modèles Java EE afin de faciliter l'intégration de conceptions et d'architectures fiables dans vos applications. Par exemple, la plupart des applications Web aujourd'hui ne sont ni connectées ni connectables à des systèmes dorsaux en permanence. C'est pourquoi SDO prend en charge un modèle de programmation hors connexion. De même, nombre applications sont souvent complexes et comprennent plusieurs couches. Comment sont stockées les données ? Comment sont-elles envoyées ? Sont-elles présentées aux utilisateurs dans une structure d'interface graphique utilisateur ? Le modèle de programmation SDO préconise des modèles d'utilisation permettant de traiter clairement chaque question séparément.

Composants SDO

Cette présentation de l'architecture SDO décrit les composants de la structure et comment ils fonctionnent les uns avec les autres. Les trois premiers composants répertoriés représentent des fonctions "conceptuelles" de SDO ; ils ne possèdent pas d'interface correspondante dans l'API.

Clients SDO

Les clients SDO utilisent la structure SDO pour travailler avec les données. Au lieu d'utiliser les structures et les API propres à la technologie, ils utilisent une API et un modèle de programmation SDO. Les clients SDO utilisent des objets de données SDO et n'ont pas besoin de savoir si les données avec lesquelles ils travaillent sont conservées ou sérialisées.

Service DMS
Le service DMS (Data mediators services) crée un graphiques de données à partir des sources de données et met à jour les sources de données selon les modifications apportées au graphique. (Un graphique de données est un objet enveloppe qui contient des objets de données de service).

Le service DMS met à disposition le mécanisme permettant de déplacer des données entre un client et une source de données. Il est créé à l'aide de métadonnées spécifiques au système dorsal. Ces métadonnées définissent la structure du datagraphe qui est généré par le service DMS, ainsi que la requête à exécuter sur le système dorsal. Lorsque le service DMS reçoit une demande de génération de graphique de données, il interroge le système dorsal ciblé et convertit l'ensemble de résultats natif au format du graphique de données. Une fois que le graphique de données est renvoyé, le service DMS ne contient plus aucune référence à ce dernier ; il ne possède par conséquent aucun état relativement au graphique de données. Lorsque le service DMS reçoit une demande de vidage des modifications d'un graphique de données existant dans le système dorsal, il extrait les modifications apportées depuis l'état initial du graphique de données et transfère ces modifications dans le système dorsal. Généralement, un service DMS recourt à une sorte de stratégie optimiste de contrôle des accès concurrents afin de détecter les collisions de mise à jour.

WebSphere Application Server fournit des fonctionnalités pour deux services DMS distincts. Si vous souhaitez simplement extraire des données d'une source de données relationnelle et renvoyer un graphique de données, l'utilisation du service Java Database Data Mediator Service est recommandée. Cependant, dans une logique applicative, vous souhaiterez probablement obtenir un rendu des données des bean entity orienté objet (OO). On peut considérer un objet SDO comme un rendu d'objet des données comme des beans entity. Mais les beans entity disposent d'outils de mappage objet-relationnel (OR) plus performants. De plus, le conteneur EJB et le gestionnaire de persistance proposent des stratégies de mise en cache plus sophistiquées. Le choix le plus judicieux est donc EJB Data Mediator Service. Le médiateur EJB peut gérer ces caches. En outre, le modèle de programmation de bean entity est un modèle de magasin à niveau unique. Vous pouvez naviguer d'une entité à une autre. Le conteneur et le gestionnaire de persistance pré-extraient ou extraient les données lentement au besoin. Au moment de la mise à jour, le programmeur valide la transaction, et le conteneur et le gestionnaire de persistance surveillent les beans mis à jour et les écrivent dans le magasin de données et dans le cache.

Sources de données
Les sources de données ne comprennent pas seulement les sources de données dorsales (comme les bases de données de persistance). Une source de données contient des données dans le format qui lui est propre. Concernant l'API SDO 1.0, seul le service DMS accède aux sources de données ; les applications SDO n'y accèdent pas. Les applications fonctionnent uniquement avec les graphiques de données SDO 1.0.
Chacun des composants ci-après correspond à une interface Java dans le modèle de programmation SDO.
Objets de données (DataObjects)

Les objets de données sont des composants essentiels de SDO et fournissent aux clients SDO une vue commune des données structurées créées. Les objets de données peuvent contenir plusieurs attributs différents de n'importe quel type sérialisable (par exemple, une chaîne ou un entier). Les objets de données plus complexes peuvent aussi comprendre des objets de données plus simples. Les objets de données contiennent toutes leurs données dans les propriétés.

Les objets de données SDO version 1.0 sont toujours liés les uns aux autres et contenus dans des graphiques de données. L'interface d'objet de données de la version 1.0 fournit des méthodes simples de création et de suppression (createDataObject() avec différentes signatures et delete()) ainsi que des méthodes réflexives permettant d'obtenir leurs types (classe d'instance, nom, propriétés et espaces de noms). L'interface prend aussi en charge des types d'objet statiques que vous créez à partir de générateurs de code externes. Voir l'article "Dynamic and static object types for the JDBC DMS" (Types d'objet dynamique et statiques pour le DNSJDBC" pour plus d'informations.

Graphique de données (datagraph)

Un graphique de données est un résultat structuré renvoyé en réponse à une demande de service. Le service DMS convertit les résultats des requêtes du système dorsal au format natif en un graphique de données qui est indépendant du magasin de données dorsal d'origine. Cette caractéristique permet au graphique de données d'être transféré aisément entre différentes sources de données. Le graphique de données est composé de noeuds interconnectés dont chacun est un élément DataObject SDO. Il est indépendant des connexions et des transactions de la source de données d'origine. Le graphique de données permet le suivi des modifications qui lui ont été apportées à partir de sa source d'origine. Le service DMS peut utiliser cet historique des modifications pour répercuter les modifications dans la source de données d'origine. Les graphiques de données peuvent facilement être convertis en documents XML, et vice versa, ce qui permet de les transférer entre différentes couches d'une architecture système à plusieurs niveaux. Un graphique de données peut être parcouru soit en "largeur d'abord", soit en "profondeur d'abord" ; par ailleurs, il fournit une cache de données hors connexion qui peut être sérialisée pour les services Web.

Le graphique de données renvoyé par le médiateur peut contenir des objets de données dynamiques ou statiques générés. L'utilisation de classes générées produit des interfaces garantissant la cohérence entre types et données, ce qui permet une programmation plus aisée et l'amélioration des performances d'exécution. Les classes générées par EMF doivent utiliser des noms et des types concordant avec le schéma qui serait créé pour les objets de données dynamiques, à cela près que des attributs et des références supplémentaires peuvent être définis. Seuls les attributs et les références spécifiés dans la requête sont renseignés à l'aide de données. Les autres attributs et références ne sont pas définis.

Récapitulatif des modifications

Les récapitulatifs des modifications dans SDO 1.0 se trouvent dans les graphiques des données et représentent les modifications apportées à un graphique de données renvoyé par le service DMS. A l'origine, ils sont vides (lorsque le graphique de données est renvoyé au client) et alimentés au fur et à mesure que le graphique de données est modifié. Le service DMS les utilise au moment de la mise à jour dorsale pour répercuter les modifications dans la source de données. Ils permettent au service DMS de mettre à jour les sources de données de façon efficace et incrémentielle en fournissant la liste des propriétés modifiées (ainsi que les anciennes valeurs) et des objets de données créés et supprimés dans le graphique de données. Les informations sont ajoutées au récapitulatif des modifications d'un graphique de données uniquement si la journalisation du récapitulatif des modifications est activée. Les récapitulatifs des modifications mettent à disposition du service DMS des méthodes permettant d'activer et de désactiver la journalisation.

Remarque : Un récapitulatif des modifications n'est pas une API client et n'est utilisé que par le service DMS.
Propriétés, types et séquences

Les objets de données conservent leurs données dans une série de propriétés. Chaque propriété possède un type : il peut s'agir d'un type d'attribut comme un type de données primitif (par exemple int) ou couramment utilisé (par exemple Date) ou, s'il s'agit d'une référence, du type d'un autre objet de données. Chaque objet de données fournit des méthodes d'accès en lecture et en écriture (getter et setter) pour ses propriétés. Plusieurs versions surchargées de ces programmes d'accès sont mises à disposition, et permettent l'accès aux propriétés via la transmission du nom de la propriété (String), du numéro (int) ou de l'objet méta de la propriété lui-même. Le programme d'accès String prend également en charge une syntaxe qui ressemble à XPath pour l'accès aux propriétés. Vous pouvez par exemple appeler get("department[number=123]") sur l'objet de données company pour extraire le premier département dont le numéro est 123. Les séquences sont des notions plus complexes. Elles permettent de conserver l'ordre entre les listes hétérogènes de paires propriété-valeur.

Informations de présentation supplémentaires

Pour obtenir une bonne présentation de SDO 1.0 qui inclut également un petit exemple d'application, voir l'article IBM® developerWorks intitulé "Introduction to Service DataObjects."

Remarque : Pour bien comprendre le service DMS EJB, vous devez posséder une bonne connaissance du modèle de programmation EJB. Pour plus d'informations, voir les articles "Task overview: Using enterprise beans in applications" et "Service Data Objects: Resources for learning."

Icône indiquant le type de rubrique Rubrique de concept



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cdat_datsdo
Nom du fichier : cdat_datsdo.html