Quel est le but des applications de bibliothèque COM +?

Question

Lorsqu'une application COM + est créée, l'assistant propose de choisir entre une bibliothèque et une application serveur.

Une application serveur est activée dans un processus séparé et peut être utilisée pour interopérer à peu de frais des consommateurs 64 bits avec des composants COM de 32 bits.

À quoi servent les applications de bibliothèque activées directement dans le processus d'appel? Pourquoi les utiliser à la place de simples serveurs COM in-proc?

Answer 1

Il existe plusieurs:

1. Performance - il est un peu plus vite que vous ne devez pas passer par l'automatisation des messages (de débranchement et unmarshalling)

2. Isolation - si un grand nombre d'applications différentes utilisent la bibliothèque, chacun aura sa propre copie. Ce point est le plus important pour traiter les différences entre un MTA (multithread Appartement) et un STA (Appartement fileté simple modèle)

Serveur IN-PROC (qui est vraiment un hors des processus, de le processus de l'appelant) est partagé par tous les différents interlocuteurs (ce qui est un excellent moyen d'avoir pas cher IPC/RPC)

Ok je suis l'édition avec quelques définitions, et un peu plus de références:

1. Contexte est vraiment tout l'état autour de l'utilisation d'un objet.
2. La causalité est vraiment un concept similaire à un fil qui indique l'utilisation d'un objet dans un contexte. ("Une causalité est une chaîne distribuée d'appels de méthode COM qui s'étend sur un nombre quelconque de contextes dans un nombre quelconque de processus" - ISBN: 0-201-61594-0)

Ceux à concepts sont discutés dans environ 30 pages du chapitre 2 de l'excellent livre de Tim Ewald "Transactional COM +" ISBN: 0-201-61594-0

Donc, en prenant une citation directe du résumé du chapitre 2: "Un objet peut interagir avec son contexte en utilisant le contexte de l'objet Ces deux objets fournissent des interfaces pour interagir avec les services d'exécution COM +, ce style de codage, «en contexte», rend le développement de COM + très différent du développement COM classique.

Enfin, le chapitre 2 a une discussion « Pourquoi Applications Bibliothèque? », (ce qui est différent de votre question, pourquoi ne pas tout simplement vieux COM?) Ses arguments indiquent essentiellement les mêmes raisons d'utiliser un objet COM, 1. Chaque application a sa propre instance. 2. Charger dans le processus non DLLhost.exe. 3. Beaucoup moins de frais généraux. 4. Déploiement simple d'objets communs. Donc, la ligne de fond est que si vous n'êtes pas distribué, et non transactionnel dans la nature, il n'y a pas de réel avantage à utiliser COM + sur COM. Mais si vous écrivez une application COM + et que vous la déployez en tant qu'application LIBRARY, elle se comportera un peu plus comme un composant COM.

Espérons que ça aide.

Answer 2

Le but principal est de bénéficier de COM+ application contexts.

CoGetObjectContext pour IObjectContext ou IObjectContextActivity retournera E_NOTINTERFACE du composant pur en cours, alors qu'il fonctionne avec succès dans une application bibliothèque COM + (et une application serveur bien sûr). Le contexte de sécurité est également disponible via CoGetCallContext pour ISecurityCallContext.

Cela n'a rien à voir avec la performance ou l'isolation. Comme une note de site, une façon de vérifier ce qui est disponible pour les applications de bibliothèque COM + est d'exécuter dcomcnfg.exe accéder aux services de composants, ordinateurs, mon ordinateur, application COM +, créer une nouvelle application de bibliothèque et vérifier ce qui est encore activé. opposition à une application serveur).