"Managed Services Engine" (MSE) est un produit d'infrastructure SOA qui met en œuvre les principes de la "Virtualisation de Services".En pratique, MSE est un médiateur entre des consommateurs et des producteurs pourfaciliter le déploiement, la réutilisation et les changements des services.

A partir d'un référentiel de gestion de méta-données associées aux services (Endpoints, Operations, Schemas, Bindings, Channels, Policies), MSE permet de versionner les opérations, router et transformer les messages, et s'assurer que les politiques sont bien respectées ("policy enforcement")

MSE est développé pour la plate-forme Windows (WCF pour gérer les communications et MS SQL Serveur pour le référentiel) mais permet de virtualiser tous types de services, que ce soit .Net, Java ou PHP.

Les équipes Services de Microsoft sont à l'origine de ce framework qui est doréavant disponible en version 6.2 sur CodePlex sous licence opensource (Licence Public). Les équipes Pattern & Practices doivent se charger par la suite de la maintenance et des évolutions de MSE, comme c'est déjà le cas pour d'autres technologies SOA telles que l'ESB guidance et la Service Software Factory.

 

Qu'est-ce que la Virtualisation de Services

Dans une approche SOA, on commence par exposer des services à partir de son existant. Dans un second temps, on s'occupe de composer des services. Cette coordination passe par le routage et la transformation des messages. C'est à ce stage que les concepts d'ESB et de virtualisation de services apparaissent.

La virtualisation répond à la problématique de gestion du changement, là où les ESB sont plutôt spécialisés sur les aspects exposition via des connecteurs, mais aussi des fonctionnalités liées au routage et à la transformation de messages. La virtualisation de services nécessite toutefois de disposer de fonctionnalités basiques de routage et de transformation. Dans certaines offres, la virtualisation de services est considérée comme une fonctionnalité de l'ESB. C'est le cas de SOA Software et de Neudesic Neuron ESB.

Pourquoi virtualiser les services ? En fait, WSDL ne prend pas en compte les aspects versionning. De plus, la description WSDL lie plusieurs notions : les opérations, les messages, et les bindings, si bien qu'il est difficile de personnaliser un contrat, ou de modifier de façon indépendante telle ou telle partie. Bref, si WSDL est bien adapté pour assurer l'interopérabilité, on doit compléter cette description sitôt que l'on veut mettre en place une SOA d'Entreprise. Notamment, il y a deux tâches à entreprendre :

  1. Dissocier les éléments d'un contrat WSDL en plusieurs descriptions indépendantes
  2. Associer des versions à ces descriptions

Ces informations sont généralement stockées dans un référentiel de description des services (Méta-données) communément appelé "Service Repository". Ce référentiel regroupe les artefacts associés aux services :

  • Les opérations exposées et les configurations des ports de communication (Operations, Endpoints, Bindings, Channels)
  • Ainsi que les descriptions associées ( Schemas et Contracts)

Pour élargir cette réflexion, je vous invite à consulter l'article de SOA World qui positionne notamment les fonctionnalités liées à la Virtualisation de Services en regard de celles associées à un ESB.

 

 

Spécifications techniques du Managed Services Engine

 

Les architectes MSE ont choisi de structurer les méta-données en Endpoints, Operations, Schemas, Bindings, Channels, Policies.

La gestion des versions s'effectue au niveau des opérations, si bien qu'une opération se présente comme un service virtuel. Chaque version d'opération expose ainsi une description, un binding et des messages entrants et sortants. La figure ci-dessous présente le méta-modèle du MSE en regard du méta-modèle WSDL .

 

Pour être tout à fait exhaustif, notons qu'il est possible d'attacher une transformation aux messages entrants et sortants sous la forme d'un XSLT. Naturellement, cette transformation est spécifiée au niveau des messages associés à une version de l'opération. Par ailleurs, un Moniker peut être utilisé afin d'émuler une version d'opération, et ce à 2 fins possibles :

  1. Emuler un service n'existant pas encore, en retournant dans ce cas, un message entendu (bouchon). Utile pour la phase de développement et tests
  2. Se substituer un service déprécié (et éventuellement supprimé) en routant vers un nouveau service (une opération dans le cas de MSE) en prenant soin au niveau du Moniker de faire les transformations nécessaires sur les messages entrants et sortants. Bref, un Moniker, 2 XSLT et une version d'opération de substitution.

Le dernier point concerne le respect des politiques "Policy Enforcement". Dans la mesure où les descriptions et l'ensemble des flux sont véhiculés depuis et au travers du MSE, il est possible de placer des filtres chargés d'implémenter ces politiques. 3 policy sont fournies à titre d'exemple au sein de la console d'administration du MSE.

 

 

