médiateur d'objet métier

Le médiateur d'objet métier effectue des transformations bidirectionnelles entre les objets SDO physiques et les SDO logiques. A travers ce rôle, il fournit une interface de persistance d'objet métier pour la couche service de données. Le médiateur d'objet métier prend en charge les opérations de lecture, de mise à jour et de suppression sur les objets SDO logiques de sorte à ce que la couche service de données puisse les utiliser au lieu du schéma physique.

Dans HCL Commerce version 6, avant le Feature Pack 3, la logique métier traitait directement les Enterprise Java™ Bean (EJB). Bien que ces beans soient relativement faciles à manipuler, leur inconvénient est qu'ils constituent un mappage direct au schéma physique, ce qui complique l'extension et la personnalisation. La manipulation directe des EJB lie également la logique métier à la technologie de persistance. Avec le passage de WebSphere® à l'architecture SOA et l'élargissement de la prise en charge de clients de services Web, un modèle logique d'objets SDO a été défini pour la logique métier à utiliser. Les objets de ce modèle logique, les objets SDO logiques, constituent le mécanisme d'échange de données pour l'interaction entre composants, tout comme pour les interactions avec les services Web.

La couche de persistance exploite également un jeu d'objets de données de service, appelés objets SDO physiques. LES SDO physiques sont des objets Java™ qui représentent le schéma physique. Le médiateur d'objet métier fournit le mappage entre ces objets SDO logiques et leurs homologues dans la couche de persistance, les objets SDO physiques.

Dans le cadre du processus de transformation, le médiateur d'objet physique utilise les services du conteneur de données physiques afin d'extraire et de mémoriser les données physiques. Ce conteneur gère concrètement l'interaction avec le schéma physique. Le conteneur de données physiques gère les objets SDO physiques : il peut les créer, stocker des grappes de ces objets et les enregistrer dans la base de données.

Comme illustré dans le diagramme ci-dessus, la persistance de données via la couche service de données peut être assurée de deux manières. L'approche usuelle consiste à appeler le médiateur d'objet métier afin de transformer vos objets SDO logiques en objets SDO physiques. Cependant, les commandes de la logique métier doivent occasionnellement opérer directement sur des objets physiques car ils ne sont pas mappés au modèle logique. Par exemple, les tables utilisées pour conserver des journaux d'audit ou des statistiques. Dans ces circonstances, la couche de logique métier peut utiliser le conteneur de données physiques pou lire et écrire des données directement dans la base de données.

Médiateurs de lecture et de changement

La couche service de données initialise les médiateurs d'objet métier. Il s'agit de classes opérant une transformation entre les représentations logiques et physiques du modèle du domaine. Ceci permet à la couche de logique métier de ne manier que la représentation logique des données. Chaque module de service fournit sa propre implémentation pour les médiateurs.

Chaque module de service fournit ses propres médiateurs qui peuvent être de deux type : Médiateurs de lecture et de changement. Ces médiateurs sont répertoriés dans le fichier Configuration du médiateur d'objet métier. Les médiateurs de lecture sont utilisés pour le traitement des requêtes Get d'OAGIS. Les médiateurs de changement traitent les requêtes OAGIS Change, Process et Sync.

Pour les opérations de lecture, la façade de la couche service de données reçoit une requête de la couche de logique métier. La requête consiste d'une expression XPath et d'un profil d'accès, extraits à partir du verbe OAGIS GET. La couche service de données fait suivre cette requête au médiateur d'objet métier, lequel la transmet à son tour au service de persistance. Ce dernier identifie le modèle SQL approprié pour la requête et l'utilise afin de générer une ou plusieurs instructions SQL. Il exécute ensuite ces instructions et mappe leurs jeux de résultats avec des objets SDO physiques. Ce mappage entre le schéma de base de données (tables et colonnes) et les classes SDO est défini par l'élément XML dénommé Métadonnées objet-relationnel. Enfin, les objets SDO physiques sont renvoyés au médiateur d'objet métier. La configuration de médiateur d'objet métier décrit comment instancier les médiateurs requis, lesquels sont renvoyés à la couche de logique métier.

Remarque : Le médiateur lui-même est renvoyé et non pas seulement l'objet SDO. Le médiateur contient les données de l'objet SDO physique. Il contient également la logique destinée à la conversion de l'objet SDO physique en objet SDO logique (c'est-à-dire la représentation Java™ d'un nom OAGIS).

Pour les opérations de changement (création, mise à jour et suppression) la façade de la couche service de données reçoit en entrée les noms OAGIS et les transmet au service de médiation de l'objet métier. Ce service instancie les médiateurs de changement appropriés. A leur tour, ces médiateurs obtiennent la représentation physique des noms depuis un service nommé service de médiation d'objet physique. Le médiateur d'objet métier renvoie ensuite les médiateurs à la couche de logique métier. Ces médiateurs sont alors appelés avec des actions spécifiques pour créer, mettre à jour ou supprimer des noms et des parties de nom. La logique à l'intérieur des médiateurs convertit ces actions en opérations sur les objets SDO physiques. Une requête de création, par exemple, créera de nouveaux objets physiques et les alimentera avec des valeurs de noms. Après avoir effectué toutes ses modifications, la couche de logique métier indique au médiateur de changement de nom d'enregistrer les objets SDO physiques mis à jour. Le médiateur appelle un service de persistance d'objet physique pour mettre à jour la base de données.

Remarque :

• La suppression d'objets de la liste des objets de données physiques d'un médiateur n'est pas prise en charge. Autrement dit, appelez la méthode delete() sur le SDO physique directement pour le supprimer.
• Si vous tentez de supprimer un objet de données (DataObject) parent après avoir extrait ses enfants dans le même datagraphe, le médiateur JDBC de WebSphere Application Server renvoie une exception. Vous devez supprimer les objets DataObjects enfants avant leur parent. Cependant, si seul l'objet de données DataObject parent est extrait dans le graphe lorsque cet objet est supprimé, les entrées de la table enfant seront supprimées de la base de données sous réserve que la table de base de données de base contienne la contrainte ON DELETE CASCADE.