Discussion :

[Nicolas Dansel]

Bonsoir

Q1/ Pouvez-vous m'expliquer pourquoi la plupart des projets Java professionnels s'appuient sur la norme J2EE (choix de Java/Web) plutôt que sur les clients lourds qu'on peut développer en Swing ou en SWT ?

Q2/ Est-ce que la tendance du marché à préférer J2EE à SWT/Swing se renforce au fil du temps ?

Merci
Nico

[Antoine_935]

Salut

Je ne travaille pas encore dans le monde pro, mais voila ce qui ressort des discussions que j'ai pu avoir:

1. Un site web est largement plus facile à déployer en entreprise. Rien à installer sur les machines client, hormis un lien si les utilisateur ne connaissant pas la notion d'url.
On pourrait penser au java web start, mais bcp d'entreprises ont encore une vieille version de java sur leurs pc.

2. Aucune idée, mais à mon avis le mouvement n'est pas près de s'inverser.


En plus de ça, l'avantage de J2EE est de pouvoir centraliser les informations (un seul serveur). Si tu veux faire ça en swing, tu devras soit

• implémenter ta couche réseau: perte de temps énorme, sans compter les bugs
• te servir d'une technologie existante, style rmi, qui n'est pas prévue du tout pour ce genre d'usage. Il est par exemple impossible d'annuler une action en cours avec le rmi.

[fr1man]

Bon déjà tu peux très bien réaliser une application J2EE avec Swing/SWT.
Swing/SWT ne représente que la couche présentation.
Comme l'a dit Antoine_935, on préfère une couche de présentation web, en partie à cause du déploiement client (inexistant dans ce cas, contrairement aux clients lourds).
Après, ça dépend un peu de ce que tu veux faire, du parc de machines de tes utilisateurs et si tu as la main dessus.
Java Web Start fonctionne à partir de Java 1.4 il me semble, donc ça laisse pas mal de possibilités.

En plus de ça, l'avantage de J2EE est de pouvoir centraliser les informations (un seul serveur). Si tu veux faire ça en swing, tu devras soit
implémenter ta couche réseau: perte de temps énorme, sans compter les bugs
te servir d'une technologie existante, style rmi, qui n'est pas prévue du tout pour ce genre d'usage. Il est par exemple impossible d'annuler une action en cours avec le rmi.

Pas du tout.
Tu peux avoir le coeur de ton application déployée sur un serveur d'application et accessible par ton application Swing via des EJBS par exemple ou des WebServices.
Encore une fois, ce n'est qu'un choix au niveau de la présentation.

[Antoine_935]

Tu peux avoir le coeur de ton application déployée sur un serveur d'application et accessible par ton application Swing via des EJBS par exemple ou des WebServices.

Ah ce serait donc pour ça ces façades remote ? J'ai encore bcp à apprendre, je crois

[Nicolas Dansel]

Tout d'abord, je vous remercie pour vos réponses.

Q1/ Quand on dit qu'on peut faire un projet J2EE en utilisant Swing/SWT pour la couche de présentation, qu'apporte J2EE dans ce cas ?
Je fais sûrement une confusion quelque part mais j'associe spontanément J2EE à des applis Java/web (sous Struts par exemple).

Q3/ Tomcat est-il un serveur J2EE ? Pourquoi ou pourquoi pas ?

[fr1man]

J2EE est un ensemble d'API.
Tu n'es pas obligé de toutes les utiliser pour prétendre avoir une application J2EE.
Tu peux utiliser l'API de persistance, des EJBs, JMS, etc, et avoir une couche présentation SWING/SWT ou JSP/JSF...
La couche présentation n'est qu'un "détail".

[OButterlin]

Pour continuer sur ce que disais fr1man, tu peux voir JEE comme un ensemble de boites à outils.
Les plus communes sont :

JPA pour l'aspect persistance
JTA pour l'aspect transaction
JMS pour l'échange de messages
JDBC pour l'accès aux bases de données
JNDI pour le service de nommage
Servlet
JSP
JSF
etc...
EJB est un peu à part dans la mesure où il traite de la persistance et des fonctions remote et des transaction...

Struts est un framework MVC2, il ne fait pas partie de JEE (même s'il s'appuie sur lui)

Tomcat est un serveur d'application "light" (avec un conteneur de servlet surtout), il n'est (à ma connaissance) pas certifié JEE.

Pour ta Q1, JEE sera certainement utilisé pour l'accès aux bases de données au travers de JDBC, à moins que ce ne soit par l'intermédiaire d'un ORM (Hibernate par exemple).
L'application pourrait également faire appel à un serveur central pour l'exécution de fonctions "métier" via EJB ou RMI...
Bref, tout dépend de l'application. L'IHM n'est qu'une partie (visible) et SWING est une réponse possible à cette partie.

A+

[Nicolas Dansel]

Merci pour cette longue réponse.

Je commence a y voir plus clair avec les APIs listées.

Par contre, je vais peut-être abuser mais peut-on faire du J2EE sans utiliser de serveur d'application (ex : JBoss) ?

Rem : je ne sais pas pourquoi mais j'associe automatiquement J2EE à "serveur d'application + web" ...

[OButterlin]

Merci pour cette longue réponse.

Je commence a y voir plus clair avec les APIs listées.

Par contre, je vais peut-être abuser mais peut-on faire du J2EE sans utiliser de serveur d'application (ex : JBoss) ?

Rem : je ne sais pas pourquoi mais j'associe automatiquement J2EE à "serveur d'application + web" ...

Oui, bien sûr, dès lors que tu utilises une API de JEE.
JDBC est l'exemple le plus commun.

Ceci dit, dans ce contexte, ça n'a pas vraiment de sens de dire "je fais une application JEE". Il est vrai qu'on associe ça plutôt à une application liée à un serveur central JEE... mais bon, il y a bien d'autres termes qui sont détournés