6 Création du squelette de l`interface utilisateur

Une architecture distribuée 3-tiers transactionnelle sous COM+
Patrick Smacchia 2002
1/36
TP: DCOM/COM+
Une architecture distribuée 3-tiers transactionnelle
Patrick Smacchia 2002
1 Définitions.............................................................................................................. 2
2 Objectifs du TP ...................................................................................................... 3
3 Technologies à utiliser ........................................................................................... 3
4 Création de la base de données .............................................................................. 4
5 Création du DSN (Data Source Name) .................................................................. 6
6 Création du squelette de l’interface utilisateur ...................................................... 8
6.1 Création du projet C++ de l’interface utilisateur ........................................... 8
6.2 Edition du dialogue de l’interface utilisateur ................................................. 9
6.3 Méthodes et Attributs du dialogue interface utilisateur ............................... 10
7 Création du squelette du serveur .......................................................................... 12
7.1 Création du projet C++ du serveur .............................................................. 12
7.2 Création de l’objet COM CompteObj avec le wizard ATL ......................... 13
7.3 Analyse du fichier idl ................................................................................... 15
7.4 Définition du type de transaction supporté .................................................. 15
7.5 Analyse de la Class C++ de l’objet COM ComptObj .................................. 16
7.6 Compilation et Enregistrement des objets COM ......................................... 17
8 Remplissage des fonctions du serveur ................................................................. 18
8.1 Introduction à ADO (ActiveX Data Object) ................................................ 18
8.2 Import de la librairie de type ADO .............................................................. 18
8.3 Ajout d’une fonction pour ouvrir une connexion avec la DB ...................... 19
8.4 Ajout de fonctions pour manipuler des long signés avec ADO ................... 20
8.5 Le code de la fonction Ajoutez() ................................................................. 21
8.6 Le code de la fonction Fermez() .................................................................. 22
8.7 Le code de la fonction Consultez() .............................................................. 23
8.8 Le code de la fonction Transfererez() .......................................................... 24
9 Remplissage des fonctions de l’interface utilisateur ............................................ 26
9.1 Appel a CoInitialize() .................................................................................. 26
9.2 Import de la librairie de type de CompteServeur ......................................... 26
9.3 Macro pour les ClassID ............................................................................... 26
9.4 Le code de la fonction OnButtonAjoute() : ................................................. 27
9.5 Le code de la fonction OnButtonFerme() : .................................................. 27
9.6 Le code de la fonction OnButtonConsulte() : .............................................. 28
9.7 Le code de la fonction OnButtonTransfere() ............................................... 28
10 Faire de CompteServeur une COM+ Application transactionnelle ................. 29
10.1 Définitions d’un snap-in .............................................................................. 29
10.2 Ouverture du snap-in Components Services ................................................ 29
10.3 Ajout d’une nouvelle application COM+ .................................................... 31
10.4 Ajout de l’objet COM CompteObj dans notre COM+Application .............. 33
10.5 Vérification du mode transactionnel supporté ............................................. 34
11 Exécution du TP ............................................................................................... 35
11.1 Déboguer un objet COM+ ........................................................................... 35
12 Bibliographie.................................................................................................... 36

Une architecture distribuée 3-tiers transactionnelle sous COM+
Patrick Smacchia 2002
2/36
1 Définitions
 Architecture distribuée : Un logiciel est dit à ‘Architecture distribuée’ s’il est formé de
plusieurs unités exécutables (appelés aussi composants) (.exe .dll sous NT) qui peuvent
éventuellement être exécutées sur plusieurs machines en communiquant entre elles.
 3-tiers : Une architecture distribuée est dite ‘3-tiers’ si elle est constituée des trois composants
suivant :
 L’interface utilisateur est utilisée pour manipuler des données. En général plusieurs
instances de ce composant tournent sur plusieurs machines différentes pour
permettre à plusieurs utilisateurs de travailler en même temps. Ce composant peut,
par exemple, se présenter sous la forme d’une page web (ASP) ou d’un exécutable
ou sous d’autres formes.
 Le serveur est utilisé pour :
o fournir les données aux utilisateurs
o enregistrer les modifications sur les données faites par les utilisateurs
o faire des opérations sur les données (business rule en anglais)
o garantir l’intégrité des données (peux être aussi gérer entièrement ou
partiellement par la base donnée)
o gérer la sécurité pour l’accès aux données (peux être aussi gérer
entièrement ou partiellement par la base donnée)
Plusieurs instances du composant serveur peuvent éventuellement être exécutées sur
plusieurs machines en même temps, pour répartir la charge de calcul sur plusieurs
machines. Dans ce cas il y a un composant entre l’interface utilisateur et le serveur
pour répartir les appels des utilisateurs sur les machines. On appelle cette étape le
‘load balancing’ (balance la plus équitable possible entre les machines pour répartir
la charge).
La propriété centrale d’un serveur et sa ‘scalabilité’ (traduction non officielle du
mot anglais scalable). On dit d’une application qu’elle est scalable, si, lorsque vous
ajoutez du hardware pour l’exécuter (processeur, RAM, PCs etc) vous obtenez un
gain de performance commensurable à la quantité de hardware ajoutée. En pratique,
on observe que l’ajout de hardware pour exécuter une application ne provoque pas
forcément un gain de performance. En effet, de nombreux goulets d’étranglement
subsistent toujours à différents niveaux (locking des données, middleware…). Seule
l’architecture de l’application peut minimiser les effets néfastes de ces goulets
d’étranglement.
 La base de données est utilisée pour stocker les données. En général ce composant
est codé par une autre entreprise (SQL server/Microsoft, Oracle…). En effet
beaucoup de services sont requis pour manipuler efficacement et de manière sure des
données (transaction, sécurité, réplication, répartition du stockage sur plusieurs
disque durs, support du langage SQL, changement de version…). Néanmoins il
arrive que la base de données soit propriétaire pour des raisons de performance ou
de compatibilité ascendante.
On appelle aussi ce type d’architecture une architecture client/serveur. Dans ce cas le
serveur représente l’amalgame serveur/base de données.
 transactionnelle : Une succession d’opérations sur des données est dite ‘transactionnelle’, si à
la fin de ces modifications tous les changement sont validés (commit), ou aucun des
changement n’est validé (roll back). En général, le milieu transactionnel n’a (heureusement)
pas à être codé. Le développeur utilise une API d’un milieu transactionnel existant
(ADO/MTS/COM+ chez Microsoft…). La théorie nous dit que quatre propriétés doivent être
supportées par un milieu transactionnel (les propriétés ACID) :
Atomicity : Toutes les actions s’effectuent ou aucune.
Consistency : Aucune action ne viole aucune loi d’intégrité des données.
Isolation : Les transactions s’effectuent d’une manière isolée.
Durable : Les résultats sont stockés de manière permanente.
On remarque qu’une transaction peut s’effectuer sur plusieurs serveurs, et sur plusieurs bases
de données différentes. (Exemple : Débit d’un compte de la banque X pour créditer un compte
de la banque Y). Toutes ces contraintes font que la théorie des transactions distribuées est très
compliquée.
Interface Utilisateur
Serveur
Base de données

Une architecture distribuée 3-tiers transactionnelle sous COM+
Patrick Smacchia 2002
3/36
2 Objectifs du TP
 Créer une architecture distribuée 3-tiers transactionnelle sur Windows 2000.
 Le logiciel développé sera de type logiciel bancaire/ gestion de comptes.
 Un compte sera indexé par un numéro et aura une somme positive ou nulle.
 Les opérations possibles à partir de l’interface utilisateur seront :
 Ouvrir un compte avec une somme de départ.
 Consulter un compte.
 Fermer un compte.
 Transférer une somme d’un compte à un autre.
 Concrètement on code :
 L’interface, qui permet :
i. d’entrer les paramètres des 4 opérations bancaires.
ii. d’appeler les 4 fonctions du serveur (correspondantes aux 4 opérations bancaires)
iii. de visualiser les résultats.
L’interface se présente sous la forme d’un .exe.
 Le serveur qui est un composant COM+. Il a une interface qui présentes les 4 fonctions
correspondantes aux 4 opérations bancaires. Le code compilé du serveur est stocké dans un dll.
3 Technologies à utiliser
VC++ Le client et le serveur seront tous les deux codés sous la forme d’un projet Visual C++.
DCOM Les clients communiqueront avec le serveur en utilisant la technologie Distributed
Component Object Model.
COM+ Le milieu transactionnel sera COM+. En fait avant Windows 2000 (NT), un service spécial
était offert par Microsoft pour gérer des transactions. C’était MTS (Microsoft Transaction
Server). Depuis MTS à été intégré à COM+. Concrètement il faudra utiliser une API Microsoft
dans notre code, et utiliser le snap-in Component Services pour vérifier et/ou modifier les
propriétés transactionnelles de notre serveur.
SQL Server Notre base de données sera stockée dans SQL server. C’est un produit Microsoft qui permet
de gérer les base de données au moyen du langage SQL.
ADO Pour communiquer avec une base de données, Microsoft à développé un ensemble (une
collection) d’objet COM appelé ADO (ActiveX Data Object). Ces composants s’appuient sur
une couche appelée ODBC (Open Database Connectivity) qui permet de communiquer à
partir d’une API avec différentes implémentation de bases de données (SQL server, Oracle…).

Une architecture distribuée 3-tiers transactionnelle sous COM+
Patrick Smacchia 2002
4/36
4 Création de la base de données
Nous allons créer notre base de données au moyen des 2 scripts en langage SQL suivant :
Script1:
CREATE DATABASE TP_DCOM
GO
Script2:
CREATE TABLE [dbo].[COMPTES] (
[ID] [int] IDENTITY (1, 1) NOT NULL,
[Somme] [int] NOT NULL)
GO
La base de données s’appelle TP_DCOM. Elle contient une seule table COMPTES.
La table COMPTES est constituée de 2 champs :
Le champ ID : C’est le numéro du compte.
Le mot clé IDENTITY nous apprend que les éléments de cette colonne sont tous différents.
Ainsi on identifiera une ligne de cette table par ce numéro. C’est donc la clé primaire de notre
table. On aurait pu renforcer ceci en utilisant la syntaxe PRIMARY KEY du langage SQL.
SQL server calcule automatiquement ce nouveau numéro lorsque l’on insère une
nouvelle ligne.
L’algorithme utilisé par SQL server est le suivant.
Premier numéro de compte :1 (premier paramètre après IDENTITY)
Incrémentation du numéro de compte lorsque l’on ajoute un élément : 1 (deuxième paramètre
apres IDENTITY)
Naturellement pour effectuer cet algorithme SQL server stocke quelque part le numéro du
dernier compte, mais ceci est complètement masqué pour l’utilisateur.
Le type de ce champs est ‘int’. En SQL server cela signifie que c’est un entier signé sur 4
bytes. Cela signifie que l’on a potentiellement un peu plus de 2 milliards de numéros de
compte différents possible.
Le champ Somme : C’est encore un champ de type ‘int‘ mais ce n’est pas une clé primaire. En effet il n’y a pas
d’objection à ce que 2 comptes différents aient la même somme. Une de nos business rule est
que l’on autorise que les valeurs positives ou nulles.
Le mot clé NOT NULL dans la définition d’un champ signifie que ce champ est obligatoirement initialisé avec une
valeur correcte du type du champ. En effet SQL server autorise de ne pas initialiser certains champs dans une
ligne.
Lancer l’outil : MenuDémarrer/Programmes/Microsoft SQL server 7.0/Query Analyzer
Choisir avec quelle machine on veut travailler, sous quel utilisateur SQL server. (voir lors du TP)
Taper le script1 pour créer la base de données TP_DCOM, puis le lancer avec le bouton ► vert.

Une architecture distribuée 3-tiers transactionnelle sous COM+
Patrick Smacchia 2002
5/36
Dans la Combo Box DB : choisir la base de données TP_DCOM.
Taper le script2 pour créer la table COMPTES, puis le lancer avec le bouton ► vert.