« Je connais mes limites. C'est pourquoi je vais au-delà. » : WCF

Plateforme SUN WSIT GlassFish hébergée au MTC Paris

stephgou — Tue, 01 Apr 2008 11:09:00 GMT

La semaine dernière, dans la continuité des travaux réalisés lors des ateliers d’interopérabilité organisés par la DGME (Direction Générale pour la Modernisation de l'Etat) pour le programme PRESTO, Alexis Moussine Pouchkine, architecte SUN (http://blogs.sun.com/alexismp/) et moi avons monté une plateforme WSIT GlassFish (serveur d’application) – Metro (Web Services) – NetBeans (Environnement de développement) au MTC (Microsoft Technology Center) Paris. L’objectif de cette plateforme est double :

· Disposer d’un environnement permanent permettant d’illustrer par des démonstrations techniques l'interopérabilité des plateformes .NET et JavaEE, via les technologies GlassFish/WSIT (https://wsit.dev.java.net/specification-links.html) et WCF (http://netfx3.com/content/WCFHome.aspx) implémentant les spécifications avancées des services Web.

· Offrir une réponse plus complète aux besoins de nos clients par la capacité à intégrer et à implémenter des scénarios complets d’interopérabilité pour les prototypes réalisés au MTC Paris dans le cadre de notre offre « SOA Accelerator Workshop ». Pour bâtir les « services » critiques du système d’information, il faut pouvoir intégrer les mêmes critères de qualité que proposent aujourd’hui les solutions orientées composants : sécurité, garantie de livraison des messages, routage, optimisation des échanges, transactions… autant de notions ayant fait l’objet de spécifications avancées : les standards WS-*. Les deux environnements WSIT et WCF implémentent ces standards. Les fonctions offertes sont volontairement très découpées de sorte qu’elles puissent être factorisées en cours d’évolution et se combiner pour offrir un traitement de bout en bout, l’objectif final étant d’abstraire le plus possible les mécanismes de communication et de rendre possible la création de véritables architectures d’applications distribuées fondées sur les services.

La mise en place de cette plateforme nous aura aussi permis de valider que le référencement d’un service WSIT depuis Visual Studio 2008 génère un binding WCF directement exploitable (plus besoin de rajouter le « binding » de niveau transport comme cela était le cas sur Visual Studio 2005). Les mises à jours des bindings après ajout de telle ou telle caractéristique de communication (MTOM) ou le support de mécanismes complexe, tel que le « Reliable Messaging », sont également assurées par un simple « Update Reference », sans nécessiter aucune édition manuelle du fichier de configuration.

Cette première « brique » fondatrice de la plateforme d’interopérabilité SUN-Microsoft au sein du MTC Paris sera très vraisemblablement étendue et complétée par d’autres actions, sur lesquelles je ne manquerai pas de vous tenir informés.

WCF Designer

stephgou — Fri, 15 Jun 2007 16:38:00 GMT

Il existe aujourd’hui de multiples moyens d'implémenter un Service WCF.

Il est possible de partir de zéro et d’enrichir manuellement classes, interfaces, en référençant System.ServiceModel.dll.

Avec les extensions WCF, Visual Studio fournit des modèles de génération de service, de l'intellisense sur le framework et le fichier de configuration, un éditeur SvcConfigEditor permettant de configurer manuellement bindings, behavior, endpoint du service...

L'équipe Pattern & Practices fournit un environnement de génération de code (Service Factory) basé sur le GAT/GAX facilitant de multiples aspects liés à la création d'un service WCF (définition des contrats de données, de message, de service, implémentation, hébergement, sécurisation et génération des paramètres de configuration associés).

Alain Metge a mis à disposition un DSL permettant de générer une application à partir de la définition d’un modèle de composant logiciel multicouches, le stockage de ces modèles dans un référentiel et le découplage des stratégies de génération de code et du modèle (téléchargeable à cette adresse http://www.dslfactory.org/files/16/candlesetup/entry110.aspx) et prenant en compte la mise en œuvre de stratégie de génération WCF.

Enfin, Jean-Marc Prieur vient de mettre à disposition un Designer WCF (téléchargeable à cette adresse : http://www.codeplex.com/DslFactoryUtilities/Release/ProjectReleases.aspx?ReleaseId=4611.Non content de proposer un modèle visuel permettant de générer code, attributs et configuration d'un service, Jean Marc a souhaité pouvoir offrir la possibilité de manipuler indifféremment le code ou les modèles (comme le Diagramme de Classes de Visual Studio). Il s’agit donc là d’un Domain Specific Language bidirectionnel, sachant que les DSL Tools n'offrent pas nativement ces mécanismes. Jean-Marc a factorisé et publié sur CodePlex cette extension des possibilités des DSL Tools, sous la forme d'une bibliothèque DslFactory.Utilities (téléchargeable à l’adresse suivante : http://www.codeplex.com/DslFactoryUtilities) offrant les classes permettant de faire la rétro-ingénierie et la génération de code incrémentale. L'évènement DSL Factory (http://www.dslfactory.org), en septembre, permettra d'avoir plus de détail sur cette implémentation.

Comparaison des performances de WCF avec les technologies de communication distribuées existantes

stephgou — Wed, 16 May 2007 23:19:00 GMT

Il m'a paru intéressant de vous signaler ce comparatif de performances, publié sur MSDN :
http://msdn2.microsoft.com/en-us/library/bb310550.aspx

Les performances qu'offre WCF sont meilleures que celles offertes par les précédentes technologies telles que Services Web ASP.NET (25 à 50% plus rapide), WSE (4 fois plus rapide), Enterprise Services (performances variables suivant les scénarios de charge) ou .NET Remoting (25% plus rapide). En outre, la progression des performances est linéaire en fonction du nombre de processeur (du mono au quadri).

Mise en perspective des patterns de sécurité offerts par WCF

stephgou — Tue, 15 May 2007 10:18:00 GMT

Je renoue enfin avec mon blog que j'avais quelque peu délaissé pour m'atteler à une tâche rédactionnelle très consommatrice en temps. Je me suis effectivement consacré à l'écriture d'un document présentant dans le détail les patterns offerts par WCF pour la sécurisation de l’échange des messages et la sécurité d’accès aux ressources.
Y sont notamment abordés le choix des différents modes de sécurité (transport et message), les mécanismes de protection des messages (chiffrement et signature), les différents modes d’authentification, , l'emprunt d’identité, la délégation, le contrôle d’accès fondé sur les rôles, le contrôle d’accès fondé sur l’usage de claims, la fédération d’identité, la technologie « Cardspace », l'audit... Autant d'occasions de découvrir la flexibilité des mécanismes de développement et de déploiement des services web avancés, avec une nette séparation entre l’abstraction de la logique « métier » et le paramétrage des détails de la communication, garantissant de surcroît l'extensibilité de la solution grâce au support de l’évolution des normes WS-*.
Ce document est téléchargeable sur le site www.netfxfactory.org à l'adresse suivante : http://www.netfxfactory.org/blogs/articles/archive/2007/05/14/mise-en-perspective-des-patterns-de-s-curit-offerts-par-wcf.aspx

J'en profite également pour attirer votre attention sur le prochain évènement que nous organisons avec cette communauté : N.E.R.D. (.Net Entreprise Realization Day) une journée pour l’échange d’expériences sur le thème de l’immersion du SI au cœur de l’activité de ses utilisateurs. Le fil conducteur de cette journée de sessions techniques, organisée par les auteurs de NetFxFactory.org, est la réalisation de cas d’utilisation métier lié à la gestion d’un centre de commandement (Samu, Police, Pompiers,...). Dans un contexte simulé seront abordés, les principes d’architecture et la sélection des technologies qui aboutissent à l’intégration de la solution applicative dans l’écosystème d’un système d’information. La page d'inscription est en ligne : http://www.microsoft.com/france/msdn/architects/nerd.mspx

Interopérabilité WCF / WSIT

stephgou — Tue, 13 Mar 2007 00:47:00 GMT

J'ai eu l'occasion aujourd'hui de faire quelques tests d'interopérabilité WCF/WSIT (https://wsit.dev.java.net/) en compagnie d'Alexis Moussine Pouchkine, architecte chez SUN (http://blogs.sun.com/alexismp/)

A la différence de précédents tests réalisés dans le contexte du Starter Kit PRESTO, plutôt que de confronter nos implémentations client et service une fois celles-ci validées dans nos environnements respectifs, nous sommes partis uniquement d'un accord sur le WSDL, qu'Alexis a utilisé comme base de description pour l'interface de son service, qu'il a fait évoluer progressivement pour lui associer différentes caractéristiques de fonctionnement (MTOM, Reliable Messaging). De mon côté, j'ai "bâti" le client WCF consommant ce service selon deux approches :

· approche statique : "Add Service Reference" depuis Visual Studio 2005, puis modification du fichier de configuration en fonction des paramètres du service (modification soit manuelle, soit par mise à jour de la référence au service).

Cette approche a porté ses fruits pour l'ensemble des caractéristiques ciblées. Il est cependant nécessaire d'ajouter manuellement le binding de niveau transport au custom Binding associé au service (alors qu'en environnement full WCF, ce binding est ajouté automatiquement).

<httpTransport />

</binding>

</customBinding>

· approche dynamique, ce qui suppose côté client, un minimum de code pour balayer la collection des endpoints obtenue via le protocole "WS-MetadataExchange" et ajout du BindingElement HttpTransport manquant à la collection de bindings du endpoint cible .

ChannelFactory<PrestoSvcSoap12> factory = null;

Uri mexUri = new Uri("http://192.168.0.1:7000/PrestoApp/PrestoSvc?wsdl");

ContractDescription contract =

ContractDescription.GetContract(typeof(PrestoSvcSoap12));

EndpointAddress mexEndpointAddress = new EndpointAddress(mexUri);

ServiceEndpointCollection endpoints =

MetadataResolver.Resolve(contract.ContractType, mexEndpointAddress);

foreach (ServiceEndpoint endpoint in endpoints)

{

if (endpoint.Contract.Namespace.Equals(contract.Namespace) &&

endpoint.Contract.Name.Equals(contract.Name))

{

Binding dynamicBinding = endpoint.Binding;

BindingElementCollection dynamicBindingCollection =

dynamicBinding.CreateBindingElements();

HttpTransportBindingElement httpTransportBindingElement =

new HttpTransportBindingElement();

dynamicBindingCollection.Add(httpTransportBindingElement);

CustomBinding currentBinding = new

CustomBinding(dynamicBindingCollection);

factory = new ChannelFactory<PrestoSvcSoap12>(currentBinding, endpoint.Address);

}

Interopérabilité Sun/Microsoft sur les Services Web Performants

stephgou — Fri, 29 Dec 2006 15:28:00 GMT

Si vous vous intéressez à WCF, à .NET, à JAVA et à l’interopérabilité des services Web, alors vous avez très certainement entendu parler du projet TANGO (https://wsit.dev.java.net/)

d'interopérabilité des services de Web pour Java et de WCF, permettant d’adresser des problématiques telles que la transmission fiable de messages, les transactions atomiques, la sécurité et la confiance, grâce à l’implémentation des spécifications WS-*.

Les Workshops PRESTO nous ont d’ailleurs permis de valider le haut degré d’interopérabilité entre les services WCF et les services Web implémentés par Sun. L’un des points concernés par ces tests était la validation du bon fonctionnement des échanges avec différents types d’encodage de message (essentiellement texte/XML et MTOM).

Pour rappel, WCF se décompose d'une manière ordonnée en plusieurs couches de communication qui peuvent être adressées par l’API de binding. L’encodage des messages est assuré par l’une de ces couches. Celle-ci supporte par défaut plusieurs types de format :

· Le format texte/XML permet d’offrir le maximum d’interopérabilité.

· La spécification MTOM (Message Transmission Optimization Mechanism) est une recommandation de W3C qui dépend d'une autre recommandation de W3C, XOP (XML-binary Optimized Packaging), pour l'empaquetage des données binaires dans des messages SOAP sans encodage base64. MTOM permet ainsi une optimisation significative des échanges et de la gestion des pièces jointes des messages SOAP en ré-encodant à la volée certaines parties du message tout en conservant la structure XML. Aujourd’hui MTOM est implémenté par de nombreux éditeurs, dont Sun, ce qui nous a permis de conduire ces tests MTOM avec succès.

· Enfin, un format propriétaire WCF, plus performant, optimisé pour les échanges de message en mémoire ou entres clients ou services liés à la plateforme Microsoft.

Cette troisième option n’est pas l’unique démarche du marché pour proposer une solution d’optimisation des échanges entre services Web plus performante que MTOM. Citons notamment l’initiative de Sun qui propose une spécification de format d’échange optimisé : FI (« Fast Infoset » - http://idealliance.org/proceedings/xtech05/papers/04-01-01/).

Conceptuellement, la spécification FI est assez semblable à MTOM en ce qui concerne la gestion des données binaires, mais vise avant tout à optimiser le parsing et la sérialisation. FI propose un encodage binaire spécifique d’infoset XML, spécifié sur la base d’un schéma ASN.1 tandis que MTOM et XOP permettent d'accéder à un infoset compatible base64 en utilisant une sérialisation Optimized MIME Multipart pour gérer les pièces jointes binaires. Au même titre que l’encodage WCF binaire, l’encodage FI devrait donc offrir de meilleurs temps d’exécution que le l’encodage MTOM.

WCF ne supporte pas nativement ce format proposé par Sun. Mais l’extensibilité de WCF permet aisément d’élargir son horizon…

Ainsi, Gerald Beuchelt (http://blog.beuchelt.com), architecte Web Services chez Sun, a effectué un portage .NET de l’implémentation opensource de la spécification FI pour un client WCF, baptisée FIFI (Fast Infoset For Indigo).

Avec cette solution, tout client WCF peut interopérer avec le serveur d’application Java de Sun (version 9.0 Glassfish), dans un mode d’échange optimisé. Pour se faire, il suffit de configurer le client WCF par un simple changement de ligne le CustomBinding associé au endpoint du service JAVA ciblé…

D’après Gerald Beuchelt, suivant l’intérêt suscité par cette implémentation, celle-ci pourrait également être mise à disposition en opensource.

L'ordre des éléments de binding

stephgou — Tue, 21 Nov 2006 22:52:00 GMT

Partant du principe que mieux vaut partager une expérience passée, que pas d'expérience du tout, je vais donc evoquer quelques épisodes récents de mes investigations sur WCF menées dans le cadre de l'implémentation du Starter Kit PRESTO.

Ayant voulu conjugué l'utilisation de WS-RELIABLE MESSAGING avec celle de WS-SECURITY, je suis tombé sur une erreur quelque peu difficile à cerner (Les opérations de chiffrement et signature fonctionnaient dans toutes les configurations sauf celle impliquant une opération de type requête-réponse avec garantie de livraison).
L'exception retournée de type "System.ServiceModel.Security.MessageSecurityException" indiquait l'erreur "An unsecured or incorrectly secured fault was received from the other party."
En fait, l'erreur provenait du fait que j'avais construit la collection d'éléments de binding sans tenir compte de l'ordre dans lequel ceux-ci sont filtrés dans le pipeline. En effet, l'élément ReliableSessionBindingElement doit être ajouté avant l'élément SecurityBindingElement.

L'ordre des éléments de binding est décrit dans la documentation WCF : http://msdn2.microsoft.com/en-us/library/ms733893.aspx

PRESTO

stephgou — Tue, 21 Nov 2006 11:34:00 GMT

Un petit billet informatif sur l'un des projets sur lesquels je travaille avec mes camarades de jeu Philippe BERAUD et Guillaume RENAUD, tous deux architectes chez Microsoft France. Il s'agit d'un kit de démarrage destiné à faciliter la mise en place d'un système conforme aux spécifications PRESTO ("PRotocole d'Echanges Standard et Ouvert").

Le protocole PRESTO est un protocole de transport sécurisé et fiable qui vise à fournir une couche générique d'échange de messages pour les besoins de l'administration électronique en France. Ce protocole, publié récemment dans le contexte du programme d'ADELE par la DGME (Direction Générale pour la Modernisation de l'Etat) est implémenté dans ce kit avec WCF (Windows Communication Foundation) et a fait l'objet de nombreux tests permettant de valider son interopérabilité avec d'autres implémentations conformes aux spécifications PRESTO.

Dans cette version préliminaire, tous les exemples sont écrits avec le langage C#.

Ce StarterKit est téléchargeable à l'adresse suivante :
http://www.microsoft.com/downloads/details.aspx?FamilyID=B8D92FE4-2D93-491E-B30C-E58CD9808AA0&displaylang=en

Je reviendrai prochainement sur certains points liés au développement de ce kit.