COM adresse les quatre problèmes de base liés au composant logiciel qui sont:
– Interopérabilité de base.
– Versioning. L’indépendance de langage.
– Interopérabilité transparente d‟inter-processus.
En plus, COM fournit une architecture à rendement élevé pour répondre aux exigences d’un marché commercial du composant.
2.6.1 Interopérabilité de base
Celle-ci est fournie par l’utilisation de COM des vtables pour définir un standard d’interface binaire pour la méthode d’appelle entre les composants. Les appels entre les composants COM dans le même processus sont seulement une poignée d’instructions de processeur plus lentes qu’un appel de fonction direct standard et pas plus lentes qu’une invocation au moment de la compilation d’objet C++ [MIC 11].
2.6.2 Versioning
Un bon mécanisme de versioning permet à un composant du système d’être mis à jour sans exiger des mises à jour à tous les autres composants dans le système. Le Versioning dans COM est mis en application en utilisant des interfaces et IUnknown:QueryInterface. La conception de COM élimine complètement le besoin des choses comme les dépôts de version ou la gestion centrale des versions des composants [MIC 11].
Quand un module de logiciel est mis à jour, il doit généralement ajouter la nouvelle fonctionnalité, ou améliorer la fonctionnalité existante. Dans COM, on ajoute la nouvelle fonctionnalité au composant COM en ajoutant le support de nouvelles interfaces. Puisque les interfaces existantes ne changent pas, d’autres composants qui se fondent sur ces interfaces continuent à fonctionner. De plus les nouveaux composants qui savent les nouvelles interfaces peuvent utiliser ces interfaces nouvellement exposées [MIC 11]. La combinaison de l’utilisation de fonctionnalité d’interfaces et QueryInterface permet à COM de fournir une architecture dans laquelle les composants peuvent être dynamiquement mis à jour, sans exiger des mises à jour à d’autres composants dépendants [MIC 11].
COM résout le problème de versioning/evolution où la fonctionnalité des objets peut changer indépendamment des clients de cet objet sans rendre les clients existants incompatibles. En d’autres termes, COM définit un système dans lequel les composants continuent à soutenir les interfaces par lesquelles ils ont fourni des services à des clients plus ancien, aussi bien que les nouvelles et les meilleures interfaces de support par lesquelles ils peuvent fournir des services à de plus nouveaux clients. Au temps d’exécution, les vieux et nouveaux clients peuvent sans risque coexister avec un composant COM donné. Il n’y a aucune chance pour des accidents aléatoires, de ce type qui se produit quand une méthode prévue sur un objet simple n’existe pas, ou ses paramètres ont changé.
2.6.3 L’indépendance de Langage
Les composants peuvent être mis en application dans un certain nombre de différents langages de programmation, et utilisés par des clients qui sont écrits en utilisant des langages de programmation complètement différents. Encore, c’est parce que COM, à la différence d’un langage de programmation orientée objet (POO), représente un standard binaire d’objet, pas un standard de code source. Les objets définis dans un langage de POO sont en général, interactive seulement avec d’autres objets définis dans le même langage. Ceci limite nécessairement leur réutilisation.
En même temps, un langage de POO peut être utilisé dans la construction des composants COM, ainsi les deux technologies sont réellement tout à fait complémentaires. COM peut être utilisé pour empaqueter et encapsuler des objets dans des composants pour la réutilisation répandue, même dans des langages de programmation très différents [MIC 11].
2.6.4 Interopérabilité Transparente d’inter-processus
Il serait relativement facile d’adresser le problème de fourniture d’une architecture de composant logiciel si les développeurs de logiciel pourraient supposer que toutes les interactions entre les composants se sont produites dans le même espace de processus. En fait, d’autres modèles proposés font cette prétention de base [MIC 11].
La partie majeure du travail, en définissant un véritable modèle de composant logiciel, suppose de jeter un pont transparent sur les barrières de processus. Dans la conception de COM, on a compris du début que l’interopérabilité se produire à travers les espaces de processus parce que la plupart des applications n’a pas pu être prévu pour être récrit comme des bibliothèques dynamique de lien (DLLs) chargées dans la mémoire partagée.
En outre, en résolvant le problème de l’interopérabilité d’inter-processus, COM résout le problème des composants communiquant d’une manière transparente entre différents ordinateurs à travers un réseau, en utilisant exactement la même interface de programmation utilisée pour des composants communiquant sur le même ordinateur [MIC 11].
La bibliothèque COM est la clef pour fournir l’interopérabilité transparente d‟inter-processus. La bibliothèque COM encapsule tout le travail lié au lancement de composants et au contrôle de la communication entre les composants. [MIC 11]
Elle isole les composants des différences d’endroit. Ceci signifie que les composants COM peuvent interopérer librement avec d’autres composants COM fonctionnant dans le même processus, dans un processus différent, ou à travers le réseau. Le code requis pour mettre en application ou utiliser un composant COM, dans n’importe quel cas, est exactement identique.
Ainsi, quand une nouvelle bibliothèque COM est libérée avec le support de l’interaction d‟inter-réseau, les composants COM existants pourront travailler dans un mode distribué sans exiger les changements, la recompilation, ou la redistribution de code source aux clients.
Page suivante : 2.7 COM et le modèle client/Server
Retour au menu : UTILISATION DES SCRIPTS POUR LE DEVELOPPEMENT DES COMPOSANTS COM ADAPTABLES