Discussion :

[kelkan]

Bonjour,
Dans l’objectif de migrer deux espaces (Clients et Conseillers) depuis un environnement Domino vers un environnement JEE, ns avons développé des web services basés sur jersey+Spring et Hibernate pr la persistance et déployés au sein d'une application web sur un Tomcat 6 existant. Ces WS remplaceraient des fonctionnalités gérées auparavant par les applications Domino. En même temps l'équipe Domino a migré une de deux interfaces vers Angular JS qui fait appel aux WS.
La base de donnés (MS Sql Server 2008) est très mal foutue, et elle est alimentée via des fichiers AS400, les donnés sont redondantes partout. J'ai dû utiliser des vues pour traiter avec cette BDD.
Les deux espaces permettent à l’utilisateur de visualiser ses contrats, et ses donnés personnelles, les modifier et réaliser des opérations (transactions finacières).
Avant les développements des ws, j'avais proposé une solution full JEE (JSF+ PrimeFaces, EJB, JPA, le tout déployé sur un serveur Web Sphere).
Aujourd'hui, on me demande de proposer une solution globale ergonomique et compatible mobile pour migrer les deux espaces. J'hésite entre deux choix,
- maintenir la solution full JEE que j'avais proposé avant de commencer les dévs des ws, ce qui implique la reprise de tout ce que nous avions fait avec Spring, et tout ce que l'équipe Domino avait fait avec Angular JS.
- proposer une nouvelle solution qui reprend l'existant -ç-à-d, les WS(Spring+Jersey) et les interfaces d'Angular JS- ce qui me parait plus judicieux, mais quelle configuration doit on mettre en place pour préserver cet existant ?
* Quel serveurs d’applications ( WildFly ou Web Sphere ) utilisé?
Pourriez-vous m’éclairer svp.
Cordialement

[fr1man]

Ca va dépendre de ton besoin de support ou non et donc aussi de ton budget.
Tu peux partir sur des solutions comme WildFly ou TomEE et garder ton existant ça semble être nettement plus simple.
Si tu veux la version commerciale, tu peux partir sur JBoss EAP basé lui même sur Wildfly.
De mon point de vue, je ne partirais pas sur Websphere ou Weblogic à moins d'une bonne raison.

[kelkan]

Bonjour,
D'abord je te remercie pour ta réponse.
Comment pourrai-je déterminer le fait que je vais avoir besoin d'un support ou pas ? et à quel moment par exemple mon besoin du support nécessiterait de payer une licence ?
Je pense que mon client se pencherait plutôt vers une solution entreprise pour bénéficier du support continue même s'il n'en a pas réellement besoin, ça serait plutôt par souci de maintenir ses services.
Quels arguments pourrait on avancer pour défendre l'idée que ns n'aurions pas besoin de payer un support ? ou penses tu que ça serait mieux d'en payer un ?

Je pensais que wildFly était plus aboutit que TomEE ?
Migrer les web services dont je dispose aujourd'hui en une solution basée sur EJB et JPA, ne nécessitent pas énormément de travail. Alors dans ce cas laquelle de deux solutions est plus efficace et pérenne à ton avis ? conserver l'existant, ou opter pour la solution full JEE ?

Les deux espaces clients, et conseillers étaient gérés auparavant par deux application distincts, je compte les gérer via une seule et même application, penses tu que cette solution est contestable ?

En te remerciant d'avance.

[fr1man]

J'ai bossé sur des projets avec des serveurs commerciaux (Websphere, Weblogic) et d'autres open sources sans support (JBoss, Glassfish).
Souvent le client est rassuré de payer pour du support.
Je n'ai jamais été confronté à un bug bloquant nécessitant un correctif. Donc le support ne m'a jamais servi à rien mais ce n'est que mon expérience.

Oui WildFly à l'air d'être plus évolué que TomEE, mais TomEE peut-être suffisant.
WildFly possède une belle console d'administration: est-ce par exemple un atout pour toi ?
Après niveaux composants, à voir ce dont tu as besoin et ce que les deux proposent.
Voir également la version de Java EE supportée.

J'aurais tendance à rester sur la norme Java EE, mais Spring / Jersey étant très proche, est-ce que ça vaut le coup de tout réécrire ?
Spring a fait ses preuves et est en constante évolution. Tu peux peut-être le proposer dans un second temps.
J'aurais gardé deux applications distinctes si possible, pour faciliter les mises à niveau indépendantes, s'il y a lieu.

[Logan Mauzaize]

Si c'est pour héberger du WS (SOAP ou REST) autant rester sur du Tomcat, ca suffit amplement. Si tout est bien codé en stateless, ajouter des noeuds sur un Apache / Nginx ou sur un serveur J2EE devrait pas posé plus de problèmes.

