.NET par Dick Lantim : le serveur d'applications

Chapitre 35 : extrait du livre .NET par Dick Lantim Lien externe au site MSDN France

Le serveur d’applications

Le serveur d’applications est devenu un élément incontournable dans les applications critiques qui gèrent un nombre important de transactions, de grands volumes de données et qui prennent en charge de nombreux d’utilisateurs. Dans ce contexte critique, le serveur d’applications donne un cadre de développement et d’exploitation qui augmente la disponibilité, la fiabilité et la sécurité de la plate-forme d’exploitation. Très popularisée, la notion de serveur d’applications est souvent utilisée de manière restrictive pour décrire le serveur HTTP qui délivre des pages Web dynamiques. Cette notion couvre en réalité un domaine plus vaste.

Si la plate-forme J2EE met en avant le serveur d’applications au travers de produits tels que WebSphere, WebLogic et JBoss pour ne citer que les plus connus, la plate-forme .NET reste discrète. Cette discrétion amène même à penser que la plate-forme .NET ne dispose pas de serveur d’applications. Or celui-ci est bien présent, mais fait partie intégrante du système d’exploitation.

Contrairement aux versions précédentes des systèmes d’exploitation serveur, Windows Server 2003 met grandement en avant ce concept. D’ailleurs, sa conception a été orientée par rapport aux fonctionnalités des serveurs d’applications. Mais que couvre donc un serveur d’applications ? Où intervient-il ? Quels sont réellement ses apports ? Afin de répondre à ces questions, ce chapitre donne une définition du serveur d’applications et montre comment les différentes briques de Windows Server 2003 et le Framework .NET répondent à cette définition.

La notion de serveur d’applications

La définition du serveur d’applications

Le serveur d’applications est un concept issu des technologies Web. Dans ce contexte, le serveur HTTP délivre des pages HTML aux clients connectés, quelle que soit la technologie utilisée pour produire ces pages. Pour les applications critiques, une architecture 3-tier est souvent utilisée. Il y a au minimum une séparation des couches de présentation, de la couche métier et de la couche données.

Dans cette architecture devenue « classique », des notions récurrentes apparaissent. Ainsi, pour prendre en charge de gros volumes transactionnels, la couche métier est souvent modélisée en composants. Le transactionnel est aussi bien utilisé au travers de la base de données qu’au travers des composants. Pour couvrir les besoins de disponibilité de la plate-forme, un système de cache et de recyclage des composants est souvent nécessaire.

Comme toutes ces opérations sont récurrentes dans l’ensemble des applications critiques, le concept de serveur d’applications est né pour permettre aux développeurs de ne pas implémenter systématiquement les mêmes briques.

Le serveur d’applications devient alors une composante du système d’informations au même titre que la base de données. Pour simplifier, un serveur d’applications est caractérisé au moins par :

un serveur HTTP
un serveur de composants
un moteur transactionnel

Mais au-delà de ces briques techniques, un serveur d’applications doit simplifier les développements, tout en favorisant la gestion de la montée en charge de la plate-forme. Par conséquent, un serveur d’applications apporte des bénéfices à court et à moyen terme dans les phases de développement et d’exploitation.

En ce qui concerne la phase de développement, le serveur d’applications doit :

mettre à disposition des développeurs un cadre de développement ;
permettre la conception des applications avec une architecture en couches.

En phase d’exploitation, il doit, principalement :

proposer une plate-forme fiable, robuste et sécurisée
supporter la montée en charge en étant scalable
assurer une bonne tolérance aux pannes, sans rupture de service

Les bénéfices en développement

En phase de développement, le serveur d’applications doit proposer un cadre de développement qui permette de tirer avantage de ce concept. Ce cadre de développement est apporté par les technologies du Framework .NET. Ainsi, on peut résumer les domaines couverts par chacune de ces technologies :

Domaine	Technologie
Présentation	Console Winform ASP.NET MMIT
Métier	Services d’entreprises
Accès aux données	ADO.NET
EAI	MSMQ

