ras le bol de voir des recruteurs demander des connaissances en j2ee / java
/ websphere.
que peut-on faire avec j2ee qu'on ne peut faire par exemple avec php / asp ?
pourquoi cet engouement soudain vers le monde java que j'ignore comme ma
premiere couche culotte ?
serait-ce pour developper des applis pour les tel portables ? excusez mon
inculture mais je ne trouve rien de pertinent sur le web a ce sujet.
Le but in fine étant de produire des pages HTML / Javascript au niveau du serveur et de pouvpoir les afficher dans un navigateur compatible sur le client.
ce que font php et asp ? qu'est-ce que ca apporte donc de plus ? tout le monde rit au nez mais aucun ne repond clairement, quand ce n'est pas pour ainsi dire a cote de la plaque (a deux exceptions pres)
La partie JSP/Servlet de J2EE fait ce que PHP et ASP font. Mais J2EE va plus loin pour aider le dévelopment d'applications niveau "entreprises". Comme tu le penses, J2EE n'apporte pas grand chose par rapport à PHP dans le cas d'applications "simple": un type de client (navigateur HTML/JavaScript), un serveur pour faire tourner l'application et une seule base de données.
Malheureusement, le cas "simple" n'est pas vraiment à l'image de l'entreprise qui utilisent de plus en plus d'applications liées entres elles. On ne se contente plus de traitements batch pour transmettre les données d'une application à une autre: la commande prise par un utilisateur sur le web est transmise directement à l'usine qui va fabriquer l'objet, les ordres ordres de ré-approvisionnement des pièces détachées sont automatiquement générés et transmisent aux fournisseurs si les stocks descendent en dessous d'un seuil minimum... Les commandes peuvent provenir du web, mais aussi d'application "business to business", d'autres entreprises dont les applications internes génère automatiquement leurs ré-approvisionnement.
Par rapport à une application Web/PHP/Base de donnée, une application "entreprise" est formée de composants sur plusieurs niveaux:
1) Web-HTTP-JSP-Servlet ou tout autre client
2) Composants EJB ("Enterprise Java Bean" literalement composant java entreprise) pouvant utiliser d'autres composant EJB pour implémenter la logique métier (le vrai travail algorithmique de traitement)
3) Composants pour acceder aux resources externes: bases de données et connecteurs servant à communiquer avec d'autres applications.
Pour permettre une intégration des composants, le serveur d'application "entreprise" se doit de gérer 2 chose d'une manière globale:
1) La sécurité: il n'est pas question que chaque composant s'assure de gérer l'authentification (s'assurer de qui est l'utilisateur) et les authorisation (vérifier ses droits). Le serveur d'application authentifie l'utilisateur et lui associe des rôles. Les composants n'on plus qu'a vérifier que ce rôle à le droit de faire l'action, et le plus souvent juste déclare dans un fichier de description quels rôles peuvent utiliser telles méthodes du composant, évitant aux développeur d'écrire du code pour ce genre de vérification.
2) La gestion des transactions: tous les composants EJB peuvent participer ou non à une transaction, et peuvent ou non partager leur contexte transactionnel, permettant ainsi si une erreur se produit d'annuler toutes les opérations, y compris celles ayant été faites par les autres composants. Les resources externes sont enregistrés auprès d'un moniteur transactionnel qui gère le commit ou rollback de toutes les transactions, assurant qu'aucun traitement partiel ne soit effectué: un client passe une commande, qui doit être enregistré dans l'application de gestion commerciale et envoyé à l'usine de production. Si la gestion commerciale (client non-solvable) ou l'usine (stock insuffisant) refuse la commande alors la commande ne doit pas être enrigistrer nulle part. Ce n'est pas aussi simple que cela parait.
Pour corser le tout, tout cela doit fonctionner même si les composants sont sur des sytèmes différents: le contexte utilisateur et transactionnel doit être transmit et traiter globalement...
Développer une application "entreprise" sans ce type d'outils est un vrai casse-tête.
-- Frédéric Lachasse - ECP86
<ampac> wrote in message news:417b9d53$0$32591$636a15ce@news.free.fr...
Dans news:417b5ed9$0$27007$8fcfb975@news.wanadoo.fr,
Le but in fine étant de produire des pages
HTML / Javascript au niveau du serveur et de pouvpoir les afficher
dans un navigateur compatible sur le client.
ce que font php et asp ? qu'est-ce que ca apporte donc de plus ?
tout le monde rit au nez mais aucun ne repond clairement, quand ce n'est
pas
pour ainsi dire a cote de la plaque (a deux exceptions pres)
La partie JSP/Servlet de J2EE fait ce que PHP et ASP font. Mais J2EE va plus
loin pour aider le dévelopment d'applications niveau "entreprises". Comme tu
le penses, J2EE n'apporte pas grand chose par rapport à PHP dans le cas
d'applications "simple": un type de client (navigateur HTML/JavaScript), un
serveur pour faire tourner l'application et une seule base de données.
Malheureusement, le cas "simple" n'est pas vraiment à l'image de
l'entreprise qui utilisent de plus en plus d'applications liées entres
elles. On ne se contente plus de traitements batch pour transmettre les
données d'une application à une autre: la commande prise par un utilisateur
sur le web est transmise directement à l'usine qui va fabriquer l'objet, les
ordres ordres de ré-approvisionnement des pièces détachées sont
automatiquement générés et transmisent aux fournisseurs si les stocks
descendent en dessous d'un seuil minimum... Les commandes peuvent provenir
du web, mais aussi d'application "business to business", d'autres
entreprises dont les applications internes génère automatiquement leurs
ré-approvisionnement.
Par rapport à une application Web/PHP/Base de donnée, une application
"entreprise" est formée de composants sur plusieurs niveaux:
1) Web-HTTP-JSP-Servlet ou tout autre client
2) Composants EJB ("Enterprise Java Bean" literalement composant java
entreprise) pouvant utiliser d'autres composant EJB pour implémenter la
logique métier (le vrai travail algorithmique de traitement)
3) Composants pour acceder aux resources externes: bases de données et
connecteurs servant à communiquer avec d'autres applications.
Pour permettre une intégration des composants, le serveur d'application
"entreprise" se doit de gérer 2 chose d'une manière globale:
1) La sécurité: il n'est pas question que chaque composant s'assure de gérer
l'authentification (s'assurer de qui est l'utilisateur) et les authorisation
(vérifier ses droits). Le serveur d'application authentifie l'utilisateur et
lui associe des rôles. Les composants n'on plus qu'a vérifier que ce rôle à
le droit de faire l'action, et le plus souvent juste déclare dans un fichier
de description quels rôles peuvent utiliser telles méthodes du composant,
évitant aux développeur d'écrire du code pour ce genre de vérification.
2) La gestion des transactions: tous les composants EJB peuvent participer
ou non à une transaction, et peuvent ou non partager leur contexte
transactionnel, permettant ainsi si une erreur se produit d'annuler toutes
les opérations, y compris celles ayant été faites par les autres composants.
Les resources externes sont enregistrés auprès d'un moniteur transactionnel
qui gère le commit ou rollback de toutes les transactions, assurant qu'aucun
traitement partiel ne soit effectué: un client passe une commande, qui doit
être enregistré dans l'application de gestion commerciale et envoyé à
l'usine de production. Si la gestion commerciale (client non-solvable) ou
l'usine (stock insuffisant) refuse la commande alors la commande ne doit pas
être enrigistrer nulle part. Ce n'est pas aussi simple que cela parait.
Pour corser le tout, tout cela doit fonctionner même si les composants sont
sur des sytèmes différents: le contexte utilisateur et transactionnel doit
être transmit et traiter globalement...
Développer une application "entreprise" sans ce type d'outils est un vrai
casse-tête.
Le but in fine étant de produire des pages HTML / Javascript au niveau du serveur et de pouvpoir les afficher dans un navigateur compatible sur le client.
ce que font php et asp ? qu'est-ce que ca apporte donc de plus ? tout le monde rit au nez mais aucun ne repond clairement, quand ce n'est pas pour ainsi dire a cote de la plaque (a deux exceptions pres)
La partie JSP/Servlet de J2EE fait ce que PHP et ASP font. Mais J2EE va plus loin pour aider le dévelopment d'applications niveau "entreprises". Comme tu le penses, J2EE n'apporte pas grand chose par rapport à PHP dans le cas d'applications "simple": un type de client (navigateur HTML/JavaScript), un serveur pour faire tourner l'application et une seule base de données.
Malheureusement, le cas "simple" n'est pas vraiment à l'image de l'entreprise qui utilisent de plus en plus d'applications liées entres elles. On ne se contente plus de traitements batch pour transmettre les données d'une application à une autre: la commande prise par un utilisateur sur le web est transmise directement à l'usine qui va fabriquer l'objet, les ordres ordres de ré-approvisionnement des pièces détachées sont automatiquement générés et transmisent aux fournisseurs si les stocks descendent en dessous d'un seuil minimum... Les commandes peuvent provenir du web, mais aussi d'application "business to business", d'autres entreprises dont les applications internes génère automatiquement leurs ré-approvisionnement.
Par rapport à une application Web/PHP/Base de donnée, une application "entreprise" est formée de composants sur plusieurs niveaux:
1) Web-HTTP-JSP-Servlet ou tout autre client
2) Composants EJB ("Enterprise Java Bean" literalement composant java entreprise) pouvant utiliser d'autres composant EJB pour implémenter la logique métier (le vrai travail algorithmique de traitement)
3) Composants pour acceder aux resources externes: bases de données et connecteurs servant à communiquer avec d'autres applications.
Pour permettre une intégration des composants, le serveur d'application "entreprise" se doit de gérer 2 chose d'une manière globale:
1) La sécurité: il n'est pas question que chaque composant s'assure de gérer l'authentification (s'assurer de qui est l'utilisateur) et les authorisation (vérifier ses droits). Le serveur d'application authentifie l'utilisateur et lui associe des rôles. Les composants n'on plus qu'a vérifier que ce rôle à le droit de faire l'action, et le plus souvent juste déclare dans un fichier de description quels rôles peuvent utiliser telles méthodes du composant, évitant aux développeur d'écrire du code pour ce genre de vérification.
2) La gestion des transactions: tous les composants EJB peuvent participer ou non à une transaction, et peuvent ou non partager leur contexte transactionnel, permettant ainsi si une erreur se produit d'annuler toutes les opérations, y compris celles ayant été faites par les autres composants. Les resources externes sont enregistrés auprès d'un moniteur transactionnel qui gère le commit ou rollback de toutes les transactions, assurant qu'aucun traitement partiel ne soit effectué: un client passe une commande, qui doit être enregistré dans l'application de gestion commerciale et envoyé à l'usine de production. Si la gestion commerciale (client non-solvable) ou l'usine (stock insuffisant) refuse la commande alors la commande ne doit pas être enrigistrer nulle part. Ce n'est pas aussi simple que cela parait.
Pour corser le tout, tout cela doit fonctionner même si les composants sont sur des sytèmes différents: le contexte utilisateur et transactionnel doit être transmit et traiter globalement...
Développer une application "entreprise" sans ce type d'outils est un vrai casse-tête.
-- Frédéric Lachasse - ECP86
ZebX
...Log du <22/10/2004 22:21> ...Post de <Cléo> :
Dans tous les cas c'est sûrement pas ton intervention qui l'aura fait progresser dans sa compréhension des solutions techniques apportées par J2ee.
C'est clair que balancer que je te cites : "Ce qui est livré dans le J2EE, c'est les interfaces compatibles à ces spécification et non leur implémentation." Ca éclaire, dommage que ca ne soit pas le bon côté. Donc, je redonne une 3eme fois le lien : http://java.sun.com/overview.html
Pour mes états d'âme, il me semble judicieux d'avertir les nouveaux de ne pas trop écouter les informaticiens qui sont plus conceptuels qu'opérationnels. Dit autrement, il y a ceux qui lisent et ceux qui codent.
-- ZebX - No comprendo
...Log du <22/10/2004 22:21> ...Post de <Cléo>
:
Dans tous les cas c'est sûrement pas ton intervention qui l'aura fait
progresser dans sa compréhension des solutions techniques apportées par
J2ee.
C'est clair que balancer que je te cites : "Ce qui est livré dans le
J2EE, c'est les interfaces compatibles à ces spécification et non leur
implémentation."
Ca éclaire, dommage que ca ne soit pas le bon côté.
Donc, je redonne une 3eme fois le lien : http://java.sun.com/overview.html
Pour mes états d'âme, il me semble judicieux d'avertir les nouveaux de
ne pas trop écouter les informaticiens qui sont plus conceptuels
qu'opérationnels. Dit autrement, il y a ceux qui lisent et ceux qui codent.
Dans tous les cas c'est sûrement pas ton intervention qui l'aura fait progresser dans sa compréhension des solutions techniques apportées par J2ee.
C'est clair que balancer que je te cites : "Ce qui est livré dans le J2EE, c'est les interfaces compatibles à ces spécification et non leur implémentation." Ca éclaire, dommage que ca ne soit pas le bon côté. Donc, je redonne une 3eme fois le lien : http://java.sun.com/overview.html
Pour mes états d'âme, il me semble judicieux d'avertir les nouveaux de ne pas trop écouter les informaticiens qui sont plus conceptuels qu'opérationnels. Dit autrement, il y a ceux qui lisent et ceux qui codent.
-- ZebX - No comprendo
Braim
ZebX wrote:
...Log du <22/10/2004 22:21> ...Post de <Cléo> :
Dans tous les cas c'est sûrement pas ton intervention qui l'aura fait progresser dans sa compréhension des solutions techniques apportées par J2ee.
C'est clair que balancer que je te cites : "Ce qui est livré dans le J2EE, c'est les interfaces compatibles à ces spécification et non leur implémentation." Ca éclaire, dommage que ca ne soit pas le bon côté. Donc, je redonne une 3eme fois le lien : http://java.sun.com/overview.html
Pour mes états d'âme, il me semble judicieux d'avertir les nouveaux de ne pas trop écouter les informaticiens qui sont plus conceptuels qu'opérationnels. Dit autrement, il y a ceux qui lisent et ceux qui codent.
Dans tous les cas c'est sûrement pas ton intervention qui l'aura fait
progresser dans sa compréhension des solutions techniques apportées
par J2ee.
C'est clair que balancer que je te cites : "Ce qui est livré dans le
J2EE, c'est les interfaces compatibles à ces spécification et non leur
implémentation."
Ca éclaire, dommage que ca ne soit pas le bon côté.
Donc, je redonne une 3eme fois le lien : http://java.sun.com/overview.html
Pour mes états d'âme, il me semble judicieux d'avertir les nouveaux de
ne pas trop écouter les informaticiens qui sont plus conceptuels
qu'opérationnels. Dit autrement, il y a ceux qui lisent et ceux qui codent.
Dans tous les cas c'est sûrement pas ton intervention qui l'aura fait progresser dans sa compréhension des solutions techniques apportées par J2ee.
C'est clair que balancer que je te cites : "Ce qui est livré dans le J2EE, c'est les interfaces compatibles à ces spécification et non leur implémentation." Ca éclaire, dommage que ca ne soit pas le bon côté. Donc, je redonne une 3eme fois le lien : http://java.sun.com/overview.html
Pour mes états d'âme, il me semble judicieux d'avertir les nouveaux de ne pas trop écouter les informaticiens qui sont plus conceptuels qu'opérationnels. Dit autrement, il y a ceux qui lisent et ceux qui codent.
