Bonjour à tous.
Je m'intéresse depuis peu aux modèles d'architecture distribuées en JAVA.
Dans ces recherches, je trouve énormément de théories sur les protocoles de
communication entre composants, sur la maniere de les concevoir, de les
déployer, de gérer la montée en charge...
Cependant, je n'arrive pas réellement à me faire une représentation pratique
de leur utilisation. On voit par exemple énormément d'offres d'emploi où
sont recherchés des spécialistes J2EE, EJB, Servlet...
A quoi tout cela sert concrètement ??. Pourriez vous me relater un cas
concret d'utilisation en entreprise (pas un cas d'école) où cette
architecture à montré son efficacité par rapport à une architecture client/
serveur classique ? (Bien entendu en dehors des projets web).
La réponse qui se profile naturellement est la notion de portabilité. Soit.
Est-ce que ça arrive souvent dans une entreprise, que du jour au lendemain,
on décide de changer tous les OS des serveurs ? Que fait-on alors de
l'existant ? J'ai du mal à croire qu'il existe des boites qui n'ont pas des
reliques d'applications qui tournent sur des bons vieux systemes NT !
J'aurais également souhaité visualiser des dossiers techniques (Toujours
sur un cas concret d'entreprise) relatif à ce type de projet (Étude de
faisabilité, spécifications, estimation des couts , plan de dév,...)
Quelqu'un aurait-il un lien intéressant à me proposer, voir me faire
parvenir un document.
Le but de ma démarche n'est absolument pas de polémiquer sur le bien fondé
de ces technologies, mais purement de m'informer sur le coté pragmatique de
la chose.
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
Pif
principe général de J2EE servlet et compagnie : le modèle MVC (modèle vue controleur)
l'objectif est de séparer en trois couches l'application - la premier contient les données métiers et un certain nombre d'opérations. C'est par exemple la base de données. - la dernière (vue) est la couche qui presente l'info, ca peut etre une interface graphique ou des servlet d'un site commercial - au milieu le middleware qui gère la communication entre les deux
ainsi tu peux changer completement le look de ton site sans avoir à te poser de question sur la bd, de meme, rien à redévelopper sur le site en changeant le modèle de la BD... application plus robuste, maintenance et développement beaucoup moins couteux
principe général de J2EE servlet et compagnie : le modèle MVC (modèle
vue controleur)
l'objectif est de séparer en trois couches l'application
- la premier contient les données métiers et un certain nombre
d'opérations. C'est par exemple la base de données.
- la dernière (vue) est la couche qui presente l'info, ca peut etre une
interface graphique ou des servlet d'un site commercial
- au milieu le middleware qui gère la communication entre les deux
ainsi tu peux changer completement le look de ton site sans avoir à te
poser de question sur la bd, de meme, rien à redévelopper sur le site en
changeant le modèle de la BD... application plus robuste, maintenance et
développement beaucoup moins couteux
principe général de J2EE servlet et compagnie : le modèle MVC (modèle vue controleur)
l'objectif est de séparer en trois couches l'application - la premier contient les données métiers et un certain nombre d'opérations. C'est par exemple la base de données. - la dernière (vue) est la couche qui presente l'info, ca peut etre une interface graphique ou des servlet d'un site commercial - au milieu le middleware qui gère la communication entre les deux
ainsi tu peux changer completement le look de ton site sans avoir à te poser de question sur la bd, de meme, rien à redévelopper sur le site en changeant le modèle de la BD... application plus robuste, maintenance et développement beaucoup moins couteux
Pif
Larry Zabim wrote:
Bonjour à tous. Je m'intéresse depuis peu aux modèles d'architecture distribuées en JAVA. Dans ces recherches, je trouve énormément de théories sur les protocoles de communication entre composants, sur la maniere de les concevoir, de les déployer, de gérer la montée en charge... Cependant, je n'arrive pas réellement à me faire une représentation pratique de leur utilisation. On voit par exemple énormément d'offres d'emploi où sont recherchés des spécialistes J2EE, EJB, Servlet... A quoi tout cela sert concrètement ??. Pourriez vous me relater un cas concret d'utilisation en entreprise (pas un cas d'école) où cette architecture à montré son efficacité par rapport à une architecture client/ serveur classique ? (Bien entendu en dehors des projets web).
principe général de J2EE servlet et compagnie : le modèle MVC (modèle vue controleur)
l'objectif est de séparer en trois couches l'application - la premier contient les données métiers et un certain nombre d'opérations. C'est par exemple la base de données. - la dernière (vue) est la couche qui presente l'info, ca peut etre une interface graphique ou des servlet d'un site commercial - au milieu le middleware qui gère la communication entre les deux
ainsi tu peux changer completement le look de ton site sans avoir à te poser de question sur la bd, de meme, rien à redévelopper sur le site en changeant le modèle de la BD... application plus robuste, maintenance et développement beaucoup moins couteux
en dehors du web, comme demandé, n'importe quelle application nécessitant une interface graphique, dont la logique métier est vouée à évoluer ou dont l'interface graphique est vouée à changer ...
le web est un exemple classique car dans beaucoup de cas, on peut développer une application (meme en intra/extra-net) dont on n'a pas à implanter le client chez l'utilisateur...
La réponse qui se profile naturellement est la notion de portabilité. Soit. Est-ce que ça arrive souvent dans une entreprise, que du jour au lendemain, on décide de changer tous les OS des serveurs ?
non, ca peut etre de passer d'un SGBD à un autre, d'un serveur à un autre, voiloir paralléliser, ... ou simplement utiliser de nouvelles technos "métier"
Que fait-on alors de
l'existant ? J'ai du mal à croire qu'il existe des boites qui n'ont pas des reliques d'applications qui tournent sur des bons vieux systemes NT !
si , à l'époque ou J2EE n'existait pas, on retrouve des applications en cobol et fortran à beaucoup d'endroit aujourd'hui encore...
J'aurais également souhaité visualiser des dossiers techniques (Toujours sur un cas concret d'entreprise) relatif à ce type de projet (Étude de faisabilité, spécifications, estimation des couts , plan de dév,...) Quelqu'un aurait-il un lien intéressant à me proposer, voir me faire parvenir un document.
Le but de ma démarche n'est absolument pas de polémiquer sur le bien fondé de ces technologies, mais purement de m'informer sur le coté pragmatique de la chose.
dsl, pas d'idée sur le sujet... en général on part du besoin pour choisir l'architecture, et pas de l'architecture pour regarder les besoins qui s'y collent (sauf si on développe l'architecture bien sur...)
Merci à vous.
Larry Zabim wrote:
Bonjour à tous.
Je m'intéresse depuis peu aux modèles d'architecture distribuées en JAVA.
Dans ces recherches, je trouve énormément de théories sur les protocoles de
communication entre composants, sur la maniere de les concevoir, de les
déployer, de gérer la montée en charge...
Cependant, je n'arrive pas réellement à me faire une représentation pratique
de leur utilisation. On voit par exemple énormément d'offres d'emploi où
sont recherchés des spécialistes J2EE, EJB, Servlet...
A quoi tout cela sert concrètement ??. Pourriez vous me relater un cas
concret d'utilisation en entreprise (pas un cas d'école) où cette
architecture à montré son efficacité par rapport à une architecture client/
serveur classique ? (Bien entendu en dehors des projets web).
principe général de J2EE servlet et compagnie : le modèle MVC (modèle
vue controleur)
l'objectif est de séparer en trois couches l'application
- la premier contient les données métiers et un certain nombre
d'opérations. C'est par exemple la base de données.
- la dernière (vue) est la couche qui presente l'info, ca peut etre une
interface graphique ou des servlet d'un site commercial
- au milieu le middleware qui gère la communication entre les deux
ainsi tu peux changer completement le look de ton site sans avoir à te
poser de question sur la bd, de meme, rien à redévelopper sur le site en
changeant le modèle de la BD... application plus robuste, maintenance et
développement beaucoup moins couteux
en dehors du web, comme demandé, n'importe quelle application
nécessitant une interface graphique, dont la logique métier est vouée à
évoluer ou dont l'interface graphique est vouée à changer ...
le web est un exemple classique car dans beaucoup de cas, on peut
développer une application (meme en intra/extra-net) dont on n'a pas à
implanter le client chez l'utilisateur...
La réponse qui se profile naturellement est la notion de portabilité. Soit.
Est-ce que ça arrive souvent dans une entreprise, que du jour au lendemain,
on décide de changer tous les OS des serveurs ?
non, ca peut etre de passer d'un SGBD à un autre, d'un serveur à un
autre, voiloir paralléliser, ... ou simplement utiliser de nouvelles
technos "métier"
Que fait-on alors de
l'existant ? J'ai du mal à croire qu'il existe des boites qui n'ont pas des
reliques d'applications qui tournent sur des bons vieux systemes NT !
si , à l'époque ou J2EE n'existait pas, on retrouve des applications en
cobol et fortran à beaucoup d'endroit aujourd'hui encore...
J'aurais également souhaité visualiser des dossiers techniques (Toujours
sur un cas concret d'entreprise) relatif à ce type de projet (Étude de
faisabilité, spécifications, estimation des couts , plan de dév,...)
Quelqu'un aurait-il un lien intéressant à me proposer, voir me faire
parvenir un document.
Le but de ma démarche n'est absolument pas de polémiquer sur le bien fondé
de ces technologies, mais purement de m'informer sur le coté pragmatique de
la chose.
dsl, pas d'idée sur le sujet... en général on part du besoin pour
choisir l'architecture, et pas de l'architecture pour regarder les
besoins qui s'y collent (sauf si on développe l'architecture bien sur...)
Bonjour à tous. Je m'intéresse depuis peu aux modèles d'architecture distribuées en JAVA. Dans ces recherches, je trouve énormément de théories sur les protocoles de communication entre composants, sur la maniere de les concevoir, de les déployer, de gérer la montée en charge... Cependant, je n'arrive pas réellement à me faire une représentation pratique de leur utilisation. On voit par exemple énormément d'offres d'emploi où sont recherchés des spécialistes J2EE, EJB, Servlet... A quoi tout cela sert concrètement ??. Pourriez vous me relater un cas concret d'utilisation en entreprise (pas un cas d'école) où cette architecture à montré son efficacité par rapport à une architecture client/ serveur classique ? (Bien entendu en dehors des projets web).
principe général de J2EE servlet et compagnie : le modèle MVC (modèle vue controleur)
l'objectif est de séparer en trois couches l'application - la premier contient les données métiers et un certain nombre d'opérations. C'est par exemple la base de données. - la dernière (vue) est la couche qui presente l'info, ca peut etre une interface graphique ou des servlet d'un site commercial - au milieu le middleware qui gère la communication entre les deux
ainsi tu peux changer completement le look de ton site sans avoir à te poser de question sur la bd, de meme, rien à redévelopper sur le site en changeant le modèle de la BD... application plus robuste, maintenance et développement beaucoup moins couteux
en dehors du web, comme demandé, n'importe quelle application nécessitant une interface graphique, dont la logique métier est vouée à évoluer ou dont l'interface graphique est vouée à changer ...
le web est un exemple classique car dans beaucoup de cas, on peut développer une application (meme en intra/extra-net) dont on n'a pas à implanter le client chez l'utilisateur...
La réponse qui se profile naturellement est la notion de portabilité. Soit. Est-ce que ça arrive souvent dans une entreprise, que du jour au lendemain, on décide de changer tous les OS des serveurs ?
non, ca peut etre de passer d'un SGBD à un autre, d'un serveur à un autre, voiloir paralléliser, ... ou simplement utiliser de nouvelles technos "métier"
Que fait-on alors de
l'existant ? J'ai du mal à croire qu'il existe des boites qui n'ont pas des reliques d'applications qui tournent sur des bons vieux systemes NT !
si , à l'époque ou J2EE n'existait pas, on retrouve des applications en cobol et fortran à beaucoup d'endroit aujourd'hui encore...
J'aurais également souhaité visualiser des dossiers techniques (Toujours sur un cas concret d'entreprise) relatif à ce type de projet (Étude de faisabilité, spécifications, estimation des couts , plan de dév,...) Quelqu'un aurait-il un lien intéressant à me proposer, voir me faire parvenir un document.
Le but de ma démarche n'est absolument pas de polémiquer sur le bien fondé de ces technologies, mais purement de m'informer sur le coté pragmatique de la chose.
dsl, pas d'idée sur le sujet... en général on part du besoin pour choisir l'architecture, et pas de l'architecture pour regarder les besoins qui s'y collent (sauf si on développe l'architecture bien sur...)
Merci à vous.
Larry Zabim
Extraits du lien:
La problématique Sécuriser les échanges de messages médicaux et l'accès à un extranet médical en utilisant la Carte Professionnel de Santé (CPS) et l'infrastructure du GIP-CPS.....
La solution développée est entièrement basée sur les standards Java J2EE, aussi bien pour la partie authentification que pour la partie chiffrement et signature des messages médicaux....
La problématique
Sécuriser les échanges de messages médicaux
et l'accès à un extranet médical en utilisant la Carte Professionnel de
Santé (CPS) et l'infrastructure
du GIP-CPS.....
La solution développée est entièrement basée sur les standards Java J2EE,
aussi bien pour la partie authentification que pour la partie chiffrement et
signature des messages médicaux....
La problématique Sécuriser les échanges de messages médicaux et l'accès à un extranet médical en utilisant la Carte Professionnel de Santé (CPS) et l'infrastructure du GIP-CPS.....
La solution développée est entièrement basée sur les standards Java J2EE, aussi bien pour la partie authentification que pour la partie chiffrement et signature des messages médicaux....