Les bénéfices en exploitation

En exploitation, les applications conçues sur le Framework .NET bénéficient de la fiabilité de l’environnement d’exécution et du modèle de sécurité de .NET. Mais en production, les applications .NET peuvent facilement changer d’infrastructure sans que soient remis en compte les développements (voir le chapitre 33, « L’architecture logique et physique »). Il est en effet simple de basculer une application mise en production sur un seul frontal dans une ferme Web sans avoir à modifier le code compilé. La gestion de la session déportée d’ASP.NET facilite cette transition. De même, une application installée sur une seule machine peut être répartie sur différentes machines physiques pour dissocier la couche de présentation de la couche métier. Ce choix peut être dicté par une augmentation des connexions Web, nécessitant ainsi l’utilisation d’une ferme Web.

D’une manière générale, les bénéfices de la plate-forme .NET permettent de dissocier l’architecture des applications lors de sa conception et de son exploitation. Il est alors aisé de modeler l’infrastructure d’une plate-forme en fonction des besoins et des contraintes de l’exploitation.

Les nouveautés de Windows Server 2003

Bien que très proche de Windows 2000, la version 2003 apporte un lot important de nouveautés. Cette mouture de Windows Server 2003 se trouve dans la lignée du programme mis en place par Microsoft destiné à fournir des produits fiables, robustes et sécurisés. Ce programme a vu la mise en place de processus internes afin de permettre le respect de cette charte.

Les composants majeurs de Windows Server 2003 sont :

Framework .NET 1.1
Active Directory
IIS 6.0
COM+ 1.5
MSMQ 3.0
UDDI

Concernant les nouveautés du système d’exploitation, celui-ci est maintenant capable de fonctionner en mode 64 bits sur les processeurs Itanium avec un cluster de 8 noeuds. La puissance et la vitesse de calcul des grands nombres et des flottants sont alors grandement améliorées. La nouvelle architecture destinée à la prise en charge des processeurs 64 bits permet alors de gérer jusqu’à 64 processeurs simultanés et 512 Go de RAM. Elle permet également de repousser les limites d’adressage des processeurs 32 bits afin d’adresser des espaces virtuels et physiques plus grands. Une autre caractéristique étonnante concerne la gestion de la mémoire : il est désormais possible d’ajouter de la mémoire « à chaud ». Cette fonctionnalité permet d’ajouter des barrettes de mémoire supplémentaires dans un serveur, sans pour autant arrêter le système. La prise en compte de la mémoire ajoutée, ou éventuellement supprimée, est immédiate.

Pour ce qui est de la compatibilité avec les applications 32 bits, fort heureusement, une compatibilité ascendante existe. Les applications 32 bits continuent à s’exécuter dans un « cocon » 32 bits qui ne perturbe pas leur exécution.

En revanche, à la date de parution de cet ouvrage, l’exécution du code managé en mode 64 bits n’est pas encore disponible. Une version 64 bits de l’environnement d’exécution est en cours de préparation. Une des difficultés des équipes de développement est de faire en sorte que l’environnement d’exécution 64 bits soit optimisé pour ce type de processeur. En effet, appréhender un processeur 64 bits n’est pas une tâche aisée. Souvenezvous le temps qu’il a fallu pour faire en sorte que les applications 32 bits Windows soient plus rapides que les applications 16 bits !

La couche de présentation IIS 6.0

La nouvelle architecture

En ce qui concerne la disponibilité, la fiabilité et la sécurité, l’architecture du serveur HTTP IIS a été complètement repensée. Si dans la version 5.5, les applications Web s’exécutaient déjà dans un processus isolé, une ressource restait partagée dans cette version : le filtre Isapi. Ainsi, chaque application Web était confinée dans un processus. Un dysfonctionnement de l’une ne pouvait altérer une autre, mais le filtre étant partagé, une application bloquée pouvait également bloquer INetInfo, donc IIS.

