Suppression des notes
This commit is contained in:
parent
67e84ac0c0
commit
8500eb716e
|
|
@ -1,41 +0,0 @@
|
||||||
Cours 3
|
|
||||||
========================
|
|
||||||
|
|
||||||
RMI : client/serveur en java. C'est un peu vieux mais ça permet de comprendre comment ça fonctionne. Les autres (suivants) sont globalement basés sur la même philosophie.
|
|
||||||
|
|
||||||
Se concentrer sur la communication plus que sur le traitement.
|
|
||||||
|
|
||||||
|
|
||||||
# CORBA
|
|
||||||
|
|
||||||
Même philosophie que RMI
|
|
||||||
|
|
||||||
Architecture d'objets distribués (voir pdf) => architecture global. Principe de fonctionnement est celui de RMI : client /serveur - appelant / appelé . L'objectif est de pouvoir assurer cette communication, come pour RMI
|
|
||||||
|
|
||||||
Architecture :
|
|
||||||
|
|
||||||
* Notion de client et de serveur
|
|
||||||
* Couche TCP IP
|
|
||||||
|
|
||||||
Chacun fait ce qu'il veut avec les objets. L'idée est que chaque demande se fasse dans un langage générique. On implémente un BUS logiciel (ORB) dans lequel on fait passer demandes. Dedans on a un traducteur qui traduit demande en un format générique et véhicule au serveur qui retraduit. Les adaptateurs qui font la traduction sont les OA
|
|
||||||
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 client et serveur.
|
|
||||||
À partir IDL => projection pour récupérer (implémenter ?) interface, chacun à sa façon selon client ou serveur. IDL se compose de 6 fichiers
|
|
||||||
On a aussi un daemon (daemon ORB = orb ), même fonctionnement qu'ailleurs, en tache de fond il orchestre communications
|
|
||||||
|
|
||||||
|
|
||||||
On doit définir un module pour chaque "élément" (à préciser) on peut pas en envoyer seuls
|
|
||||||
```
|
|
||||||
Module {
|
|
||||||
Interface {
|
|
||||||
Attributs : type nom options;
|
|
||||||
Méthodes : type retour, statut, nom, paramètres type de passage (in ou out ou inout en entré en sortie ou les deux)
|
|
||||||
}
|
|
||||||
}
|
|
||||||
```
|
|
||||||
Tout modification a niveau de l'objet implique une régénération complète : on évite donc !
|
|
||||||
|
|
||||||
Ordre de démarrage :
|
|
||||||
|
|
||||||
* orbd
|
|
||||||
* serveur
|
|
||||||
* client
|
|
||||||
|
|
@ -1,8 +0,0 @@
|
||||||
Cours 4
|
|
||||||
========================
|
|
||||||
|
|
||||||
Ajd TP CORBA
|
|
||||||
Pour juin, TP à faire (seul à priori) sur une archi au choix. Choisir si on prned TP Guillaume est une grosse merde puante ou bien si on fait un exam classique. + exam écrit à la fin dnas tous les cas.
|
|
||||||
|
|
||||||
Rappels sur CORBA
|
|
||||||
|
|
||||||
|
|
@ -1,81 +0,0 @@
|
||||||
Cours 5
|
|
||||||
========================
|
|
||||||
|
|
||||||
Arrivé en retard, y a plein de trucs chelous marqués au tableau c'est flippant
|
|
||||||
|
|
||||||
## JEE
|
|
||||||
|
|
||||||
JEE est un srveur 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 ls choses (le langage rest du java)
|
|
||||||
|
|
||||||
### EJB
|
|
||||||
|
|
||||||
EJB = Java Bean
|
|
||||||
|
|
||||||
Plusieurs formes d'EJB :
|
|
||||||
|
|
||||||
* Session Beand (partie business/traitement)
|
|
||||||
* Entity Bean (partie données)
|
|
||||||
|
|
||||||
#### Session Bean
|
|
||||||
|
|
||||||
Deux types de session Bean :
|
|
||||||
|
|
||||||
* Stateful (avec état)
|
|
||||||
* 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)
|
|
||||||
|
|
||||||
#### Entity Bean
|
|
||||||
|
|
||||||
C'est la couche persistance est celle qui va communiquer avec la base de données. On ne fait plus de SQL, on passe par la couche persistance (ORM)
|
|
||||||
On trouve JPA (en ORM ?).
|
|
||||||
Chaque = une table en bdd (entity, comme dans symfony)
|
|
||||||
|
|
||||||
|
|
||||||
### Méthode travail
|
|
||||||
|
|
||||||
#### Annotation
|
|
||||||
|
|
||||||
Existe depuis version 5
|
|
||||||
|
|
||||||
annotation avec un "@" devant (comme dans symfony). Ca permet de définir les trucs,par exemple sateful :
|
|
||||||
@Stateful
|
|
||||||
|
|
||||||
#### SessionBean
|
|
||||||
|
|
||||||
Chaque SessionBean doit définir deux interfaces et une classe
|
|
||||||
Les deux interfacs 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 :
|
|
||||||
|
|
||||||
@Remote
|
|
||||||
public interface Icalc {
|
|
||||||
public double add ()(double a, double b);
|
|
||||||
...
|
|
||||||
...
|
|
||||||
}
|
|
||||||
|
|
||||||
Pour la classe :
|
|
||||||
|
|
||||||
@Stateful
|
|
||||||
public class Calc implements ICalc {
|
|
||||||
public double add(double a, double b) {
|
|
||||||
return a+b;
|
|
||||||
}
|
|
||||||
....
|
|
||||||
...
|
|
||||||
}
|
|
||||||
|
|
||||||
# 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électionn 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 rpojet EJB, clic droit > New > SessionBean. Mettre un nom d epackage
|
|
||||||
Loading…
Reference in a new issue