Architecture du Managed Services Engine

Les spécifications évoquées précédemment sont implémentées au sein de 2 composants majeurs, complétés d'outils d'administration :

  • Service Catalog
    • Catalog Repository : Le Referentiel sous Microsoft SQL Serveur
    • Catalog Server : Le gestionnaire du référentiel (utilisé en phase de développement / configuration)
  • Service Runtime Engine
    • Runtime Server : le moteur d'exécution du serveur de virtualisation des services

 

Le Runtime Server met en œuvre un pipeline qui enchaîne 3 modules de façon séquentielle afin de traiter un message : Messenger, Broker et Dispatcher. Ce concept est récurrent dans les interfaces de communication des produits de médiation (WCF, BizTalk, ESB guidance…). Concernant MSE, retenez qu'il est possible de dissocier le Messenger du Broker/ Dispatcher, qui communique alors via un canal WCF au binding configurable. Cette dissociation est utile pour adapter l'architecture de production aux contraintes d'exploitation. La figure ci-dessous présente un exemple :

 

 

 

 Termes de licence

 

La licence d'utilisation présentée sur CodePlex et reprise dans l'installeur est opensource, de type "Public" (il s'agit du renommage de la licence MS-Permissive suite à la reconnaissance des licences opensource Microsoft par l'OSI le 16 octobre 2007).

 

La licence Microsoft Public Licence  stipule que vous êtes donc libre de modifier, compléter, redistribuer ce code sans en avertir Microsoft ni verser de  contre-partie.

 

Voilà qui devrait permettre à MSE de venir compléter les offres d'éditeurs de logiciels et d'intégrateurs autour de la SOA, ainsi que des développements BizTalk.

 

 

Installation

 

Un guide détaille l'installation  pour XP, Vista et Windows Server. Dans la mesure où il s'agit d'un produit d'infrastructure, en production vous serez intéressés pour une installation sur version Windows Serveur. Pour l'utilisation en développement sous Visa et Windows Server 2008, 3 mots, "Run as administrator".

 

L'installeur rappelle les composants de MSE :

    • Catalog Repository : Le Referentiel sous Microsoft SQL Serveur
    • Catalog Server : Le gestionnaire du référentiel (utilisé en phase de développement / configuration)
    • Runtime Server : le moteur d'exécution du serveur de virtualisation des services
    • Administration tools : un console MMC et des commandes en ligne
    • Plus de la documentation, des exemples, et un client de tests.

 

 

Attention: par défaut l'installation de SQL Express n'est pas supportée (vous aurez un échec au moment de la configuration de la base de données).

 

Si vous voulez utiliser SQL Express (version gratuite de Microsoft SQL Serveur), lire le manuel d'installation. En résumé :

  • Lancer la commande msiexec à la main: > msiexec /i "MSE6.msi" SQLSERVER=.\SQLEXPRESS
  • L'installation terminée, éditer le fichier " C:\Program Files\Microsoft Managed Services Engine\Microsoft.MSE.Repository.Service.exe.config"
    • Remplacer la valeur de <DBConnString>… à la ligne 9
    • par <DBConnString>Initial Catalog=MSE6DB; Data Source=.\ SQLEXPRESS;MultipleActiveResultSets=True;Integrated Security=SSPI</DBConnString>
  • Lancer les services  “MSE Catalog Server” puis “MSE Runtime Server" qui n'avaient pas pu démarrer

Si vous rencontrez toujours un problème à l'installation, cela peut être lié à une anomalie avec SQL Express, qui a été corrigée le 3 novembre. Assurez-vous que vous disposez bien de la version 6.2 CTP d'une taille de 8913 KB .

 

 

 Walkthrough

 

En 30 minutes, ce guide vous propose de mettre en œuvre des fonctionnalités suivantes, sur un scénario simple où le Runtime Server joue à la fois le rôle de Messenger et de Broker / Dispatcher :

  1. Lancement des Services
  2. Initialisation du Runtime Server
  3. Creation d'un premier EndPoint
  4. Chargement d'une opération (exemple d'un service qui fournit une opération de Calcul)
  5. Création d'un second EndPoint (correspondant à un second service qui fournit une même opération de Calcul)
  6. Déclaration d'une nouvelle version
  7. Suppression de la première implémentation (on arrête le service)
  8. Appliquer une "policy" au service

Attention à bien relancer le service "MSE Runtime Server" lorsque vous modifiez la configuration des runtimes (ajout du runtime en phase 2.)

Pour moi, le scénario a fonctionné lorsque j'ai nommé mon runtime de la même façon que ma machine (à bon entendeur...)