La nouvelle architecture de la version 6.0 du serveur HTTP IIS déporte le filtre Isapi dans chaque processus représentant une application Web. Les applications Web gérées par IIS ne partagent plus de ressources communes. Ainsi, le dysfonctionnement d’une application ne peut plus affecter l’exécution d’une autre application. Il y a réellement un confinement des ressources au sein de chaque processus. Le noyau http.sys ne fait que rediriger une requête HTTP vers une application Web. Aucun traitement n’est effectué par ce noyau.

Avec cette nouvelle architecture, la stabilité, la robustesse, la disponibilité et la sécurité de IIS ont été améliorées. Comme il n’y a plus de ressource partagée, le serveur IIS se concentre à contrôler et surveiller ses applications Web. Il est alors possible de lancer un processus, de suspendre son exécution, de la relancer et de la terminer. Un contrôle très fin peut aussi être réalisé afin de tester le bon fonctionnement d’une application Web. En cas de faille de l’une d’entre elles, le serveur IIS est même capable de relancer une nouvelle instance. Les notions de pooling d’applications Web et de recyclage d’applications font leur apparition.

Le pooling d’applications

Le serveur HTTP IIS 6.0 utilise la notion de pool d’applications pour exécuter une ou plusieurs applications Web. Chaque application Web doit obligatoirement être associée à un pool pour s’exécuter. L’idée est qu’un pool définit certaines caractéristiques qui sont appliquées aux applications Web associées. Ces caractéristiques portent sur :

la notion de Web Garden
la stratégie de recyclage des applications
la santé de l’application.

Généralement, les applications Web associées dans le même pool d’applications sont liées fonctionnellement. Ainsi, il est possible de suspendre et de relancer toutes les applications Web d’un même pool par administration. La configuration d’un pool peut être sauvegardée pour être appliquée à un autre pool d’applications.

La notion de Web Garden

Par défaut, une application Web est représentée par un seul processus dit Worker Process. Toutes les requêtes clientes reçues par IIS sont acheminées vers le Worker Process par le noyau http.sys. Les requêtes sont alors réparties sur les différents threads du processus.

Ce mécanisme par défaut couvre la majorité des besoins mais n’est pas forcément adapté pour un grand volume de transactions. La limite de requêtes traitées par une application Web dépend du temps de traitement et du nombre de threads disponibles. Dans certains cas, il convient de disposer d’un plus grand nombre de threads. Une des solutions est de définir un Web Garden, c’est-à-dire d’allouer plus d’un processus pour une application Web.

Pour cela, il convient de modifier la valeur spécifiée dans l’onglet Pool des propriétés d’un pool d’applications. Il n’y a pas de règle précise car ce paramétrage dépend du fonctionnel de l’application Web. Cependant, une bonne règle consiste à définir autant de Worker Process dans un Web Garden que le système dispose de processeurs physiques.

Le recyclage d’applications Web

Une application Web est généralement conçue pour fonctionner 24 heures sur 24 et quelquefois, 7 jours sur 7 du fait de l’internationalisation de ce support. Afin de limiter la maintenance d’un site, une application Web doit être suffisamment robuste ou doit disposer de processus de maintenance palliatifs, comme la réinitialisation des serveurs durant le week-end si le fonctionnel de l’application le permet.

Malheureusement, dans beaucoup de cas, une application Web ne peut être arrêtée. Pourtant, même si une application est correctement programmée, sans fuite de mémoire ou autre défaillance, il se peut que les performances ne soient pas les mêmes après quelques mois de fonctionnement en continu. En effet, une application peut se dégrader dans le temps du fait d’une mémoire trop fragmentée, d’un cache peu efficace en raison de la trop grande quantité de données inutiles conservée, etc. Dans ce cas, une réinitialisation de l’application peut tout remettre en ordre.

C’est dans ce but que le serveur HTTP IIS 6.0 dispose d’une notion de recyclage des applications Web qui permet de réinitialiser une application en fonction des critères suivants :

nombre de hits sur le site
nombre d’heures pendant lesquelles elle est utilisée
périodes d’utilisation
quantité de mémoire consommée

