| Témoignage |
 Écrivez à AILES ! |
 Retour vers programmation |
Retour vers les questions Architecture |
Retour vers les questions Type vs. Instance |
|
Lorsque deux applications doivent communiquer entre elles, comment se considèrent-elles : comme deux types ou deux instances ? Comme deux "types" s'échangeant des messages au travers de services ? Comme deux "instances" s'échangeant des objets au travers de messages ? Dans les architecture "orientées-service" (type) vs. "orientées-objet" (instance), on a vite fait de revenir à ses petites habitude de programmation procédurale ou objet. Et là, attention danger! |
Type vs. Instance : Domaine Architecturale :
Ces notions interviennent dans le monde de l'architecture informatique en tant que pattern de comportement. Il ne s'agit donc pas d'une problématique métier ou fonctionnelle, et l'on ne parle pas ici d'une technique bien identifiée (comme des EJB ou des IDL CORBA).
Il s'agit donc d'une problématique applicative, qui s'inscrit dans l'Architecture Applicative et qui doit permettre de supporter des composants fonctionnels défini dans l'Architecture Fonctionnelle.
Type vs. Instance : Différence majeure
Comme le rappelle [msdn], la principale différence réside dans l'état associé au composant architecturale.
Type
Dans une architecture d'un style à base de type, on trouvera un manager de type, qui gère les état des différents composants, chaque composant n'étant qu'un "type de donnée" (du genre des abstract data type).
Cela permet de construire un système de bas vers le haut, en partant de composants au comportement simple et déterministe (le composant est appelé, rempli sa fonction et retourne un résultat sans mémoriser le moindre état interne).
On s'adresse à un type "manager" qui fournit des services afin de modifier une ou plusieurs instances de ce type. Celles-ci ne sont donc pas directement accessible via le réseau.
Instance
Dans une architecture d'un style à base d'instance, chaque composant gère son propre état et devient de fait une instance conceptuelle : il modélise un concept comme le fait un objet, d'où l'aspect "orienté-objet" d'une telle architecture.
La conséquence de cette autonomie conceptuelle, c'est que l'on peut vouloir, dans le cas d'architectures distribuées, vouloir l'adresser par le réseau (inutile de passer par un manager unique). Cela met une contrainte supplémentaire sur l'infrastructure technique qui supporte une telle architecture.
Type vs. Instance : Problème majeur
Il s'agit bien sûr de la gestion de la transaction, qui doit permettre de conserver un état. Ici, il faut comprendre "transaction" au sens applicatif du terme, et non au sens technique (c'est-à-dire transaction ACID). Une transaction applicative peut s'étendre sur plusieurs application (entre poste client léger jusqu'à un serveur distant), et sur plusieurs couche (entre une base de données, une ou plusieurs application, et une IHM).
Type
Une "transaction" dans ce type de système se traduit par une simple séquence d'appels, ce qui convient bien à des systèmes distribués, asynchrones et peu couplés.
Instance
L'état véhiculé par la transaction n'est pas simplement celui d'une donnée (comme dans le cas d'un type), mais d'une instance "objet", donc d'une donnée et d'un état, ce qui signifie la gestion du dead-lock, commit, rollback, et autres problématiques liées aux transactions.
Type vs. Instance : Danger majeur
Un seul mot : granularité. Si l'on adopte un style et que l'on se trompe de granularité, on peut se trouver dans une situation embarrassante.
Par exemple, supposons qu'un client demande à une application de lui fournir la liste des 1800 chambre d'hôtel.
Type
On peut s'adresser à un manager qui rendra le service voulu en revoyant une collection de données (énorme) correspondants au 1800 chambres. Cela peut fonctionner... sauf si les 2 applications (clients et serveur) sont dans des technologies très différentes, ce qui impose de passer par un langage neutre lors de l'échange de données (typiquement XML) et un traitement de ces données du côté du client pour les traduire... et cela peut entraîner un temps de traitement prohibitif (du XSLT sur un gros fichier XML...)
Instance
1800 instances de "chambre" vont être renvoyées par le serveur, ce qui peut entraîner une surcharge et une occupation excessive du réseau. Le fait de penser "objet" (je demande l'objet "hôtel" sur lequel je demande la liste des chambres") entraîne vite à cette dérive. Dès que l'on est dans un univers distribué, il faut repenser les services que l'on souhaite rendre accessible. Pourquoi vouloir les liste des chambres ? Pour les compter ? Mieux vaut demander à l'objet hôtel le nombre de chambre plutôt que toutes leurs instances!
Décollage ! | Présentation du site web "AILES" |
Infos générales | articles "Informatique"