[ Simon Boigelot World ]

Architecture simplifiée de BizTalk

Togis — Tue, 15 Jul 2008 04:41:35 +0200

Dans cet article vous trouverez une première compréhension générale de l'architecture de BizTalk.

Cette compréhension est nécessaire avant de nous plonger dans le développement.

BizTalk permet de mettre en place des flux de données à partir d’une origine A vers un destination B. Mais que ce passe-t-il entre ces deux points ? Tel est la question à laquelle nous allons répondre.

Voici une vue très simplifiée de l’architecture de BizTalk :

1. Les données sont reçues par un Receive Port. Les receive ports ne font que transmettre les données en format binaire, sans se soucier du contenu de ce qu’ils transportent.
2. Elles sont acheminées vers une base de données centrale par une Receive Pipeline. C’est lors de cette phase du transport que le mapping sera appliqué aux données binaires pour fournir un format XML comprenant des promoted properties.
3. Ensuite, si des orchestrations sont configurées pour agir sur le type de message reçu, elles seront instanciées. Une orchestration est une étape du processus métier qui est prise en charge par BizTalk.
4. Les Send Pipelines sont l’exact opposé des Receive Pipelines. Ces pipelines vont prendre les données sous format XML et les convertir dans le format destination désiré. Encore une foi grâce à un mapping.
5. Les données sont enfin envoyées au destinataire par un Send Port qui ne se charge que de transmettre les informations binaires au bon endroit.

Pour savoir quelle est l’étape à appliquer à un message à un moment donné, BizTalk garde un fichier supplémentaire, le fichier de contexte.

Ce fichier de contexte possède de nombreuses information tel que :

· Le type du fichier message
· L’historique complet du fichier à travers le processus BizTalk
· Les erreurs éventuelles survenues
· Les différentes promoted properties

C’est sur les valeurs contenues dans ce fichier de contexte que les différentes parties du flux BizTalk, les artefacts, peuvent souscrire.

Ainsi nous allons pouvoir créer, par exemple, une Send Pipeline et la souscrire aux messages ayant un schéma correspondant au XSD « monSchema.xsd » et provenant de l’orchestration « monOrchestration ».

Le moteur interne de BizTalk créera alors toutes les suscriptions T-SQL nécessaire pour instancier cette Send Pipeline à chaque foi que des données correspondante seront insérée dans la MessageBox.

La MessageBox est le cœur de BizTalk. Elle repose sous SQL-Server ce qui nous offre beaucoup de possibilité quand à la fragmentation de cette base de donnée.

Lorsque qu’un fichier est reçu par BizTalk on parle de message. Les messages peuvent-être dupliqué, ainsi si plusieurs artefacts ont une suscription qui correspond à un même message, chacun de ces artefacts recevra une copie autonome du message.

Maintenant que nous avons une vue globale de l’architecture de BizTalk, nous allons pouvoir nous intéresser en détail à chaque artéfact.

Port

Un port est la représentation logique d’une communication physique par laquelle BizTalk reçoit et envoi des messages.

Chaque port est un conteneur qui possède toutes les informations nécessaires à l’établissement d’un canal de communication.

L’élément principal d’un port est l’adaptateurs qu’il utilise. Chaque type de communication possède son adaptateur.

Par exemple, un Send Port utilisant le protocole FTP possèdera un adaptateur FTP ainsi que les configurations suivantes :

· Ip de contact
· Login
· Password

Pour ne citer que les plus évidentes.

Receive Port

Les receive ports ont pour particularité d’être des conteneurs de Port. Ainsi un unique reveive port peut en faite être associé à plusieurs configurations différentes, nommée Receive Location.

Ainsi un receive port attendant des ordres d’achat pourra être composé de plusieurs receive locations :

· La première attendant des fichiers sur un FTP
· La seconde sur le système de fichier d’un serveur
· La troisième par mail

Quelque soit l’origine du fichier reçu, il sera traité de la même manière dans la suite du flux de donnée.

Send Port

En contradiction avec les receive port, les send ports eux ne peuvent contenir qu’un unique port de destination.

Pour palier à ce désavantage, BizTalk offre la possibilité de crée des SendPortGroup, contenant plusieurs Send Port.

Logical Port

Lors de la création d’une orchestration, le programmeur ne sait pas forcément d’où lui viendra les données, ni où il devra les envoyer ensuite.

C’est dans ces cas précis qu’interviennent les ports logiques.

Les ports logiques ne doivent être liés à des ports physiques qu’au moment du déploiement de l’application.

