Nouvelles Chroniques d'Amethyste

Penser au Sens, pas au Verbe


Poster un commentaire

Les 4 modes d’échange de données

Il existe 4 mode d’échange de données entre deux systèmes.

 

La télémétrie c’est lorsqu’un périphérique envoi des données en continue ou par intermittence vers un service.

2016-04-02_17-30-33

Une habitation peut être équipée de capteurs qui vont relever des températures, éclairage, humidité…

La notification fonctionne en sens inverse de la télémétrie:

2016-04-02_17-47-52

La requête concerne le cas ou un périphérique interroge un service interne afin d’obtenir des informations:

2016-04-02_17-41-27

Par exemple le système de chauffage connecté de la maison détecte une baisse des températures et demande s’il doit augmenter le chauffage.

Le mode commande fonctionne dans le sens inverse du précédent. Le serveur envoi une requête vers un périphérique qui lui répond:

2016-04-02_17-44-26

Vous demandez à votre habitation connectée les courbes de température de la journée.


Poster un commentaire

Inversion de contrôle, Injection de dépendance et Service locator

A l’origine de ces techniques, la volonté de maîtriser la complexité des applications et des frameworks.

Comment s’assurer que le code soit testable unitairement?

Comment maîtriser les impacts d’un correctif ou d’une évolution?

Comment organiser du code en unités logiques plus faciles à comprendre?

Comment ajouter de nouvelles fonctionnalités?

Peut t’on choisir dynamiquement un comportement?

 

Supposons par exemple que nous disposions d’une Dll MyDll, on pourrait écrire typiquement ce type de code:

using MyDll;

class ClasseX
{
   void MaFonction()
   {
       ClasseY maClasseY = new ClasseY();
       maClasseY.LireDonnees();
       maClasseY.TraitementDonnees();
   }
}

C’est la structure du code qui nous intéresse, on pourrait la représenter ainsi: 2015-09-04_09-27-04 On a une classe ClasseX qui constitue notre application. Cette classe utilise ClasseY venue de la Dll. Il existe donc une dépendance de ClasseX envers ClasseY.

Si vous réexaminez la liste (non exhaustive) de questions posées en début de ce texte, il n’est pas difficile de voir les nuages qui se profilent à l’horizon. Par exemple il n’est pas facile de remplacer ClasseY par ClasseZ qui implémente un autre algorithme de traitement des données, surtout si ClasseY est utilisée un peu partout dans l’application. Et ce n’est qu’un exemple, de multiples autres Dll peuvent parfaitement être utilisées tout au long de l’application. La difficulté croît de façon exponentielle.

L’application sera difficilement maintenable.

Lire la suite


Poster un commentaire

C’est quoi une Single Page Application (SPA)?

Voici un exemple de terme que tout le monde croit connaître, mais mis au défi de le définir, lors d’un entretien par exemple, les difficultés surgissent rapidement.

Est-ce vraiment une application avec une seule page?  Regardez alors cet exemple proposé par John Papa:

http://cc-ng-z.azurewebsites.net/#/

Cette application gère le planning d’orateurs lors d’un congrès.

 

On a des menus qui permettent de naviguer au delà de la page d’accueil, si on clique sur orateur on voit s’afficher son planning….

En apparence on a plusieurs pages, mais pourtant il s’agit d’une application SPA!

 

La difficulté que l’on éprouve à définir ce qu’est une SPA est entièrement là: un problème de vocabulaire. Peut être que l’expression SPA est mal choisie comme le suggère John Papa dans cet article qui inspire le mien:

http://www.johnpapa.net/pageinspa/

Nous allons essayer de clarifier les choses.

Lire la suite


Poster un commentaire

Windows Activation Service (WAS)

Il est possible d’héberger des services WCF de 3 façons (au-moins):

  1. Dans IIS
  2. Dans une application console, Windows Service ou Winform
  3. Avec le service WAS hébergé par IIS

 

Hébergement IIS

J’ai écris une série d’articles qui montre les différentes façons d’héberger un service WCF dans IIS. Le premier de la série est:

https://amethyste16.wordpress.com/2013/05/18/programmer-avec-les-services-2/

 

Hébergement dans un AppDomain
L’hébergement dans une application de type application console se réalise avec une instance de ServiceHost

Note: Les autres hébergement utilisent aussi ServiceHost en interne, il est juste masqué à l’utilisateur

Voici un article avec un exemple:

http://msdn.microsoft.com/fr-fr/library/system.servicemodel.servicehost(v=vs.110).aspx
ServiceHost est un conteneur pour héberger WCF et fournir une description du service accessible via Wsdl. Il gère aussi un cycle de vie via divers événements comme Closed, Closing…

Ce type d’hébergement est appelée self-hosting car on doit alors tout prendre en charge:

  • Instancier le service et initialiser l’environnement
  • Gérer son paramétrage
  • Gérer la montée en charge
  • Gérer le recyclage et le cycle de vie
  • Gérer les logs et les exceptions
  • Gérer le monitoring

Seuls IIS et WAS propose ces extensions de services de façon intégrées. C’est ou ce n’est pas utile à votre application. Comme toujours, le besoin prime.

Si vous choisissez cette option, je recommande fortement d’utiliser un service Windows. L’application console (voir WinForm) a ses adeptes, mais je n’en comprends même pas l’intérêt en production.

 

Hébergement WAS

WAS est arrivé avec IIS 7. Il s’agit donc d’une extension de IIS.