Grâce à cette notion de recyclage d’applications, il est possible de relancer des instances fraîches d’une application Web selon une stratégie définie. Le recyclage d’application Web peut alors garantir un niveau de performance sans dégradation dans le temps. Par ce mécanisme, il est même possible de mieux sécuriser une application boguée mise en production. Il suffit de réinitialiser l’application avant que les anomalies se déclenchent. Dans ce cas, les erreurs applicatives sont camouflées jusqu’à la correction des anomalies de fonctionnement.

Durant le recyclage du Worker Process, le service est interrompu puisque le processus est détruit puis relancé. Cependant, en définissant un Web Garden, il est possible de faire en sorte qu’il n’y ait pas de rupture de service. Lorsqu’un Worker Process doit être recyclé, les nouvelles requêtes clientes ne sont plus acheminées par le noyau sur le Worker Process en cours de recyclage mais vers les autres Worker Process du Web Garden. Cela est uniquement vrai si la stratégie de recyclage n’est pas fondée sur une période ou un temps d’exécution fixes.

La couche métier services d’entreprise

Les nouveautés de COM+ 1.5

Les composants COM+ ont déjà été abordés dans le chapitre dédié au modèle COM. Principalement, l’accent a été porté sur le développement des composants à partir du Framework .NET et leur installation au sein d’une application COM+. Dans cette partie, l’accent est mis essentiellement sur les nouveautés de la version COM+ de Windows Server 2003. Ces nouveautés vont dans le sens de la plate-forme Windows Server 2003 qui se veut plus fiable, plus robuste et plus disponible.

Les limites de la version antérieure ont aussi été améliorées dans COM+ 1.5. Par exemple, le nouveau modèle Neutral Thread Appartment réunit les avantages des deux modèles de threads précédents : Single Thread Appartment (STA) et Multiple Thread Appartment (MTA). Le mode STA bien que thread safe est un goulot d’étranglement dans une architecture à haute disponibilité, tandis que le mode MTA délègue la responsabilité du mode thread safe au développeur. Le modèle NTA garde les spécificités du mode STA tout en permettant l’utilisation de plusieurs threads pour accéder aux objets.

Toujours au chapitre des améliorations, à l’instar du serveur HTTP IIS, la nouvelle version de COM+ bénéficie d’une nouvelle architecture. Grâce à cette refonte, les nouvelles caractéristiques renforcent la notion de serveur d’applications de Windows 2003. Ces nouveautés portent essentiellement sur :

la notion d’alias de composant
le pooling d’applications COM+ et de composants
le recyclage d’applications
l’exportation des applications en tant que services NT ou services Web
l’utilisation des services COM+ sans composant

La notion d’alias permet d’identifier un composant par plusieurs identifiants. Il est alors possible d’associer des contextes différents à un composant selon l’alias qui est utilisé. Généralement, les différences portent sur les chaînes de connexion et les utilisateurs associés. Outre cette notion d’alias, la nouvelle architecture apporte une continuité entre les caractéristiques du serveur HTTP IIS 6.0 et la gestion des composants. Ces nouvelles caractéristiques sont détaillées dans les sections suivantes.

Le pooling COM+

Les applications

Par analogie aux applications Web, les applications COM+ disposent également d’un mécanisme de pooling. Par ce système, les invocations clientes sont réparties sur l’ensemble des instances d’une même application dans le pool. En cas d’indisponibilité d’une des instances, le service continue grâce aux autres instances d’application dans le pool. Bien entendu, seules les applications COM+ de type serveur peuvent en bénéficier Par défaut, l’installation d’une application COM+ ne définit qu’une instance dans le pool. La constitution d’un pool d’applications doit être constituée au travers de la console d’administration Services de composants de COM+. Il convient d’activer la gestion du pool en précisant le nombre voulu d’instances de l’application dans le pool (figure 36-1).