Dynamic Send Port

Ces send ports particulier permettent de définir la destination des messages au moment de l’exécution au lieu de le faire lors déploiement de l’application.

Cette destination doit être définie par déduction sur des promoted properties.

Adaptateur

Les adaptateurs sont les interfaces de communication de BizTalk autant en entrée qu’en sortie.

La plupart du temps, les adaptateurs ne sont que des interfaces de communication basée sur un protocole de transport donné. Ils n’ont donc aucune compréhension interne des données qu’ils transportent.

Leur unique utilité est de nourrir et de délester la machinerie de BizTalk.

Dans le cas d’adaptateur de réception, deux modes principaux existent :

· Le pooling : de temps à autre l’adaptateur vérifie le contenu d’un répertoire (ou autre) pour vérifier si des messages attendu par BizTalk ne s’y trouve pas. C’est le cas du « File System Adaptater ».
· L’écoute : l’adaptateur est en attente d’un événement en provenance su monde extérieur pour se réveiller.

Lorsqu’un message est reçu par un adaptateur, contrairement à ce que l’on dessine habituellement, il n’est pas envoyé directement à une receive pipeline mais passe d’abord par la MessageBox.

C’est le « Message Engine » de BizTalk qui à la charge de transmettre ce message de la MessageBox a la receive pipeline appropriée.

Un adaptateur des plus important est le « SQL Adaptater », en effet, la MessageBox reposant sur une base de données SQL Server, chaque communication interne à BizTalk repose sur cet adaptateur.

Pipeline

Les pipelines ont pour fonction d’effectuer des traitements de données sur les messages entrants ou les messages sortants. Cet aussi cet artéfact qui à comme responsabilité la validation de ces messages.

Par traitements de données ont entent principalement tout ce qui est sécurité (cryptage/décryptage, signature).

BizTalk fournit 4 pipelines basiques qui permettent de remplir toutes les fonctions les plus couramment utilisées :

· Receive Pipeline

o XmlReceive : permet de recevoir des messages XML et de les valider
o PassThruReceive : permet de recevoir des messages sous format flat file

· SendPipeline

o XmdTransmit : permet d’envoyer des messages XML et de les valider
o PassThruTransmit : permet d’envoyer des messages sous format flat file

Comme son nom l’indique, un pipeline est un suivit d’opérations les unes aux suites des autres. Dans un pipeline l’ordre des opérations est très important, en effet, a quoi bon par exemple essayer de valider un fichier XML qui n’a pas été décrypté.

Pour simplifier la mise en place de pipeline, BizTalk à séparé en grands groupes les type d’opérations pouvant être effectuée sur un message.

Receive Pipeline Operation Group :

1. Décode : cette étape sert à décoder les messages d’un format externe à un format lisible par les autres composants. Le plus commun des cas de décode est sans nul doute le décryptage.
2. Désassemble : en fonction du type de message, cette étape va soit traduire le message d’origine en un message XML, soit découper le message en plusieurs sous-messages plus conforme à l’implémentation du flux.
3. Validation : valide un message à partir d’un schéma.
4. Résoudre les partenaires : cette étape est principalement utilisée pour certifier la provenance des messages reçus.

Send Pipeline Operation Group :

1. Pré-assemble : cette étape et le dernier point de modifications des données par le flux BizTalk, généralement utilisée pour faire des transformations de dernière minute sur le XML interne de BizTalk avant qu’il ne soit transformé en flat file.
2. Assemble : utilisation d’un schéma pour transformer un ou plusieurs messages en un message respectant le format convenant au destinataire.
3. Encore : à l’inverse de décode, cette phase est utilisée pour crypter les données. (Un autre exemple est la compression des données)

De nombreux composant de pipelines effectuant ce genre d’opération sont inclus dans BizTalk mais il est toujours possible d’écrire nos propres composants ou d’en acheter de nouveau, comme d’habitude.

Orchestration

Les orchestrations permettent au développeur BizTalk d’implémenter un processus métier à travers un outil de dessin : l’Orchestration Designer.

Cet outil permet d’exprimer le processus métier via une série de forme glissée sur la surface de dessin à partir de la boîte à outil de Visual Studio.

A travers ces dessins, tout le framework .Net ainsi que le framework BizTalk sont accessible.

Il est ainsi possible de laisser libre cours à son implémentation du processus métier sans pour autant devoir écrire plusieurs programmes fastidieux pour gérer chaque étape de ce processus.