L’intérêt de l’hébergement WAS est que l’on n’a pas la dépendance avec Http. On peut donc utiliser n’importe quel protocole WCF (TCP, MSMQ…), mais on garde les services standards de IIS (monitoring, cycle de vie, gestion temps morts…).

Important: WAS n’est disponible qu’en mode pipeline intégré.

 

IIS a apporté quelques modifications dans l’architecture IIS justement pour pouvoir supporter WAS. On parle d’écouteurs de protocole, d’adaptateurs et de gestionnaires de protocoles:

  • Ecouteurs de protocole (protocol listeners)
    Un service dont le rôle est de recevoir des requêtes dans un protocole donné. On a toujours l’écouteur Http hérité de IIS 6 (http.sys), mais on en a de nouveau avec WAS
  • Adaptateurs (listeners adapter)
    C’est un adaptateur au sens développé dans cet article:
    https://amethyste16.wordpress.com/2014/07/02/comparaison-des-patrons-proxy-adaptateur-et-facade/
    Son rôle est de traiter la requête reçue dans un protocole, mettre éventuellement la requête dans une queue et enfin la router vers le worker process qui pourra la traiter à l’aide d’un gestionnaire de protocole.
  • gestionnaires de protocole (protocol Handlers)
    Le gestionnaire instancie (si nécessaire) un ServiceHost pour le protocole demandé et lui passe la requête à traiter.

Une petite infographie et ce sera sans doute plus clair. Elle est tirée de l’article de Michele Leroux Bustamante cité plus bas:

2014-08-14_17-30-59

 

Comme on le voit, la nouvelle architecture permet à IIS de traiter n’importe quelle requête de n’importe quel protocole de façon homogène.

 

Si vous souhaitez en savoir plus (et notamment comment activer WAS dans IIS), lisez cet excellent article de Michele Leroux Bustamante:

http://www.codemag.com/Article/0701041

J’ai bien aimé également cet article écrit aussi par une femme:

http://searchwindowsserver.techtarget.com/definition/Windows-Process-Activation-Service-WPAS

 

Un exemple d’hébergement WAS:

http://msdn.microsoft.com/fr-fr/library/ms733109(v=vs.110).aspx

http://www.wcftutorial.net/wcf-was-hosting.aspx

 

 

Maintenant le moyen le plus simple d’exploiter WAS reste Windows AppFabric. A suivre justement un article sur ce thème.

 


Poster un commentaire

Processus et domaine d’application

Processus

Un processus (process) est un conteneur pour un (ou plusieurs) exécutables (un programme) et ses données. Le processus fournit à l’exécutable un espace mémoire réservé par le système d’exploitation. De plus le processus est parcourut par au moins 1 thread, mais très souvent on en rencontre plus. Toutes ressources ou fichiers ouverts ou créés par le programme appartient lui aussi au processus.
Pour finir un processus embarque un contexte de sécurité qui lui est propre. Ce contexte dicte au processus ce qu’il a le droit ou non de faire sur la machine, le réseau ou toute autres ressources.

Comme on le voit, un processus agit comme une frontière pour isoler un programme des autres programmes. Le processus est la plus petite unité d’isolation d’un code sous Windows.
Une erreur, un plantage dans un processus, n’affecte que les applications qui tournent dans le processus. Les autres processus ne sont pas affectés si ce n’est pas un éventuel verrou sur une ressource, l’utilisation d’espace mémoire…

Théoriquement, un serveur voulant héberger plusieurs sites ou plusieurs services créera autant de processus qu’il y aura d’instances afin de les isoler les uns des autres.
Seulement la création d’un processus est une opération coûteuse en ressources système. On va rapidement atteindre les limites physiques du serveur.

Domaine d’application

L’environnement .Net propose une solution à ce problème: le domaine d’application (application domain).

Par certains aspects, les domaines d’application (DA) ressemblent à un processus: ils sont à la fois frontière et conteneur. Cela signifie en particulier qu’un objet vit dans un et un seul DA. Par exemple une classe avec des propriétés statiques ne partagera pas son état avec un autre DA, chaque application a sa propre copie de cache, session…

Il y a toutefois des spécificités:

  • Il ne s’agit que d’un concept .Net. Windows ne gère pas les domaines d’application.
  • Les DA n’ont pas leur propre contexte de sécurité. Ils utilisent celui du processus
  • Les DA appartiennent à un seul processus, mais un processus peut héberger plusieurs DA

Ce dernier point peut être important surtout si l’on sait que par défaut ASP.NET est lancé en full trust.

Un DA est moins coûteux à créer et a besoin de moins de ressources puisqu’ils partages celles de leur processus hôte.

Il est possible de savoir combien de DA sont chargés dans un processus avec perfmon.exe:

2014-08-09_21-03-50

Vision développeur

Les processus sont pris en charge par la classe Process. Par exemple le code suivant fournit le processus courant:

Process process = Process.GetCurrentProcess();

L’instance expose un grand nombre de propriétés comme la collection de modules chargés en mémoire, la durée de consommation de la CPU, les threads…

On peut aussi choisir d’énumérer tous les processus disponibles:

foreach (Process process in Process.GetProcesses())
{
    Console.WriteLine(process.ProcessName);
}

Chaque application .Net tourne dans un DA. On peut obtenir des informations à son sujet avec le code suivant:

AppDomain appDomain = AppDomain.CurrentDomain;

Et les états du domaine:

2014-08-09_19-06-24