Descripteur de déploiement

Dimension: px
Commencer à balayer dès la page:

Download "Descripteur de déploiement"

Transcription

1 Chapitres traités Application Web Descripteur de déploiement Lorsque nous avons étudiés les servlets, nous avons déjà rencontrés et utilisés les descripteurs de déploiement. Dans ce chapitre, nous allons découvrir un peu plus en détail toutes les subtilités de ce fichier particulier. Les descripteurs de déploiement sont fichiers XML contenant toutes les informations de configuration relatifs à une application Web. Pour chaque application Web, le descripteur de déploiement s'appelle <web.xml>. Par ailleurs, une application Web doit respecter une structure particuliere. Avant de rentrer dans le vif du sujet concernant le descripteur de déploiement, il me paraît primordial de connaître ce qu'est une application Web. Application Web Une application Web doit répondre à un certain nombre d'attente de la part du client. Elle est généralement composée d'un certain nombres d'éléments en interaction entre eux. Une application Web peut être relativement conséquente et être composée de beaucoup d' éléments. Elle peut posséder : plusieurs pages statiques <*.html>, plusieurs servlets, des pages JSP, des JavaBeans, des objets distribués de type EJB, des applets, etc. Cette complexité ne doit pas du tout apparaître pour le client. L'utilisation de l'application Web doit au contraire être la plus conviviale possible et sa structure totalement transparente. En fait, pour l'utilisateur, il doit juste proposer le nom de l'application Web, dans l'url, à la suite du nom du site. comme par exemple Pour que cela soit aussi simple pour l'utilisateur, il est nécessaire d'avoir une architecture particulière, prédéfinie, qui sera la même pour toutes les applications Web de type Java. Structure d'une application Web <webapps> Une application web est donc visible par son nom d'appel dans l'url lors de l'exécution d'un script. Elle correspond de façon cachée à une arborescence particulière des fichiers sur le disque dur. Cette arborescence possède une structure préétablie que nous devons respecter. Lorsque l'utilisateur se connecte sur le site, et grâce à cette organisation particulière, le serveur Web (Tomcat par exemple) va systématiquement procéder à la même démarche : 1. Recherche de la page d'accueil correspondant à l'application Web. C'est généralement une page Web statique et pour plus de souplesse elle porte le nom de <index.html>. Elle peut comporter un formulaire à remplir. (Il peut déjà y avoir aussi des pages Web dynamiques de type JSP ou servlets). Grâce au descripteur de déploiement <web.xml>, il est possible de définir n'importe quel fichier comme fichier d'accueil. Ainsi, au lien de <index.html>, nous pourrions définir la page d'accueil <login.jsp>. 2. Après validation du formulaire, le serveur Web, au travers de composants Web (servlet, JSP, EJB) fabrique une nouvelle page Web en correspondance de la saise réalisée par le client. L'utilisation et la situation du bon composant Web est indiquée par le descripteur de déploiement. Dans l'exemple ci-contre, nous faisons appel à la servlet <Formulaire.class>. Pour que tout se passe convenablement, il faut donc respecter l'architecture des dossiers, telle qu'elle vous est présentée dans le tableau ci-dessous : Dossiers webapp Type de fichier ressources Web publiques (pages accessibles directement) Pages statiques : <*.html> Pages dynamiques JSP : <*.jsp> Applets : <*.class> WEB-INF ressources Web privée (pages non accessibles directement) Fichier de configuration de l'application WEB : <web.xml> Fragment de pages : <*.jspf> Pages d'erreur :<*.jsp> classes tlds lib Emplacement des servlets et des JavaBeans : <*.class>. Les servlets sont nécessairement compilées. Bibliothèques de balises Bibliothèques <*.jar> non standards comme les drivers JBDC. Le tableau ci-dessus nous montre donc l'architecture à respecter pour mettre en oeuvre une application Web. Normalement, il est préférable qu'elle dispose d'un dossier personnel nommée ici <webapp>. Ce dossier peut prendre le nom que vous désirez comme FormulairePersonne. Généralement le nom choisi correspond au nom de l'application Web..