Les orchestrations, tout comme les autres artéfacts de BizTalk, souscrivent à certain messages arrivant dans la MessageBox et sont instanciée par celle-ci lorsque l’un deux arrive.

Ces orchestrations sont alors capable, par exemple de gérer des exception tel que : « A la réception d’un ordre d’achat j’envoie une facture, mais si je n’ai pas d’accusé de réception avant 2 jours, j’annule l’ordre »

Encore une foi, les « shape d’orchestration », ces fameuses formes servant à dessiner sont nombreuses mais il est toujours possible de créer les nôtre.

Créer une orchestration BizTalk avec Visual Studio

Togis — Tue, 15 Jul 2008 04:12:00 +0200

Dans cet exercice nous allons apprendre à créer des orchestrations grâce à l’Orchestration Designer de BizTalk.

L’orchestration que nous allons créer va faire exactement la même chose que les filtres des Send Ports du chapitre précédent. Cependant gardez à l’esprit que les orchestrations ont bien plus de capacités, mais il faut bien commencer petit.

· Ouvrez Visual Studio

· Créer un nouveau projet « Empty Biztalk Server Project » du nom de « LabOrchestration »

· N’oubliez pas de directement changer le nom de déploiement du projet pour « LabOrchestration » et de lui assigner une clef de signature.

· Ajoutez 1 schéma au projet :

· Pour des raisons éducative, ne faites pas de « NombrePage » un « xs :int » mais gardez le en « xs :string »

· Pour pouvoir utiliser ce champ lors d’une orchestration, il doit recevoir une promotion particulière nommée « Distinguished Field ».

· Pour ce faire, cliquez sur le champ avec le bouton droit de la souris et sélectionnez « Promote à Show Promotion »

· Dans la boîte de dialogue qui s’ouvre vous trouvez la possibilité d’ajouter le champ « NombrePage » aux « Distinguished Fields ».

· Cliquez avec le bouton droit de la souris sur votre projet, sélectionnez « Add à New Item… »

· Dans la boîte de dialogue « Add New Item », sous « Orchestration Files » choisissez « BizTalk Orchestration » et nommez la « OrchestrationTrieLivre »

· L’éditeur d’orchestration s’ouvre dans Visual Studio.

Une orchestration commence toujours par la réception d’un message, soit par suscription, soit par appel à partir d’une autre orchestration.

Dans la boîte à outil de Visual Studio vous trouverez tous les « Shapes » de base utilisés lors de la création d’une nouvelle orchestration.

Passons en revue les plus intéressants :

Shape	Explication
	Action d’envoyer un message à travers un Send Port
	Action de recevoir un message en provenance d’un Receive Port.
	Représentation d’un port au niveau d’une orchestration, il s’agit ici d’un port logique qui devra être lié à un port physique lors de la configuration de l’orchestration. (Après déploiement)
	Permet d’appliquer un map XSLT sur un message
	Action de construire un nouveau message sur base d’un schéma
	Permet à une orchestration d’en invoquer d’autre. Call est synchrone, Start asynchrone.
	Permet de faire appel au Business Rule Engine.
	Permet l’appel d’un script .Net
	Représentation d’un « If-then-else »
	Permet à l’orchestration de marquer un temps de pause
	Multithreading interne aux orchestrations
	Représentation d’un boucle « Tant que (condition) »
	Shapes utilisée pour la gestion des erreurs
	Met une Orchestration en attentent de l’action d’un administrateur.
	Met fin à l’orchestration

Notre orchestration doit recevoir un Livre et l’envoyer à deux ports différents selon le nombre de Page qu’il contient.

Pour ce faire, il nous faudra donc :

Ø 3 Ports Logique (1 receive, 2 send)

Ø 1 Receive Shape

Ø 2 Send Shapes

Ø 1 Decide Shape

Ajoutez le premier Port Logique à l’orchestration en le glissant sur le « Port Surface » de gauche du designer.

· Un assistant de configuration de ce port s’ouvre. Cliquez sur Next.

· Le nom de ce port est « OrchRcvPortLivre ». Cliquez sur Next.

· L’assistant nous demande de choisir ou de crée un « Type de port » pour notre nouveau port logique. En effet, on ne peut lier un port physique à un port logique que si, et seulement si, ses caractéristiques son similaire. Le « Type de port » est le conteneur des caractéristiques de notre port logique. N’en ayant encore jamais créé auparavant dans ce projet, créons en un.

· Choisissez « OrchRcvPortLivreType » comme nom de Type

· « One-Way » et « Internal » comme caractéristiques. Cliquez sur Next.

