Service DMS (Data Mediator Service) Enterprise JavaBeans

Le service DMS (Data Mediator Service) EJB (Enterprise JavaBeans) est l'interface Java™ SDO (Service Data Objects) qui, au vu d'une demande émise sous forme de requêtes EJB, renvoie des données sous la forme d'un datagraphe contenant divers types d'objets de données.

Cela diffère des méthodes EJB classiques finder et ejbSelect qui prennent également une requête EJB mais qui renvoient une collection d'objets EJB (tous du même type) ou une collection de valeurs de persistance gérée par conteneur (CMP, Container Managed Persistence).

Le service DMS EJB permet de spécifier une requête EJB qui renvoie un datagraphe (graphique de données) des objets de données. La requête peut être exprimée sous forme de requête EJB composée contenue dans un tableau de chaînes d'instructions de requête EJB. L'avantage d'un datagraphe réside dans le fait que la plupart du code écrit dans un bean session de façade EJB impliqué dans la création, le remplissage et la mise à jour d'objet auxiliaires de copie peut être remplacé par un datagraphe et un service DMS.
Important : Le service DMS EJB ne prend en charge que les beans entity EJB2.x à persistance CMP. Il ne prend pas en charge les modules EJB 3.x.

L'appel getGraph permet d'obtenir un datagraphe à partir d'instances EJB mises en cache dans le conteneur ou de la requête d'interrogation compilée dans SQL et exécutée directement sur la source de données.

Les objets de données mis à jour peuvent être de nouveau écrits dans le magasin de données à l'aide de la méthode applyChanges de deux manières différentes. Soit en traduisant les mises à jour en SQL et en les appliquant directement au magasin de données ou en les réinscrivant via des méthodes d'accès EJB. La réinscription directe dans le magasin de données améliore les performances car elle évite l'activation d'EJB. Toutefois, si l'application requiert une fonction de logique métier ou de conteneur EJB, la réinscription via EJB est la meilleure méthode. Lors de la réinscription via EJB vous pouvez spécifier une méthode d'adaptateur de médiateur définie par l'utilisateur assurant une gestion personnalisée des objets de données modifiés. Cette personnalisation peut intégrer un contrôle des accès simultanés optimiste propre aux applications, l'appel de méthodes métier sur l'EJB pour effectuer des mises à jour, la mise à jour de valeurs calculées dans l'objet de données et l'appel de méthodes de création propres aux applications sur EJBHome.

Le traitement des mises à jour ne dépend pas de la façon dont le datagraphe a été extrait à l'origine. En d'autres termes, il est possible d'extraire un datagraphe directement de la source de données et d'appliquer les mises à jour différées via un bean enterprise ou d'une autre façon.

Quelle que soit la méthode retenue, un algorithme de contrôle des accès simultanés optimiste est utilisé. Les zones désignées comme étant cohérentes sont lues lors de la mise à jour pour s'assurer que la valeur courante est égale à l'ancienne valeur de la zone dans l'objet de données.

Traitement de la phase d'exécution

Une requête de médiateur d'EJB est une requête d'EJB composée, constituée d'une liste ordonnée de requêtes d'EJB classiques. Chaque requête de la requête composée définit un SDO. La clause SELECT de la requête désigne les expressions ou zones CMP à renvoyer dans l'objet de données. La clause WHERE indique les conditions de filtrage. La première requête de la liste est considérée comme étant le noeud racine du datagraphe. La clause FROM d'une requête (autre que la première clause) indique la relation EJB utilisée pour créer des références entre les objets données. Pour plus de détails sur la manière dont le schéma du datagraphe résulte de la requête, voir la rubrique Schéma de datagraphe.


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=cejb_ejbmed
Nom du fichier : cejb_ejbmed.html