2 Partie publique <webapps> ou <FormulairePersonne> Votre application Web se situe donc dans le répertoire qui servira au déploiement. Tous les fichiers qui se trouvent dans la racine de ce répertoire constitue la partie publique de l'application, celle qui sera uniquement accessible directement par les clients Web potentiels. Au niveau de la racine, nous devons trouver au moins la page d'accueil, plus quelques pages Web statiques ou dynamiques (JSP) qui ont un intérêt public. Se trouvent également les pages Web avec client "riche", c'est-à-dire celles qui comportent des applets. Les applets doivent donc se situer dans cette partie publique sinon elles ne seraient pas accessibles. La page d'accueil est généralement, soit : 1. index.html 2. index.htm 3. index.jsp Il est possible d'utiliser un autre nom de page d'accueil comme <Identification.html>. Il est alors nécessaire de le préciser dans la descripteur de déploiement. Dans l'extrême, nous pouvons donner une liste de pages d'accueil potentielles, mais la plupart du temps, nous indiquons dans ce descripteur juste la page que nous avons décidé de prendre. Partie privée <WEB-INF> Dans l'application Web se trouve systématiquement le répertoire <WEB-INF> qui est un répertoire spécial contenant toutes les informations de déploiement et le code de l'application. Ce répertoire est protégé par le serveur Web, et son contenu est invisible, même si l'on rajoute /WEB-INF/ à L'URL de base. <WEB-INF> est donc la partie privée de l'application Web et ne peut-être accessible que par décision des développeur au travers du descripteur de déploiement contenu dans ce répertoire. Toutefois, vos classes d'application peuvent charger des fichiers complémentaires directement à partir de cette zone, en utilisant la méthode getresource( ), et c'est un endroit sûr pour stocker des ressources d'application. Le répertoire <WEB-INF> contient le très important fichier <web.xml> qui est justement le descripteur de déploiement.. Répertoires <WEB-INF/classes> et <WEB-INF/lib> Ces deux répertoires contiennent, respectivement, des fichiers de classes Java et les bibliothèques Jar. Le répertoire <WEB-INF/classes> est automatiquement rajouté au chemin de classe de l'application Web, et chaque fichier de classes qui y est stockée est donc disponible pour l'application. Nous y retrouvons spécialement les classes des servlets et des Javabeans. Le répertoire <WEB-INF/lib> est utile pour stocker les bibliothèques nécessaires à l'application Web, mais qui ne font pas partie de JRE standard comme, par exemple, les pilotes JDBC. Constitution du descripteur de déploiement Pour chaque application Web, nous avons besoin d'un descripteur de déploiement. Il est unique. Il s'agit d'un fichier XML qui porte le nom de <web.xml>. Nous venons de le voir, ce fichier doit être placé dans le répertoire <WEB-INF> de l'application Web. <web.xml> est un fichier de configuration de l'application Web. Ce descripteur de déploiement permet de recencer les composants Web (servlets, JSP, EJB) qui font parti de l'application Web. Il permet également de maîtriser la gestion des exceptions en proposant des pages d'erreur (Web) personnalisés suivant le type d'erreur survenu lors d'une mauvaise saisie du client. Il permet également de mettre en place des filtres afin de recencer toutes les requêtes soumises par le client et ainsi de lancer le bon composant Web qui sera adapté à la situation. Elément du descripteur de déploiement Ce document XML comporte l'élément racine <web-app>. Le descripteur de déploiement étant contenu dans un fichier XML, il doit être conforme à cette spécification. Il doit donc commencer par une déclaration XML suivi d'une déclaration DOCTYPE (jusqu'à la spécification Servlet 2.3) ou par un Schéma XML (à partir de la spécification 2.4). Sous-éléments du descripteur de déploiement L'élément racine <web-app> dispose généralement d'un ou plusieurs sous-éléments suivant : Elément icon display-name description distributable context-param filter filter-mapping listener servlet Description Le chemin d'accès a une icône qui peut être employée par un outil graphique pour représenter l'application Web. Un nom qui peut être employé par un outil de gestion d'applications pour représenter l'application Web. Une description de l'application. Indique si l'application peut être distribuée entre plusieurs serveurs. La valeur par défaut est false. Contient les valeurs des paramètres valables pour toute l'application Web. Définit une classe de filtre qui sera aplliquée avant la servlet. Définit un alias pour un filtre. Définit une classe de listener qui sera appelée par le conteneur à la survenue d'un événement particulier. Définit une servlet par son nom et sa classe. servlet-mapping session-config mime-mapping welcome-file-list error-page Définit un alias pour une servlet. Définit un délai maximal d'inactivité pour les sessions. Définit une association entre les fichiers publics de l'application et des types MIME. Définit la ressource à retourner par défaut au client si aucune ressource n'est spécifiée. Définit la page d'erreur à retourner si aucune erreur particulière se produit.

3 taglib resource-env-ref resource-ref security-constraint login-config security-role env-entry ejb-ref ejb-local-ref Définit l'emplacement des bibliothèques de balises. Configure une ressource externe qui peut être utilisée par la servlet. Configure une ressource externe qui peut être utilisée par la servlet. Décrit les rôles des utilisateurs pouvant accéder à l'application Web. Configure la méthode d'authentification. Définit un rôle de sécurité pour l'application. Définit le nom d'une ressource accessible grâce à l'interface JNDI. Définit une référence distante à un Entreprise JavaBean (EJB). Définit une référence locale à un EJB. Nous ne ferons pas une étude exhaustive. Dans la suite, nous allons décrire un certain nombre de balises que vous serez succeptible de rencontrer ou d'utiliser. Nos premiers descripteurs de déploiement seront exploités à partir d'exemples simples. Nous commencerons par un exemple que nous étofferons au fur et à mesure. Affichage de l'application Web : <display-name> Cette balise représente tout simplement un nom qui peut être employé par un outil de gestion d'applications (comme le Gestionnaire d'applications WEB Tomcat) pour représenter l'application Web. Elle n'a pas une grande importance, mais cela peut être sympathique d'avoir une visualisation sommaire de ce que réalise notre Application Web. Définition des pages d'accueils : <welcome-file-list> Cette balise permet de définir le document à retourner par défaut au client si aucune ressource n'est spécifiée. Afin d'illustrer l'intérêt de cette balise, nous allons prendre l'exemple de la page d'accueil ci-dessous située dans la partie publique de notre application Web.

4 Pour accéder à cette page, le client Web, sur son URL, doit obligatoirement désigner en plus du nom du site et de l'application Web, le nom de la page Web à afficher. Ainsi, en effectuant le test sur l'ordinateur où se situe le serveur Web, nous devrions écrire : Cela impose que le client connaisse le nom de la page Web à afficher et doit en plus écrire une URL relativement longue. Il serait préférable que le client spécifie uniquement le nom de l'application Web sans qu'il se tracasse du nom de la page d'accueil qui est derrière. C'est au serveur Web à s'occuper de trouver la bonne page à afficher automatiquement. La première solution consiste, et nous en avons souvent parler, de prendre comme nom de page d'accueil <index.html>. Seulement, il peut aussi être intéressant de conserver le nom de la page que nous avons choisi puisque ce nom est relativement évocateur. C'est là qu'intervient le descripteur de déploiement. En effet, la balise <welcome-file-list> permet justement de spécifier l'ensemble des documents à ouvrir automatiquement lorsque le client se contente de spécifier uniquement le nom de l'application Web dans son URL. Lorsque le client devrait écrire uniquement ceci : Le serveur renvoie le premier document trouvé parmi ceux proposés de la liste donnée par la balise <welcome-file-list>. Chaque document est ensuite désigné par la balise <welcome-file>. Nous pouvons effectivement proposer plusieurs documents dans le cas où plusieurs solutions sont envisageables. Toutefois, dans la pratique, un seul document sera souvent suffisant. <welcome-file-list> <welcome-file>index.html</welcome-file> <welcome-file>index.htm</welcome-file> <welcome-file>index.jsp</welcome-file> </welcome-file-list> Dans cet exemple, <welcome-file-list> indique lorsqu'une requête partielle (chemin de répertoire) est reçue, le serveur doit d'abord chercher un fichier appelé <index.html> puis, en cas d'échec, un fichier appelé <index.htm> puis, de nouveau en cas d'échec, un fichier appelé <index.jsp>. Si aucun de ces fichiers n'est trouvé, c'est au serveur de décider quelle page à afficher. En général, les serveurs sont configurés pour afficher une liste organisée comme un répertoire ou pour renvoyer un message d'erreur. Définition des servlets : <servlet> L'élément <servlet> est l'un des plus important du descripteur de déploiement. Il permet de décrire les servlets de l'application Web. L'élément <servlet> indique au conteneur la classe qu'il doit associer au nom de la servlet. Eventuellement, l'élément <servlet-mapping> (qui est souvent en relation avec cet élément <servlet> ) associe une URL à ce nom. L'élément <servlet> peut posséder les sous-éléments suivant : <icon> <servlet-name> <display-name> <description> <servlet-class> <jsp-file> <init-param> <load-on-startup> <run-as> <security-role-ref> <servlet-name> et <servlet-class> Les sous-éléments obligatoires sont <servlet-name> et un des éléments <servlet-class> ou <jsp-file> (Les pages JSP sont automatiquement compilées sous forme de servlets). L'élément <servlet-name> définit un nom qui peut être utilisé pour désigner la ressource. Les éléments <servlet-class> et <jsp-file> définissent les noms qualifiés de la classe de la servlet ou du fichier JSP.

5 En définissant le nom de la servlet Identification et en utilisant l'élément <servlet-mapping> pour associer une URL /Identification au nom Identification, nous pouvons accéder à la servlet à l'aide de l'url : Ce n'est pas ici une économie impressionnante, mais si le nom de la classe était web.entreprise.service.subdivision.identification, il serait agréable de pouvoir y accéder par un nom plus simple. <load-on-start-up> <servlet> <load-on-start-up>5</load-on-start-up>... </servlet> L'élément <load-on-start-up> lorsqu'il est présent, contient un entier positif qui indique qu'il faut charger la servlet au démarrage du serveur. L'ordre de chargement des servlets est déterminé par cette valeur. Les servlets ayant la plus petite valeur sont chargées les premières. En cas de valeurs égales, l'ordre de chargement est arbitraire. Si l'élément est absent, la servlet est chargée lors de la première requêtes.. <init-param> Une servlet possède une méthode init() qui est sollicité juste après sa création. Cette méthode permet à la servlet de lire les paramètres d'initialisation ou les données de configuration, d'initialiser des ressources externes telles des connexions à une base de données ou d'effectuer diverses autres tâches qui seront accomplies une seule fois juste après la création de la servlet. La classe GenericServlet fournit deux formes de cette méthode : public void init() throws ServletException public void init(servletconfig) throws ServletException Le descripteur de déploiement peut définir des paramètres qui s'appliquent à la servlet au moyen de l'élément <init-param>. Le conteneur de servlets lit ces paramètres dans le fichier <web.xml> et les stocke sous forme de paires clé/valeur dans l'objet ServletConfig. L'interface Servlet ne définissant que init (ServletConfig), c'est cette méthode que le conteneur doit appeler. GenericServlet implémente cette méthode pour stocker la référence à ServletConfig puis appelle la méthode init( ) sans paramètres. Aussi pour effectuer l'initialisation, nous avons seulement besoin de redéfinir init( ) sans paramètre. La référence à ServletConfig étant déjà mémorisée, la méthode init( ) a accès à tous les paramètres d'initialisation qui y sont stockées. Pour récupérer ces paramètres, il suffit d'utiliser la méthode getinitparameter (String). public String GenericServlet.getInitParameter(String nomduparamètre) ; // retourne la valeur du paramètre L'intérêt des paramètres d'initialisation est de permettre de changer de configuration sans avoir besoin de recompiler la servlet. Par exemple, vous pouvez placer dans le descripteur de déploiement, le nom du pilote du serveur d'une base de données ainsi que sa localisation. Si plutard, vous devez changer de serveur, il suffit de modifier les valeurs directement dans la balise <init-param> du descripteur de déploiement (changement de texte) sans recompiler la servlet qui a déjà été mis en oeuvre. Ainsi notre servlet fonctionne quelque soit le serveur de base de données. <init-param> est composé de deux sous-éléments qui correspondent respectivement au nom du paramètre suivi de sa valeur : 1. <param-name> : nom du paramètre 2. <param-value> : valeur du paramètre Voici un exemple de paramètres initiaux définissant le serveur de base de données MySql définies dans le descripteur de déploiement associés à la servlet FormulairePersonne :

6 Récupération de ses paramètres initiaux dans la servlet FormulairePersonne : Pour cet exemple, nous avons utilisé la méthode getinitparameter(string) à l'intérieur de la méthode init(). Il est possible de l'utiliser dans les autres méthodes de la servlet comme doget() ou dopost(). Cela correspond alors à des paramètres moins spécifiques. Association entre l'url et la servlet : <servlet-mapping> Cet élément est utilisé pour définir des associations entre des URL et des noms de servlets. Dans l'exemple ci-dessous, l'url /Identification est finalement associée à la classe web.identification par l'intermédiaire de l'alias proposé : Identification. Il existe une association par défaut pour toutes les servlets utilisées par Tomcat. Les URL correspondantes au schéma /servlet/* sont en effet transmises à une servlet spéciale nommée invoker. Cette servlet lit les URL et transmet les requêtes aux servlets correspondantes. Mappage avec joker <url-pattern>/identification</url-pattern> La balise <url-pattern> spécifiée dans l'exemple précédent était une simple chaîne, "/Identification". Pour ce modèle, seule une correspondance finissant exactement par "/Identification" invoquerait la servlet, comme l'url suivante : La balise <url-pattern> permet d'utiliser des modèles beaucoup plus puissant, incluant même des caractères jokers. Par exemple, spécifier le mappage suivant : <url-pattern>/identifi*</url-pattern>

7 permet à la servlet d'être invoquée par les URL suivantes : ou Il est même possible de spécifier des caractères jockers suivis d'extensions, par exemple, <*.html> ou <*.perso>. Dans ce cas, la servlet peut être invoquée par n'importe quel chemin finissant par ces caractères. Définition des paramètres de l'application Web : <context-param> En imaginant que votre application Web dispose de plusieurs servlets qui font appel à la même base de données, il peut être génant de placer les mêmes paramètres d'initialisation <init-param> du pilote JDBC pour chacune de ces servlets. En effet, l'élément <init-param> défini dans le descripteur de déploiement, est associé à une servlet en particulier. Il serait préférable d'utiliser plutôt les paramètres d'initialisation de l'application Web, appelé paramètres de contexte <context-param>, qui sont accessibles pour tous les composants Web constituant l'application Web. <context-param>, comme pour <init-param> est composé de deux sous-éléments qui correspondent respectivement au nom du paramètre suivi de sa valeur : 1. <param-name> : nom du paramètre 2. <param-value> : valeur du paramètre Pour que chacune des servlets récupèrent ces paramètres, il est nécessaire d'abord de solliciter l'objet correspondant au contexte de la servlet (plus précisément, au contexte de l'application Web) à l'aide de la méthode getservletcontext(). Cet objet ensuite, peut délivrer les paramètres initiaux de l'application Web grâce à la méthode getinitparameter(). Gestion des exceptions - Pages d'erreur : <error-page> Les exemples de servlets proposés jusqu'à présent consistait au maximum à enregistrer la trace dans un journal. C'est bien pour l'administrateur, ça l'est beaucoup moins pour le client. Reprenons l'exemple précédent avec comme scenario, le serveur de base de données non opérationnel. Voilà ce que reçoit le client lorsqu'il remplit le formulaire et qu'il envoie la requête au serveur :

8 Suivant les serveurs, l'utilisateur voit s'afficher la trace de l'exception ou alors il n'obtient aucune réponse du serveur. Dans tous les cas, l'utilisateur a le sentiment que l'application est défectueuse, ce qui est le cas puisque pour l'instant, il n'y a pas de véritable gestion d'exception. Autre exemple, que se passe-t-il lorsque l'utilisateur saisie une valeur non numérique dans le champ correspondant à l'âge? Dans ce cas, le constructeur de la classe Integer lance une exception qui au niveau du client se traduit également par l'affichage de la trace de l'exception. Cette situation n'est pas acceptable. Nous avertissons le client lorsque l'enregistrement c'est bien déroulé. Nous devons également l'avertir lorsqu'un problème s'est rencontré et lui proposer une solution éventuelle, notamment lors de la mauvaise saisie d'un champ. C'est la moindre des choses. Bref, nous devons gérer l'exception. Règle de bonne conduite : A moins que l'exception soit une IOException (communication interrompue) survenant lors de l'écriture de la réponse, le client devrait toujours recevoir une réponse intelligible. Les pages d'erreur : <error-page> La solution au problème que nous venons d'évoquer pourrait être de ne placer un bloc try...catch qu'autour des instructions susceptibles de lancer des exceptions ou d'ajouter des instructions d'affichage dans le bloc catch pour retourner une réponse spécifique en cas d'erreur. C'est effectivement une solution plausible, mais le code de la servlet devient relativement surchargé. Il est préférable de séparer le code du fonctionnement normal de la servlet, avec le code relatif aux problèmes rencontrés, grâce à des pages spécialisées qui s'appellent des pages d'erreur. Il est possible de définir des pages Web ou des pages JSP qui seront retournées au client suivant le type d'erreur survenu. Ainsi, le client sait toujours à quoi s'en tenir quelque soit le scenario rencontré. Chaque page correspond donc a un type d'erreur. Il faut que le développeur indique quel est la page qui doit être envoyée au client au regard de l'exception lancée. Il le définit, tout simplement, à l'aide du descripteur de déploiement. Ainsi, lorsqu'un problème survient, le conteneur de servlets activera une page d'erreur d'une part, suivant l'exception qui est lancée, et d'autre part suivant ce que décrit le descripteur de déploiement au regard de cette exception. Dans le descripteur de déploiement, l'élément qui décrit les pages d'erreur est <error-page>. Deux scenarii sont possibles. Soit nous indiquons le type d'erreur exacte, soit un code d'erreur délivré par le protocole HTTP (500 par exemple) qui correspond alors à une erreur plus générique. Le conteneur de servlets prend toujours, dans le descripteur de déploiement, en premier la page qui correspond pile à l'erreur. S'il ne la trouve pas, il se rabat alors sur le code d'erreur qui englobe un ensemble d'erreurs potentielles. Sous-éléments de <error-page> : <exception-type> et <code-type> Nous avons donc deux écritures possibles dans le descripteur de déploiement qui correspondent au deux scenarii. C'est le choix des sous-éléments de <errorpage> qui détermine le scenario choisi. Ainsi nous pouvons avoir les sous-éléments suivants : <error-page> </error-page> <exception-type>java.lang.numberformatexception</exception-type> <location>/web-inf/nombreincorrect.html</location> ou/et les sous-éléments suivant :

9 <error-page> </error-page> <code-type>500</exception-type> <location>/web-inf/erreurserveur.html</location> La première écriture indique que si une erreur de type numérique intervient, c'est la page <NombreIncorrect.html> qui va être envoyée au client. Dans le deuxième cas, c'est l'erreur 500 donnée par le protocole HTTP qui permet d'envoyer au client la page <ErreurServeur.html>. L'erreur 500 devrait systématiquement être traitée de cette façon. Ce code indique une erreur interne du serveur que celui-ci ne peut traiter. Il peut s'agir d'un problème de compilation d'une JSP ou d'une exception dans une servlet. En spécifiant une page d'erreur, vous vous assurez que le client recevra une page lisible et correctement mis en forme, plutôt qu'une trace cabalistique.. Localisation des pages d'erreur : <location> L'élément <location> permet de déterminer quelle est la page qui doit être affichée au client. C'est le serveur qui l'envoie. Ce n'est pas le client qui l'utilise directement. Les pages d'erreur doivent donc être inaccessible de l'extérieur et doivent du coup être placée dans la zone privée de l'application Web, c'est-à-dire dans le répertoire <WEB-INF>. Descripteur de déploiement NombreIncorrect.html

10 ErreurServeur.html Sécurité et authentification Avec l'api Servlet 2.3, l'une des fonctionnalité les plus puissantes dans une application Web est la possibilité de définir des contraintes de sécurité déclarative. Par sécurité déclarative, on entend le fait qu'il suffit de décrire dans votre fichier web.xml les parties de votre application Web (accès à des documents, répertoires, servlets, etc.) qui sont protégés par mot de passe, le type d'utilisateurs autorisés à y accéder et la classe du protocole de sécurité nécessaire aux communications (crypté ou pas). Pour implémenter ces procédures de sécurité de base, il n'est pas nécessaire d'ajouter du code à vos servlets.. Deux types d'entrées du fichier web.xml contrôlent la sécurité et l'authentification (avec toutefois un troisème pour la définition du rôle) : 1. <security-contraint> : qui fournissent des autorisations basées sur les rôles utilisateurs et, si vous le souhaitez, sur le transport sécurisé de données. 2. <login-config> : qui détermine le type d'authentification utilisée pour l'application Web. 3. <security-role> : qui définit un rôle de sécurité pour l'application web. (A placer avant la balise <security-contraint>). Attribution de rôles aux utilisateurs Revenons sur notre application Web Personnel. Je désire que cette application Web ne soit accessible que par login et mot de passe. L'extrait suivant du fichier web.xml définit une zone appelée Application sécurisée, à partir d'un modèle d'url / et précise que seul les utilisateurs possédant le rôle personnel peuvent y accéder. Il utilise la forme la plus simple du processus de connexion : le modèle d'identification BASIC, qui affiche dans le navigateur une simple boîte de dialogue nom d'utilisateur/mot de passe :

11 Ici, le modèle d'url est /, ce qui signifie que toute l'application Web est sécurisée. Nous pourrions sécuriser qu'une seule partie de l'application Web, par exemple un répertoire de l'application qui ne sera accessible que par mot de passe. Soit, par exemple, le répertoire secret qui devrait être sécurisé, il faudrait alors préciser le modèle d'url suivant : <url-pattern>/secret/</url-pattern> L'entrée de contrainte de sécurité apparaît donc dans le fichier web.xml après toutes les entrées relatives à la servlet et au filtre. Chaque bloc <securityconstraint> contient une section <web-ressource-collection> qui fournit une liste nommée de modèle d'url d'accès à certaines zones de l'application Web, suivie d'une section <auth-contraint> listant les rôles utilisateur autorisés à accéder à ces zones, au moyen des balises successives <role-name>. Toutefois, pour que la section <auth-contraint> soit efficace, il est préférable que ces rôles aient été préalablement définies, en dehors de la balise <securitycontraint>, au moyen de la balise <security-role> à l'intérieur de laquelle se trouve également une suite de balises <role-name>. <security-role> <role-name>personnel</role-name> </security-role> <security-constraint>... <auth-constraint> <role-name>personnel</role-name> </auth-constraint> </security-constraint> Attention : Avant que cela fonctionne, il reste toutefois une étape à franchir : créer le rôle utilisateur "personnel", ainsi qu'un véritable utilisateur "Emmanuel" possédant ce rôle dans votre serveur d'application. Dans le serveur Tomcat, il est facile d'ajouter des utilisateurs et d'attribuer des rôles ; il suffit d'éditer le fichier conf/tomcat-users.xml. En voici un exemple cidessous avec l'ajout d'un seul utilisateur (N'oubliez pas de fabriquer le rôle). Le droit d'accès à des zones protégées est accordé à des rôles d'utilisateur et non pas à des utilisateurs individuels. Un rôle utilisateur représente en fait un groupe d'utilisateurs. Au lien d'allouer les droits à chaque utilisateur, par nom, on les alloue à des rôles, les utilisateurs se voyant attribuer un ou plusieurs rôles. C'est le cas notamment ci-dessus avec l'utilisateur admin qui peut aussi bien jouer le rôle de gestionnaire d'application Web (manager) que le rôle d'administrateur (admin) du serveur web Tomcat. Lorsqu'un utilisateur essaie d'accéder à une zone protégée par mot de passe, le login est testé afin de vérifier s'il possède le rôle adéquat.. Transport de données sécurisées Pour que votre application Web soit parfaitement sécurisée, il faudrait également protéger les informations qui transitent sur le réseau. Il nous faut donc aborder un élément supplémentaire de la contrainte de sécurité : la garantie de transport. Chaque bloc <security-contraint> peut finir par une entrée <user-data-contraint>, qui indique lequel des trois niveaux de sécurité de transport est retenu pour le protocole utilisé lors du transfert de données de et vers la zone protégées.

12 Les trois niveaux de sécurité sont : 1. NONE : qui est équivalent à une sortie de section, sans transport spécial. C'est le mode standard pour le trafic web, qui en général véhicule du texte plein via le réseau. 2. INTEGRAL : précise que le protocole de transport utilisé doit garantir que les données envoyées ne sont pas modifiées durant le transit. Ceci implique l'utilisation de signatures digitales ou de tout autre méthode de validation des données à l'arrivée, mais n'impose pas que les données soient chiffrées et cachées durant le transport. 3. CONFIDENTIAL : ajoute le chiffrement à la méthode INTEGRAL. En pratique, le seul mode de transport sécurisé largement utilisé dans les navigateurs web est SSL. Exiger une garantie de transport autre que NONE impose l'utilisation du SSL au navigateur client. Authentification des utilisateurs La section <login-config> détermine exactement comment un utilisateur s'authentifie à l'entrée de la zone protégée. La balise <auth-method> permet d'utiliser quatre types d'authentification : 1. BASIC : utilise la boîte de dialogue standard "nom/mot de passe" du navigateur web. L'authentification BASIC envoie le nom et le mot de passe utilisateur en texte plein sur le réseau, à moins qu'une garantie de transport n'ait été utilisée séparément pour démarrer SSL et chiffrer le stream de données. 2. DIGEST : est une variante de BASIC qui cache le texte de mot de passe mais n'est pas vraiment beaucoup plus sécurisée ; elle est peu utilisée. 3. FORM : est équivalente à BASIC, mais permet d'utiliser, au lieu de la boîte de dialogue standard, son propre formulaire HTML ou servlet. 4. CLIENT-CERT : est une option intéressante. Elle impose que l'utilisateur soit identifié via un certificat de clé publique côté client. Ceci implique l'utilisation d'un protocole comme SSL, qui permet des échanges sécurisés et l'authentification mutuelle en utilisant des certificats numériques. La méthode FORM est la plus utilisée car elle permet de personnaliser la pagede connexion (nous vous recommandons l'usage de SSL afin de sécuriser le stream de données. Il est également possible de spécifier une page d'erreur en cas d'échec de l'authentification.

13 Les filtres de servlet La servlet "Formulaire.java" que nous avons mis en oeuvre est relativement sophistiquée puisqu'elle intègre le stockage des informations, saisie par l'opérateur, dans la base de données. Cette servlet intègre également la journalisation des requêtes dans un fichier journal mémorisant toutes les tentatives d'accès. Pour cette journalisation, nous avons dû modifier la servlet en ce sens, la recompiler et la redéployer. C'est alors que l'on (votre patron, ou votre client) va vous demander de modifier l'application pour que le journal soit enregistré dans une base de données. Il vous faudra modifier de nouveau la servlet, la compiler, la déployer... C'est alors que l'on va vous demander... Bientôt, votre servlet sera remplie de code utile mais pas exactement en rapport avec sa fonction initiale : recevoir les requêtes et répondre aux clients. Nous avons besoin d'une solution plus efficace. Rôle des filtres Les filtres sont un moyen permettant de donner à une application une structure modulaire. Ils permettent d'encapsuler différentes tâches annexes qui peuvent être indispensables pour traiter les requêtes. Ainsi, dans notre exemple, nous pouvons créer un filtre prévu uniquement pour la journalisation des événements, alors que la servlet principale s'occupe du traitement de la requête proprement dite. Grâce à cette modularité, il devient facile de modifier le comportement de l'application Web en modifiant uniquement son descripteur de déploiement. La fonction principale d'une servlet consiste uniquement à recevoir des requêtes et répondre aux clients. Toute autre activité annexe est du ressort d'une autre classe. Aussi, lorsque que vous avez à implémenter une fonction particuliere, vous pouvez tirer profit des filtres et de la façon dont ils permettent d'encapsuler ces traitements spécifiques. Par ailleurs, leur modularité leur permet d'être utilisés avec plusieurs servlets différentes, ce qui facilite la maintenance en évitant la duplication du code. Structuration des filtres Les filtres sont chaînés, ce qui signifie que lorsque nous appliquons plus d'un filtre, la requête du serveur est passée à travers chacun d'eux de manière séquentielle, chacun ayant l'opportunité d'agir dessus ou de la modifier (notion de filtre) avant de passer au prochain. De manière similaire, à l'exécution, le résultat de la servlet est repassée à travers la chaîne en sens inverse. Il est donc possible au travers des filtres de modifier également la réponse de la servlet, même si le cas le plus fréquent consiste plutôt à faire des traitements au niveau de la requête. L'ordre des filtres de la chaîne est spécifié dans le descripteur de déploiement. Lorsque la méthode dofilter() d'un filtre est appelée, un des arguments passés est une référence à un objet de type FilterChain. Lorsque le filtre appelle chain.dofilter(), le filtre suivant la chaîne est exécuté. Le code placé avant chain.dofilter() est exécuté avant le traitement de la servlet (ou d'un autre filtre). Toute modification que le filtre doit apporter à la requête doit donc être effectué avant cet appel. Le code placé après cet appel est exécuté après le traitement de la servlet. C'est donc là que doivent être effectuées toutes les modifications à apporter à la réponse. Si le filtre doit agir sur la requête et sur la réponse, il contiendra donc du code avant et après l'invocation de la méthode chain.dofilter().

14 Par ailleurs, si l'un des filtres doit interrompre le traitement (par exemple en cas d'échec de l'authentification d'un client implémenté dans le prmier filtre), il peut le faire simplement en n'appelant pas la méthode dofilter(). Les filtres de servlet peuvent opérer sur tout type de requêtes d'une application Web, pas seulement sur celles gérées par des servlets. Ils peuvent également être appliqués à du contenu statique. Finalement ils peuvent être utilisés pour tous les composants Web : Servlet, JSP, EJB et HTML. Création d'un filtre Pour créer un filtre pour notre application Web, nous devons accomplir deux tâches. La première consiste à écrire une classe implémentant l'interface Filter, la seconde à modifier le descripteur de déploiement de l'application pour indiquer au conteneur qu'il doit utiliser le filtre. L'API Filter comporte trois interfaces : Filter, FilterChain, et FilterConfig. javax.servlet.filter est l'interface implémntée par les filtres. Elle déclare trois méthodes : 1. void init (FilterConfig filterconfig) : Cette méthode est appelée par le conteneur pour indiquer au filtre qu'il est mis en service. 2. void dofilter (ServletRequest request, ServletResponse response, FilterChain chain) : Cette est appelée par le conteneur chaque fois qu'une paire requête/réponse est traitée pour un client. 3. void destroy ( ) : Cette méthode est appelée par le conteneur pour indiquer au filtre qu'il est mis hors service. Vous pouvez constater que cette interface ressemble beaucoup à l'interface Servlet. Vous ne serez donc sûrement pas surpris d'apprendre que le cycle de vie des filtres ressemble également beaucoup à celui des servlets : 1. Lorsqu'un filtre est créé, le conteneur appelle sa méthode init(). Dans cette méthode, nous pouvons accéder aux paramètres d'initialisation grâce à l'interface FilterConfig. Toutefois, contrairement aux servlets, il n'est pas possible d'accéder à FilterConfig dans la méthode dofilter() sans en avoir préalablement enregistré une référence. 2. Lors du traitement de la requête, le conteneur appelle la méthode dofilter(). 3. Avant de détuire le filtre, le conteneur appelle sa méthode destroy(). L'interface javax.servlet.filterchain représente une chaîne de filtres. Elle déclare une méthode que chaque filtre peut invoquer pour appeler le filtre suivant dans la chaîne : void dofilter(servletrequest request, ServletResponse response) : Cette méthode entraine l'appel du filtre suivant dans la chaîne. Si le filtre appelant est le dernier de la chaîne, la ressource cible de la requête est appelée (par exemple une servlet). Lorsque la méthode dofilter() d'un filtre est appelée, un des arguments passés est une référence à un objet de type FilterChain. Lorsque le filtre appelle chain.dofilter(), le filtre suivant la chaîne est exécuté. Descripteur de déploiement Le descripteur de déploiement est utilisé pour indiquer au conteneur le ou les filtres qu'il doit appeler pour chaque servlet de l'application. Deux éléments sont utilisés pour décrire les filtres et indiquer à quelles servlets, ils doivent être appliqués. Le premier est <filter>. Voici un exemple de <filter> contenant tous les sous-éléments possibles : <filter> <icon>chemin d'accès à une icône</icon> <filter-name>le nom du filtre pour l'application Web</filter-name> <display-name>le nom utilisé par le gestionnaire d'application Web</display-name> <description>une description de l'application</description> <filter-class>le nom qualifié de la classe filtre</filter-class> <init-param> <param-name>nom du paramètre</param-name> <param-value>valeur du paramètre</param-value> </init-param> </filter> Seuls les sous-éléments <filter-name> et <filter-class> sont requis. Si un élément <init-param> est employé, les sous-éléments <param-name> et <param-value> doivent être présents. Ces paramètres sont accessibles grâce à l'interface FilterConfig. Le second élément est filter-mapping. Il peut prendre une des deux formes suivantes : <filter-mapping> <filter-name>même nom que pour l'élément filter</filter-name> <url-pattern>schéma d'url auquel le filtre doit être appliqué</url-pattern> </filter-mapping> ou <filter-mapping> <filter-name>même nom que pour l'élément filter</filter-name> <servlet-name>nom de la servlet auquel le filtre doit être appliqué</servlet-name> </filter-mapping> N'oubliez pas que l'ordre des éléments dans le descripteur de déploiement est important. Les éléments <filter> doivent être placés avant les éléments <filtermapping> qui doivent se trouver avant les éléments <servlet>. Si plusieurs filtres sont nécessaires, ils doivent être présentés par des éléments <filter-mapping> séparés. Les filtres sont appliqués dans l'ordre du descripteur de déploiment. <filter-mapping> <filter-name>filtreb</filter-name> <servlet-name>formulaire</servlet-name> </filter-mapping> <filter-mapping> <filter-name>filtrea<filter-name> <servlet-name>formulaire</servlet-name> </filter-mapping> Toute requête adressée à la servlet Formulaire est d'abord envoyée à FiltreB, car il est le premier dans le descripteur de déploiement. Lorsque FiltreB invoque la méthode chain.dofilter(), le FiltreA est appelé. Lorsque ce dernier invoque lui-même la méthode chain.dofilter(), la servlet Formulaire est enfin exécutée. Mise en oeuvre

15 Nous allons reprendre l'application Web précédente, et nous allons modifier son comportement. En effet, souvenez-vous, dans la servlet Formulaire, nous avions placée la journalisation des événements - grâce à la méthode log(). Ce n'est pas du tout le but de cette servlet qui doit s'occuper avant tout de la sauvegarde des informations saisies par l'opérateur dans la base de données. Nous allons donc mettre en oeuvre un filtre qui va s'occuper uniquement de cette journalisation. De plus, nous allons faire en sorte que cette journalisation, donc ce filtre, soit lancée pour tous les composants qui constitue notre application Web. Ainsi, il sera possible de contrôler précisément le parcours de l'opérateur. L'exemple ci-dessous nous montre le passage de l'opérateur par la page d'accueil "Formulaire.html", la confirmation de sa saisie grâce à la servlet "Confirmation.java" ainsi que l'enregistrement définitif au moyen de la servlet "Formulaire.java". Nous enlevons toutes les commandes log() de la servlet "Formulaire.java" et nous les plaçons dans le filtre "Journal.java" implémenté ci-dessous : Vous remarquez que les méthodes log() ont été supplantées par les méthodes println() sur la sortie standard. Le journal ainsi créé est représenté alors par le fichier stdout.log, comme vous l'avez vu d'ailleurs sur le journal d'exemple.

16 Voici ce que devient la servlet "Formulaire.java" sans les méthodes log() : Attention, n'oubliez pas de compléter le descripteur de déploiement pour que ce filtre soit utilisé. Si vous désirez que tous les éléments de l'application Web activent le filtre avant d'être lancés, il suffit de prendre plutôt la balise <url-pattern> dans la mapping de filtre et de placer l'url suivante : /* (le joker spécifie bien la prise en compte de tous les éléments).

Développement de Servlets et JSP avec Eclipse

Développement de Servlets et JSP avec Eclipse Développement de Servlets et JSP avec Eclipse Sommaire 1 Mise en place o 1.1 Installation de Galileo o 1.2 Association de Galileo avec une installation de Tomcat o 1.3 Pilotage des serveurs 2 Développement

Plus en détail

Bypass et filtre sur les requêtes destinées à la servlet W4

Bypass et filtre sur les requêtes destinées à la servlet W4 Note technique W4 Engine Bypass et filtre sur les requêtes destinées à la servlet W4 Cette note technique décrit le filtre de contrôle du bypass de la servlet W4. Versions de W4 Engine concernées : 5.0

Plus en détail

Avant-propos 1. Avant-propos...3 2. Organisation du guide...3 3. À qui s'adresse ce guide?...4

Avant-propos 1. Avant-propos...3 2. Organisation du guide...3 3. À qui s'adresse ce guide?...4 Les exemples cités tout au long de cet ouvrage sont téléchargeables à l'adresse suivante : http://www.editions-eni.fr. Saisissez la référence ENI de l'ouvrage EP5EJAV dans la zone de recherche et validez.

Plus en détail

TD4 : Wikis, Servlets & Projet

TD4 : Wikis, Servlets & Projet Université Bordeaux 1 T.D. License 3 Informatique 2007 2008 TD4 : Wikis, Servlets & Projet L objet de cette séance est de vous familiariser avec les sockets et les servlets, et d introduire le projet.

Plus en détail

Extension SSO Java. Cette note technique décrit la configuration et la mise en œuvre du filtre de custom SSO Java.

Extension SSO Java. Cette note technique décrit la configuration et la mise en œuvre du filtre de custom SSO Java. Note technique W4 Engine Extension SSO Java Cette note technique décrit la configuration et la mise en œuvre du filtre de custom SSO Java. 1 Présentation 3 2 Custom SSO Java 4 3 Bilan 10 Sommaire Référence

Plus en détail

Applications Web. Cours 2: Introduction J2EE Servlets et JSP. Khaled Khelif

Applications Web. Cours 2: Introduction J2EE Servlets et JSP. Khaled Khelif Applications Web Cours 2: Introduction J2EE Servlets et JSP Khaled Khelif 1 Rappel Web statique vs. Web dynamique Principe des applications web Protocole HTTP : requêtes en mode texte Développement d applications

Plus en détail

Kit d'intégration FAS+

Kit d'intégration FAS+ Guide d'intégration de l'application IAM - Annexe Kit d'intégration FAS+ Date 24/08/2012 Version 3.0 TABLE DES MATIÈRES 1 Introduction...3 2 Kit d'intégration FAS+...3 2.1 Pages JSP...4 2.2 Classes Java...7

Plus en détail

Ala Eddine BEN SALEM. T.P. 2 Servlet

Ala Eddine BEN SALEM. T.P. 2 Servlet EPITA Ala Eddine BEN SALEM App-Ing2 J2EE T.P. 2 Servlet 1. Création d'un projet Web: A l'aide d'eclipse, créer un nouveau projet «sampleservlet» avec comme environnement d'exécution le serveur Tomcat installé

Plus en détail

Frame m w e o w rk k STR T U R T U S T Confi o gur g e ur r r un e un nv n iro r nne o me m nt Axel KAMALAK

Frame m w e o w rk k STR T U R T U S T Confi o gur g e ur r r un e un nv n iro r nne o me m nt Axel KAMALAK Framework STRUTS Configurer un environnement Axel KAMALAK Outils nécessaires Eclipse Java EE IDE for Web Developers. Tomcat 5.5 Struts 1.3.10 JRE 6 Outils nécessaires Eclipse Java EE IDE for Web Developers.

Plus en détail

Annuaire : Active Directory

Annuaire : Active Directory Annuaire : Active Directory Un annuaire est une structure hiérarchique qui stocke des informations sur les objets du réseau. Un service d'annuaire, tel qu'active Directory, fournit des méthodes de stockage

Plus en détail

Le développement d applications Web

Le développement d applications Web Le développement d applications Web Plan Principes des applications Web Origine et utilité des Servlets Présentation des Servlets Les JSP La Standard TAG Library Servlet, JSP et accès aux SGBD Les technologies

Plus en détail

Création d'un site dynamique en PHP avec Dreamweaver et MySQL

Création d'un site dynamique en PHP avec Dreamweaver et MySQL Création d'un site dynamique en PHP avec Dreamweaver et MySQL 1. Création et configuration du site 1.1. Configuration de Dreamweaver Avant de commencer, il est nécessaire de connaître l'emplacement du

Plus en détail

Création d'un projet Web avec Netbeans 1. Création de son projet Web

Création d'un projet Web avec Netbeans 1. Création de son projet Web 1. Création de son projet Web Web Application Web Next Nommer le projet propose une localisation des sources par défaut Laisser Set as Main Project Next Tomcat 6 serveur d'application par défaut Choisi

Plus en détail

SPECIFICATIONS TECHNIQUES POUR LE DEVELOPPEMENT DES PLUGINS TOURISM SYSTEM CLIENT. V 1.0 27 janvier 2011

SPECIFICATIONS TECHNIQUES POUR LE DEVELOPPEMENT DES PLUGINS TOURISM SYSTEM CLIENT. V 1.0 27 janvier 2011 SPECIFICATIONS TECHNIQUES POUR LE DEVELOPPEMENT DES PLUGINS TOURISM SYSTEM CLIENT V 1.0 27 janvier 2011 Ce document présente l'utilisation des plugins dans Tourism System Client. Dans le Client, un plugin

Plus en détail

et Groupe Eyrolles, 2006, ISBN : 2-212-11747-7

et Groupe Eyrolles, 2006, ISBN : 2-212-11747-7 Tsoft et Groupe Eyrolles, 2006, ISBN : 2-212-11747-7 OEM Console Java OEM Console HTTP OEM Database Control Oracle Net Manager 6 Module 6 : Oracle Enterprise Manager Objectifs Contenu A la fin de ce module,

Plus en détail

A. Architecture du serveur Tomcat 6

A. Architecture du serveur Tomcat 6 Administration du serveur A. Architecture du serveur Tomcat 6 La compréhension de l architecture interne du serveur Tomcat 6 est un pré-requis indispensable pour bien en maîtriser l administration et la

Plus en détail

Application web de gestion de comptes en banques

Application web de gestion de comptes en banques Application web de gestion de comptes en banques Objectif Réaliser une application Web permettant à un client de gérer ses comptes en banque Diagramme de cas d'utilisation 1 Les cas d'utilisation Connexion

Plus en détail

Programmation servlet

Programmation servlet Programmation servlet Olivier Aubert 1/23 Références http://developer.java.sun.com/developer/onlinetraining/servlets/fundamenta http://www.servlets.com http://java.sun.com/products/jsp/index.html http://www.servletcentral.com/

Plus en détail

Fonctionnement du serveur Z39.50

Fonctionnement du serveur Z39.50 Fonctionnement du serveur Z39.50 Table des matières 1 Configuration du serveur...2 1.1 Comportement du serveur...2 1.2 Configuration de la traduction z39.50 -> base de données...2 1.3 Configuration du

Plus en détail

Google Chrome. La barre de favoris: Une petit barre (Ctrl+B) qui fait tout la largeur du navigateur juste en dessous de la barre de recherche.

Google Chrome. La barre de favoris: Une petit barre (Ctrl+B) qui fait tout la largeur du navigateur juste en dessous de la barre de recherche. Google Chrome Résumé rapide: Lien de téléchargement: http://www.google.fr/chrome La barre de favoris: Une petit barre (Ctrl+B) qui fait tout la largeur du navigateur juste en dessous de la barre de recherche.

Plus en détail

Dossier de Conception Système

Dossier de Conception Système Dossier de Conception Systeme FullMANGA Document Dossier de Conception Système Version 1.2 Commencé le 30 novembre 2006 Dernière modification 4 décembre 2006 Statut Finale Client Enseignants du M2P GI

Plus en détail

JAVA PROGRAMMATION. Programme. 1. Java, HTML et World Wide Web

JAVA PROGRAMMATION. Programme. 1. Java, HTML et World Wide Web PROGRAMMATION PUBLIC Professionnels informatiques qui souhaitent développer des applications et «applets» Java DUREE 4 jours 28 heures OBJECTIF Créer divers «applets» à intégrer dans un site Web dynamique,

Plus en détail

TP 3 Outils de programmation Web

TP 3 Outils de programmation Web TP 3 Outils de programmation Web L'objectif de ce TP est de bien comprendre et maîtriser la technologie des servlets. La maîtrise de ces briques de base doit vous permettre de construire de larges applications

Plus en détail

Sage CRM. 7.2 Guide de Portail Client

Sage CRM. 7.2 Guide de Portail Client Sage CRM 7.2 Guide de Portail Client Copyright 2013 Sage Technologies Limited, éditeur de ce produit. Tous droits réservés. Il est interdit de copier, photocopier, reproduire, traduire, copier sur microfilm,

Plus en détail

Guide d utilisateurs Plesk WEBPACK GUIDE D UTILISATEURS

Guide d utilisateurs Plesk WEBPACK GUIDE D UTILISATEURS Guide d utilisateurs Plesk WEBPACK GUIDE D UTILISATEURS 1 PleskWebpack MAS_FR- Octobre 2010 SOMMAIRE - Introduction 1 - Créer un compte FTP et les droits d accès 2 - Utiliser l outil de rapport (statweb,

Plus en détail

Application Web et J2EE

Application Web et J2EE Application Web et J2EE Servlet, JSP, Persistence, Méthodologie Pierre Gambarotto Département Informatique et Math appli ENSEEIHT Plan Introduction 1 Introduction Objectfis

Plus en détail

Chapitre 4 Les Servlets. 1. Qu'est-ce qu'une Servlet? 1.1 Présentation. 1.2 Requêtes HTTP

Chapitre 4 Les Servlets. 1. Qu'est-ce qu'une Servlet? 1.1 Présentation. 1.2 Requêtes HTTP 210 Les Servlets 1. Qu'est-ce qu'une Servlet? 1.1 Présentation Les Servlets sont la base de la programmation Java EE. La conception d'un site Web dynamique en Java repose sur ces éléments. Une Servlet

Plus en détail

Travaux Dirigés 5. Création d'un projet web sous Eclipse

Travaux Dirigés 5. Création d'un projet web sous Eclipse Travaux Dirigés 5 L objectif de ce TD est de vous permettre de construire une fiche de Maintenance ainsi que de définir les procédures à mettre en place lors d une maintenance. Dans le but d automatiser

Plus en détail

Partie 2.2: Servlet et Tomcat

Partie 2.2: Servlet et Tomcat Partie 2.2: Servlet et Tomcat 1 Plan du cours Servlets Présentation Exemple 2 Plan du cours Tomcat Des servlets à Tomcat: pourquoi Tomcat? Architecture Tomcat Installation et configuration de Tomcat Configuration

Plus en détail

Les architectures N-tiers

Les architectures N-tiers Les architectures N-tiers 1 SOMMAIRE DU COURS XML ET LES ARCHITECTURES N-TIER Introduction aux architectures N-tier Serveurs d applications Déploiement d applications J2EE Tiers applicatif : servlets Tiers

Plus en détail

Architecture J2EE. Thierry Lecroq (merci à Alexandre Pauchet (INSA Rouen)) Université de Rouen FRANCE. Thierry Lecroq (Univ. Rouen) J2EE 1 / 16

Architecture J2EE. Thierry Lecroq (merci à Alexandre Pauchet (INSA Rouen)) Université de Rouen FRANCE. Thierry Lecroq (Univ. Rouen) J2EE 1 / 16 Architecture J2EE Thierry Lecroq (merci à Alexandre Pauchet (INSA Rouen)) Université de Rouen FRANCE Thierry Lecroq (Univ. Rouen) J2EE 1 / 16 Plan 1 Historique 2 Architecture J2EE 3 J2EE et applications

Plus en détail

SQUID P r o x y L i b r e p o u r U n i x e t L i n u x

SQUID P r o x y L i b r e p o u r U n i x e t L i n u x SQUID P r o x y L i b r e p o u r U n i x e t L i n u x 1. P r é s e n t a t i o n : SQUID est un proxy (serveur mandataire en français) cache sous linux. De ce fait il permet de partager un accès Internet

Plus en détail

Rapport d'architecture

Rapport d'architecture Romain Alexandre Cécile Camillieri Rapport d'architecture 1 / 12 Table des matières I) Description du projet p. 3 1) Canaux de communication p. 3 2) Diagrammes de cas d'utilisation p. 3 II) Gestion des

Plus en détail

Système de contrôle d accès

Système de contrôle d accès Système de contrôle d accès Installation du système Les éléments à mettre en place. Pour mettre en place l environnement de travail de la badgeuse, il faut suivre plusieurs étapes : Sur l ordinateur devant

Plus en détail

1. Introduction... 2. 2. Création d'une macro autonome... 2. 3. Exécuter la macro pas à pas... 5. 4. Modifier une macro... 5

1. Introduction... 2. 2. Création d'une macro autonome... 2. 3. Exécuter la macro pas à pas... 5. 4. Modifier une macro... 5 1. Introduction... 2 2. Création d'une macro autonome... 2 3. Exécuter la macro pas à pas... 5 4. Modifier une macro... 5 5. Création d'une macro associée à un formulaire... 6 6. Exécuter des actions en

Plus en détail

Serveur d'archivage 2007 Serveur Archivage : Manuel Utilisateur

Serveur d'archivage 2007 Serveur Archivage : Manuel Utilisateur Type du document Manuel utilisateur Auteur(s) Eric Bouladier Date de création 26/03/2007 Domaine de diffusion Illimité Validé par Versions Date Auteur(s) Modifications 1.0 26/03/2007 Eric Bouladier Création

Plus en détail

Applications Web (Java)

Applications Web (Java) Applications Web (Java) Mohamed Quafafou 4A Polytech'Marseille mohamed.quafafou@univ-amu.fr 1 Servlets [Bases Exemples] 2 Java Servlets Java Servlet est une extension générique de serveur qui signifie

Plus en détail

Principe de fonctionnement du contrôleur de domaine

Principe de fonctionnement du contrôleur de domaine MODULE UTILISATION DES ESPACES DE STOCKAGE (source :prise en main du contrôleur de domaine Solaere) Préambule Vos stations sont configurées et intégrées dans le domaine. Principe de fonctionnement du contrôleur

Plus en détail

Client Citrix ICA Windows CE Carte de référence rapide

Client Citrix ICA Windows CE Carte de référence rapide Client Citrix ICA Windows CE Carte de référence rapide Exigences Pour exécuter le client ICA Windows CE, vous devez disposer des éléments suivants : Un périphérique Windows CE Une carte d'interface réseau

Plus en détail

Projet Java EE Approfondi

Projet Java EE Approfondi EISTI Projet Java EE Approfondi Manuel d installation du framework Stripes Amaury Languillat, Yann Gonzalez, Arnaud Recher, Vincent Laronde, Anys Mechkar 10 Manuel d installation Téléchargement On part

Plus en détail

Guide d'utilisation du CFEnet Local, version 2 1 / 8

Guide d'utilisation du CFEnet Local, version 2 1 / 8 Livrable Automate de Transmission des Fichiers CFEnet, version 2 : Guide d'utilisation Version Auteur Validation Date de diffusion Destinataires Version de travail Thierry Mallard Thierry

Plus en détail

Web Tier : déploiement de servlets

Web Tier : déploiement de servlets Web Tier : déploiement de servlets 1 / 35 Plan 1 Introduction 2 Servlet : Principe de fonctionnement 3 Création et développement sur un serveur JEE 4 Quelques méthodes de l API des servlets 5 Utilisation

Plus en détail

Documentation de CMS-gen

Documentation de CMS-gen Table des matières GÉNÉRALITÉ... 1 LA ZONE D'ADMINISTRATION... 2 LOGIN SUR LA ZONE D ADMINISTRATION... 2 EDITION DU CONTENU EN LIGNE... 3 LE MODE EDITION... 3 PUBLICATION... 3 SUPPRIMER DES MODIFICATIONS...

Plus en détail

AP-5 TD n 2 J2EE 5 novembre 2013

AP-5 TD n 2 J2EE 5 novembre 2013 Objectifs Prérequis Gestion des informations temporaires, sessions et cookies JSP et servlets, mise en place d un contrôleur Java Runtime Environnement (http://www.java.com/fr/download/) (JRE Java 7) IDE

Plus en détail

EXPORTATION ET TRANSFERT DE FICHIERS / Web Designer 7 FileZilla 2

EXPORTATION ET TRANSFERT DE FICHIERS / Web Designer 7 FileZilla 2 EXPORTATION ET TRANSFERT DE FICHIERS / Web Designer 7 FileZilla 2 But du tutoriel : Enregistrer son site Web depuis Magix Web Designer 7 puis lexporter sur le disque dur et enfin transférer les fichiers

Plus en détail

Installation et gestion du site Web de rapports dans cet article :

Installation et gestion du site Web de rapports dans cet article : Base de connaissances SiteAudit Installation et gestion du site Web de rapports dans cet article : Avril 2010 Présentation des fonctionnalités Installation de RWS Gestion des dossiers de rapport Accès

Plus en détail

Le site engarde-service.com pour publier des résultats de compétitions Service proposé par la société ANPV-log

Le site engarde-service.com pour publier des résultats de compétitions Service proposé par la société ANPV-log Le site engarde-service.com pour publier des résultats de compétitions Service proposé par la société ANPV-log 1. introduction 2. Création d'un compte sur engarde-service.com 2.1. Inscription 2.2 Gestion

Plus en détail

WINDOWS SERVER 2003 ADMINISTRATION A DISTANCE

WINDOWS SERVER 2003 ADMINISTRATION A DISTANCE 1. Introduction WINDOWS SERVER 2003 ADMINISTRATION A DISTANCE En règle générale, les administrateurs ne travaillent pas en salle serveurs. Et cette dernière peut se trouver n'importe où dans le bâtiment.

Plus en détail

Applications Web et servlets Java

Applications Web et servlets Java Département de génie logiciel et des TI LOG660 - Base de données haute performance Applications Web et servlets Java Application Web Une application Web répartie sur trois couches (three-tier Web application)

Plus en détail

ENVOL - Guide utilisateur

ENVOL - Guide utilisateur Secrétariat général DIRECTION DES SYSTÈMES D'INFORMATION ET DE COMMUNICATION SDES Bop Affaire suivie par : En cas de problème, contacter votre support informatique. ENVOL - Guide utilisateur Objet Ce document

Plus en détail

Le meilleur de l'open source dans votre cyber cafe

Le meilleur de l'open source dans votre cyber cafe Le meilleur de l'open source dans votre cyber cafe Sommaire PRESENTATION...1 Fonctionnalités...2 Les comptes...3 Le système d'extensions...4 Les apparences...5 UTILISATION...6 Maelys Admin...6 Le panneau

Plus en détail

SCOoffice Mail Connector for Microsoft Outlook. Guide d'installation Outlook 2002

SCOoffice Mail Connector for Microsoft Outlook. Guide d'installation Outlook 2002 SCOoffice Mail Connector for Microsoft Outlook Guide d'installation Outlook 2002 Rév 1.1 4 décembre 2002 SCOoffice Mail Connector for Microsoft Outlook Guide d'installation - Outlook XP Introduction Ce

Plus en détail

Client SQL Server version 3

Client SQL Server version 3 Client SQL Server version 3 Présentation du programme Par Jean-Pierre LEON Mise à jour du 10/06/2014 Page 2 sur 21 Présentation du logiciel Ouvrir, analyser, consulter, modifier une base de données au

Plus en détail

Programmation Avancée pour le Web

Programmation Avancée pour le Web L3 Informatique Option : ISIL Programmation Avancée pour le Web RAMDANI Med U Bouira 1 Contenu du module Introduction aux applications Web Rappels sur les sites Web Conception d une application Web Notion

Plus en détail

StreamServe Persuasion SP4 Control Center

StreamServe Persuasion SP4 Control Center StreamServe Persuasion SP4 Control Center Manuel utilisateur Rév. PA23 StreamServe Persuasion SP4 Control Center - Manuel utilisateur Rév. PA23 2001-2009 STREAMSERVE, INC. TOUS DROITS RESERVES Brevet américain

Plus en détail

Mémento professeur du réseau pédagogique

Mémento professeur du réseau pédagogique Mémento professeur du réseau pédagogique 1. Accéder au réseau pédagogique Il suffit quand on vous demande votre nom d utilisateur et votre mot de passe de renseigner ceux-ci. Votre nom d utilisateur est

Plus en détail

TP RPV DE NIVEAU APPLICATION EXTRANET

TP RPV DE NIVEAU APPLICATION EXTRANET TP RPV DE NIVEAU APPLICATION EXTRANET Étudions le cas de l entreprise MAROQ. L entreprise a décidé d ouvrir une partie de son SI (Système d information) à ses partenaires. Cette ouverture s effectue par

Plus en détail

Gestion du Serveur Web

Gestion du Serveur Web Gestion du Serveur Web Console de gestion du Serveur Web Une console de gestion est disponible dans l'outil de l'administrateur. Cette console de gestion vous permet de configurer les services JetClouding

Plus en détail

Dr. Djamel Benmerzoug. Email : djamel.benmerzoug@univ-constantine2.dz

Dr. Djamel Benmerzoug. Email : djamel.benmerzoug@univ-constantine2.dz Master 2 SITW Les services Web Dr. Djamel Benmerzoug Email : djamel.benmerzoug@univ-constantine2.dz Maitre de Conférences A, Département TLSI Faculté des NTIC Université Constantine 2 Abdelhamid Mehri

Plus en détail

Présentation du projet:

Présentation du projet: : Le but du projet est de réaliser le fonctionnement d'un jeu d échec valide. Plus spécifiquement, il consiste à implémenter l'organisation générale du jeu, et le suivi des règles du mouvement des pièces.

Plus en détail

Authentification CAS : module apache V2 mod_cas

Authentification CAS : module apache V2 mod_cas Page 1 of 8 Authentification CAS : module apache V2 mod_cas Ce document décrit l'installation et le paramétrage du module mod_cas esup-portail pour apache V2. Vincent Mathieu Université Nancy 2 Dates de

Plus en détail

Manuel utilisateur. des. listes de diffusion. Sympa. l'université Lille 3

Manuel utilisateur. des. listes de diffusion. Sympa. l'université Lille 3 Manuel utilisateur des listes de diffusion Sympa à l'université Lille 3 1 Table des matières Table des matières...2 I. Introduction...3 II. Principe général de fonctionnement de «Sympa»...3 1. Les principaux

Plus en détail

Application de lecture de carte SESAM-Vitale Jeebop

Application de lecture de carte SESAM-Vitale Jeebop Application de lecture de carte SESAM-Vitale Jeebop Présentation Le module de lecture de carte SESAM-Vitale Jeebop est une application Java Web Start, c'est à dire une application Java qui se télécharge

Plus en détail

La sécurité. Chapitre 6. 1. Introduction. 2. La sécurité des accès

La sécurité. Chapitre 6. 1. Introduction. 2. La sécurité des accès 259 Chapitre 6 La sécurité 1. Introduction La sécurité La sécurité des données est un enjeu capital. Une base de données peut être amenée à stocker des données très sensibles, confidentielles. L'implémentation

Plus en détail

TeamViewer 9 Manuel Management Console

TeamViewer 9 Manuel Management Console TeamViewer 9 Manuel Management Console Rév 9.2-07/2014 TeamViewer GmbH Jahnstraße 30 D-73037 Göppingen www.teamviewer.com Sommaire 1 A propos de la TeamViewer Management Console... 4 1.1 A propos de la

Plus en détail

I généralités 3. II les fichiers de ressources 3. III exemple d utilisation de fichiers de ressources 7

I généralités 3. II les fichiers de ressources 3. III exemple d utilisation de fichiers de ressources 7 Les fichiers de ressources sous Visual Basic 5.0 I généralités 3 a) Fichiers de ressources et Ressources de chaîne 3 b) Modèle d'adaptation 3 c) Avantages liés à la conception d'un logiciel multilingue

Plus en détail

Plan. Environnement Client/Serveur. Cours 6 Rappels Java (suite) Appel de méthode à distance. Utilité. static

Plan. Environnement Client/Serveur. Cours 6 Rappels Java (suite) Appel de méthode à distance. Utilité. static Plan Environnement Client/Serveur Cours 6 Rappels Java (suite) Appel de méthode à distance kn@lri.fr http://www.lri.fr/~kn 1 Rappels sur les systèmes d'exploitations / Communication par mémoire partagée

Plus en détail

Utilisation de Jakarta Tomcat

Utilisation de Jakarta Tomcat ISI 1022 : Déploiement d applications Web Jean-Noël Sorenti. Année 2002/2003 Déploiement d application Web Utilisation de Jakarta Tomcat ISI 1022 : 1 ISI 1022 : Déploiement d applications Web Une application

Plus en détail

Tutorat C/Unix : Un Rapido Client/Serveur

Tutorat C/Unix : Un Rapido Client/Serveur Tutorat C/Unix : Un Rapido Client/Serveur Nouredine Melab 1 Description générale du projet 1.1 Objectif L'objectif du projet est de concevoir et de réaliser un jeu de hasard dénommé Rapido. Un serveur

Plus en détail

Explication des statistiques

Explication des statistiques Explication des statistiques Sources : http://www.eolas.fr/8-conseil/65-interpreter-vos-statistiques-webalizer.htm http://support.sherweb.com/faqdetails.php?idarticle=68 Un site web est un ensemble de

Plus en détail

DÉMARRAGE RAPIDE. Présentation et installation de NetStorage

DÉMARRAGE RAPIDE. Présentation et installation de NetStorage Novell NetStorage www.novell.com DÉMARRAGE RAPIDE Présentation et installation de NetStorage Novell NetStorage est une fonction de NetWare 6 qui permet d'accéder facilement, via Internet, au système de

Plus en détail

Manuel d'utilisation Android

Manuel d'utilisation Android Projet de fin d'année BTS IRIS version 1.7 Manuel d'utilisation Android Réalisé par: Romain Gaillard Version numérique Promo 2014 Lycée Alfred Kastler Tables des matières INSTALLATION :... 3 I. IHM CONNEXION

Plus en détail

Mise en œuvre de serveurs d application TD n o 2

Mise en œuvre de serveurs d application TD n o 2 Master IST-IE 2007 08 UE 203d Mise en œuvre de serveurs d application TD n o 2 1 Introduction Dans ce TD, vous regarderez le contenu d une application J2EE. Ensuite, vous utiliserez les pages JSP pour

Plus en détail

Guide d'administration. BlackBerry Professional Software pour IBM Lotus Domino. Version: 4.1 Service Pack: 4

Guide d'administration. BlackBerry Professional Software pour IBM Lotus Domino. Version: 4.1 Service Pack: 4 BlackBerry Professional Software pour IBM Lotus Domino Version: 4.1 Service Pack: 4 SWD-311541-0911043520-002 Table des matières 1 Gestion des comptes d'utilisateur... 7 Ajouter un compte utilisateur...

Plus en détail

Publication d'application

Publication d'application Publication d'application Vue d'ensemble JetClouding supporte 3 types de publication d'application: Microsoft Remote Desktop: L'utilisateur verra le Bureau à distance Windows dans la session. Le contrôle

Plus en détail

MANUEL DU KIT DE DEVELOPPEMENT DE CONNECTEURS Référence: W4JC_DEVKIT_020_FR

MANUEL DU KIT DE DEVELOPPEMENT DE CONNECTEURS Référence: W4JC_DEVKIT_020_FR W4 CONNECTORS FOR JAVA MANUEL DU KIT DE DEVELOPPEMENT DE CONNECTEURS Référence: W4JC_DEVKIT_020_FR Les prochaines mises à jour de ce document seront disponibles sur www.myw4.com W4 CONNECTORS FOR JAVA

Plus en détail

Gestion du parc informatique des collèges du département du Cher. Manuel d utilisation de la solution de gestion de Parc

Gestion du parc informatique des collèges du département du Cher. Manuel d utilisation de la solution de gestion de Parc Gestion du parc informatique des collèges du département du Cher Manuel d utilisation de la solution de gestion de Parc Table des matières 1. Préambule... 3 2. Pré requis... 3 3. Objectifs... 3 4. Connexion

Plus en détail

Le système eregistrations

Le système eregistrations NATIONS UNIES CNUCED Le système eregistrations Guichets uniques en ligne pour des administrations efficaces eregistrations est un système de gouvernement électronique configurable, conçu pour automatiser

Plus en détail

Symfony 2. 1.Définition de symfony 2. 2.Installation. 3.Structure. 4.Symfony et les commandes

Symfony 2. 1.Définition de symfony 2. 2.Installation. 3.Structure. 4.Symfony et les commandes Symfony 2 Sommaire : 1.Définition de symfony 2 2.Installation 3.Structure 4.Symfony et les commandes 5.Le fonctionnement : le routeur (les url), les bundles, twig(templates) 6.L architecture de symfony2

Plus en détail

Documentation Utilisateur. ADKiosk

Documentation Utilisateur. ADKiosk Documentation Utilisateur ADKiosk DU_ADKioskV36.odt 27/10/11 16:59:29 Page 1/18 Suivi du Document Version Date Auteur Objet 0.1 06/05/2008 O. LAZZAROTTO Rédaction initiale 1.0 02/06/2008 V. MONTAGNON Relecture

Plus en détail

SQLI. Solution Santé. IdeoSSO - Intégration d'un client IdeoSSO 22/10/2007. Confidentiel SQLI Solution Santé 28/03/2008 P 1/35

SQLI. Solution Santé. IdeoSSO - Intégration d'un client IdeoSSO 22/10/2007. Confidentiel SQLI Solution Santé 28/03/2008 P 1/35 SQLI Solution Santé IdeoSSO - Intégration d'un client IdeoSSO 22/10/2007 Confidentiel SQLI Solution Santé 28/03/2008 P 1/35 Historique Historique des versions du document Version / Date Auteur Commentaire

Plus en détail

Les servlets Le langage Java Les Servlets XVII-1 JMF

Les servlets Le langage Java Les Servlets XVII-1 JMF Les Servlets XVII-1 servlet =? Une servlet est un programme (plug-in) à ajouter à un serveur (quel qu'il soit). Ce cours a trait à la programmation Java coté serveur (J2EE ) Pour l'instant les serveurs

Plus en détail

1. Installation d'un serveur d'application JBoss:

1. Installation d'un serveur d'application JBoss: EPITA Ala Eddine BEN SALEM App-Ing2 J2EE T.P. 4 EJB3, Serveur d'application JBoss 1. Installation d'un serveur d'application JBoss: télécharger l'archive du serveur JBoss à l'adresse: http://sourceforge.net/projects/jboss/files/jboss/jboss-5.0.0.ga/jboss-5.0.0.ga.zip/download

Plus en détail

Version 1.0 Janvier 2011. Xerox Phaser 3635MFP Plate-forme EIP

Version 1.0 Janvier 2011. Xerox Phaser 3635MFP Plate-forme EIP Version 1.0 Janvier 2011 Xerox Phaser 3635MFP 2011 Xerox Corporation. XEROX et XEROX and Design sont des marques commerciales de Xerox Corporation aux États-Unis et/ou dans d'autres pays. Des modifications

Plus en détail

Mode d'emploi Application Présences Planification des évènements

Mode d'emploi Application Présences Planification des évènements Mode d'emploi Application Présences Planification des évènements 21 avril 2005 Page 1 / 31 2005 / Guillaume Fort Sommaire 1. Description du concept...3 2. Démarrage de l'application...4 3. Philosophie

Plus en détail

E-mail : contact@nqicorp.com - Web : http://www.nqicorp.com

E-mail : contact@nqicorp.com - Web : http://www.nqicorp.com - 5, rue Soutrane - 06560 Valbonne Sophia-Antipolis E-mail : contact@nqicorp.com - Web : http://www.nqicorp.com NQI Orchestra 3.3 - Guide d'installation Windows.................................................................

Plus en détail

TP RPV de niveau application EXTRANET

TP RPV de niveau application EXTRANET TP RPV de niveau application EXTRANET L entreprise MAROQ a décidé d ouvrir une partie de son SI (Système d information) à ses partenaires. Cette ouverture s effectue par la création d un site web privé

Plus en détail

Jean-Michel Richer jean-michel.richer@univ-angers.fr http://www.info.univ-angers.fr/pub/richer. L3 Pro Informatique - 2010-2011

Jean-Michel Richer jean-michel.richer@univ-angers.fr http://www.info.univ-angers.fr/pub/richer. L3 Pro Informatique - 2010-2011 1 / 34 Développement Web - Servlet Jean-Michel Richer jean-michel.richer@univ-angers.fr http://www.info.univ-angers.fr/pub/richer L3 Pro Informatique - 2010-2011 2 / 34 Plan Plan 1 Introduction 2 Servlet

Plus en détail

Environnements de Développement

Environnements de Développement Institut Supérieur des Etudes Technologiques de Mahdia Unité d Enseignement : Environnements de Développement BEN ABDELJELIL HASSINE Mouna m.bnaj@yahoo.fr Développement des systèmes d Information Syllabus

Plus en détail

Explorateur Windows EXPLORATEUR WINDOWS...1 INTRODUCTION...2 LANCEMENT DE L'EXPLORATEUR WINDOWS...3 PRÉSENTATION PHYSIQUE...3 RECHERCHER...

Explorateur Windows EXPLORATEUR WINDOWS...1 INTRODUCTION...2 LANCEMENT DE L'EXPLORATEUR WINDOWS...3 PRÉSENTATION PHYSIQUE...3 RECHERCHER... EXPLORATEUR WINDOWS SOMMAIRE EXPLORATEUR WINDOWS...1 INTRODUCTION...2 LANCEMENT DE L'EXPLORATEUR WINDOWS...3 PRÉSENTATION PHYSIQUE...3 RECHERCHER...6 ORGANISATION DE SES DOSSIERS...7 CRÉER UN DOSSIER...7

Plus en détail

Microsoft Dynamics. Installation de Management Reporter for Microsoft Dynamics ERP

Microsoft Dynamics. Installation de Management Reporter for Microsoft Dynamics ERP Microsoft Dynamics Installation de Management Reporter for Microsoft Dynamics ERP Date : mai 2010 Table des matières Introduction... 3 Présentation... 3 Configuration requise... 3 Installation de Management

Plus en détail

Chapitre 4 La base de données

Chapitre 4 La base de données Chapitre 4 La base de données La Base de données INTRODUCTION 4 La Base de données INTRODUCTION Vectorworks permet de lier les objets du dessin à des formats de base de données (BDD), c'est-à-dire d'associer

Plus en détail

Le Sphinx Utilisation du script d'enregistrement

Le Sphinx Utilisation du script d'enregistrement Le Sphinx Développement Le Sphinx Utilisation du script d'enregistrement Parc Altaïs Tel. : 04 50 69 82 98 74650 Chavanod contact@lesphinx-developpement.fr Il est possible de mettre un formulaire sur son

Plus en détail

LANDPARK HELPDESK GUIDE DE PRISE EN MAIN (VERSION 3.9.2)

LANDPARK HELPDESK GUIDE DE PRISE EN MAIN (VERSION 3.9.2) LANDPARK HELPDESK GUIDE DE PRISE EN MAIN (VERSION 3.9.2) Avril 2014 Installation de l application Pré-requis (page 2) Mise en place de la base de données Base de données SQL Express (page 2) Base de données

Plus en détail

Module 13 : Mise en œuvre des serveurs Microsoft DNS

Module 13 : Mise en œuvre des serveurs Microsoft DNS Module 13 : Mise en œuvre des serveurs Microsoft DNS 0RGXOH#46#=#0LVH#HQ#±XYUH#GHV#VHUYHXUV#0LFURVRIW#'16# # 5

Plus en détail

Le Guide de marquage des Podcasts

Le Guide de marquage des Podcasts Le Guide de marquage des Podcasts Médiamétrie-eStat Buropolis, Bât 3 1240, route des Dolines Sophia Antipolis 06560 Valbonne Tél : 04 92 38 38 20 Fax : 04 92 96 91 25 E-mail : serviceclient@mediametrie-estat.com

Plus en détail

ipra*cool v 1.08 guide de l utilisateur ipra*cool v.1-08 Guide de l'utilisateur ipra*cool v 1.08 1

ipra*cool v 1.08 guide de l utilisateur ipra*cool v.1-08 Guide de l'utilisateur ipra*cool v 1.08 1 ipra*cool v.1-08 Guide de l'utilisateur ipra*cool v 1.08 1 Sommaire 1 ipra*cool en bref 2 Démarrage d' ipra*cool 2.1 Initialisation du logiciel ipra*cool ( sur MOBILE et PC) 2.1.1 Vérification des connexions

Plus en détail

Gestion d une école. FABRE Maxime FOUCHE Alexis LEPOT Florian

Gestion d une école. FABRE Maxime FOUCHE Alexis LEPOT Florian Gestion d une école FABRE Maxime 2015 Sommaire Introduction... 2 I. Présentation du projet... 3 1- Lancement de l application... 3 Fonctionnalités réalisées... 4 A. Le serveur... 4 1 - Le réseau... 4 2

Plus en détail

GetSimple 3. Le guide complet pour créer des sites web. GetSimple 3 - Le guide complet pour créer des sites web. GetSimple 3 26,50.

GetSimple 3. Le guide complet pour créer des sites web. GetSimple 3 - Le guide complet pour créer des sites web. GetSimple 3 26,50. Le guide complet pour créer sites web Vous verrez ensuite comment gérer les pages qui constituent la structure du site : créer les pages, les paramétrer pour la publication, les modifier, les supprimer

Plus en détail

Cours Administration BD

Cours Administration BD Faculté des Sciences de Gabès Cours Administration BD Chapitre 2 : Architecture Oracle Faîçal Felhi felhi_fayssal@yahoo.fr 1 Processus serveur 1 Mémoire PGA Architecture SGBD Oracle Processus serveur 2

Plus en détail