Vois du côté de la section sysadmin.


Pour la partie mobile, il faut savoir si c'est du full Web, de l'hybride ou du natif. Et pour commencer se demander à quel point l'interface peut-être différente. Pour la partie "backend" si tu as des WS REST (JSON de préférence), ca ne devrait pas poser de problèmes pour les ré-utiliser.

Si tu fais une interface en Angular, je te conseille de dissocier (gestion de configuration : source, packaging, déploiement, etc.) le "backend" et le "frontend". Tu pourras les faire évoluer indépendamment.

[kelkan]

Bonjour Logan Mauzaize,
mes réponses en bleue.
Si c'est pour héberger du WS (SOAP ou REST) autant rester sur du Tomcat, ca suffit amplement. Si tout est bien codé en stateless, ajouter des noeuds sur un Apache / Nginx ou sur un serveur J2EE devrait pas posé plus de problèmes.

Vois du côté de la section sysadmin.

Oui, mais un WildFly, serait qd même mieux qu'en Tomcat, en terme de gestion de pool de connexions, datasource, etc.. et même l'ajout des noeuds pour clusteriser.


Pour la partie mobile, il faut savoir si c'est du full Web, de l'hybride ou du natif. Et pour commencer se demander à quel point l'interface peut-être différente. Je ne sais pas si j'ai bien compris, mais aujourd'hui angularjs permet de rendre une application web compatible mobile sans avoir besoin à développer une partie mobile de cette application. et c'est ce que je veux, l'application serait une application web qui pourrait se transformer en application mobile selon le terminal qui la consulte, c'est ce qu'on appelle du "responsive web design", je pense.


Si tu fais une interface en Angular, je te conseille de dissocier (gestion de configuration : source, packaging, déploiement, etc.) le "backend" et le "frontend". Tu pourras les faire évoluer indépendamment.

Merci pour le conseil

[Logan Mauzaize]

Oui, mais un WildFly, serait qd même mieux qu'en Tomcat, en terme de gestion de pool de connexions, datasource, etc.. et même l'ajout des noeuds pour clusteriser.

Concernant la gestion des ressources :

• Si elles sont gérées correctement, cela ne fera aucune différence. WildFly (et autres serveurs J2EE) utilisent les mêmes composants que tu peux déployer sur un simple Tomcat. La seule différence c'est le CMT (et autres fonctionnalités similaires) qui bindent l'allocation des ressources à la requête et font le ménage. Tu peux très bien faire la même chose avec une Servlet Filter ou un Listener. Par ailleurs Spring Framework propose des solutions pour le gérer.
• Si tu codes correctement avec Spring (@Service, @Transactional, etc.) tes ressources seront gérées comme avec un CMT.

Je ne sais pas si j'ai bien compris, mais aujourd'hui angularjs permet de rendre une application web compatible mobile sans avoir besoin à développer une partie mobile de cette application. et c'est ce que je veux, l'application serait une application web qui pourrait se transformer en application mobile selon le terminal qui la consulte, c'est ce qu'on appelle du "responsive web design"

"Responsive Design" c'est l'idée d'adapter un produit par rapport au support sur lequel il est consommé. Il existe plusieurs techniques dont les MediaQuery de CSS. Mais quoiqu'il en soit cela n'a rien de magique.

AngularJS ne fournit rien de ce point de vue. Mais Twitter Boostrap, oui. Néanmoins, une vraie interface responsive en CSS nécessite tout de même de coder certains éléments d'IHM avec différents rendu selon le support. Le principe de base de Twitter c'est de fournir des tailles de police, de grilles, etc. adpatés en fonction des tailles d'écrans. Mais cela ne permet par exemple pas de transformer un menu "inline" (ex : "item1 | item2 | item3") à un menu masqué qui s'affiche avec un bouton ou un menu réduit avec les options les plus intéressantes.

C'est justement sur la transformation que tu veux apporter à ton interface en mode mobile ou autres qui définira ta solution technique pour fournir la solution adaptée à chaque support.

Quoiqu'il en soit si tu déploies un site Web alors les utilisateurs devront passer par leur navigateur mobile pour accéder à l'application et ne pourront pas la télécharger depuis le store ou avoir un icône pour lancer l'application (quoiqu'il existe des projets pour cela).
En revanche avec des produits comme Ionic Framework, tu peux développer une "vraie" application basée sur un navigateur Web (et donc avec Angular JS mais d'autres aussi). Cette application pourra alors être déployée sur les principaux types de terminaux (iPhone, Android, etc.)