Un autre avantage du pool d’applications est la possibilité de suspendre et de relancer l’exécution d’une application par administration. Non seulement cette fonctionnalité permet de rendre un service indisponible, mais elle permet aussi de vider la mémoire d’une instance d’une application COM+. Tant qu’une application COM+ est suspendue, les applications clientes reçoivent une exception si elles tentent d’accéder à un composant. Dès que l’application COM+ reprend son exécution, les applications clientes accèdent de nouveau aux composants COM+. Notons que durant la mise en pause d’une application COM+, il n’est pas possible de créer une nouvelle instance.

Figure 35-1 Configuration du pool d’applications COM+

Les composants

Le premier rôle du moteur de COM+ est de gérer le cycle de vie des composants. Il instancie le composant sur une demande cliente, gère sa mémoire, exécute les méthodes et libère l’objet lorsqu’il n’est plus utilisé. Dans ces différentes phases, les phases de création et de libération sont fréquemment les plus coûteuses. Souvent, dans une application classique, une des optimisations adoptées consiste à ne pas libérer l’objet afin de le réutiliser pour les différents appels.

Dans cette optique, le nouveau moteur de COM+ apporte la notion de pool de composants. Son but est de réutiliser les instances des composants créées pour l’ensemble des demandes clientes. De même que le pool d’applications, au sein d’une même application COM+, les requêtes clientes sont réparties sur un ensemble de composants. Cela permet d’une part d’économiser les temps de construction et d’initialisation du composant, mais aussi de paralléliser les demandes pour améliorer les temps de réponses. Enfin, si un composant est défaillant, les requêtes clientes sont redirigées sur les instances encore valides, rendant ainsi l’application tolérante aux pannes et la plate-forme disponible.

En revanche, en distribuant les requêtes sur un ensemble de composants, un même client n’est pas certain d’invoquer un même composant entre deux appels. Par conséquent, les composants doivent être sans état (stateless).

La configuration du pool de composants s’effectue soit par administration au travers de la console d’administration des composants, soit par programmation à l’aide d’attributs personnalisés.

La console d’administration permet d’activer le pool de composants par l’option Enable object pooling de l’onglet Activation des propriétés du composant. Une fois activé, il est possible de spécifier le nombre minimal et maximal d’instances dans le pool.

Figure 35-2 Le pool de composanst COM+

Par programmation, la configuration du pool de composants est réalisée par l’attribut personnalisé ObjectPooling. Cet attribut dispose des paramètres MinPoolSize et MaxPool Size qui permettent de spécifier le nombre minimal d’instances d’objets et le nombre maximal dans le pool.

[ObjectPooling(Enabled = true, MinPoolSize = 6,
    MaxPoolSize = 10)] public class Euro : ServicedComponent {
    … }

Bien que le pool de composants permette d’éviter l’instanciation systématique des composants, le gestionnaire de pools peut nécessiter de désactiver des instances de la mémoire en cas d’une longue inactivité ou d’une saturation de la mémoire. Dès que le composant est de nouveau sollicité, le gestionnaire de pools réactive automatiquement le composant. Cette gestion particulière du pool doit être prise en compte au sein de vos composants pour faciliter leur déshydratation et leur réhydratation.

Au niveau de la programmation des composants mis en pool, il va de soi que le code d’initialisation ne doit être spécifié ni dans le constructeur et ni dans le destructeur d’un objet. Lorsque l’objet est désactivé, le code du destructeur n’est pas invoqué, et lorsqu’il est de nouveau activé, le code du constructeur n’est pas invoqué non plus. Par conséquent, le code d’initialisation d’un composant doit être spécifié dans les méthodes virtuelles Activate, Deactivate et CanBePool qui correspondent au cycle de vie du gestionnaire de pools. Il convient également de définir la méthode CanBePool pour indiquer au gestionnaire de pools si le composant peut être mis en veille. En cas de réponse positive, le composant sera mis en veille par le gestionnaire de pools.

