IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Java EE Discussion :

Migration Java SE vers Java EE


Sujet :

Java EE

  1. #1
    Membre à l'essai
    Profil pro
    Conseil - Consultant en systèmes d'information
    Inscrit en
    Mai 2006
    Messages
    15
    Détails du profil
    Informations personnelles :
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Conseil - Consultant en systèmes d'information

    Informations forums :
    Inscription : Mai 2006
    Messages : 15
    Points : 19
    Points
    19
    Par défaut Migration Java SE vers Java EE
    Bonjour, je me demande si quelqu'un a deja fait l'experience ou a des informations sur l'idee (saugrenue) de migrer une application Java SE vers Java EE. Grossierement, le project consiste a mutualiser un code existant (plusieurs centaines de milliers de lignes) pour reutiliser les ojects de gestion. Bien entendu, le code doit rester compatible avec la version Java SE. Ce sont des entites contenant la logique de persistance relativement facile a migrer vers une solution de type JPA.
    Par contre, je bloque sur toutes les methodes statiques du genre "public static InventoryProfile findProfile(String name)" pour passer au modele EJB. Revoir la totalite du code existant n'est pas possible (delai environ 1 mois) et utiliser autre chose n'est pas permis, le chef a deja achete le bouquin Java EE 6 et a decide que ce serait la solution

  2. #2
    Expert éminent sénior
    Avatar de sinok
    Profil pro
    Inscrit en
    Août 2004
    Messages
    8 765
    Détails du profil
    Informations personnelles :
    Âge : 43
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Août 2004
    Messages : 8 765
    Points : 12 977
    Points
    12 977
    Par défaut
    Bah procéder par délégation, extraire le code de la méthode statique, le transformer de façon à ce que ça colle avec les notions EJB, puis dans la méthode statique faire appel à l'EJB. La logique doit se trouver au niveau de l'EJB, la méthode statique doit rester dans la partie JavaSE.
    Hey, this is mine. That's mine. All this is mine. I'm claiming all this as mine. Except that bit. I don't want that bit. But all the rest of this is mine. Hey, this has been a really good day. I've eaten five times, I've slept six times, and I've made a lot of things mine. Tomorrow, I'm gonna see if I can't have sex with something.

  3. #3
    Membre à l'essai
    Profil pro
    Conseil - Consultant en systèmes d'information
    Inscrit en
    Mai 2006
    Messages
    15
    Détails du profil
    Informations personnelles :
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Conseil - Consultant en systèmes d'information

    Informations forums :
    Inscription : Mai 2006
    Messages : 15
    Points : 19
    Points
    19
    Par défaut
    Citation Envoyé par sinok Voir le message
    Bah procéder par délégation, extraire le code de la méthode statique, le transformer de façon à ce que ça colle avec les notions EJB, puis dans la méthode statique faire appel à l'EJB. La logique doit se trouver au niveau de l'EJB, la méthode statique doit rester dans la partie JavaSE.
    Je suis bien d'accord, mixer le controleur, la logique et l'entite en une seule classe, c'est pas beau! Il faut extraire et transformer. Cependant c'est facile a dire, facile a faire quand c'est les autres qui se tape le boulot mais ce coup ci je ne suis plus le chef de projet, je suis le programmeur... N'arrivant pas a exprimer mon desarroi devant ce type de probleme, j'ai mis le clavier en face de mon collegue. Je me suis marre quand il est reste pendant une minute sans bouger, les mains au dessus du clavier, ne sachant plus comment faire.
    Sachant que cela represente un code de plus de 300000 lignes, je tourne ma question differemment: ai je un autre choix que de creer un outil de refactoring qui va analyser le code, extraire le code de la méthode statique, le transformer de façon à ce que ça colle avec les notions EJB, etc... ou alors dois-je passer mes jours et mes nuits pour faire cela a la main avec toutes les risques d'erreurs que cela implique?
    Ce que je recherche, c'est un retour d'experience et/ou de la documentation, des outils, etc..

  4. #4
    Membre à l'essai
    Profil pro
    Inscrit en
    Juillet 2009
    Messages
    9
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juillet 2009
    Messages : 9
    Points : 15
    Points
    15
    Par défaut
    Et est-ce que refactorer le code pour passer tes services statiques métier à Spring (qui se reposerait sur Java EE/JPA) plutôt qu'aux EJB est une solution envisageable ?

    Je pense que le coût de refactoring serait bien moins élevé.

  5. #5
    En attente de confirmation mail

    Homme Profil pro
    Inscrit en
    Juillet 2006
    Messages
    766
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : Juillet 2006
    Messages : 766
    Points : 1 267
    Points
    1 267
    Par défaut
    J'avais une application Swing+JDBC que j'ai tranformée en Applet Swing + jdbc via internet. Puis en ce moment, je travaille sur un client GWT qui fait des appels REST vers le serveur.

    Mes objets métiers sont les mêmes côté client et serveur, cependant à travers le réseau, ils sont sérialisés/désérialisés à ma façon, à l'aide de xml customisé.

    Par contre mes objets métiers ne sont pas des Entities. J'utilise des classes de types CRUD pour mapper mes objets métiers avec mes entities. C'est long , mais facile à tester avec Junit, et donc à refactoriser/augmenter petit à petit.

  6. #6
    Membre averti
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Février 2005
    Messages
    241
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Février 2005
    Messages : 241
    Points : 399
    Points
    399
    Par défaut
    Bonjour,

    le choix technique étant fait, peut-être pourriez-vous nous clarifier quelques éléments:

    - qu'entendez-vous par compatibilité EE/SE ? la même base de code doit être utilisée pour les deux?
    Le passage en modèle EJB va être très impactant car la façon de travailler entre ces beans est assez différente. ( lookup JNDI par exemple )
    - Est-ce que les deux types de clients vont travailler en même temps ( client web, client swing par exemple ) ? qu'est-ce qui sera commun aux deux, le cas échéant?
    - Concernant les méthodes statiques, pourquoi ne pas simplement faire déléguer la méthode de traitement EJB à celle-ci ?

    Séb

  7. #7
    Rédacteur
    Avatar de eclesia
    Profil pro
    Inscrit en
    Décembre 2006
    Messages
    2 108
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2006
    Messages : 2 108
    Points : 3 203
    Points
    3 203
    Par défaut
    Nous avons eu a porter (ou plus exactement reecrire vu tout ce qui a changé) une application swing vers JSF.

    se serait a refaire, je dirais tout de suite non. une aplication web ne vaut et ne vaudra jamais la qualité d'une application desktop et ca sur de nombre point : temps de developpement, rapidité, debuggage, taille, ergonomie...

    Personnellement je conseil d'explorer la voie Java Web Start.
    Systèmes d'Informations Géographiques
    - Projets : Unlicense.science - Apache.SIS

    Pour un monde sans BigBrother IxQuick ni censure RSF et Les moutons

  8. #8
    Membre à l'essai
    Profil pro
    Conseil - Consultant en systèmes d'information
    Inscrit en
    Mai 2006
    Messages
    15
    Détails du profil
    Informations personnelles :
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Conseil - Consultant en systèmes d'information

    Informations forums :
    Inscription : Mai 2006
    Messages : 15
    Points : 19
    Points
    19
    Par défaut
    @fbaligand
    Utiliser Spring aurait certainement ete une solution plus judicieuse mais le style ici est plutot "on code d'abord et on verra apres". Apres le cowboy coding, le cowboy designing . Je suis assez pessimiste sur l'issue de ce projet mais je sens que l'experience va etre assez interessante.
    @Desboys
    Pour l'instant, c'est un portage exacte du code de l'application Java SE vers Java EE, le resultat final etant un tronc commun ayant le meme source et les partie communication (RMI/Remote EJB) et Persistence(ORM maison/Entite EJB) separees par quelques interfaces judicieusement placees entre chaque couches.
    L'utilisation des annotations permet d'avoir le meme code sans difficulte majeure. L'idee n'est pas suffisament louffoque pour que je puisse mettre mon veto. Cependant, sachant qu'il y a des appels a des composant Swing tel que JDialog dans le source des objets metiers, je sens que cela va etre tres chaud.

    Le projet reste avec une application Swing cote client mais il n'est pas prevu de reutiliser le code client a l'identique.

Discussions similaires

  1. Problème en java (algorithme vers java)
    Par almofa237 dans le forum Langage
    Réponses: 2
    Dernier message: 10/05/2010, 16h48
  2. Quelles sont les migrations d'aujourd'hui ? Java vers C# ou C# vers Java ?
    Par grunt2000 dans le forum Langages de programmation
    Réponses: 5
    Dernier message: 19/05/2009, 15h32
  3. [OC4J] Migration d'une application Java web de Tomcat vers OC4J
    Par Alpha2008 dans le forum Tomcat et TomEE
    Réponses: 1
    Dernier message: 23/03/2008, 15h40
  4. Documentation relative à une migration vers Java
    Par GammaOH dans le forum Smalltalk
    Réponses: 5
    Dernier message: 26/04/2006, 16h29

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo