jdbc

Transcription

jdbc

Les interfaces du middleware
Jdbc/Tx/MOM
Stéphane Frénot -MID - V.0.1.0
Part II - Jdbc-Tx-Mom 1
Répartition d'une application
Conteneur de
présentation
Application de
Présentation
Middleware Implicite
J2EE
Conteneur de traitement
Conteneur
EJB
Application de
Données
Middleware
Explicite
Système
Système
•rmi
d'exploitation
d'exploitation
Données
Middleware
Système
•SGFdistribué
Données
Interfaces
J2EE
Système
d'exploitation
Données
Les interfaces J2EE
• La connexion sur une base de données :
– le jdbc (Java DataBase Connectivity)
• La gestion des transactions
– Tx/XA
• La gestion des messages
– Message-Oriented Middleware
JDBC
Java Databases Connectivity
Objectifs
•
•
•
•
•
Fournir un accès homogène aux SGBDR
Abstraction des SGBDR cibles
Requêtes SQL
Simple à mettre en oeuvre
Core API (1.1)
Fonctionnement
• JDBC interagit avec le SGBDR par un driver
• Il existe des drivers pour Oracle, Sybase, Informix, DB2, ...
• 4 types de drivers :
–
–
–
–
1. Bridge ODBC (fourni avec JDBC)
2. Native-API partly-Java driver
3. JDBC-Net all-Java driver
4. Native-protocol all-Java driver
• 1. et 2. nécessite des architectures 3-tiers pour les applets
Drivers JDBC
Client
Application Java
JDBC API
JDBC-ODBC
Bridge
JDBC-Native
Bridge
JDBC-Net
Bridge
(Type 2)
(Type 1)
All Java
JDBC Driver
(Type 4)
(Type 3)
Native API
(C, C++)
ODBC Driver
JDBC NetDriver
SGBDR
Architectures 2-tier et 3-tier
Application
ou
Applet
J
D
B
C
TCP / Protocole propriètaire (SqlNet Oracle)
SGBDR
Architecture 2-tier
Frontend
Applet
J
D
B
C
SGBDR
Architecture 3-tier
Accès aux données
1 Charger le driver
2 Connexion à la base
3 Création d'un statement
4 Exécution de la requête
5 Lecture des résultats
Chargement du driver
• Utiliser la méthode forName de la classe Class :
– Class.forName("sun.jdbc.odbc.JdbcOrdbDriver").newInstance();
– Class.forName("postgres95.pgDriver").newInstance();
Connexion à la base (1/2)
• Accès via un URL qui spécifie :
– l'utilisation de JDBC
– le driver ou le type du SGBDR
– l'identification de la base
• Exemple :
String url="jdbc:odbc:ma_base";
String url="jdbc:pg95:mabase?username=toto:password=titi";
• Ouverture de la connexion :
Connection conn = DriverManager.getConnection(url, user, password);
Création d'un Statement
• 3 types de statement :
– statement
: requêtes simples
: requêtes précompilées
statement : procédures stockées
– prepared statement
– callable
• Création d'un statement :
Statement stmt = conn.createStatement();
Execution d'une requête (1/2)
• 3 types d'executions :
– executeQuery
: pour les requêtes qui retournent un ResultSet
: pour les requêtes INSERT, UPDATE, DELETE,
CREATE TABLE et DROP TABLE
execute : pour quelques cas rares (procédures stockées)
– executeUpdate
–
Execution d'une requête (2/2)
• Execution de la requête :
String myQuery = "SELECT prenom, nom, email " +
"FROM employe " +
"WHERE (nom='Dupont') AND (email IS
NOT NULL) " +
"ORDER BY nom";
ResultSet rs = stmt.executeQuery(myQuery);
Lecture des résultats (1/2)
renvoit un ResultSet
Le RS se parcourt itérativement row par row
Les colonnes sont référencées par leur numéro ou par leur nom
L'accès aux valeurs des colonnes se fait par les méthodes getXXX
() où XXX représente le type de l'objet
Pour les très gros row, on peut utiliser des streams.
• executeQuery()
•
•
•
•
Lecture des résultats (2/2)
java.sql.Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("SELECT a, b, c FROM Table1");
while (rs.next())
{
// print the values for the current row.
int i = rs.getInt("a");
String s = rs.getString("b");
byte b[] = rs.getBytes("c");
System.out.println("ROW = " + i + " " + s + " " + b[0]);
}
Accès aux méta-données
• La méthode getMetaData() permet d'obtenir les méta-données
d'un ResultSet.
• Elle renvoit des ResultSetMetaData.
• On peut connaitre :
–
–
–
–
Le nombre de colonne : getColumnCount()
Le nom d'une colonne : getColumnName(int col)
Le type d'une colonne : getColumnType(int col)
...
Exemple complet :
public class TestJDBC {
public static void main(String[] args) throws Exception {
Class.forName("postgres95.pgDriver");
Connection conn;
conn = DriverManager.getConnection("jdbc:pg95:mabase", "dedieu", "");
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("SELECT * from employe");
while (rs.next()) {
String nom = rs.getString("nom");
String prenom = rs.getString("prenom");
String email = rs.getString("email");
}
}
}
Jbdc / ejb
• Les ejb Entity, sont automatiquement associées
aux tables d'une base de donnée
– Le conteneur d'EJB automatise la persistance sur la
base de données,
– En se reposant sur des appels jdbc
• Insert, Update, Delete, Select
– Le conteneur utilise un driver jdbc type III
La gestion de transactions
Distributed Systems « Concepts and Design »
George Coulouris, Jean Dollimore et Tim Kindberg
http://www.cdk3.net/
Définition : transaction
«Une transaction définit une séquence d'opérations sur un serveur
qui est garantie d'être atomique dans le cas d'un accès
concurrentiel de plusieurs clients et de crash du serveur »
• Les opérations issues des autres clients ne la perturbe pas
• Toutes les opérations sont réalisées ou, il n'y a aucun effet en cas
de panne du serveur
Coordinateur d'une transaction
• Un coordinateur est un objet qui répond à l'interface suivante
– TransID openTransaction( )
– Status closeTransaction(TransID)
• Status = commit | abort
– void abortTransaction(TransID)
• Le client demande au coordinateur l'initialisation d'une
transaction
• A Chaque opération on ajoute un champ d'identification de la
transaction
– void retrait(int val); --> void retrait (TransID, val)
– Cette insertion peut être automatisée par le conteneur !
Cycle de vie des transactions
•
Succès
openTransaction
operation
operation
.
.
operation
Abandon du client
openTransaction
operation
operation
.
.
operation
closeTransaction
abortTransaction
Abandon du serveur
openTransaction
operation
operation
Server aborts
.
Transaction-->
.
operation ERROR
exception au client
Actions en cas de crash du process serveur :
– Le nouveau serveur qui le remplace doit abandonner les transactions en cours,
– et doit récupérer les données des dernières transactions validées (commitées)
– si un client crash, le serveur donne un time-out, et annule toute transaction qui n'est pas complétée dans ce
délai
•
Actions du client en présence de panne du serveur :
– Le client est notifié du crash car son opération part en time-out,
– Si un serveur est remplacé pendant une transaction, les numéros de transaction (TransId) ne sont plus
valables
– ==> Dans tous les cas, le client doit prendre une décision concernant la transaction.
Propriétés d’une transaction
•
•
•
•
ATOMICITE
les opérations d’une transaction seront toutes entièrement exécutées, en cas
de problème avant terminaison, les opérations exécutées seront annulées.
COHERENCE
la transaction est un programme correct qui fait passer la base de données
d’un état cohérent vers un autre état cohérent.
ISOLATION
les résultats intermédiaires d’une transaction (avant terminaison) ne seront
pas accessibles par les autres transactions
DURABILITE
les résultats d’une transaction sont permanents après terminaison et ne
doivent être altérés par aucun type de panne
Transaction : l'exemple de base
Transaction T :
balance=b.getBalance();
// 100
b.setBalance(balance*1.1); // 110
a.widthdraw(balance/10);
// 10
Transaction U :
// 100
b.setBalance(balance*1.1); // 110
c.widthdraw(balance/10);
// 10
• L’exécution en série des transactions consiste à ce que, pour tout couple de transactions,
toutes les opérations de l’une se soient exécutées avant toute opération de l’autre
(performances)
• Une exécution est sérialisable si elle produit les mêmes résultats et les mêmes effets sur les
données que l’exécution en série des mêmes transactions (dépend de l'ordre). La
sérialisabilité d’une exécution concurrente de transactions est le critère habituel de
recherche pour les méthodes de contrôle de concurrence.
• Sinon, on peut constater deux problèmes :
• - Perte de mise à jour, lecture inconsistante
Gestionnaire de transactions: processus partagés
• Sans gestionnaire de transactions
1000
Clients
1000 connexions
+ de 1000 processus
+ de 500 Mo RAM
+ de 10000 fichiers ouverts
Système d’exploitation
sur les genoux
• Avec gestionnaire de transactions
1000
Clients
Gestionnaire
de
transactions
50 connexions partagés
+ de 50 processus
+ de 25 Mo RAM
500 fichiers ouverts
Système
d’exploitation
va mieux
Transaction : « Lost update »
Transaction T :
b.setBalance(balance*1.1);
Transaction T :
Transaction U :
b.setBalance(balance*1.1);
Transaction T :
//100
//100
b.setBalance(balance*1.1); //110
b.setBalance(balance*1.1); //110
// 90
// 90
Transaction : « lectures inconsistantes »
Transaction V :
a.withdraw(100);
b.deposit(100;
Transaction V :
a.withdraw(100);
Transaction W :
aBranch.branchTotal();
Transaction W :
100
total=a.getBalance(); 100
total+=b.getBalance(); 300
total+=c.getBalance();
b.deposit(100);
300
Entrelacement de T et U pour une équivalence
L’accès à B est séquentiel le reste peut s’entrelacer
séquentielle
Transaction T:
balance = b.getBalance()
b.setBalance(balance*1.1)
a.withdraw(balance/10)
Transaction U:
c.withdraw(balance/10)
$200
$220
a.withdraw(balance/10)
$220
$242
c.withdraw(balance/10)
$278
$80
•
Equivalence séquentielle de V et W entrelacés
pourrait entrelacer la première ligne de W et la dernière de V
(RésolutionOn des
lectures inconsistantes)
Transaction V:
a.withdraw(100);
b.deposit(100)
Transaction W:
aBranch.branchTotal()
a.withdraw(100);
$100
b.deposit(100)
$300
total = a.getBalance()
$100
total = total+b.getBalance()
$400
total = total+c.getBalance()
...
•
•
•
Si W est lancé avant ou après V, le problème n’apparaît pas
donc, il n’apparaitra pas pour n'importe quelle exécution séquentielle équivalente
L’exemple est séquentiel, mais ce n’est pas obligatoire
•
Règles de conflits sur les opérations
de lecture/écriture
Operations de
Conflits
Transactions différentes
Raison
Lecture
Lecture Non
read
write
Yes
Car les effets des opérations de lecture / écriture
dépendent de l’ordre des opérations
write
write
Yes
Car les effets des opérations d’écriture / écriture
dépendent de l’ordre des opérations
Car les effets des opérations de lecture sont
indépendant de leur ordre d’exécution
• Opérations en conflit :
• une paire d’opération si leur effet dépend de l’ordre d’exécution
– Pour la lecture : la valeur obtenue, pour l’écriture la valeur écrite
•
Equivalence séquencielle
définie
en terme
Quelles sont leurs
opérations
en conflit ?
d’opérations conflictuelles
• Pour que deux transaction soient “Séquentiellement
équivalentes”, il est nécessaire et suffisant que toutes les paires
d’opérations conflictuelles des deux transactions soient
exécutées dans le même ordre pour tous les objets auxquelles
elles accèdent toutes les deux
T et U accèdent i et j
• Soient deux transactions
– T: x = read(i); write(i, 10); write(j, 20);
– U: y = read(j); write(j, 30); z = read (i);
L’équivalence séquentielle nécessite que, soit :
T accède i avant U et T accède j avant U. ou
U accède i avant T et U accède j avant T
Equivalence séquentielle est le critère pour définir des
protocoles de gestion de la concurrence
•
Entrelacement non séquentiellement équivalent
entre T et U
Transaction T:
x = read(i)
write(i, 10)
write(j, 20)
•
•
•
•
Transaction U:
y = read(j)
write(j, 30)
z = read (i)
Chaque accès à i et j et serialisé l’une par rapport à l’autre mais,
T fait tous ses accès à i avant U
U fait tous ses accès à j avant T
de ce fait l’entrelacement n’est pas séquentiellement équivalent
•
3 méthodes pour contraindre l'équivalence
séquentielle
• Les locks :
– Chaque objet est locké en début de transaction
– Technique la plus classique
• Concurrence optimiste
– On suppose qu'un certain nombre de Tx en
concurrences ne le sont pas vraiment
– La vérification se fait avant le commit
• Ordonnancement par horodatation
– Des dates accompagnent les objets
Récupération sur abandons
• Si une transaction est annulée, le serveur doit garantir que les
autres transactions concurrentes n’en voient pas les effets
• On peut voir deux problèmes :
• ‘dirty reads’
– Une interaction entre une opération de lecture d’une transaction et une
opération précédente d’écriture sur le même objet (par une transaction
qui abandonne entre temps)
– Une transaction qui a validée un ‘dirty read’ n’est pas récupérable
• ‘écriture prématurée’
– interactions entre des opérations d’écriture sur le même objet par
différentes transaction, dont une est abandonnée
• (getBalance est une lecture et setBalance une écriture)
•
Une ‘lecture sale’ quand une Tx est
Quelabandonnée
est le problème ?
Transaction T:
Transaction U:
a.getBalance()
a.setBalance(balance + 10)
a.getBalance()
balance = a.getBalance()
$100
$110
T est abandonnée entre temps.
U lit le total de A (qui a été
positionné par T) puis est validée
balance = a.getBalance()
$110
$130
commit transaction
abort transaction
U vient de faire une ‘lecture sale’Ces opérations sont séquentiellement
équivalentes
• U est validée, elle ne peut plus être abandonnée
•
Récupération de Txs
• Si une transaction (comme U) valide après avoir vu les
effets d’une transaction qui est annulée entre-temps, ce
n’est pas récupérable
Pour récupérer :
La validation est temporisée jusqu’à ce que toutes les
autres transactions dont on a observé l’état ont été validées
càd. U attends que T valide ou abandonne
si T abandonne, U abandonne
Quel est le problème suivant ?
•
Pour la récupération
-- différer les validations
Abandons
en cascade
• Supposons que U temporise sa validation jusqu’à ce que T abandonne
– alors, U doit également abandonner.
– Si d’autre transactions ont vu les effets de U, elles doivent également
être annulées
– etc...
• Cette situation est appellée “annulation en cascade” (cascading aborts)
Pour éviter les annulation en cascade
Les transactions ne sont autorisées à ne lire les objets que des transactions validées
pour cela, chaque opération de lecture doit être différée jusqu’à ce que les autres
transactions qui ont fait une opération d’écriture sur ce même objet soient validées ou
annulées
Càd. U attends de faire le getBalance jusqu’à ce que T valide ou annule
Eviter les annulations en cascade est plus important que la reprise sur pann
•
Ecritures prématurées
écrasement de valeurs non validées
Transaction T:
a.setBalance(105)
a.setBalance(105)
Avant T et U le total
de A est 100 $
$100
$105
Transaction U:
a.setBalance(110)
Exécutions séq.
équivalentes de T et U
Interactions entre opérations d’écritures
quand une transaction est annulée
a.setBalance(110)
$110
Certains gestionnaires de bases de données conservent des
‘images avant’ et les restituent si il y a abandon
càd 100$ est l’image avant l’écriture de T, 105$ est l’image avant l’écriture de U
si U annule on obtient la bonne valeur de 105$
Mais si U valide puis T annule, on obtient 100$ au lieu de 110$
•
Exécutions strictes de transactions
• Soigner les écritures prématurées :
– si un schéma de récupération utilise les ‘images avant’
• les opérations d’écritures sont différées jusqu’à ce que les transactions précédentes qui ont
mis à jour les même objets aient soit validé soit annulé
• Exécutions strictes de transactions
– Pour éviter à la fois les ‘lectures sales’ et les ‘écritures prématurées’
• différer aussi bien les opérations d’écriture et de lecture
– les exécutions de transactions sont appellées strictes si à la fois les lectures et les
écritures sont différées le temps que toutes les autres transactions qui ont écrit l’objet
ont soit validée soit annulée
– L’exécution stricte de transaction reforce le I de ACID
• “Les versions d’essais” (tentative versions) sont utilisées pendant le
processus de la transaction
– espace privé de la transaction en mémoire volatile
•
Nested transactions
T : top-level transaction
T1 = openSubTransaction
T2 = openSubTransaction
T1 :
commit
T2 :
openSubTransaction
openSubTransaction
prov. commit
T11 :
T12 :
openSubTransaction
abort
T21 :
openSubTransaction
prov. commit
prov. commit
prov. commit
T211 :
prov.commit
• Une transaction peut être composée d’autre transactions
– plusieurs transactions peuvent être déclanchées à partir d’une autre
– on a une transaction ‘top-level’ et des sous-transactions qui peuvent
avoir d’autres sous-transactions
•
Transaction Imbriquées
• Pour un parent, une sous-transaction est atomique par
rapport aux pannes et aux accès concurrents
• les transactions au même niveau (T1 et T2) peuvent
s’exécuter concurremment mais les accès aux objets
communs sont sérialisés
• une sous-transaction peut échouer indépendamment de
son parent ou des autres sous-transactions
– Si elle est annulée, son parent décide quoi faire, càd en
déclancher une autre ou abandonner
•
Avantage des transactions imbriquées
(par rapport aux Tx à plat)
• Les sous-transactions peuvent s’exécuter en concurrence avec les
autres sous-transactions du même niveau
– Ceci permet une nouvelle concurrence d’exécution
– Si les sous-transactions s’exécutent sur différents serveurs, elles peuvent
être parallélisées
• càd sur l’exemple du calcul du total des comptes
• il peut être implanté avec une sous-transaction par compte
– Ce peut être fait en parallèle sur plusieurs serveurs
• Une sous-transaction peut être validée ou abandonnée de manière
indépendante
– C’est potentiellement plus robuste
– un parent peut prendre des décision en fonction du résultat
•
Validation de transactions imbriquées
• Une transaction ne peut être validée ou annulée qu’après que ses
filles soient finies
• Une sous-transaction décide de manière autonome si elle valide
provisoirement ou annule. Sa décision d’abandonner est finale
• Quand un parent annule, toutes ses sous-transactions sont
annulées
• Quand une sous-transaction annule, le père décide s’il doit
abandonner ou non.
• Si la transaction ‘top-level’ valide, alors toutes les soustransactions qui ont provisoirement validées peuvent également
valider, à condition qu’aucun de leur ancêtre n’ai abandonné
•
Résumé sur les transactions
• On ne considère les transaction que sur un serveur unique, elles sont :
• atomiques en présence de transactions concurrentes
– Ce qui peut être réalisé par des exécutions séquentiellement équivalentes
• atomiques en présence de crashes du serveur
– Les états commités sont stockés de manière permanente
– Elles reposent sur des exécutions strictes pour les abandons
– Elles reposent sur des versions d’essai pour permettre les validations / abandons
• Les transaction imbriquées sont structurées par des sous-Tx
– Elles permettent l’exécution concurrente de sous-transactions
– Elles permettent une récupération indépendante des sous-Tx
•
Modèle DTP
(Distributed Transaction Processing)
de X/Open (1993)
Application
RM API
Gestionnaire de
ressources
XATMI
TxRPC
CPI-C
TX
Gestionnaire de
transactions
XA
Gestionnaire de
communications
XA+
Principaux gestionnaires de transactions
Produit
Editeur
Plateformes
SGBD
Outils
TUXEDO
Bea
Intel, Risc,...
XA (Oracle)
non-XA
(pas d’isolation,
ni intégrité)
Cobol, C++
L4G SGBD
AGL Windows
(Ingres, NSDK,...)
HP, Hitachi,
NEC, SNI
Stratus, Sun,IBM
Intel
Intel
IBM ES/9000
IBM ES/9000
DPSx000
XA et non-XA
Cobol, C++
Itran Toolkit
ENCINA
Transarc
MTS
OTM
CICS/MVS
IMS/DC
TDS (TP8)
Microsoft
Orbix
IBM
IBM
Bull
XA
XA
DB2
DL/1
Oracle
Cobol
Cobol
Cobol
Pourquoi un gestionnaire de transactions ?
• Assurer une fiabilité dans l’exécution d’applications distribuées
• Augmenter la disponibilité par une meilleure maîtrise des ressources
• Equilibrer dynamiquement les charges de serveurs multiples ou d’un serveur
SMP
• Intégration et pilotage des communications: par messages, appel de
procédures ou files d’attente
• Evolutivité matricielle, par coopération avec d’autres gestionnaires (tm ou
rm) hétérogènes
• Réduction de coûts machine par l’optimisation de l’utilisation du système
d’exploitation
Conteneur de
présentation
Application de
Présentation
J2EE
Conteneur
EJB
Application de
Données
Middleware
Explicite
Système
Système
•rmi
d'exploitation
d'exploitation
Données
Middleware
Système
•SGFdistribué
Interfaces
J2EE
Système
d'exploitation
Données
Données
Les MOM
Message Oriented Middleware
Qu’est ce que la messagerie ?
• Mécanisme permettant de faire communiquer
deux programmes
• Il existe de nombreux systèmes de messagerie
–?
–?
–?
Middleware orienté message
• MOM concerne une infrastructure indépendante
permettant de mettre en œuvre un support de
messagerie
• Les architectures de MOM doivent définir :
–?
–?
–?
• Il existe trois systèmes de messagerie
Architecture orientées MOM
• Les SI construits à base de MOM ont :
• Des possibilités d'échanges de messages vers de multiples
clients à travers des systèmes hétérogènes
• Un potentiel élevé d'accroissement
• Une réduction des risques
• Un temps de développement réduit
• Une maintenance facile
• Standardisation des échanges interprocess
• détails protocolaires, keep-alive, fabrique de messages,
format binaires propriétaires des messages, modes de
livraison...
Avantages des MOM
• Intégration de multiples protocoles et des multiples
plateformes
• Messages définis par les utilisateurs
• GMD : Guaranteed Message Delivery
• Equilibrage de charge
• Tolérance de pannes
• Support pour plateformes hétérogènes
• Gestion et configuration sur interfaces graphiques
Les types de MOM
• Les logiciels de MOM peuvent fonctionner
dans trois catégories (Elles définissent quels
clients reçoivent un message)
– Point-To-Point (PTP)
– Publish-Subsribe(Pub/Sub)
– Request-Reply(RR)
récepteur ?
récepteur ?
message
mom
émetteur
récepteur ?
Le domaine Point à Point
• Mets en relation un client (le producteur) qui
envoie un message vers un autre client (le
receveur)
émetteur
récepteur ?
émetteur
récepteur ?
Queues PTP
• Plusieurs producteurs peuvent placer
les messages pour divers destinataires
dans une queue
récepteur
Queue de distribution
producteur
récepteur
producteur
Gestionnaire de files(Serveur MOM)
récepteur
==> Exemples d'utilisation ?
Le domaine P/S
• Les producteurs de messages (appelés
publishers) génèrent des données pour de
multiples clients (subscribers)
Abonné
Editeur
Abonné
==> Mécanisme similaire ?
Abonné
Sujets de Pub/Sub
• La publication et l'abonnement à un sujet
découple le producteur et le consommateur
récepteur
Le cinéma contemporain
producteur
récepteur
producteur
Gestionnaire de sujets (Serveur MOM)
récepteur
==> Exemple d’utilisation
Le domaine Request/Reply
• Le domaine R/R définit un programme qui
envoie un message et attend une réponse
immédiatement
• Ce domaine modélise :
– l'approche client/serveur
– l'approche des systèmes distribués
• EJB
• CORBA
• DCOM
Que fournit JMS
• JMS est un ensemble d'interfaces (et de leurs
sémantiques associées) qui définissent comment un
client utilise les fonctionnalités offertes par un
système de messagerie
• JMS définit les API :
– du domaine PTP
– du domaine Pub/Sub
• http://java.sun.com/products/jms/index.html
Une application JMS c’est :
•
•
•
•
Des clients JMS
Des clients non JMS
Des messages
Un fournisseur de service de
messagerie
• Des objets administrés standards
– Messages préfabriqués
– Destinataires standards
Client JMS
Client non-JMS
MOM
Implantation JMS
Objets
administrés
standards
Objets Destination et
Usine de connexion
préfabriqués
Les serveurs Mom
•
•
•
•
MQSeries,
TopEnd,
DecMessageQ
WebLogic JMS,
Conteneur de
présentation
Application de
Présentation
J2EE
Conteneur
EJB
Application de
Données
Middleware
Explicite
Système
Système
•rmi
d'exploitation
d'exploitation
Données
Middleware
Système
•SGFdistribué
Données
Interfaces
J2EE
Système
d'exploitation
Données

jdbc

Transcription

Documents pareils

([ Sherlock`s Gestion : Recherche : Détail d`une transaction ])

Rentabiliser le contenu de vos sites web ou vendre des services et

FEATURE FILMS TV FEATURES SHORTS COMMERCIALS

MANON GAURIN

139 000 € - Sun Immobilier

INSPECTION ACADEMIQUE DES BOUCHES DU RHONE

FICHE DE POSTE complète téléchargeable ici - bni

Personnalités - Association

Carte Visa* Prépayée de Poste Canada