Lorsqu'un projet cible Java 2 Platform, Enterprise Edition (J2EE) comprend au moins un bean dont le nom et l'espace de nom sont identiques à une classe UML de la transformation, un scénario de réapplication peut intervenir. L'on parle de scénario de réapplication lorsque le type du bean enterprise existant correspond au type de celui qui doit être généré pour la classe correspondante dans le modèle UML.
En revanche, lorsque le type du bean enterprise à générer est incompatible avec celui du bean existant, c'est un scénario de collision qui se produit. Dans un tel scénario, la transformation d'UML en EJB n'actualise pas le bean existant et ne génère pas de nouveau bean.
Le tableau suivant énumère les manières dont la transformation doit normalement réagir aux éventuels scénarios de réapplication pour les beans entity CMP 2.x :
Bean enterprise à générer |
Bean enterprise existant |
Scénario prévu |
Réaction de la transformation |
CMP 2.x |
CMP 2.x |
Réapplication |
Mise à jour des champs et des méthodes CMP |
CMP 2.x |
CMP 1.1 |
Réapplication |
Mise à jour des champs et des méthodes CMP comme s'il s'agissait d'un scénario de réapplication CMP 1.1/CMP 1.1 classique |
CMP 2.x |
BMP |
Réapplication |
Mise à jour des champs et des méthodes BMP comme s'il s'agissait d'un scénario de réapplication BMP/BMP classique |
CMP 2.x |
Session (avec état ou sans état) |
Collision |
Le bean session demeure intact |
CMP 2.x |
Piloté par message |
Collision |
Le bean piloté par message demeure intact |
Le tableau suivant énumère les manières dont la transformation doit normalement réagir aux éventuels scénarios de réapplication pour les beans entity CMP 1.1 :
Bean enterprise à générer |
Bean enterprise existant |
Scénario prévu |
Réaction de la transformation |
CMP 1.1 |
CMP 2.x |
Réapplication |
Mise à jour des champs et des méthodes CMP comme s'il s'agissait d'un scénario de réapplication CMP 2.x/CMP 2.x classique |
CMP 1.1 |
CMP 1.1 |
Réapplication |
Mise à jour des champs et des méthodes CMP |
CMP 1.1 |
BMP |
Réapplication |
Mise à jour des champs, des méthodes et des associations BMP comme s'il s'agissait d'un scénario de réapplication BMP/BMP classique |
CMP 1.1 |
Session (avec état ou sans état) |
Collision |
Le bean session demeure intact |
CMP 1.1 |
Piloté par message |
Collision |
Le bean piloté par message demeure intact |
Le tableau suivant énumère les manières dont la transformation doit normalement réagir aux éventuels scénarios de réapplication pour les beans entity BMP :
Bean enterprise à générer |
Bean enterprise existant |
Scénario prévu |
Réaction de la transformation |
BMP |
CMP 2.x |
Réapplication |
Mise à jour des champs et des méthodes CMP comme s'il s'agissait d'un scénario de réapplication CMP 2.x/CMP 2.x classique |
BMP |
CMP 1.1 |
Réapplication |
Mise à jour des champs et des méthodes CMP comme s'il s'agissait d'un scénario de réapplication CMP 1.1/CMP 1.1 classique |
BMP |
BMP |
Réapplication |
Mise à jour des champs et des méthodes BMP |
BMP |
Session (avec état ou sans état) |
Collision |
Le bean session demeure intact |
BMP |
Piloté par message |
Collision |
Le bean piloté par message demeure intact |
Le tableau suivant énumère les manières dont la transformation doit normalement réagir aux éventuels scénarios de réapplication pour les beans session :
Bean enterprise à générer |
Bean enterprise existant |
Scénario prévu |
Réaction de la transformation |
Session (avec état ou sans état) |
CMP 2.x |
Collision |
Le bean CMP 2.x demeure intact |
Session (avec état ou sans état) |
CMP 1.1 |
Collision |
Le bean CMP 1.1 demeure intact |
Session (avec état ou sans état) |
BMP |
Collision |
Le bean BMP demeure intact |
Session (avec état) |
Session (avec état uniquement) |
Réapplication |
Mise à jour des champs et des méthodes du bean session |
Session (avec état) |
Session (sans état uniquement) |
Collision |
Le bean session sans état demeure intact |
Session (sans état) |
Session (avec état uniquement) |
Collision |
Le bean session avec état demeure intact |
Session (sans état) |
Session (sans état uniquement) |
Réapplication |
Mise à jour des champs et des méthodes du bean session |
Session (avec état ou sans état) |
Piloté par message |
Collision |
Le bean piloté par message demeure intact |
Le tableau suivant énumère les manières dont la transformation doit normalement réagir aux éventuels scénarios de réapplication pour les beans pilotés par message :
Bean enterprise à générer |
Bean enterprise existant |
Scénario prévu |
Réaction de la transformation |
Piloté par message |
CMP 2.x |
Collision |
Le bean piloté par message demeure intact |
Piloté par message |
CMP 1.1 |
Collision |
Le bean piloté par message demeure intact |
Piloté par message |
BMP |
Collision |
Le bean piloté par message demeure intact |
Piloté par message |
Session (avec état ou sans état) |
Collision |
Le bean piloté par message demeure intact |
Piloté par message |
Piloté par message |
Réapplication |
Mise à jour des champs et des méthodes du bean piloté par message |
Le tableau suivant énumère les manières dont la transformation doit normalement réagir aux éventuels scénarios de réapplication pour les classes UML non marquées :
Stéréotype sur classe UML |
Bean enterprise existant |
Scénario prévu |
Réaction de la transformation |
Non marquée |
CMP 2.x |
Réapplication |
Mise à jour des champs et des méthodes du bean entité CMP 2.x dans son interface distante existante |
Non marquée |
CMP 1.1 |
Réapplication |
Mise à jour des champs et des méthodes du bean entité CMP 1.1 dans son interface distante existante |
Non marquée |
BMP |
Réapplication |
Mise à jour des champs et des méthodes du bean entité BMP dans son interface distante existante |
Non marquée |
Session (avec état ou sans état) |
Réapplication |
Mise à jour des champs et des méthodes de la session dans son interface distante existante |
Non marquée |
Piloté par message |
Réapplication |
Génération d'une classe Java normale |
Dans les scénarios de réapplication pour les classes UML non marquées, les modifications de code apportées à l'interface distante du bean enterprise peuvent provoquer des erreurs de construction dans le projet EJB. Ces erreurs de construction se produisent parce que le code modifié de l'interface distant n'est pas conforme aux spécifications EJB pour les interfaces distantes. Si vous prévoyez de remplacer la totalité du bean enterprise, vous devrez le supprimer avant d'exécuter la transformation EJB.
La présente section examine plus en détail la réaction de la transformation à un scénario de réapplication en indiquant ce qu'il convient d'attendre de la transformation après une réapplication.
En cas de scénario de réapplication pour un bean entity CMP 2.x, les modifications suivantes peuvent se produire :
Les modifications suivantes ne doivent pas se produire :
En cas de scénario de réapplication pour un bean entity CMP 1.1, les modifications suivantes peuvent se produire :
Les modifications suivantes ne doivent pas se produire :
En cas de scénario de réapplication pour un bean entity BMP, les modifications suivantes peuvent se produire :
Les modifications suivantes ne doivent pas se produire :
En cas de scénario de réapplication pour un bean session, les modifications suivantes peuvent se produire :
Les modifications suivantes ne doivent pas se produire :
En cas de scénario de réapplication pour un bean piloté par message, les modifications suivantes peuvent se produire :
Les modifications suivantes ne doivent pas se produire :
Conditions d'utilisation | Retours d'informations
(C) Copyright IBM Corporation 2004. All Rights Reserved.