Dans la page suivante de cet assistant, on nous propose de spécifier le sens du port et on nous offre le choix entre plusieurs possibilités quant-à son implémentation physique.

« Port binding » offre 3 possibilités :

Ø Spécify now: crée directement un port physique sur base des informations du port logique

Ø Spécify later : permet au développeur de lier ce port logique à un port physique plus tard, après le déploiement.

Ø Direct : Ce port logique prend sa source soit directement sur la MessageBox de BizTalk, soit d’une autre Orchestration, soit de cette orchestration elle-même. (Cette dernière option peut paraître étrange mais il ne s’agit en faite que de la possibilité de créer des Orchestration récursives)

· Choisissez « Spécify later ». Cliquez sur Next.

Cliquez sur le port nouvellement ajouté et ouvrez ses propriétés.

· Remarquez que BizTalk demande que vous lui spécifier quel schéma sera utilisé pour la validation des message entrant par ce port.

· Choisissez « LabOrchestration.Live »

· Ajouter un « Receive Shape » à l’Orchestration en le glissant sur la surface de dessin.

· Liez ce « Receive Shape » à votre port « OrchRcvPortLivre »

· Ajoutez un « Decide Shape » à l’orchestration :

· Sélectionnez le point d’exclamation et cliquez sur « No Expression, Click… »

· Une boîte de script .Net s’ouvre, c’est ici que nous allons définir la condition de notre « if-then-else ».

· Remplissez-la par :
« System.Int32.Parse(Message_1.NombrePage) < 500 »
il s’agit de notre condition.

·Ajoutez un Port logique dans le « Port Surface » de gauche.

· Ajoutez un Port logique dans le « Port Surface » de droite.

· Ajouter un « Send Shape » sur chaque branche de « Decide Shape » et liez les aux Send Port que vous venez de créer.

· Au final votre orchestration devrait ressembler à ceci :

· Avant de pouvoir enfin déployer, il faut spécifier à cette orchestration qu’elle peut-être automatiquement instanciée à la réception d’un Livre.

· Ouvrez les propriétés du « Receive Shape » et faites-y passer la propriété « Activate » à true.

· Deployer votre projet

· Lier les ports logiques de cette orchestration avec des ports physique se fait dans BizTalk Server Administration.

Importer une application BizTalk à partir d’un fichier MSI

Togis — Tue, 15 Jul 2008 03:52:00 +0200

Suite de l'article : Exporter une application BizTalk à partir d’un fichier MSI

Dans le but de cet exercice nous allons tout d’abord effacer toute trace de l’application SugarFactory de notre environnement BizTalk.

Pour ce faire :

· Ouvrez BizTalk Server administration Console.

· Stoppez l’application « SugarFactory »

· Une boîte de dialogue vous demande de choisir entre 3 différents arrêts d’applications, choisissez « Fill Stop – Terminate instances »

· Cliquez sur Stop.

· Cliquez avec le bouton droit de la souris sur votre application et sélectionnez « Delete »

· « Do you wish to delete this application ? » à Yes

Pour importer notre application SugarFactory à partir du fichier MSI précédemment crée :

· Ouvrez BizTalk Server administration Console.

· Cliquez sur le nœud « Application » avec le bouton droit de la souris et sélectionnez « Import à MSI File »

· Dans la première page de l’assistant, sélectionnez le fichier MSI « C:\TFE08BTS06\SugarFactory\Install\SugarFactory.msi »

· Cliquez deux foi sur Next et ensuite sur Import.

L’application SugarFactory est revenue dans l’environnement BizTalk, sans perdre aucune de ses configurations.

Exporter une application BizTalk à partir d’un fichier MSI

Togis — Tue, 15 Jul 2008 03:51:00 +0200

Dans cet exercice nous allons apprendre à exporter une application BizTalk à partir de l’outil « Export MSI wizard » de BizTalk 2006.

· Ouvrez BizTalk Server administration Console.

· Cliquez avec le bouton droit de la souris sur une de vos applications. Pourquoi pas « SugarFactory ». Sélectionnez « Export à MSI File »

· Dans la page d’accueil de l’assistant, cliquez sur Next. Et faite de même pour les pages suivantes jusqu’à arriver à la page « Destination »

· Changer la destination du fichier MSI généré pour « C:\TFE08BTS06\SugarFactory\Install\SugarFactory.msi »

· Cliquez sur Export

Création de schéma avec l’éditeur de BizTalk

Togis — Tue, 15 Jul 2008 02:28:50 +0200

