SGE – Système de Gestion des Echanges - Portail
description
Transcript of SGE – Système de Gestion des Echanges - Portail
Proposition technique GSA/EUC/2003/091/CDM V1.1Réponse à l'appel d'offres COL-SGE-DC-001-04 du 01/08/2003.
SGE – Système de Gestion des Echanges - Portail
Application GMEC - Solution V0.1
Solution fonctionnelle V0.1Solution technique V0.1
Solution fonctionnelle V0.1
Architecture fonctionnellePrésentation de la solution
© 2003 Cap Gemini Ernst & Young - All right reserved25/09/03 – SGE - Portail – Proposition Technique / Page 4
Solution fonctionnelle V0.1
Architecture fonctionnelle
Système GMEC V0.1
Authentification
Administration locale et nationale
Gérer les Modules
Gestion des modules (DI, DR, PEE, REE, FDM, DES,
Documents impactés, Ecarts et Réserves, DEM)
Import de DonnéesReporting sous
BO Interfaces avec les différents sous-systèmes
Gérer les Processus
Gérer les processus Workflow (DI, DR, Suivi des travaux,
Gestion des Ecarts et Réserves, Gestion des modifications
locales, Gestion des Contrats)
Partage de données entre les Equipes
Communes
Gestion des tâches Workflow - Relances
Editions de Données et Requêtes
Export de Données
© 2003 Cap Gemini Ernst & Young - All right reserved25/09/03 – SGE - Portail – Proposition Technique / Page 5
Architecture générale V0.1Schéma d’architecture des flux simplifié
Serveur HTTPApache
WebLogic Portal
SGBDOracle Métier
HTTP
AnnuaireLDAP
LDAP
EJB
Serveur SMTP(messagerie)
HTTP
DMZ EXTERNE
DMZ INTERNE
INTRANET ETENDU
INTERNET
RMI/IIOP
Plate-forme Portail SGE V0.1
Acteurs internes
HTTP
Composants hors périmètre
SMTP
HTTP
Solution fonctionnelle V0.1
SGBD W4Oracle
W4 Servlet
W4 Engine
RMI/IIOP
© 2003 Cap Gemini Ernst & Young - All right reserved25/09/03 – SGE - Portail – Proposition Technique / Page 6
Présentation de la solutionF : Gérer les Processus workflow
Les habilitations d’accès aux différents workflows sont gérées : de façon générale au niveau de l’application ( en fonction du profil de l’acteur dans la base métier) pour l’affichage des
menus en fonction du profil de l’utilisateur. Si l’utilisateur est habilité sur un ou plusieurs processus workflow, un lien dans le menu de l’application GMEC lui permet d’accéder à la gestion des processus (liste des tâches à réaliser – relances).
de façon fine au niveau d’un processus. Par exemple l’habilitation nécessaire à la création d’un processus défini est réalisée au sein même du module de workflow, au travers du rôle de cet utilisateur dans le processus de workflow.
La gestion des actions de type workflow d’un utilisateur au niveau d’un processus sera réalisée à partir de ses rôles définis dans la base W4
Authentification
W4 Gestion fine des actions de
l’utilisateur en fonction de ses
rôles dans W4
Solution fonctionnelle V0.1
Utilisateur
Gestion Processus
Liste des tâches
Processus 2
Processus 1
Processus 3
Gestion des Modules
© 2003 Cap Gemini Ernst & Young - All right reserved25/09/03 – SGE - Portail – Proposition Technique / Page 7
Présentation de la solutionF : Gérer les Modules
Les habilitations d’accès aux différents modules sont gérées : de façon générale au niveau de l’application pour le droit d’accès à GMEC (authentification), aux différents modules
(DI, DR, etc) et à l’administration locale et/ou nationale. Si l’utilisateur est habilité sur un processus workflow, un lien dans le menu de l’application lui permet d’accéder à la gestion des processus workflow.
De façon fine, au niveau de la gestion des modules, l’authentification de l’utilisateur permet de déterminer la base de donnée locale qui lui est rattachée, en fonction de son équipe commune de rattachement.
Gestion des Modules
Utilisateur
Accès Worflow
Module 2
Module 1
Administration
Authentification
automatique
Gestion fine des habilitations
de l’utilisateur (profils)
Gestion fine des rôles sur
les processus Workflow au
niveau W4
Gestion des Processus
© 2003 Cap Gemini Ernst & Young - All right reserved25/09/03 – SGE - Portail – Proposition Technique / Page 8
Présentation de la solutionF6 : Administration locale / nationale
L’habilitation de l’utilisateur Cette fonctionnalité doit permettre à l’utilisateur de réaliser l’administration, de la base locale en fonction de son équipe commune de rattachement.
Une liste des événements à tracer est définie. Chaque événement déclenche une trace indiquant le type d’événement, l’utilisateur à l’origine de l’action, la date et l’heure, le détail éventuel de l’événement (par exemple : « consultation du message M00023 »).
Evénements
Evénement 1
Evénement 2
Evénement 3
Utilisateur
Solution fonctionnelle V0.1
© 2003 Cap Gemini Ernst & Young - All right reserved25/09/03 – SGE - Portail – Proposition Technique / Page 9
Présentation de la solutionF9 :
Les workflows métiers (processus) proprement-dits sont modélisés à partir de l’outil de modélisation W4 Studio, puis publiés sur le serveur W4.
Les acteurs ainsi que les rôles pour la gestion des processus sont définis dans la base de donnée du workflow. Les utilisateurs accédant à l’application GMEC doivent s’authentifier via la saisie d’un identifiant utilisateur et d’un mot de passe.
Cette authentification est définie au sens LDAP et Workflow.
Une fois authentifié, le système définit l’espace local auquel l’utilisateur a accès : visualisation de ses données sur son espace local.
L’utilisateur se connecte à GMEC
Les informations sur son profil permettent de déterminer l’espace
local auquel il a accès
1
Les informations concernant l’utilisateur (rôle workflow)
permettent de définir les processus et tâches associées
2
Page d’accueil personnalisée
Solution fonctionnelle V0.1
Solution technique V0.1
Architecture généraleMécanismes applicatifsArchitecture technique
© 2003 Cap Gemini Ernst & Young - All right reserved25/09/03 – SGE - Portail – Proposition Technique / Page 11
Architecture générale Schéma d’architecture générale du portail V0.1 (*)
Solution technique V0.1
Serveur HTTPApache 1.3.19
Plug-in WebLogic
Weblogic Server 6.1 SP2
Serveur d’EJBWeblogic Server
Serveur de données
Oracle 8.1.7
Plate-forme SGE V0.1 (Solaris 8)
RMI/IIOP
INTERNET
HTTPS
Certificat Serveur
Serv
eu
r d
e
mess
ag
er
ie
Système de fichiers
SMTP
LDAP
Navigateur Web : Internet Explorer 5.0 à 6Acteurs
externes
INTRANET
Acteurs internes
HTTP
Sous-système EAI/B2B
Sous-système WORKFLOW
FTP
WebLogic Portal 4.0 SP2
HTTP
Annuaire d’authentificati
on EDF
© 2003 Cap Gemini Ernst & Young - All right reserved25/09/03 – SGE - Portail – Proposition Technique / Page 12
Mécanismes applicatifs Gestion de contenu V0.1 – 1/2
La mise en place de Documentum n’est pas prévue dans le cadre de la V0.1 du portail SGE.
Une architecture temporaire est donc mise en place pour la gestion des contenus de cette version (Outils transverses, contenus éditoriaux, guides et autres documents). Cette architecture, qui vise à minimiser les impacts liés au passage à Documentum, est décrite page suivante.
Toutefois, CGE&Y recommande la mise en œuvre de Documentum dès la V0.1 du portail afin de l’intégrer dès le démarrage à l’architecture du projet :
Cette mise en œuvre permet d’intégrer dès la V0.1 les mécanismes d’accès à l’outil de gestion de contenu. Ces mécanismes sont réalisés au travers du contentSelector BEA et du eConnector Documentum. Ces composants, déjà utilisés sur d’autres projets EDF, sont complètement maîtrisés par CGE&Y.
L’intégration n’a pas d’impact en terme de délais sur le projet, la mise en place de Documentum pouvant être gérée de façon assez séparée du reste du système.
La mise en place prévue dans le cadre de la V0.1 vise essentiellement l’intégration de contenus statiques (pas de gabarits, utilisation du workflow standard du produit). Ces fonctions de base seront ensuite enrichies au fur et à mesure des versions : personnalisation fine des contenus, développement de gabarits, workflow de validation des documents…
Documentum permettra une première prise en main par les contributeurs et un retour d’expérience dès la V0.1.
La mise à jour du site pourra être réalisée de façon autonome par EDF, ce qui apporte une plus grande souplesse d’administration.
La modification graphique et/ou ergonomique de différents modèles de présentation des contenus est facilement impactée sur l'ensemble des contenus existants, ce qui peut faciliter l’application de la charte graphique SGE lors des développements de la V0.2.
CGE&Y propose d’étudier avec EDF les conditions de mise en place de Documentum dès la V0.1.
Solution technique V0.1
© 2003 Cap Gemini Ernst & Young - All right reserved25/09/03 – SGE - Portail – Proposition Technique / Page 13
Mécanismes applicatifs Gestion de contenu V0.1 – 2/2 De la même façon qu’un système Documentum classique, la gestion de contenu en V0.1 repose sur :
une base Oracle dans laquelle sont stockées les informations liées aux documents : titre du document, chemin d’accès, propriétés liées à la personnalisation.
un système de fichier dans lequel sont placés les documents : fichiers HTML, documents Word…
L’affichage des documents aux utilisateurs est réalisé en deux étapes :1. La sélection des documents est réalisée au travers d’une table de propriétés qui prend en compte les spécificités de l’utilisateur connecté. Il s’agira
par exemple d’afficher à un utilisateur uniquement les guides d’implémentation des flux auxquels il a accès.
2. Une fois le ou les document(s) identifié(s), ils sont récupérés à partir du système de fichier via le eConnector Documentum.
Afin de minimiser l’impact de la mise en place de Documentum en V0.2, la sélection des contenus est réalisée de la même façon que pour un accès à une base Documentum Webcache : utilisation du contentSelector BEA et du eConnector Documentum. La base de données contenant les propriétés des documents a donc une structure identique à celle d’une base Webcache.
La mise à jour des contenus implique une re-livraison des fichiers impactés sur la plate-forme de production. L’ajout de documents requiert la mise à jour de la base via des ordres SQL classiques.
Propriétés
Portail SGE
Requête de sélection des documents à afficher1
2 Récupération des fichiers à afficher
contentSelector BEA+
eConnector
Webcache
Portail SGE V0.1 Portail SGE V0.2
Solution technique V0.1
© 2003 Cap Gemini Ernst & Young - All right reserved25/09/03 – SGE - Portail – Proposition Technique / Page 14
Mécanismes applicatifsPropagation de l’authentification aux sous-systèmes – Présentation
Ce mécanisme doit permettre l’intégration des sous-systèmes Workflow et EAI/B2B dans l’architecture SGE, le portail étant le point d’accès à ces deux sous-systèmes.
Chaque sous-système possède sa propre gestion des utilisateurs et des habilitations. Afin d’éviter une re-saisie par l’utilisateur du portail de ses identifiant et mot de passe, l’authentification est propagée par le portail vers ces applications via l’utilisation de l’identifiant (login) de l’utilisateur.
Suite à cette authentification automatique, chaque sous-système a en charge la gestion des habilitations de l’utilisateur connecté.
Les applications Workflow et EAI/B2B s’affichent dans les écrans du portail sous la forme de composants de type Portlet. Ce qui implique le respect de la charte du site par ces applications ainsi que d’un certain nombre de normes de développement qui sont à définir dans le cadre de la conception technique du Portail SGE V0.1 (réalisation du modèle d’application W4).
Portail SGE Sous-système 1
Appel d’un service sous-système 1
Utilisateur Re-direction de l’appel vers le sous-systèmeLe login utilisateur est envoyé au sous-
système sous la forme d’un cookie dans le header HTTP
Le cas échéant, le sous-système ouvre une session pour l’utilisateur à partir du login envoyé (lors du premier appel par exemple).Puis il renvoie la page demandée au portail.
Le service demandé est renvoyé au portail sous la forme d’un flux HTML
Le flux HTML est encapsulé sous la forme d’une portlet dans l’interface du
portail et renvoyé à l’utilisateur
Solution technique V0.1
© 2003 Cap Gemini Ernst & Young - All right reserved25/09/03 – SGE - Portail – Proposition Technique / Page 15
Mécanismes applicatifsPropagation de l’authentification aux sous-systèmes – Solution 1
Une première solution, telle que décrite dans le dossier d’architecture SGE, consiste à utiliser un composant de type WebClipping qui re-dirige les appels aux différents sous-systèmes en mode HTTP :
Serveur HTTPApache
WebLogic Portal
SGBDOracle
EJB
HTTP
RMI/IIOP
Sous-système EAI/B2B ou WORKFLOW
HTTP
HTTP
WebClipping
Composants hors périmètre
Composants du module de re-directionDMZ EXTERNE
DMZ INTERNE
INTRANET ETENDU
INTERNET
Filtre flux HTTP
Solution technique V0.1
© 2003 Cap Gemini Ernst & Young - All right reserved25/09/03 – SGE - Portail – Proposition Technique / Page 16
Mécanismes applicatifsPropagation de l’authentification aux sous-systèmes – Solution 2
Dans cette seconde solution, un composant de type Servlet et un EJB de re-direction sont développés pour re-diriger les appels à ces sous-systèmes :
Serveur HTTPApache
WebLogic Portal
SGBDOracle
EJB
HTTP
RMI/IIOP
EJBSous-système EAI/B2B ou WORKFLOW
HTTP
RMI/IIOP
Servlet de re-
direction
Composants hors périmètre
Composants du module de re-directionDMZ EXTERNE
DMZ INTERNE
INTRANET ETENDU
INTERNET
Solution technique V0.1
© 2003 Cap Gemini Ernst & Young - All right reserved25/09/03 – SGE - Portail – Proposition Technique / Page 17
Mécanismes applicatifsPropagation de l’authentification aux sous-systèmes – Conclusion
La solution 1, à base d’un composant WebClipping impose l’ouverture d’un flux HTTP entre la DMZ Interne et l’Intranet RIN, et donc l’introduction d’un dispositif supplémentaire pour la sécurisation de ce flux.
La solution 2, à base d’une Servlet et d’un EJB de re-direction, est basée sur un flux autorisé (RMI/IIOP) mais nécessite l’installation d’une WebApplication au niveau de l’Intranet RIN pour la réception de l’EJB de re-direction.
Ces deux solutions ont déjà été mises en œuvre par CGE&Y sur des projets EDF.
CGE&Y propose d’étudier avec EDF parmi ce deux solutions, celle qui est la mieux adaptée au contexte du portail SGE et des contraintes d’architecture EDF. La solution retenue sera ensuite implémentée par CGE&Y lors de la réalisation du portail SGE V0.1.
Solution technique V0.1
© 2003 Cap Gemini Ernst & Young - All right reserved25/09/03 – SGE - Portail – Proposition Technique / Page 18
Mécanismes applicatifsModèle d’application W4
Parallèlement à la réalisation du composant de re-direction vers les sous-systèmes SGE, un modèle d’application W4 est développé par l’équipe CGE&Y afin de :
valider le fonctionnement du composant de re-direction, notamment la propagation des informations de connexion vers W4 et la bonne intégration du sous-système au sein du portail ;
définir les règles de développement qui devront être respectées par le chantier Workflow.
Ce modèle d’application doit permettre de définir les règles de développement des processus W4 qui alimenteront le portail au fur et à mesure de la réalisation du chantier Workflow :
contraintes techniques liées à l’authentification à partir du portail : mode de réception des identifiants, paramètres de session…
contraintes de développement liées à l’intégration de l’application Workflow : gestion du multi-fenêtrage, intégration des appels de type MultipartRequest (upload et download de fichiers), JavaScript…
contraintes liées au respect de la charte graphique du portail : feuille de style, images…
Un cahier des charges technique est réalisé à destination des équipes de réalisation du chantier Workflow afin d’intégrer l’ensemble de ces contraintes et règles de développement.
Ce cahier des charges intègre également une notice d’installation et de paramétrage du composant de re-direction.
Solution technique V0.1
© 2003 Cap Gemini Ernst & Young - All right reserved25/09/03 – SGE - Portail – Proposition Technique / Page 19
Mécanismes applicatifsInterface EAI/B2B
L’interface entre le portail SGE V0.1 et le sous-système EAI/B2B doit permettre aux utilisateurs de visualiser et télécharger les fichiers qui leur sont adressés (données de facturation, de consommation et bilans globaux).
Cette interface peut être réalisée de deux façons :
La solution retenue sera définie lors de la phase de conception technique du système. CGE&Y implémentera la solution choisie.
So
us
-sy
stè
me
E
AI/
B2
BPortail SGE
FTP
Utilisateur
Solution 1 : les fichiers et leur description (titre, utilisateur destinataire…) sont envoyés par l’EAI/B2B sur un serveur du portail (machine Weblogic située sur l’Intranet étendu). Un composant est développé au niveau du portail, qui accède à ces fichiers et restitue la liste de ceux destinés à l’utilisateur connecté.
Solution 2 : le projet EAI/B2B développe sont propre composant de visualisation et de téléchargement des fichiers. Ce composant est alors présenté dans le portail SGE sous la forme d’une portlet via le composant de re-direction.
So
us
-sy
stè
me
E
AI/
B2
B
Portail SGE
HTTP
Utilisateur
Composant de re-direction
La demande de l’utilisateur est re-dirigée vers le service de téléchargement de la brique EAI/B2B. Ce service apparaît
dans l’interface du portail au sein d’une portlet.
Le sous-système EAI/B2B dépose régulièrement les fichiers via FTP sur le serveur du portail. Un traitement permet l’intégration de ces fichiers dans la base du portail. Les fichiers sont ensuite
restitués à l’utilisateur sous la forme d’un écran applicatif.
HTTPHTTP
Solution technique V0.1
© 2003 Cap Gemini Ernst & Young - All right reserved25/09/03 – SGE - Portail – Proposition Technique / Page 20
Mécanismes applicatifsSolutions choisies par EDF (*)
Suite à la production du cahier des charges du projet SGE et à l’oral du 27/08/2003, EDF a avancé sur un certain nombre de points techniques :
Concernant la solution de « Propagation de l’authentification aux sous-systèmes » : La solution 2, basée sur un composant de type Servlet et un EJB de re-direction, requiert la localisation des sous-
systèmes cibles (EAI/B2B et Workflow) au niveau de l’Intranet Etendu. En effet, le flux de type RMI/IIOP n’est pas autorisé entre l’Intranet Etendu et le RIN. Cette solution n’est donc pas envisageable puisque le sous-système EAI/B2B se situe au niveau du RIN.
La solution 1, à base d’un composant WebClipping et d’un filtre flux HTTP est donc la solution retenue.
Concernant l’ « Interface EAI/B2B » : La solution 2, consistant à déléguer l’interface de consultation des fichiers mis à disposition au niveau du sous-système
EAI/B2B n’est pas envisageable.
La solution 1 est donc retenue : le sous-système EAI/B2B dépose les fichiers au niveau du portail, ce dernier réalise l’ensemble des traitements nécessaire à l’intégration de ces fichiers et fournit l’interface de consultation.
© 2003 Cap Gemini Ernst & Young - All right reserved25/09/03 – SGE - Portail – Proposition Technique / Page 21
Mécanismes applicatifsGénération des traces
Ce mécanisme a pour objectif de tracer un certain nombre d’événements réalisés dans l’interface du portail par les utilisateurs. La liste des événements à tracer est à définir au cours de la phase de conception du portail V0.1.
CGE&Y propose de s’appuyer sur le système de suivi comportemental standard de Weblogic Portal, qui permet :
de tracer des événements standards, par exemple la connexion ou la déconnexion d’un utilisateur ;
de définir des événements spécifiques à l’application, par exemple, tracer l’appel à un écran de consultation, tracer la visualisation d’un document (ex : guide d’implémentation), tracer l’appel à un service d’un sous-système…
L’ensemble des événements est enregistré en mode asynchrone afin de ne pas impacter les performances du système.
Les événements sont stockés dans un schéma Oracle spécifique, indépendant du schéma applicatif, ce qui facilitera l’évolution et l’interfaçage vers le futur sous-système « traces, supervision, archivage ».
Solution technique V0.1
© 2003 Cap Gemini Ernst & Young - All right reserved25/09/03 – SGE - Portail – Proposition Technique / Page 22
LDAP
Base de donnée
LoginMot de passe
LoginMot de passe
Nom, PrénomCoordonnées personnelles
Adresse individuelle de travailFonction, Question
Nom, PrénomCoordonnées personnelles
Adresse individuelle de travailFonction, Question
Raison sociale de l’entrepriseActivité de l’entreprise
Raison sociale de l’entrepriseActivité de l’entreprise
Données de connexion
Données utilisateur
Données entreprise
Profil de l’utilisateur(UUP)
Mécanismes applicatifsGestion des profils utilisateurs
Les profils utilisateurs sont gérés par Weblogic Portal au travers du module UUP (Unified User Profile). UUP permet de créer une vue uniforme et homogène des caractéristiques des utilisateurs issues de différentes sources hétérogènes.
L’ensemble des informations caractérisant un utilisateur est remonté en mémoire dans la session utilisateur lors de sa connexion.
La gestion via UUP permet d’assembler les informations utilisateurs provenant de différents sources hétérogènes (annuaire LDAP, base de données, différentes tables de données) et d’optimiser l’accès à ces données qui sont remontées en mémoire cache dans la session utilisateur à la connexion.
Solution technique V0.1
© 2003 Cap Gemini Ernst & Young - All right reserved25/09/03 – SGE - Portail – Proposition Technique / Page 23
Architecture technique Weblogic Portal – Version utilisée
Les souches de développement Weblogic Portal version 8.0 sont en cours de validation au sein de la DIT EDF (projet IDP).
La date de mise à disposition de ces souches n’est aujourd’hui pas compatible avec le planning du projet SGE, aussi CGE&Y intègre dans sa proposition une architecture technique basée sur le framework Weblogic Portal 4.0.
Toutefois, dans le cas où les souches Weblogic Portal 8.0 seraient disponibles au cours du projet, CGE&Y propose de les intégrer dans des conditions identiques sous réserve qu’elles soient disponibles avant T0 + 2 semaines (début d’installation de la plate-forme de développement CGE&Y).
Nom de la tâche
Gestion de projet
Lancement du projet
Organisation du projet
Revue de lancement
Spécifications et conception
Spécifications fonctionnelles
Conception technique générale
Installation plate-forme de développement
Développement et validation interne
08/09 Lancement du projet
09/09
10/09 Spécifications et conception
23/09
30/09
25/09 Développement et validation interne
01 04 07 10 13 16 19 22 25 28 01 04 07 10 13 16 19 22 18Septembre 2003 Octobre 2003
Solution technique V0.1
© 2003 Cap Gemini Ernst & Young - All right reserved25/09/03 – SGE - Portail – Proposition Technique / Page 24
Architecture technique Weblogic Portal - Architecture du produit
Weblogic Portal est une infrastructure technologique pour le développement de portails d’entreprise.
Il se compose d’outils d’administration des utilisateurs et des ressources, de systèmes de personnalisation et de gestion des interactions, et de services d’intégration permettant d’associer les systèmes d’information existants et diverses ressources Internet.
Il comprend les modules applicatifs suivants :
PortletsPortlets
Personnalisation & gestion intéractionPersonnalisation & gestion intéraction
Services fondamentaux d’un PortailServices fondamentaux d’un Portail
Administration IntelligenteAdministration Intelligente
Servicesd’intégration
Servicesd’intégration
Services e-CommerceIntégration Solutions ContenuMoteurs de rechercheChartes graphiques et mises en pages
Architecture déploiementConfiguration mode déconnectéPortail multi-ongletsFramework de portletsWebLogic Server
Outils fonctionnels (interface)Administration DéléguéeGestion des accès par règles
Règles de personnalisationSuivi ComportementalIntéraction et gestion de campagnes
Temps réelEvènements spécifiques Unified User Profile
(UUP)
Pipeline Components
Web Services Client Portlet Builder
WebLogic Integration
BEA Partenaires Spécifique
BEA Weblogic Portal
WebFlow – Conception de la navigationWebFlow – Intégration des process
Solution technique V0.1
© 2003 Cap Gemini Ernst & Young - All right reserved25/09/03 – SGE - Portail – Proposition Technique / Page 25
Architecture technique Weblogic Portal - Principes de programmation
Les développements réalisés sur SGE sont conformes au modèle multicouches J2EE.
L’architecture logicielle préconisée est basée sur le modèle MVC (Modèle – Vue – Contrôleur). Elle s’organise autour des composants de type :
JSP pour la représentation graphique des informations,
Servlets ou Pipelines pour les contrôles et la navigation,
EJB pour la récupération des informations en provenance du modèle.
Serv
eu
r Web
Serv
eu
r Web
Serveur d’application WebLogic
Navig
ate
ur
Navig
ate
ur
Présentation
(Contrôleur)Servlet ou Pipeline
(Contrôleur)Servlet ou Pipeline
(Vue)JSP
(Vue)JSP
(EJB)Modèle
(EJB)Modèle
Base de données
Requête
1
5PageHTML
2
3
4
Réponse
Métier
Solution technique V0.1
© 2003 Cap Gemini Ernst & Young - All right reserved25/09/03 – SGE - Portail – Proposition Technique / Page 26
Architecture techniqueOutils de développement
Les outils de développement utilisés sont les suivants : DreamWeaver (MACROMEDIA) : éditeur HTML utilisé pour le maquettage des écrans.
JBuilder (BORLAND) : atelier de développement Java.
PowerAMC (SYBASE) : Outil de spécification de modèles de données et de processus.
WinCVS (CVS) : Outil client de gestion de configuration sous Windows.
Outils Portal : EBCC (E-Business Control Center) : interface d’administration du portail, utilisée pour le paramétrage.
Les postes de développement utilisent le système d’exploitation suivant Windows 2000. Ils sont équipés d’un navigateur Web de type Microsoft Internet Explorer ou Netscape Navigator, et du plug-in Acrobat Reader.
Solution technique V0.1