COM
L'histoire a commencé en 1993 avec Object Linking and Embedding (OLE 2.0). Le fondement de OLE était Component Object Model (COM), un standard de compatibilité binaire entre objets.A l'époque, ce système procurait de nombreux avantages:
- Un cadre standardisé pour faire interagir des composants logiciels (objets COM) pré-compilés.
- Un cadre standardisé pour intégrer des composants logiciels (objets COM) développés indépendamment.
- La possibilité de développer des composants logiciels (objets COM) dans n'importe quels langages, puis de les faire interagir.
Pratiquement, les OLE ou COM permettent de réaliser trois sortes de copiage plus ou moins sophistiqués:
- Copier un tableau EXCEL et le coller dans un document WORD.
- Copier un tableau EXCEL et le coller avec liaison dans un document WORD, de telle sorte que les valeurs des cellules du tableau EXCEL dans le document WORD soient actualisées en même temps que les valeurs des cellules du tableau dans le fichier EXCEL.
- Copier un tableau EXCEL avec un mini tableur EXCEL et le coller dans un document WORD. Le tableau EXCEL bénéficie ainsi des principales fonctionalités de l'application EXCEL standard, lesquelles permettrons de modifier le tableau dans le document WORD sans faire appèle à l'application EXCEL.
Puis en 1996, Microsoft généralise l'usage de COM avec les technologies DCOM et ActiveX:
- Les Distributed COM (DCOM) sont une extension de la technologie COM qui permettent d'intégrer dans un document un objet stocké sur une autre machine du réseau.
- Les ActiveX sont une extension de la norme COM qui autorise un hébergement dans les navigateurs Internet.
En 1997 apparaitra Microsoft Transaction server (MTS), un composant COM dédié aux transactions distribuées. L'évolution de cette technologie sera terminée en 1998 avec la publication COM+ et son lot de services standardisés tels que: Distributed Transaction Coordinator (DTC), In Memory dataBase (IMDB) et Object Pooling.
L'arrêt du développement de la technologie COM+ en 1999 annonce l'arrivée de son successeur, le Framework .NET (2002).
Interopérabilité entre objets COM et .Net
COM et .Net sont des architectures très différentes et dans la pratique on rencontre souvent des difficultés à faire communiquer ces deux mondes. Bien que le Framework .Net soit en mesure de créer tout le code d'accès à des objets COM ou à l'inverse de générer des appels aux interfaces COM, la complexité des mécanismes sous-jacents demeure bien réelle. L'extrait ci-dessous est issu de la documentation technique de Microsoft.COM diffère du modèle objet .NET Framework sur plusieurs points importants:
- Un client COM doit gérer explicitement la durée de vie de son objet COM. Le Common Language Runtime (CLR) gère automatiquement la durée de vie des objets dans son environnement.
- Les clients des objets COM déterminent si un service est disponible en demandant explicitement une interface qui fournit ce service et en récupérant le cas échéant un pointeur d'interface en retour. Les clients des objets .NET peuvent obtenir automatiquement une description de la fonctionnalité d'un objet par le mécanisme de réflexion.
- Les objets NET résident dans la mémoire managée par l'environnement d'exécution du Framework .NET. Celui-ci peut déplacer a tout moment des objets dans sa mémoire et mettre à jour toutes les références aux objets qu'il déplace. Les clients non managés tels que de objets COM ayant obtenu un pointeur désignant un objet, s'attendent à ce que cet objet reste au même emplacement. Ces clients ne disposent d'aucun mécanisme leur permettant d'utiliser un objet dont l'emplacement n'est pas fixe.
Liens intéressants
- Questions/Réponses
- Communications entre objets COM et .Net
- Appel d'un objet .Net depuis COM: COM Callable Wrapper
- Appel d'un objet COM depuis .Net: Runtime Callable Wrapper
- Migration de Services COM+ vers WCF
Aucun commentaire:
Enregistrer un commentaire