Dernières corrections
This commit is contained in:
parent
8500eb716e
commit
e9b5718b90
|
|
@ -21,7 +21,7 @@ Rapide rappel sur l'UML :
|
|||
| - Attr1<br/>-Attr2 | Données : ce qu'il est |
|
||||
| +Méthode1<br/>+Méthode2 | Traitement : ce qu'il sait faire |
|
||||
|
||||
Signe - : privé
|
||||
Signe - : privé
|
||||
Signe + : Public
|
||||
|
||||
Pour symboliser l'héritage, on fait une flèche de l'enfant vers le parent.
|
||||
|
|
@ -30,13 +30,13 @@ Pour symboliser l'héritage, on fait une flèche de l'enfant vers le parent.
|
|||
|
||||
## Présentation
|
||||
|
||||
Architecture (client/serveur, mais on s'en doutait) crée par Sun. C'est un package : ensemble de librairies.
|
||||
RMI pour Remote Method Invocation
|
||||
Centralise un service sur un serveur, les clients s'y connectent pour l'obtenir (on parle plutôt de données brutes).
|
||||
Les clients viennent se connecter à un objet mis à disposition par le serveur, pour obtenir un service.
|
||||
Architecture (client/serveur, mais on s'en doutait) crée par Sun. C'est un package : ensemble de librairies.
|
||||
RMI pour Remote Method Invocation
|
||||
Centralise un service sur un serveur, les clients s'y connectent pour l'obtenir (on parle plutôt de données brutes).
|
||||
Les clients viennent se connecter à un objet mis à disposition par le serveur, pour obtenir un service.
|
||||
|
||||
On a besoin du jdk pour l'exploiter.
|
||||
C'est basé sur RPC : Remote Procedure Call (Accès à une procédure à distance...)
|
||||
On a besoin du jdk pour l'exploiter.
|
||||
C'est basé sur RPC : Remote Procedure Call (Accès à une procédure à distance...)
|
||||
On a besoin du même langage et de la même version sur le client ET le serveur.
|
||||
|
||||
## Structure
|
||||
|
|
@ -70,7 +70,7 @@ Puis la classe qui implémente l'interface
|
|||
|
||||
## Conclusion
|
||||
|
||||
RMI : client/serveur en java. C'est un peu vieux mais ça permet de comprendre comment ça fonctionne.
|
||||
RMI : client/serveur en java. C'est un peu vieux mais ça permet de comprendre comment ça fonctionne.
|
||||
Les autres architectures qu'on va voir ensuite sont globalement basées sur la même philosophie.
|
||||
|
||||
Se concentrer sur la communication plus que sur le traitement.
|
||||
|
|
@ -81,7 +81,7 @@ Même philosophie que RMI
|
|||
|
||||
Architecture d'objets distribués (voir pdf) => architecture globale.
|
||||
|
||||
Le principe de fonctionnement est celui de RMI : client /serveur - appelant / appelé .
|
||||
Le principe de fonctionnement est celui de RMI : client /serveur - appelant / appelé.
|
||||
L'objectif est de pouvoir assurer cette communication, comme pour RMI
|
||||
|
||||
## Architecture
|
||||
|
|
@ -98,7 +98,7 @@ On a aussi un daemon (daemon ORB = orb ), qui a le même fonctionnement qu'aille
|
|||
|
||||
### IDL
|
||||
|
||||
Il y a toujours besoin d'une interface qui permet de savoir tout ce qu'on peut implémenter. Ici c'est IDL : un fichier texte dans un langage particulier qui implémente l'interface. Ce fichier est partagé par le client et le serveur.
|
||||
Il y a toujours besoin d'une interface qui permet de savoir tout ce qu'on peut implémenter. Ici c'est IDL : un fichier texte dans un langage particulier qui implémente l'interface. Ce fichier est partagé par le client et le serveur.
|
||||
À partir de IDL, il y a une projection pour implémenter l'interface, chacun à sa façon selon s'il s'agit du client ou du serveur. À l'issue de cette projection, IDL se décompose en 6 fichiers.
|
||||
|
||||
On doit définir un module pour chaque "élément" (à préciser), on peut pas en envoyer seuls.
|
||||
|
|
@ -138,9 +138,11 @@ Voir TP Banque
|
|||
|
||||
# JEE
|
||||
|
||||
Ressource utiles : https://openclassrooms.com/courses/creez-votre-application-web-avec-java-ee/la-persistance-des-donnees-avec-jpa
|
||||
|
||||
## Introduction
|
||||
|
||||
JEE est un serveur d'application (Apache TomCat) non pas un simple chef d'orchestre
|
||||
JEE est un serveur d'application (Apache TomCat) non pas un simple chef d'orchestre
|
||||
On va se concentrer sur la partie EJB.
|
||||
|
||||
JEE est une architecture, pas un langage. C'est du design pattern, une manière de développer et de penser les choses (le langage rest du java)
|
||||
|
|
@ -163,13 +165,13 @@ On a deux types de session Bean :
|
|||
|
||||
- Stateless (sans état)
|
||||
|
||||
Qu'est ce que ça veut dire ? >> Si le client se connecte à notre logiciel, est-ce qu'il a une version du catalogue (stateful) ou accès au seul et unique catalogue, unique pour tous (stateless) ?
|
||||
Qu'est ce que ça veut dire ? >> Si le client se connecte à notre logiciel, est-ce qu'il a une version du catalogue (stateful) ou accès au seul et unique catalogue, unique pour tous (stateless) ?
|
||||
En gros la version avec état instancie les ressources là ou la sans état agit sur une entité commune et partagée.
|
||||
|
||||
### Entity Bean
|
||||
|
||||
C'est la couche persistance et celle qui va communiquer avec la base de données. On ne fait plus de SQL, on passe par la couche persistance (ORM)
|
||||
On va utiliser JPA (qu'on peut considérer comme une API orm).
|
||||
C'est la couche persistance et celle qui va communiquer avec la base de données. On ne fait plus de SQL, on passe par la couche persistance (ORM)
|
||||
On va utiliser JPA (qu'on peut considérer comme une API orm).
|
||||
Chaque entité sera une table en bdd
|
||||
|
||||
## Méthode de travail
|
||||
|
|
@ -182,7 +184,7 @@ Les annotations s'écrivent avec un "@" devant . Ça permet de définir les truc
|
|||
|
||||
### SessionBean
|
||||
|
||||
Chaque SessionBean doit définir deux interfaces et une classe
|
||||
Chaque SessionBean doit définir deux interfaces et une classe
|
||||
Les deux interfaces sont *remote* et *locale*. En général, la locale hérite de la remote. On a ensuite une classe qui implémente les deux interfaces à la fois.
|
||||
|
||||
Déclarer une interface :
|
||||
|
|
@ -207,19 +209,18 @@ public class Calc implements ICalc {
|
|||
....
|
||||
...
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
## TP
|
||||
|
||||
New > Project > enterprise application project
|
||||
choisir un nom (ne pas mettre ejp ça fait planter eclipse)
|
||||
Next (on est en train de créer une appli avec les différentes couches qu'on peut avoir dans le serveur)
|
||||
New module > on sélectionne les couches qui nous intéressent (ici tout sauf connector)
|
||||
New > Project > enterprise application project
|
||||
choisir un nom (ne pas mettre ejp ça fait planter eclipse)
|
||||
Next (on est en train de créer une appli avec les différentes couches qu'on peut avoir dans le serveur)
|
||||
New module > on sélectionne les couches qui nous intéressent (ici tout sauf connector)
|
||||
Puis finish deux fois.
|
||||
|
||||
Ca crée automatiquement 4 projets : le principal et les couches.
|
||||
|
||||
Dans Projet EJB, clic droit > New > SessionBean. Mettre un nom de package.
|
||||
|
||||
Il est possible de résumer ce TP comme un des plus mal expliqués de l'année (derrière le dev mobile quand même). Rien ne marchait, explications uniquement pour le premier rang, compréhension 0.
|
||||
Il est possible de résumer ce TP comme un des plus mal expliqués de l'année (derrière le dev mobile quand même). Rien ne marchait, explications uniquement pour le premier rang, compréhension 0.
|
||||
|
|
|
|||
Loading…
Reference in a new issue