Dans cet exercice, nous allons voir en détails comment créer un nouveau schéma en se passant de l’assistant (wizard) de Visual Studio.

· Ouvrez Visual Studio

· Créer un nouveau projet « Empty Biztalk Server Project » du nom de « LaboSchemas »

Prenez pour bonne habitude de directement changer le nom de déploiement du projet pour « LaboSchemas ».
Pour rappel, changer le nom de déploiement d’un projet se fait dans les propriétés du projet, Onglet « Configuration Properties à Deployement », champ « Application Name »

Ainsi que de lui attribuer un clé de signature.

Pour rappel, cette clef se change dans les propriétés du projet, onglet « Common Properties à Assemly », champ « Assembly Key File »

· Dans l’explorateur de solution, cliquez avec le bouton droit de la souris sur votre projet et sélectionnez « Add à New Item… »

· Dans la boîte de dialogue « Add New Item », sous l’onglet « Schema Files », choisissez le template « Schema » et nommez le « AdresseDeLivraison »

· Cliquez sur Add.

· L’éditeur de schémas s’est maintenant ouvert dans Visual Studio, avec à gauche une représentation sous forme de TreeView, et à droite le code XSD de notre schéma.

· Dans le TreeView, cliquez sur « Root » avec le bouton droit de la souris et renommez le « AdresseDeLivraison »

· Cliquez avec le bouton droit de la souris sur le nœud « adresseDeLivraison » et sélectionnez « Insert Schema Node à Child Field Element », nommez cet élément « Ville ».

· Recommencez l’étape précédente pour les champs suivant :

o Pays
o Rue
o Emai
o Fax
o Localité
o CodePostal
o Téléphone

· Enregistrez votre schéma.

Comme nous pouvons le remarquer sur cette image :

Il existe différent type d’élément de schéma. Les plus intéressants étant les suivant :

	Un child record est un enfant polymorphe qui peut contenir tout et n’importe quoi. C’est l’élément le plus simple qui existe. En XML, il se présentera sous forme d’un élément enfant : <NoeudRoot><Enfant/></NoeudRoot>
	Le field attribute est l’équivalent du child record hors mit qu’en XML il se représentera sous forme d’un attribut : <NoeudRoot Attribut= « »/>
	Similaire au child Record en ce qui nous concerne excepté que celui-ci ne peut pas contenir d’enfant.
	L’élément sequence group permet de définir des séquence tel que celle-ci : <Livres> <Livre/> <Livre/> <Livre/> </Livres>

Différentes contraintes sont applicables à ces éléments. Vous en trouverez une liste en cliquant sur l’élément « Ville » de notre précédent schéma, dans le panel des propriétés de l’élément.

Ces contraintes, une foi intégrées au schéma, seront vérifiées par BizTalk à chaque étape d’un processus métier. Si l’une d’elle n’est pas respectée, le message sera mit en attente d’une action d’un administrateur, pour peu que l’erreur généré ne soit pas gérée dans le code du processus.

Threading et Mutex - AutoResetEvent - ReaderWriterLock

Togis — Fri, 09 Nov 2007 15:48:44 +0200

Ca y est, la mode est lancée, on n'entend plus parler que de programmation asynchrone, parrallèlle, etc. Tout ça en prévision d'un futur, pas si lointain que ça, où nous n'aurons plus assé de doigts pour compter le nombre de core processeur notre pc contient.

Le multithreadé est l'avenir, et bien que l'on espère voir apparaître un jour un super framework qui gérera tout ça pour nous en attendant il faut bien ressortir nos vieux bouquins et se demander : "mais, et si je devais programmer du multithreadé maintenant, et si je voulais le faire bien pour une foi, quel patern devrais-je appliquer?"

Et bien, rien de plus simple ;) (Ca fait peur quand ça commence comme ça non?)

Tout d'abord, revoyons rapidement deux bases : les mutex et les events.

Mutex

Le mutex est un des moyens les plus bas niveau pour proteger l'acces concurent à une ressource partagée.

On peut voir un mutex comme une clefs unique pour un verou unique. Si je prend la clefs, mon voisin ne saura pas la prendre tant que je ne l'aurais pas remise sur la table, et donc va attendre que je la repose avant de continuer.

En C# la class Mutex contient 2 methodes indispensable :

WaitOne() : (ou "Prendre la clefs") Vérifie qu'aucun autre thread n'a la main sur le Mutex, dans le cas contraire, bloque le thread appellant jusqu'à la libération du Mutex par celui qui le possède.
ReleaseMutex() : (ou "Rendre la clefs") Libère le Mutex.

