Chapitre 35 : extrait du livre .NET par Dick Lantim .gif)
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.
.jpg)
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.
.jpg)
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.
.jpg)
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.
.jpg)
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.
.jpg)
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.
Dernière
mise à jour le mardi 28 octobre 2003
Pour en savoir plus