Ce produit prend en charge la spécification Enterprise JavaBeans (EJB) 3.1.
Avant de commencer
Il n'existe aucun problème de migration inhérent à l'utilisation
de beans EJB 3.x. L'exécution des applications actuelles se poursuit
et la compilation s'effectue sans erreur.
Remarque : Les spécifications EJB 3.0 et EJB 3.1
rendent obsolète l'utilisation de beans d'entité du style EJB 1.1 Même si l'utilisation des modules EJB 2.x et de modules antérieurs dans le produit n'a pas encore
été déconseillée, il est fortement conseillé de lancer la migration vers l'API JPA (Java™ Persistence
API) ou JDBC.
Pourquoi et quand exécuter cette tâche
Suivez la
procédure correspondant à votre déploiement d'application.
Procédure
- Modifiez le code des beans enterprise en fonction des
modifications apportées à la spécification.
Vous devez faire migrer vos beans version 1.1 vers la version 2.x
et les redéployer sur le produit. Pour plus d'informations, voir Migration du code des beans enterprise de la version 1.1 à la version 2.1.
Remarque : Selon la spécification EJB version 2.0, avant que le
conteneur EJB exécute une
requête findByXXX, l'état de tous les
beans enterprise enrôlés dans la transaction courante doit être synchronisé avec le
système de stockage persistant. Cette synchronisation est effectuée ainsi afin que la requête
soit exécutée sur les données actuelles. Lorsque les beans de la version 1.1 sont à nouveau assemblés dans
un module compatible avec EJB 2.x, le conteneur EJB synchronise l'état des beans de la
version 1.1 et celui des beans de la version 2.x. Le comportement des applications peut donc être modifié, même si le code
d'application des beans de la version 1.1 n'a pas été modifié.
Vérifiez la compatibilité de WebSphere Application
Server avec la version 64 bits. Cela ne pose pas de problème pour une application pure Java.
Toutefois, si votre code d'application utilise le code JNI (Java Native Interface), prenez en compte les remarques suivantes : l'interface JNI permet au code Java s'exécutant dans une machine virtuelle d'interagir avec des applications et des bibliothèques écrites dans d'autres langages, tels
C, C++ et l'assembleur. Il est possible que les appels JNI soit différent après la compilation, du fait que les spécifications JNI peuvent changer d'une version à une autre version.
- Réassemblez et redéployez
tous les modules afin d'intégrer le code migré.