Voici un exemple de code pour illustrer les Mutex, dans ce cas-ci aucune ressource n'est protégée, mais le principe est le même, la ressource protégée doit être accédée uniquement quand le thread courant possède le Mutex. (Dans le cas d'un Mutex, si l'on ne joue pas le jeu, le système ne criera pas sur vous).

[code:c#]
using System.Threading;

namespace Blog
{
class Program
{

      private void ThreadWriteLine(string s)
      {
           Console.WriteLine(Thread.CurrentThread.ManagedThreadId + " > " + s);
      }

       public void TimerCallback(object MutexHandle)
       {
           ThreadWriteLine("Waiting mutex");
           (MutexHandle as Mutex).WaitOne();
           ThreadWriteLine("I have the mutex ! --> sleep");
           Thread.Sleep(5000);
           ThreadWriteLine("Releasing mutex");
           (MutexHandle as Mutex).ReleaseMutex();
      }

      static void Main(string[] args)
      {
          Program p = new Program();
          Mutex MutexHandle = new Mutex(false);

          for (int i = 0; i < 5; i++)
          {
              Timer T = new Timer(new TimerCallback(p.TimerCallback), MutexHandle, 0, 0);
          }
          Console.ReadKey();
      }
    }
}
[/code]

AutoResetEvent

Les évents, ou plustôt les AutoResetEvents vont nous permettre d'envoyer un signal d'un thread à un autre.

Cette Class contient elle aussi deux méthodes :

WaitOne() : met le thread courent en attente jusqu'à ce qu'un autre emette un évènement sur ce même AutoResetEvent
Set() : emet un évènement sur un AutoResetEvent

Une foi de plus, voici un petit bout de code pour illustrer l'utilisation des AutoResetEvent :

[code:c#]
namespace Blog
{
    class Program
    {
        public void TimerCallback(Object waitHandle)
        {
            ThreadWriteLine("TimeCallBack Begin");
            Thread.Sleep(1000);
            (waitHandle as AutoResetEvent).Set();
        }

        static void Main(string[] args)
        {
            Program p = new Program();
            AutoResetEvent waitHandle = new AutoResetEvent(false);

Timer T = new Timer(new TimerCallback(p.TimerCallback), waitHandle, 0, 0);

waitHandle.WaitOne();

            p.ThreadWriteLine("Event Fired");
            Console.WriteLine("Press a key");
            Console.ReadKey();
        }

        private void ThreadWriteLine(string s)
        {
            Console.WriteLine(Thread.CurrentThread.ManagedThreadId + " > " + s);
        }
     }
}
[/code]

ReaderWriterLock

Nous avons vu qu'un Mutex pouvait protéger une ressource,mais avouons que c'est une méthode très bas niveau. Le framework .Net nous offre des class toute faites, prévue pour chaque situation, tel que celle-ci, le ReaderWriterLock.

Le ReaderWriterLock est une class qui permet de limiter l'acces à une ressource, de manière unitaire en écriture mais de manière concurente en lecture.

Soit :

Si deux threads essayent d'écrire dans la ressource simultanément, l'un des deux va devoir attendre la fin du travail du suivant
Si deux threads essayent de lire la ressource et qu'aucun autre thread n'est en train d'y écrire, il vont pouvoir le faire simultanément

Nous alos donc, cette foi, avoir 4 méthodes au lieu de 2 :

AcquireWriterLock() : demande de permission d'écrirure, si un autre thread à déjà cette permission, cette méthode est bloquante
ReleaseWriterLock() : libère la permission d'écriture
AcquireReaderLock() : demande de permission de lecture, su un autre thread possède la permission d'écrire, cette méthode est bloquante
ReleaseReaderLock() : libère la permission de lecture

Dans l'exemple qui suit, un thread writer crée un thread enfant demandant une permission de lecture, on constate que cette permission ne lui est accordée que quand le thread writer à effectué son ReleaseWriterLock().

[code:c#]
using System;
using System.Threading;

namespace ConsoleApplication9
{
class Program
{

private ReaderWriterLock LockHandle;
private string val;

        public Program()
        {
            LockHandle = new ReaderWriterLock();
            val = "";
        }

        private void ThreadWriteLine(string s)
        {
            Console.WriteLine(Thread.CurrentThread.ManagedThreadId + " > " + s);
        }

        public void Read()
        {
            LockHandle.AcquireReaderLock(Timeout.Infinite);
            ThreadWriteLine("AcquireReaderLock > val :'" + val + "'");
            Thread.Sleep(1000);
            ThreadWriteLine("ReleaseReaderLock > val :'" + val + "'");
            LockHandle.ReleaseReaderLock();
        }

        public void Write()
        {
            LockHandle.AcquireWriterLock(Timeout.Infinite);
            ThreadWriteLine("AcquireWriterLock! > writing start");
            int id = LockHandle.WriterSeqNum;
            ThreadWriteLine("WriterSeqNum = " + id);
            Thread.Sleep(1000);
            val = "Hello ";
            Thread.Sleep(1000);
            (new Thread(new ThreadStart(this.Read))).Start();
            val += "World ";
            Thread.Sleep(1000);
            val += "I'm ";
            Thread.Sleep(1000);
            val += "a writer !";
            Thread.Sleep(1000);
            ThreadWriteLine("ReleaseWriterLock");
            LockHandle.ReleaseWriterLock();
        }

        static void Main(string[] args)
        {
            Program p = new Program();

            Thread[] writer = new Thread[10];

            for (int i = 0; i < 3; i++)
            {
                writer[i] = new Thread(new ThreadStart(p.Write));
            }

            for (int i = 0; i < 3; i++)
            {
                writer[i].Start();
            }
            Console.ReadKey();
        }
    }
}
[/code]

NB : Ceci n'est qu'un exemple, généralement, éviter d'utiliser ThreadStart, choisisez de préférence l'utilisation du pool de thread de l'application.

Conclusion

Il existe déjà dans le monde .Net de nombreux moyens pour synchroniser différents threads lorsque néccessaire. De nombreuses règles de bonnes pratique existe et nous évite de nous arracher les cheveux.

Ce que l'avenir nous réserve dans tout ça ? Avec la mutiplication des traîtements parrallèle, l'écriture "humaine" d'une gestion de ces traîtements sera rapidement longue, fastidieuse, voir impossible. Nous allons voir apparaître de nouveaux languages (tel que le F#) ainsi que des librairies pour les languages existants (tel que Microsoft.Research.Join) nous permettant une programmation plus déclarative que celle à laquelle nous sommes habitué.

Mais je pense qu'il ne faut pas négliger les bases, ces concepts, même s'ils deviendront peut-être invisibles, seront de plus en plus existant au sein même de nos applications.

WPF - Binding List to UI - Un petit résumé rapide mais utile

Togis — Thu, 08 Nov 2007 15:17:00 +0200

Nous pouvons voir partout de nombreux exemples expliquant comment binder une liste d'éléments vers une interface xaml de notre application, voici en passant, un résumé reprennant les différentes étapes pour mettre en place ce genre de binding.

Que Binder ?

Techniquement, vous pouvez binder n'importe quelle type de liste, que ce soit une List<Generique>, un tableau, une ArrayList, tout passera, cependant, vous vous rendrez vitte compte que seul les ObservableCollection<> offrent un support pré-intégré pour l'update du binding lors de l'ajout ou du retrait d'un élément de la collection.

Donc, à mon avis, quitte à avoir parfois besoin d'ObservableCollection, hors mit autre contrainte, autant toujours les utiliser.

Ou binder ?

La class ItemsControl est la class de base des conteneur de list de n'importe d'item. De cette class dérive tout ce qui est Menu, ListBox, ComboBox, TreeView, ...
Tout ce qui est customisable sur un ItemControl est donc aussi customisable sur un de ses dérivé.

Binder une liste se fait des deux coté de notre interface, premièrement dans les déclaration xaml, ensuite dans le code behind.

Prennon un exemple simple, une liste d'employés :

Creation de notre class d'exemple

[code:c#]
class Employee
{
    private string _nom;
    public string Nom
    {
        get { return _nom; }
        set { _nom = value; }
    }

    private string _prenom;
    public string Prenom
    {
        get { return _prenom; }
        set { _prenom = value; }
    }

    private int _age;
    public int Age
    {
        get { return _age; }
        set { _age = value; }
    }
}
[/code]
Création de notre ObservableCollection dans le code behind de notre application

[code:c#]
public Window1()
{
InitializeComponent();

    ObservableCollection<Employee> list = new ObservableCollection<Employee>()
    {
        new Employee() { Prenom = "Simon", Nom = "Boigelot", Age=22 },
        new Employee() { Prenom = "Loïc", Nom = "Bar", Age=19 },
        new Employee() { Prenom = "Thieu", Nom = "Lizin", Age=21 }
    };
}
[/code]

Creation de notre ItemControl dans les déclaration xaml

[code:xml]
<Window x:Class="SimpleBinding.Window1"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Title="Window1" Height="300" Width="300">
    <Grid>

        <ItemsControl Name="myItemControl"/>

    </Grid>
</Window>
[/code]

Nous avons maintenant une liste, un endroit ou l'afficher, mais il manque encore un lien entre les deux.

Ce lien se fait à partir de la propriété ItemSource de notre ItemsControl.

Définir l'ItemSource dans le code behind

Par exemple, nous pouvons simplement lier notre liste à notre ItemsControl dans le code behind :

[code:c#]
myItemControl.ItemsSource = list;
[/code]

Le résultat sera directement visible :

Définir l'ItemSource dans les définition xaml

Malheureusement, bien que la solution précédente pour lier notre list à l'interface semble fonctionner, ce n'est pas celle qui sera retenue car elle ne respecte pas du tout la séparation entre le code et l'interface.

Imaginons, par exemple, vouloir retrouver cette liste à deux endroits différents de l'interface, dans ce dernier cas, il faudrait revenir dans le code behind et ajouter une ligne, ect.

La meilleur méthode pour binder une liste à une interface est de passer par un ObjectDataProvider :

Changer notre xaml pour y intégrer notre ObjectDateProvider

[code:xml]
<Window x:Class="SimpleBinding.Window1"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Title="Window1" Height="300" Width="300">
    <Window.Resources>
        <ObjectDataProvider x:Key="myEmployeeList"/>
    </Window.Resources>
    <Grid>
        <ItemsControl Name="myItemControl">
            <ItemsControl.ItemsSource>
                <Binding Source="{StaticResource myEmployeeList}"/>
            </ItemsControl.ItemsSource>
        </ItemsControl>
    </Grid>
</Window>
[/code]
Changer notre code behind pour lier notre list à notre ObjectDataProvider

[code:c#]
public Window1()
{
    //init + create list

    ObjectDataProvider odp = this.FindResource("myEmployeeList") as ObjectDataProvider;
    odp.ObjectInstance = list;
}
[/code]

Le résultat est exactement le même que dans le dernier exemple, mais nous passons par un intermédiaire suppléméntaire qui assure la séparation du code.

Comment rendre le tout lisible ?

Par defaut, le binding utilise la méthode ToString() des objects que vous lui donner.

ToString()

Une première méthode pour rendre votre binding lisible est donc simplement d'overrider cette méthode :

[code:c#]
public class Employee
{

    //properties...

    public override string ToString()
    {
        return Nom + " " + Prenom + " (" + Age + ")";
    }
}
[/code]

Résultat:

Mwai, mais encore une foi, comme toute première méthode, elle ne respecte pas la séparation du code, qui plus est, si l'on désire afficher différement des employés à un endroit de l'interface et à un autre... ca coince.

Cette méthode ne sera jamais utilisée comme méthode d'affichage définitive, mais elle peut avoir son utilité lors du developement.

DataTemplate

Voici la façon la plus belle de rendre lisible tout notre brol. Un DataTemplate est une structure xaml qui sera appliquée à chacun des items de notre ItemsControl.

Ici le changement ne se fait que dans le code xaml, l'idépendance avec le code behind est parfaite !

[code:xml]
<Window x:Class="SimpleBinding.Window1"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Title="Window1" Height="300" Width="300">
    <Window.Resources>
        <ObjectDataProvider x:Key="myEmployeeList"/>

        <DataTemplate x:Key="EmployeeDataTemplate">
            <Border CornerRadius="5" Margin="3"
                    BorderBrush="Black" BorderThickness="1">
                <WrapPanel>
                    <Label Content="{Binding Path=Nom}"/>
                    <Label Content="{Binding Path=Prenom}"/>
                    <Label Content="{Binding Path=Age}"/>
                </WrapPanel>
            </Border>
        </DataTemplate>
    </Window.Resources>
    <Grid>

        <ItemsControl Name="myItemControl"
                      ItemTemplate="{StaticResource EmployeeDataTemplate}">
            <ItemsControl.ItemsSource>
                <Binding Source="{StaticResource myEmployeeList}"/>
            </ItemsControl.ItemsSource>
        </ItemsControl>

    </Grid>
</Window>
[/code]

Résultat:

Conclusion

Voilà, vous avez binder correctement votre liste d'objet, du moins pour ce qui est de l'affichage. Il nous faudra parler de la modification dans un futur proche.

Quelques autres post pourons vous être utiles :