SOA & Interop @ Microsoft France : Gouvernance

Les Bus de Services en pratique

Steve SFARTZ — Tue, 22 Jul 2008 16:52:00 GMT

En février 2008, Anne Thomas Manes du Burton Group publiait l’étude « Enterprise Service Bus: The Volatile Market Landscape » et conseillait de voir les bus de services comme multiples au sein d’une organisation et comme des plate-formes applicatives couplées à un modèle de programmation plutôt que comme une infrastructure centralisée, point de passage obligé pour tous les messages échangés entre les services.

Si l’objectif d’un bus de services est bien d'assurer les échanges des messages, plusieurs options s’offrent à nous pour établir ces communications : le mode « point à point » ou bien « brokered ».

Dans les 2 cas, il est nécessaire d’intégrer les capacités techniques suivantes pour que ces solutions d'échanges de messages puissent s'intégrer dans une vision Services : traçabilité et monitoring technique pour vérifier les engagements de SLA, suivi d’activité métier pour ajuster / piloter l’activité métier, configuration centralisée et/ou synchronisée des paramètres de connectivité entre les services (endpoint, bindings), capacité d’intervention au niveau du contenu et du routage des messages en amont ou en aval pour être capable d’assurer le respect des policy et gérer les évolutions de versions.

Détaillons les propositions de Microsoft et de ses partenaires sous cet éclairage, en intégrant les annonces technologiques de ces derniers mois ainsi que certains compléments disponibles en opensource :

Mode Point à Point : Le framework de communication WCF, proposé au sein du framework .Net, apporte une flexibilité extrême en terme d’adaptation de protocoles et de formats d’échanges. Afin de l’intégrer dans une vision Bus de Services, on complètera WCF par les extensions BAM de BizTalk, une gestion de configuration centralisée telle que « Configuration Services v2 », un hébergement capable de gérer le versioning et l’adaptation de protocoles tel que « Managed Services Engine », et la panoplie d’indicateurs techniques built-in : Logs, instrumentation WMI et compteurs de performances.

Mode Brokered : La passerelle de services « Managed Services Engine » proposée par Microsoft Services permet d’adapter les protocoles et formats d’échanges (par exemple du SOAP sur TCP vers de l’XML sur HTTP) mais aussi de router des messages vers la version ad-hoc des services concernés. Néanmoins, la technologie ne permet pas d’assurer de routage dynamique (notamment l’établissement d’un itinéraire en fonction du contenu des messages), tel que proposé par les Entreprise Service Bus.

Mode Brokered : Les Enterprise Service Bus tel que l’ESB guidance proposé en téléchargement par les équipes Microsoft Pattern & Practices ou bien Neuron ESB proposé par le partenaire Neudesic reposent sur les capacités de connectivité de WCF et la robustesse et montée en charge de BizTalk Server. Par ailleurs les connecteurs WCF (SOAP, XML, JSON, ainsi que le BizTalk Adapter Pack) sont enrichis par la large panoplie de connecteurs de BizTalk Server (MainFrame, ERP, EDI, RFID, Métiers ...).

On comprend dès lors que ces technologies ne sont pas exclusives mais viennent se compléter. L'articulation suivante apparait notamment comme judicieuse :

WCF et BizTalk ESB Guidance comme infrastructure de communications à l’intérieur de l’entreprise
MSE comme passerelle d’entrée sur le système d’informations (Internet Services Gateway)
et WCF pour une consommation étendue aux mobiles et à des clients riches occasionnellement connectés.

Enfin, la gouvernance n'est pas en reste dans la mesure où l’ extensibilité de ces technologies permet de les gouverner avec un outillage commun tel que le démontre SOA Software en annonçant une gouvernance pour Team Foundation Server, pour WCF, pour BizTalk Server, et une certification pour Neuron ESB.

Pour vous accompagner dans l'implémentation de votre SOA d'entreprise, nous vous proposons de rencontrer nos experts du Microsoft Technology Center, ainsi que les équipes Microsoft Services qui proposent une méthodologie et l’outillage adaptable « Service Oriented Modeling » avec un support en environnement critique au travers de contrats Premiers.

BPMS, BPP et ICE

Steve SFARTZ — Fri, 11 Jan 2008 15:55:00 GMT

Janelle Hill, référent BPM du Gartner, présente dans cette interview sa vision de l'évolution du BPM, et la nécessaire adaptation des Quadrants Magiques :

Les entreprises continuent à investir sur la dimension agilité de leurs processus Métier. L'objectif : permettre aux équipes Métier d'adapter les processus au travers d'outils dédiés et sans avoir recours aux cycles de développements traditionnels, lesquels ne sont plus en phase avec les rythmes d' évolution de l'activité Métier.
Les suites BPM traditionnelles ont le défaut de ne pas être autosuffisantes : il est nécessaire de les compléter par de la documentation, et des outils de modélisation mais aussi d'interactions (Information Worker - Office) ciblant les utilisateurs Métier.
Le concept de suite BPM évolue vers un concept plus global : il s'agit de plateformes BPM (BPP) ainsi que d'environnements intégrés pour les applications composites (ICE).

Faisons la lumière sur ces acronymes en regard de la Plateforme Applicative Microsoft :

BPMS - Business Process Management Suite : BizTalk Server en version 2006 R2 assure les fonctionnalités d'un BPMS, et intègre notamment des modules BAM (suivi de l'activité métier), BRE (moteur de règles métier), HATS (monitoring de l'état de santé technique) ainsi que la connectivité au système d'informations (Adaptateurs techniques - protocoles, EDI et RFID - et connecteurs vers les ERP du marché)
BPP - Business Process Platform : Toute la plate-forme applicative Microsoft (BizTalk Server 2006 R2, Visual Studio Team Suite & Team Foundation Server, System Center) 2007 est sollicitée pour fluidifier la gestion des processus métier en (re)donnant notamment la main aux équipes Métier via les interfaces MOSS (Office SharePoint 2007), tout en gérant l'ensemble du cycle de vie des processus métier (et donc au travers des différents outils et runtimes impliqués).
ICE - Integrated Composition Environment : Stratégie qui consiste à composer des services plutôt que d'investir sur des développements sur mesure. Bref, ICE par opposition et/ou en complément des IDE. C'est l'objectif de l'initiative Oslo de Microsoft que de faciliter la création d'applications composites, en intégrant nativement les modèles à la plate-forme applicative Microsoft. Et ce, au travers d'un référentiel assurant la gestion du cycle de vie des modèles qui constituent le liant entre les phases d'analyse, conception, implémentation et déploiement des applications métier : en bref, "le modèle est l'implémentation".

Managed Services Engine : Une infrastructure communautaire de Virtualisation de Services

Steve SFARTZ — Thu, 08 Nov 2007 11:34:00 GMT

"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 :

Dissocier les éléments d'un contrat WSDL en plusieurs descriptions indépendantes
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 :

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
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 :

Lancement des Services
Initialisation du Runtime Server
Creation d'un premier EndPoint
Chargement d'une opération (exemple d'un service qui fournit une opération de Calcul)
Création d'un second EndPoint (correspondant à un second service qui fournit une même opération de Calcul)
Déclaration d'une nouvelle version
Suppression de la première implémentation (on arrête le service)
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...)