Préambule
Résumé pour décideurs
Introduction.
1.  Les modèles relationnel et objet.
1.1  PRESENTATION DUMODELE RELATIONNEL.
1.2  PRESENTATION DU MODELE OBJET
1.3  DIFFERENCES ENTRE LES MODELES OBJET ET RELATIONNEL
1.4  INTEGRATIONDES MODELESOBJET ETRELATIONNEL
1.5  CARACTERISTIQUES D’UN MECANISME DE PERSISTANCE OBJET-RELATIONNEL TRANSPARENT
1.6  ROLE ET OBLIGATIONS DE LA COUCHE DE PERSISTANCE
2.  J2EE et lesarchitectures multi-tiers
2.1  TYPOLOGIE DES ARCHITECTURES MULTI-TIERS
2.2  RAPPELS SUR LE STANDARD J2EE
2.3  J2EE ET LES ARCHITECTURES MULTI-TIERS.
3.  Les solutions de persistance objet en architecture J2EE
3.1  ALTERNATIVES DE PERSISTANCE D’OBJETSMETIER DANS UNE ARCHITECTURE J2EE
3.2  COUVERTURE FONCTIONNELLE DUSTANDARD EJB EN MATIERE DE PERSISTANCE
3.3  COUVERTURE FONCTIONNELLE DE JDO EN MATIERE DE PERSISTANCE
3.4  COUVERTURE FONCTIONNELLE D’ ORACLE9IAS TOPLINK EN MATIERE DE PERSISTANCE.
3.5  PERSPECTIVES DE NORMALISATION ENMATIERE DE PERSISTANCE OBJET
4.  Les atouts d’ Oracle9iAS TopLink pour une architecture J2EE
5.  Annexes
5.1  GRILLE DE CRITERES POUR L’EVALUATION DETAILLEE DES SOLUTIONS DE PERSISTANCE OBJET
5.2  RESULTATS DE L’EVALUATIONDETAILLEE POUR LEMODELE EJB
5.3  RESULTATS DE L’EVALUATIONDETAILLEE POUR LEMODELE JDO.
5.4  RESULTATS DE L’EVALUATIONDETAILLEE POUR ORACLE9IAS TOPLINK

Extrait du cours maîtriser la persistance objet métier au sein d’une architecture J2EE