using System;
using System.EnterpriseServices;
[ObjectPooling(MinPoolSize = 2, MaxPoolSize = 10)]
public class Euro : ServicedComponent {
public Euro() {
}
protected override void Activate() {
base.Activate();
}
protected override bool CanBePooled() {
return base.CanBePooled();
}
protected override void Deactivate() {
base.Deactivate();
}
public double ConvertEuro2Francs(double euro) {
return euro * 6.55957;
}
public double ConvertFrancs2Euro(double francs) {
return francs / 6.55957;
}
}

D’une manière générale, il est conseillé de faire en sorte que le code d’un composant soit sans état et qu’il puisse facilement être suspendu. Malgré tout, les méthodes virtuelles Activate, Deactivate et CanBePool, permettent de conserver par l’intermédiaire d’un programme un état telle une connexion à une base de données.

Le recyclage d’applications

Une nouveauté majeure de la version COM+ 1.5 est la possibilité de définir une stratégie de recyclage des applications COM+. Dans la même optique que les applications Web, le recyclage d’applications COM+ permet de s’assurer que les applications COM+ ne se dégradent pas ou ne dégradent pas le système dans le temps. Même si les stratégies sont moins nombreuses que pour le Web, il est possible de recycler une application par rapport à sa durée de vie, sa mémoire consommée, son délai d’expiration, son nombre limite d’invocations et son nombre limite d’activations.

Le paramétrage de ces stratégies s’opère dans les propriétés de l’application COM+ à l’intérieur de la console d’administration de COM+. Cette notion est uniquement applicable aux applications COM+ de type serveur. Les applications COM+ de type librairie, quant à eux, s’appuient sur la configuration locale du processus qui instancie l’objet.

Figure 35-3 Paramétrage du recyclage COM+

Les objets COM+ partagent les mêmes ressources. Par conséquent, lorsqu’un objet COM+ doit être recyclé, les nouvelles invocations sont redirigées sur une nouvelle instance. Ce n’est que lorsque l’instance de l’application à recycler termine toutes ses transactions en cours que l’instance est réellement détruite. En cas d’utilisation d’une ressource singleton, la nouvelle application peut être en attente de la libération de la ressource. Il convient donc de s’assurer qu’une application qui dispose d’une stratégie de recyclage ne contient pas de point de conflit lors du recyclage.

L’export des composants COM+

COM+ en service NT

Les applications COM+ peuvent désormais être utilisées en tant que services NT. De cette manière, une application COM+ est disponible dès le chargement de la machine. Cette fonctionnalité facilite l’utilisation d’applications COM+ dans un contexte de machine serveur et notamment dans le cadre de fermes Web où les composants métier sont installés dans un cluster.

Pour définir une application en tant que service NT, il convient d’activer l’option « Activer l’application en tant que service NT » dans l’onglet Activation de l’application COM+. Pour cela, l’application COM+ doit être activée en tant qu’Application Serveur.

COM+ en service Web

Un des avantages des serveurs d’applications est de pouvoir faire bénéficier de nouvelles fonctionnalités les applications qui respectent ses spécifications. Ainsi, en définissant un objet COM+, il est possible d’exporter ses méthodes en tant que services Web. Le serveur d’applications s’occupe de créer l’enveloppe Soap nécessaire à son invocation, et expose le service et son Wsdl sans nécessiter de code.

Tout composant COM+ peut être exposé en tant que service Web sous Windows XP. En revanche, sous Windows Server 2003, un composant ne peut être exposé qu’après qu’une politique de sécurité a été définie. Pour cela, il convient de spécifier le compte utilisateur qui sera utilisé pour invoquer le composant. Au plus simple, si le service Web peut être accédé sans restriction, il conviendra de procéder ainsi :

Dans l’onglet Default des propriétés de l’ordinateur
- choisir Connect and Identify dans les boîtes combo
Dans l’onglet Security des propriétés de l’application COM+
- enlevez de la sélection Enforce...
- choisissez la première option dans Security Level
- enlevez la sélection Apply Software restriction policy
- choisissez None pour Authentification Level
- choisissez Anonymous pour Impersonation Level.

Figure 35-4 La sécurité d’un composant COM exposé en Soap

