Cours les acteurs d’une application J2EE, tutoriel & guide de travaux pratiques langage Java en pdf.

Les acteurs d’une application J2EE

La réalisation d’une application basée sur l’architecture J2EE fait appel à différents types de compétences que l’on trouve rarement chez une même personne car cela va de la conception jusqu’à la supervision de l’application en passant par le développement et le déploiement. Afin de pouvoir maîtriser ce processus J2EE adopte l’approche des partages des responsabilités.
Plus spécifiquement pour les EJB, cette approche définit plusieurs niveaux de responsabilité :
• Le fournisseur des EJB : c’est l’acteur qui fournit des composants métiers réutilisables soit par l’achat à un fournisseur de composants, soit par développement interne ;
• L’assembleur d’applications : l’acteur qui est capable de construire une application à partir d’EJB existants ;
• Le déployeur : l’acteur qui récupère l’application et s’occupe de son déploiement dans un serveur d’applications ;
• L’administrateur : l’acteur qui contrôle le fonctionnement du serveur d’application et assure la supervision des applications ;
• Le fournisseur de conteneur : l’éditeur qui commercialise un conteneur web ou un conteneur EJB ; cet éditeur commercialise souvent un serveur d’application incluant ces conteneurs ;
• Le fournisseur de serveur : c’est l’éditeur qui commercialise un serveur d’application (BEA, IBM etc…)

J2EE en détail

Architecture du JDK J2EE
J2EE décrit l’architecture d’un standard pour les serveurs d’application. Nous allons étudier plus précisément les composants, les dépendances et les protocoles utilisés.
Schéma des relations entre composants et « tiers » dans l’architecture J2EE :
Les différents rectangles définissent les conteneurs (de l’environnement d’exécution J2EE) qui fournissent les services pour les différents composants (représenter par les rectangles dans les rectangles). L’ensemble des composants sera expliqué dans le chapitre suivant.
Les flèches représentent les types d’accès que le type d’application peut avoir avec les autres applications distantes. Par exemple, l’application client peut se connecter au « Web Container » par l’intermédiaire des JSP / Servlet, elle peut également se connecter à « EJB Container » …
Voici à présent le schéma de l’interopérabilité entre la plateforme J2EE et les autres programmes (les différents protocoles utilisés).
Ce schéma est très important dans le domaine de l’interopérabilité entre différentes applications. Il fournit les informations concernant les protocoles utilisés pour chacune des connexions distantes possibles. Par exemple, « Web Container » fournit des accès via HTTP / SSL ou SOAP ; « EJB Container » fournit des accès HTTP / IIOP (RMI : Internet Inter-Orb Protocol) / SSL …
Nous pouvons alors penser qu’un client en C#, par exemple, peut se connecter sur un EJB en mode HTTP (dans l’idéal) ou via le protocole IIOP (plus répandu).
Les différents outils de « bas niveau »
Nous venons de voir (très succinctement) l’architecture globale de la plateforme J2EE. Nous allons maintenant présenter les différents outils.
Il existe 3 grands types d’outils :
• Composants
• Services d’infrastructures
• Services de communications
Composants
On distingue, en général, 2 catégories de composants :
• Web
• Métiers
Web
Il s’agit de la partie présentation (interface de l’utilisateur et les traitements).
a. JSP
Les JSP (Java Server Page) sont les pages servant à générer l’ensemble du code HTML de l’interface utilisateur. On y intègre aussi bien du code HTML que des scriplet Java (code java) ou encore des balises personnalisées (tag-lib).
Cette technologie est donc dédiée à la génération de HTML et non au traitement de la requête de l’utilisateur. On l’appelle généralement : Vue.
b. Servlet
Une Servlet est une classe Java qui permet de traiter une requête venant d’un client. Cette technologie doit s’occuper de traiter les données envoyées par l’utilisateur et choisir la Vue à retourner à celui-ci.
On appelle cette partie : Contrôleur. En général, la classe Java ne doit quasiment pas générer de code HTML (sauf dans certains cas précis).
Métier – EJB (Entreprise JavaBean)
Il s’agit de composants spécifiques chargés des traitements des données propres à un secteur d’activité (on parle de logique métier ou de logique applicative) et de l’interfaçage avec les bases de données.
On parle de la partie : Modèle.
Services d’infrastructures
JDBC – Java Database Connectivity C’est une API d’accès aux bases de données.
JNDI
C’une API d’accès aux services de nommage et aux annuaires d’entreprises tels que DNS, NIS, LDAP, etc.
JTA / JTS – Java Transaction Api / Java Transaction Services C’est un API définissant des interfaces standard avec un gestionnaire de transactions.
 JCA (J2EE Connector Architecture)
C’est une API de connexion au système d’information de l’entreprise, notamment aux systèmes dits «Legacy» tels que les ERP.
JMX (Java Management eXtension)
Cette API fournit des extensions permettant de développer des applications web de supervision d’applications.
Services de communications
JAAS (Java Authentification and Authorization Service) C’est une API de gestion de l’authentification et des droits d’accès.
RMI (Remote Method Invocation) C’est une API permettant la communication synchrone entre objets.
 Web services
Les Web services permettent de « partager » un ensemble de méthodes qui pourront être appelées à distance. Cette technologie utilise XML, ce qui permet d’être utilisée par n’importe quel langage et n’importe quelle plateforme.
JMS (Java Message Service) Cette API fournit des fonctionnalités de communication asynchrone (appelées MOM pour Middleware Object Message) entre applications.
JavaMail C’est une API permettant l’envoi de courrier électronique.
Implémentation de J2EE : les serveurs d’application
Il est avant tout indispensable de définir clairement ce qu’est un serveur d’application. En effet, une confusion règne dans les esprits quant à la notion de serveur d’application. Cette confusion a été introduite en grande partie par les éditeurs de serveurs d’application J2EE (Java2 Entreprise Edition) afin de s’approprier ce marché. La notion de serveur d’application a en effet été mélangée avec celle de serveur d’objet qui n’a absolument rien à voir.
Qu’est ce qu’un serveur d’application ?
Le serveur d’application est l’environnement d’exécution des applications côté serveur. Il prend en charge l’ensemble des fonctionnalités qui permettent à N clients d’utiliser une même application :
• Gestion de la session utilisateur : N clients utilisant une même instance d’application sur le serveur, il est nécessaire que le serveur d’application puisse conserver des contextes propres à chaque utilisateur (par exemple, un panier de commandes). La plupart des serveurs d’application génèrent un identifiant unique pour chaque nouveau client et transmettent cet identifiant lors de chaque échange HTTP par URL longs, variables cachées ou cookies.
• Gestion des montées en charge et reprise sur incident : Afin de gérer toujours plus d’utilisateurs, le serveur d’application doit pouvoir se déployer sur plusieurs machines et éventuellement offrir des possibilités de reprise sur incident (même si dans la grande majorité des cas, on se contente d’une gestion des montées en charge au niveau réseau – boîtier de répartition, DNS round-robin, reverse proxy …).
• Ouverture sur de multiples sources de données : C’est le serveur d’application qui rend accessible les données des applications du système d’information. Il doit donc pouvoir accéder à de nombreuses sources de données. On s’attend également à ce qu’il fournisse des mécanismes performants comme le pooling de connexion base de données.
• ……