- une application qui soit accessible pour partie via web services et pour
partie via interface html
- des fonctionnalités qui s'appuient sur des transactions simultanées
[Chaque transaction = plusieurs transactions sérialisées ou parrallèles vers
des serveurs LDAP (au moins deux annuaires différents) et BDD (trois bases
différentes)]
- une qualité de service/uptime quasi 24/7/365
Alors vraiment des EJB ?? ou servlets/javabeans seront suffisants ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Nicolas Delsaux
Le 19.11 2003, latitude.world s'est levé et s'est dit : "tiens, si j'écrivais aux mecs de fr.comp.lang.java ?"
Bonjour,
Objectifs :
- une application qui soit accessible pour partie via web services et pour partie via interface html
C'est quasiment ce que dans le monde de l'application web on appelle une application web, en quelque sorte ... si je ne m'abuse ;-)
- des fonctionnalités qui s'appuient sur des transactions simultanées [Chaque transaction = plusieurs transactions sérialisées ou parrallèles vers des serveurs LDAP (au moins deux annuaires différents) et BDD (trois bases différentes)]
Rien de bien complexe, quoi.
- une qualité de service/uptime quasi 24/7/365
La QoS dépend de nombreux facteurs, qui sont pour autant matériels que logiciels. Avant même de se poser la question de la technologie à employer, la question du matériel se pose : garantit-il un uptime suffisant ? Et les différentes couches logicielles garantissent-elles, de même, cet uptime ?
Alors vraiment des EJB ?? ou servlets/javabeans seront suffisants ?
On peut déja faire pas mal de choses avec des servlets/javabeans. D'après ce que j'en comprend (en ne les ayant jamais pratiqué) les EJB vont apporter à ton application beaucoup de capacités d'intégration à ton réseau d'entreprise (MOM, management SNMP, persistance un peu facilitée, transactions nettement facilitées, je crois). Donc, plus que l'uptime, la question à tes poser est à mon avis celle des services. Desquels as-tu besoin parmi toute la gamme de ce que proposent les EJB ? Si ta réponse est aucun, alors tu n'as en fait pas besoin de cette lourdeur.
Merci pour vos conseils
-- Nicolas Delsaux "Celui qui est capable de marcher derrière une musique militaire n'a pas besoin de cerveau : une moelle épinière suffit." Albert Einstein
Le 19.11 2003, latitude.world s'est levé et s'est dit : "tiens, si
j'écrivais aux mecs de fr.comp.lang.java ?"
Bonjour,
Objectifs :
- une application qui soit accessible pour partie via web services et
pour
partie via interface html
C'est quasiment ce que dans le monde de l'application web on appelle une
application web, en quelque sorte ... si je ne m'abuse ;-)
- des fonctionnalités qui s'appuient sur des transactions simultanées
[Chaque transaction = plusieurs transactions sérialisées ou
parrallèles vers des serveurs LDAP (au moins deux annuaires
différents) et BDD (trois bases différentes)]
Rien de bien complexe, quoi.
- une qualité de service/uptime quasi 24/7/365
La QoS dépend de nombreux facteurs, qui sont pour autant matériels que
logiciels. Avant même de se poser la question de la technologie à
employer, la question du matériel se pose : garantit-il un uptime
suffisant ?
Et les différentes couches logicielles garantissent-elles, de même, cet
uptime ?
Alors vraiment des EJB ?? ou servlets/javabeans seront suffisants ?
On peut déja faire pas mal de choses avec des servlets/javabeans. D'après
ce que j'en comprend (en ne les ayant jamais pratiqué) les EJB vont
apporter à ton application beaucoup de capacités d'intégration à ton
réseau d'entreprise (MOM, management SNMP, persistance un peu facilitée,
transactions nettement facilitées, je crois).
Donc, plus que l'uptime, la question à tes poser est à mon avis celle des
services. Desquels as-tu besoin parmi toute la gamme de ce que proposent
les EJB ? Si ta réponse est aucun, alors tu n'as en fait pas besoin de
cette lourdeur.
Merci pour vos conseils
--
Nicolas Delsaux
"Celui qui est capable de marcher derrière une musique militaire n'a pas
besoin de cerveau : une moelle épinière suffit."
Albert Einstein
Le 19.11 2003, latitude.world s'est levé et s'est dit : "tiens, si j'écrivais aux mecs de fr.comp.lang.java ?"
Bonjour,
Objectifs :
- une application qui soit accessible pour partie via web services et pour partie via interface html
C'est quasiment ce que dans le monde de l'application web on appelle une application web, en quelque sorte ... si je ne m'abuse ;-)
- des fonctionnalités qui s'appuient sur des transactions simultanées [Chaque transaction = plusieurs transactions sérialisées ou parrallèles vers des serveurs LDAP (au moins deux annuaires différents) et BDD (trois bases différentes)]
Rien de bien complexe, quoi.
- une qualité de service/uptime quasi 24/7/365
La QoS dépend de nombreux facteurs, qui sont pour autant matériels que logiciels. Avant même de se poser la question de la technologie à employer, la question du matériel se pose : garantit-il un uptime suffisant ? Et les différentes couches logicielles garantissent-elles, de même, cet uptime ?
Alors vraiment des EJB ?? ou servlets/javabeans seront suffisants ?
On peut déja faire pas mal de choses avec des servlets/javabeans. D'après ce que j'en comprend (en ne les ayant jamais pratiqué) les EJB vont apporter à ton application beaucoup de capacités d'intégration à ton réseau d'entreprise (MOM, management SNMP, persistance un peu facilitée, transactions nettement facilitées, je crois). Donc, plus que l'uptime, la question à tes poser est à mon avis celle des services. Desquels as-tu besoin parmi toute la gamme de ce que proposent les EJB ? Si ta réponse est aucun, alors tu n'as en fait pas besoin de cette lourdeur.
Merci pour vos conseils
-- Nicolas Delsaux "Celui qui est capable de marcher derrière une musique militaire n'a pas besoin de cerveau : une moelle épinière suffit." Albert Einstein
Lionel
Nicolas Delsaux wrote:
Donc, plus que l'uptime, la question à tes poser est à mon avis celle des services. Desquels as-tu besoin parmi toute la gamme de ce que proposent les EJB ? Si ta réponse est aucun, alors tu n'as en fait pas besoin de cette lourdeur.
et il y a aussi une question de délai et de compétences. Bien maitriser les EJB et les bons pattern design, ca prend du temps. Bien maitriser un bon framework de persitance (fait maison, ou Hibernate ou autre) c'est beaucoup plus facile (et souvent beaucoup plus propre et performant).
Nicolas Delsaux wrote:
Donc, plus que l'uptime, la question à tes poser est à mon avis celle
des services. Desquels as-tu besoin parmi toute la gamme de ce que
proposent les EJB ? Si ta réponse est aucun, alors tu n'as en fait
pas besoin de cette lourdeur.
et il y a aussi une question de délai et de compétences.
Bien maitriser les EJB et les bons pattern design, ca prend du temps.
Bien maitriser un bon framework de persitance (fait maison, ou Hibernate ou
autre) c'est beaucoup plus facile (et souvent beaucoup plus propre et
performant).
Donc, plus que l'uptime, la question à tes poser est à mon avis celle des services. Desquels as-tu besoin parmi toute la gamme de ce que proposent les EJB ? Si ta réponse est aucun, alors tu n'as en fait pas besoin de cette lourdeur.
et il y a aussi une question de délai et de compétences. Bien maitriser les EJB et les bons pattern design, ca prend du temps. Bien maitriser un bon framework de persitance (fait maison, ou Hibernate ou autre) c'est beaucoup plus facile (et souvent beaucoup plus propre et performant).
cilovie
Les EJB servent à être distribués (c'est un peu leur principal but) Donc si tu veux distribuer par web services et non par des ejbs pas la peine de rajouter la "lourdeur" des ejbs.
Faire des EJB's pour en faire ou parce que cela fait bien dans un projet/cv, c'est un peu dommage.
"latitude.world" a écrit dans le message de news: bpga59$h43$
Bonjour,
Objectifs :
- une application qui soit accessible pour partie via web services et pour
partie via interface html - des fonctionnalités qui s'appuient sur des transactions simultanées [Chaque transaction = plusieurs transactions sérialisées ou parrallèles vers
des serveurs LDAP (au moins deux annuaires différents) et BDD (trois bases différentes)] - une qualité de service/uptime quasi 24/7/365
Alors vraiment des EJB ?? ou servlets/javabeans seront suffisants ?
Merci pour vos conseils
Les EJB servent à être distribués (c'est un peu leur principal but)
Donc si tu veux distribuer par web services et non par des ejbs pas la peine
de rajouter la "lourdeur" des ejbs.
Faire des EJB's pour en faire ou parce que cela fait bien dans un projet/cv,
c'est un peu dommage.
"latitude.world" <latitude.world@oleane.com> a écrit dans le message de
news: bpga59$h43$1@s1.read.news.oleane.net...
Bonjour,
Objectifs :
- une application qui soit accessible pour partie via web services et
pour
partie via interface html
- des fonctionnalités qui s'appuient sur des transactions simultanées
[Chaque transaction = plusieurs transactions sérialisées ou parrallèles
vers
des serveurs LDAP (au moins deux annuaires différents) et BDD (trois bases
différentes)]
- une qualité de service/uptime quasi 24/7/365
Alors vraiment des EJB ?? ou servlets/javabeans seront suffisants ?
Les EJB servent à être distribués (c'est un peu leur principal but) Donc si tu veux distribuer par web services et non par des ejbs pas la peine de rajouter la "lourdeur" des ejbs.
Faire des EJB's pour en faire ou parce que cela fait bien dans un projet/cv, c'est un peu dommage.
"latitude.world" a écrit dans le message de news: bpga59$h43$
Bonjour,
Objectifs :
- une application qui soit accessible pour partie via web services et pour
partie via interface html - des fonctionnalités qui s'appuient sur des transactions simultanées [Chaque transaction = plusieurs transactions sérialisées ou parrallèles vers
des serveurs LDAP (au moins deux annuaires différents) et BDD (trois bases différentes)] - une qualité de service/uptime quasi 24/7/365
Alors vraiment des EJB ?? ou servlets/javabeans seront suffisants ?
Merci pour vos conseils
Cédric Chabanois
Les EJB servent à être distribués (c'est un peu leur principal but) Donc si tu veux distribuer par web services et non par des ejbs pas la peine de rajouter la "lourdeur" des ejbs.
Faire des EJB's pour en faire ou parce que cela fait bien dans un projet/cv, c'est un peu dommage.
Ouai enfin les EJBs ne servent pas que "à être distribués". Il y a aussi la gestion des transactions et de la persistance, des permissions, des pools d'objets etc ... Si c'est pour redévelopper tout ca à côté, autant utiliser les ejbs plutôt.
Moi je ne pense pas qu'il soit stupide d'accéder à des ejbs via soap et donc de présenter certains ejbs comme des services webs (voir J2EE 1.4)
Les ejbs ne sont plus "à la mode" parce que les serveurs d'applications n'étaient pas au point jusqu'à peu et que mal utilisés ils peuvent tuer un projet. Je conseille de développer avec un serveur d'application léger (Jboss) quitte après à déployer sur un gros (Websphere, Weblogic)
Cédric
Les EJB servent à être distribués (c'est un peu leur principal but)
Donc si tu veux distribuer par web services et non par des ejbs pas la peine
de rajouter la "lourdeur" des ejbs.
Faire des EJB's pour en faire ou parce que cela fait bien dans un projet/cv,
c'est un peu dommage.
Ouai enfin les EJBs ne servent pas que "à être distribués". Il y a aussi
la gestion des transactions et de la persistance, des permissions, des
pools d'objets etc ...
Si c'est pour redévelopper tout ca à côté, autant utiliser les ejbs plutôt.
Moi je ne pense pas qu'il soit stupide d'accéder à des ejbs via soap et
donc de présenter certains ejbs comme des services webs (voir J2EE 1.4)
Les ejbs ne sont plus "à la mode" parce que les serveurs d'applications
n'étaient pas au point jusqu'à peu et que mal utilisés ils peuvent tuer
un projet.
Je conseille de développer avec un serveur d'application léger (Jboss)
quitte après à déployer sur un gros (Websphere, Weblogic)
Les EJB servent à être distribués (c'est un peu leur principal but) Donc si tu veux distribuer par web services et non par des ejbs pas la peine de rajouter la "lourdeur" des ejbs.
Faire des EJB's pour en faire ou parce que cela fait bien dans un projet/cv, c'est un peu dommage.
Ouai enfin les EJBs ne servent pas que "à être distribués". Il y a aussi la gestion des transactions et de la persistance, des permissions, des pools d'objets etc ... Si c'est pour redévelopper tout ca à côté, autant utiliser les ejbs plutôt.
Moi je ne pense pas qu'il soit stupide d'accéder à des ejbs via soap et donc de présenter certains ejbs comme des services webs (voir J2EE 1.4)
Les ejbs ne sont plus "à la mode" parce que les serveurs d'applications n'étaient pas au point jusqu'à peu et que mal utilisés ils peuvent tuer un projet. Je conseille de développer avec un serveur d'application léger (Jboss) quitte après à déployer sur un gros (Websphere, Weblogic)