Une fois la sécurité définie pour l’application, les objets peuvent être exposés en tant que services Web Soap, il suffit de cocher la case Soap de l’onglet Activation des propriétés de l’application COM+. Le service Web sera exposé par IIS avec le nom saisi dans la zone d’édition suivant la case à cocher (voir figure 35-5). Par exemple, en spécifiant Test- SOAP sur un serveur nommé MonServeur, un client peut accéder à la définition du service Web par l’intermédiaire de l’adresse suivante : http://MonServeur/TestSOAP?wsdl.

Dans le code, il est possible de définir l’exportation d’un objet COM+ en tant que service Web à l’aide de l’attribut personnalisé ApplicationActivationAttribute.SoapVRoot, de cette manière :

[assembly:ApplicationActivation(ActivationOption.Library, SoapVRoot="test")]

Le nom attribué à SoapVRoot correspond au nom exposé par le serveur IIS pour accéder au composant au travers d’un service Web.

Figure 35-5 Exposition d’un composant COM+ en service Web

COM+ en tant que composant privé

Un composant COM+ peut désormais être privé à l’aide de l’attribut PrivateComponent. Dans ce cas, seuls les composants publics installés dans COM+ peuvent instancier les composants privés. Cette nouveauté permet de renforcer la sécurité d’une plate-forme en limitant l’exposition des composants à risque. Seuls les clients habilités peuvent y accéder. Cette notion reste vraie même si l’application COM+ est définie en tant que librairie.

L’utilisation sans composant

Dans le cadre de la conception d’une application, une des grandes nouveautés de la version 1.5 de COM+ est la capacité d’utiliser les services d’entreprise sans nécessiter la conception d’un composant COM+. Une application peut alors profiter des services transactionnels de COM+ pour des besoins spécifiques.

Pour cela, COM+ 1.5 définit un composant générique qui peut être utilisé par l’environnement d’exécution (CLR). Ce composant est accessible par les classes ServiceDomain, ServiceConfig et ContextUtil de l’espace de noms System.EnterpriseServices. Elles exposent des méthodes statiques qui permettent d’utiliser les services du composant de manière transparente.

Le principe d’utilisation d’un service COM+ est très simple. Il convient dans un premier temps d’indiquer à COM+ que l’on désire utiliser ses services : cela s’effectue à l’aide de la méthode Enter de la classe ServiceDomain. Cette méthode prend en paramètre une instance de la classe ServiceConfig qui permet de spécifier la nature de la transaction voulue. La méthode Enter bloque le thread appelant tant que l’objet COM+ n’est pas disponible. Une fois l’objet COM acquis, selon le type de transaction spécifié dans l’objet ServiceConfig, la classe ContextUtil définit l’état de la transaction. Ses méthodes SetComplete et Abort permettent de valider ou non les transactions en cours. Il est alors ensuite possible de voter pour un commit de la transaction globale par la propriété MyTransactionVote de la classe ContextUtil.

Voici un exemple complet d’utilisation de ses classes. Pour tester cet exemple, il convient de déclarer l’espace de noms System.EnterpriseServices.

private void button1_Click(object sender, System.EventArgs e) {
ServiceConfig srvConfig = new ServiceConfig();
srvConfig.Transaction = TransactionOption.RequiresNew;
srvConfig.IsolationLevel = TransactionIsolationLevel.ReadCommitted;
ServiceDomain.Enter(srvConfig);
try {
ContextUtil.SetComplete();
ContextUtil.MyTransactionVote = TransactionVote.Commit;
}
catch {
ContextUtil.MyTransactionVote = TransactionVote.Abort;
}
ServiceDomain.Leave();
}

Lorsque l’utilisation des services de COM+ est terminée, il est important de libérer l’objet COM+. Cela s’effectue par l’invocation de la méthode Leave de la classe Service- Domain. Comme cette libération est importante, il est conseillé d’utiliser une structure try..finally. Dans l’exemple précédent, seule la transaction est protégée pour une meilleure lisibilité du code source.

Intro

Dernière mise à jour le mardi 28 octobre 2003

Pour en savoir plus