Préambule
Il y a tout juste un an, SQLI publiait une étude intitulée « Stratégies de persistance d’objets  métiers en architecture J2EE ».
Un mois plus tard, un magazine de référence reprenait l’étude ettitrait « J2EE faitvaciller  l’édifice e-business ».Il s’avère que nous avions simplement pris nos responsabilités et  alerté nos clients sur le manque de maturité d’un pan important de la technologie EJB 2 .0 à  savoir les Entity Beans CMP. Nous avons passé beaucoup de temps en conférences et  séminaires pour expliquer le contenu précis et les résultats des tests rigoureux menés par  nos équipes de R&D.
Nous avons dû aussi rappeler très souvent que malgré les résultats de notre étude, le  Groupe SQLI considère que Java en tant que langage et J2EE en tant qu’architecture  technique sont parfaitement viables pour sous-tendre des applications transactionnelles  lourdes et critiques dans le cadre de projets stratégiques au sein de grandes entreprises.
Nous allons continuer dans cette voie et agir en vue d’assumer pleinement notre rôle de  réducteur de risques techniques dans l’adoption des nouvelles technologies au service de  nos clients et de la communauté.
Résumé pour décideurs
Les systèmes de gestion de bases de données relationnels (SGBDR) sont devenus un pilier incontournable dans le développement d’applications de gestion, et seront présents pour longtemps dans les systèmes d’information : le modèle relationnel, simple et puissant est rapidement assimilé par les concepteurs d’applications ; le niveau de fiabilité et de performances des SGBDR ont conquis les responsables d’exploitation et la pérennité des
éditeurs rassure les directions informatiques.
Un SGBDR doit cependant être utilisé avec un serveur d’application, afin de satisfaire les contraintes de sécurité, de modularité, de performances et de diffusion multi-canal qui sont imposées aux applications d’aujourd’hui. On dit alors que ces applications sont basées sur des architectures multi-tiers.
Introduction
A travers cette étude, nous nous proposons d’étudier la problématique de la persistance objet, et d’évaluer les solutions existantes pour le développement d’applications au sein d’architectures multi-tiers en environnement J2EE.
Les différentes alternatives que nous avons identifiées pour la persistance objet sont :
– le modèle de composants métier persistants EJB Entité de la spécification J2EE
– un nouveau standard de persistance émergent représenté par la norme JDO, apparu  fin 1999, et dont la première version a été finalisée au milieu de l’année 2002.
– les frameworks de mapping objet-relationnel, représentés par l’une des principales  offres en ce domaine : le produit Oracle9iAS TopLink.
En parallèle à l’évaluation fonctionnelle que nous mènerons sur ces différentes solutions, nous nous attacherons également à expliquer comment tirer parti de la complémentarité de ces technologies pour la mise en œuvre de la persistance objet.
La première partie de cette étude sera consacrée à l’explication de la problématique de la persistance objet, de l’intégration des modèles objet et relationnel, et des différents mécanismes mis en œuvre au sein d’un moteur de persistance objet.
Dans la deuxième partie, nous évoquerons les différents modèles d’architectures multitiers, les services de haut-niveau apportés par les plates-formes J2EE, et l’intégration de  l’infrastructure de persistance au sein de ces architectures.
1. Les modèles relationnel et objet
Le modèle relationnel, mis au point dans les années 1970 à la suite notamment des travaux théoriques d’ Edward F. Codd , a constitué une véritable révolution pour la conception des systèmes d’information. Durant les 30 dernières années, les bases de données relationnelles se sont largement répandues et imposées au sein des organisations et entreprises de toutes tailles. La simplicité et la puissance intrinsèques au modèle relationnel, et le support massif des géants du logiciel comme Oracle, IBM ou Microsoft ont contribué à ce mouvement. En gérant avec succès de nombreuses applications critiques, les systèmes de gestion de bases de données relationnelles ont prouvé leur fiabilité et gagné la confiance des directions informatiques.
1.1 Présentation du modèle relationnel
1.1.1 Caractéristiques principales
Le modèle relationnel se distingue par ses capacités élaborées de gestion des données, parmi lesquelles les plus remarquables sont :
– sa capacité à stocker de manière durable et fiable de très gros volumes de données
– la possibilité d’organiser les données de façon structurée et de définir des relations  simples entre ces données
– la gestion de l’intégrité des données et des accès et mises à jour concurrentes
– la possibilité de manipuler les données de façon très rapide et sélective, à travers des  requêtes exprimées à l’aide d’un langage spécifique (DML – Data Manipulation Language)
1.1.2 La gestion transactionnelle
Généralités sur les transactions
Dans un système de base de données, une transaction est une séquence d’opérations élémentaires (lecture ou mise à jour de données sur une ou plusieurs tables) exécutée comme une seule opération indivisible :
– si l’ensemble des opérations est mené à terme avec succès, les modifications effectuées deviennent permanentes — la transaction est validée.
– si l’une des opérations échoue, les modifications partielles déjà effectuées sont annulées et l’état initial de la base de données est restauré — la transaction est annulée.
Par exemple, dans une application bancaire, un virement de compte à compte peut être modélisé comme une transaction constituée de deux opérations complémentaires et indissociables:
– débit du compte source d’une somme X
– crédit du compte cible de la même somme X
Afin de maintenir l’intégrité des données bancaires, il est primordial de garantir que soit ces  deux opérations seront exécutées, soit qu’aucune ne le sera. En aucun cas ne doit exister de situation dans laquelle seule l’une des deux opérations est exécutée. On peut également enrichir cette transaction en y ajoutant une 3ème opération, préliminaire : la vérification de la disponibilité des fonds pour le virement sur le compte source. Si le solde du compte source est insuffisant pour permettre le virement, alors on doit forcer l’annulation de la transaction.

………
Si le lien ne fonctionne pas correctement, veuillez nous contacter (mentionner le lien dans votre message)
Maîtriser la persistance objet métier au sein d’une architecture J2EE (2369 KO)  (Cours PDF)