L'article MSDN "Windows Communication Foundation: Application Deployment Scenarios" proposé par la Michele Leroux Bustamante d' IDesign, présente 5 scénarios de déploiement de services basés sur WCF. Architecture, implémentation et sécurité, tout y est.
Un guide qui méritera d'être actualisé avec l'arrivée de Silverlight 2, et les spécificités du proxy client WCF.
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.
Derrière le nom de code "Zermatt" se cache un framework (ex IDFX) permettant de créer des services et des applications Web .Net dont la sécurité (authentification et autorisations) soit basée sur des claims.
Zermatt arrive à point nommé :
- d'un point de vue technique la création et la manipulation de claims est un exercice délicat,
- dans un contexte où les claims apportent la souplesse en terme de sécurité qui permet à vos services de supporter à la fois des scénarios "Single Sign On" mais aussi de fédération d'identités.
Zermatt est en beta et disponible sur Microsoft Connect, où vous trouverez un livre blanc d'introduction pour les développeurs à la gestion de Claims et la mise en oeuvre en .Net avec Zermatt : Microsoft Code Name "Zermatt" white paper for developers
Les possibilités de gestion de claims ont pour objectif d'être totalement interopérables avec les standards du marché (WS-Trust, Federation Active & Passive Profiles notamment) et les offres qu'elles soient éditeurs ou opensource.
"everyone should understand that our intent is for this platform to interoperate fully with products and frameworks produced by other vendors and open source projects, and to help the capabilities we are developing to become universal." Kim Cameron
De plus, Kim souligne que Zermatt est utilisé comme fondation pour construire les produits commerciaux de Microsoft tels que ADFS v2 (qui sera capable de gérer des scénarios Active Profile où tout type de client peut s'interfacer avec le fournisseur de jeton ADFS, ce qui n'est pas le cas de la v1 pour rappel limité à des scénarios Passif, c'est-à-dire initiés pas un browser Web et dont le protocole de récupération d'un jeton est basé sur des redirects HTTP plutôt que sur des échanges SOAP / WS-Trust).
Voci quelques scénarios d'utlisation de Zermatt pour la mise en oeuvre d'applications reposant sur la réception de claims, mais Zermatt permet aussi à vos applications de se positionner comme fournisseur de claims, ou encore de créer des cartes d'identité (type Microsoft Cardspace).
Building claims-aware applications
Zermatt makes it easier to build identity aware applications. In addition to providing a new claims model, it provides applications with a rich set of API’s to reason about the identity of a caller using claims.
Zermatt also provides developers with a consistent programming experience whether they choose to build their applications in ASP.NET or in WCF environments.
ASP.NET Controls
ASP.NET controls simplify development of ASP.NET pages for building claims-aware Web applications, as well as Passive STS’s.
Building Security Token Services (STS)
Zermatt makes it substantially easier for building a custom security token service (STS) that supports the WS-Trust protocol. These STS’s are also referred to as an Active STS.
In addition, the framework also provides support for building STS’s that support WS-Federation to enable web browser clients. These STS’s are also referred to as a Passive STS.
Creating Information Cards
Zermatt includes classes that you can use to create Information Cards - as well as STS’s that support them.
Lors du Tech Ed 2008, Microsoft Services a dévoilé l'offre SOM - Service Oriented Modeling - qui vient faire le lien de façon pragmatique entre :
Cette offre vient concrétiser l'expérience des consultants Microsoft Services en terme de mises en oeuvre d'architecture de services, en s'appuyant à la fois sur ces méthodologies (MSBA, SOAMM) et les technologies proposées par Microsoft en terme d'infrastructure (.Net, BizTalk, System Center) et de développement (Visual Studio, Team Foundation Server et Service Software Factory).
SOM est orienté Modèles, en conformité avec les investissements Microsoft autour de la modélisation, sans pour autant mettre en oeuvre les référentiels ni les outils liés à Oslo. Néanmoins, Microsoft Services souligne qu'en respectant l'approche SOM, la transition vers les technologies liées à Oslo sera d'autant facilitée puisque vos référentiels méthodologiques les outils associés seront déjà orientés Modèles.
SOM est délivré par les équipes Microsoft Services au travers d'une mission de conseil démarrant à 4 semaines d'intervention et transfert de compétences.
SOA, SaaS, BizTalk, ESB, Oslo ... dans cet interview ITRmanager.com, Bernard Ourghanlian, directeur technique de Microsoft France, présente la démarche SOA Microsoft, les produits impliqués ainsi que les investissements courants.
Le Service Pack 1 du framework .Net 3.5, actuellement en beta, apporte un grand nombre de nouveautés pour le développement Web (ASP.Net, AJAX, MVC) et Windows (WPF, ClickOnce) mais le développeur de services n'est pas en "REST": améliorations WCF et WF et les nouveaux Data Services !
Si la présentation du Service Pack 1 de .Net 3.5 donne un aperçu des nouveautés et ces démonstrations sur Channel 9, je vous invite surtout à lire VS2008 and .NET 3.5 SP1 Enhancements for Service Developers.
En résumé, un support plus large de REST et d'AtomPub dans WCF, un raccourci pour la sérialization SOAP, et des améliorations au niveau des assistants Visual Studio pour WCF et WF. Sous oublier, l'arrivée des Data Services dans le framework .Net pour supporter les scénarios d'exposition de ressources.
Un seul bémol, cette beta n'est pas compatible SilverLight 2 (en beta aussi). Donc vous ne pouvez pour le moment ne tirer parti des toutes dernières nouveautés que sur une seule filière de développement : Production ou consommation des services.
Windows Communication Foundation and Workflow Foundation Changes
- New Hosting Wizard for WCF Service projects.
- Enhancements in Test Client such as support for RM Sessions, Message Contract and Nullable<T> types enables testing of broader set of WCF-based services.
- Expanding reach of DataContract Serializer by relaxing the need of having [DataContract]/ [DataMember] on types and by supporting an interoperable mechanism for dealing with object references.
- Improved Partial Trust Debugging Experience with support for Event Log.
- Support for ADO.NET Entity Framework entities in WCF contracts.
- Improvements in writing REST based services ranging from easily supporting ServiceDocuments publication and consumption to providing greater control and usability of UriTemplate.
- Significant performance improvements on large workflow-based projects in Visual Studio.
- Considerable scalability increases for hosted WCF services in IIS7-integrated mode.
Attention, 2 anomalies répertoriées dont vous trouverez ici les contournements :
- HTTP POX is not composable with One-way
- Windows XP issue when AllowNtlm is set to false
Steve Martin vient d'annoncer la sortie d'une release 3 pour BizTalk pour mi-2009, avec des compléments d'informations chez Sam Gentile.
En bref, cette version a 2 objectifs :
- Un alignement avec la génération 2008 de la plate-forme Microsoft (Windows Server 2008, SQL Server 2008 et Visual Studio 2008).
- L'élargissement de la prise en charge des scénarios SOA avec la mise en oeuvre de patterns complémentaires et de bonnes pratiques mais surtout la prise en charge d'une registry de services compatible UUDIv3.
Quoi de neuf par rapport à UDDI ?
La capacité UDDI sur la plate-forme Microsoft est aujourd'hui implémentée dans l'OS Windows Server. Les versions 2003 et 2008 de Windows Server implémentent UDDI v2.
Ce sera donc BizTalk qui prendra désormais la responsabilité de l'implémentation des spécifications UDDI, mais surtout qui proposera les capacités services "registry" et "repository".
Dès aujourd'hui, l'infrastructure de services - SOI Microsoft - propose un premier niveau d'implémentation des aspects registry et repository au travers des offres BizTalk Server 2006 R2, l'Enterprise Service Bus Guidance et le Managed Services Engine (MSE). Notamment le référencement, la gestion des itinéraires, l'application de policy, suivi des échanges de messages d'un point de vue technique et métier (BAM, HATS, Management portal).
Qu'est-ce qu'une registry de services ?
- une "SOA Registry" est une composante de l’infrastructure permettant la découverte, la création, le déploiement et la gouvernance des Services. Une «registry» permet une taxonomie en accord avec une organisation. Elle contient aussi la liste des "policies” à appliquer à chaque service ainsi que les liens de dépendance entre les Services -
Regis MAUGER, Architecte Microsoft France
Qu'est-ce qu'un repository de services ?
- Le «SOA Repository» minimum contient des informations référencées dans le «SOA Registry» généralement par leurs URL. Ces informations peuvent être des fichiers WSDL, des fichiers de policies, toute information utile à la découverte et au bon usage des services. Le «SOA Repository» peut aussi contenir des informations générées lors de l’exécution messages de logs, performances, état de santé. -
Regis MAUGER, Architecte Microsoft France
La conférence Managed Services Engine réalisée en Février durant le parcours Architectes / SOA desTechDays est désormais en ligne. En complément du billet présentant le Managed Services Engine, vous pourrez télécharger la présentation Virtualisation de Services mais aussi assister à 3 démonstrations tirées du laboratoire MSE disponible sur CodePlex :
- Premier contact avec MSE (en fin de vidéo 1 et début de vidéo 2) importer un service existant dans MSE
- Faire évoluer la version d'un service en important le contrat d'un second service de calcul (vidéo 2)
- Décommissionner la version d'origine du service (vidéo 3) et appliquer les transformations aux messages entrants et sortants pour invoquer la nouvelle version.
Voici le descriptif de la session pour rappel :
La mise en œuvre d’une infrastructure de services consiste dans un premier temps à assurer la bonne disponibilité des Services par les applications du système d’informations. Cette première étape passée, il est indispensable de s’attaquer à la problématique de la gestion du cycle de vie des services, et notamment leur évolution. Nous nous concentrerons sur deux problématiques liées : - Comment gérer la montée de versions d’un service ? - Comment adapter les protocoles d’accès à ses services, en fonction des consommateurs désirant y accéder ? La Virtualisation de Services correspond aux solutions d’infrastructure qui permettent de répondre à ces enjeux de façon non intrusive, c’est-à-dire, sans intervenir sur les codes développés. Nous illustrerons nos propos en présentant l’architecture et des démonstrations du moteur opensource proposé par les équipes Microsoft Consulting Services et Patterns et Practices, le « Managed Services Engine ».
 |
François Cointe signe cette bande dessinée qui met en exergue les atouts et les déboires des initiatives SOA en entreprise
Bravo Angélica Reyes et Eric Ortiz pour cette démocratisation réussie de la SOA ! |
Le guide Microsoft BizTalk Server Operations Guide a été rédigé à partir de nombreuses expériences terrain. Il est intéressant pour son côté opérationnel : comment intervenir sur la disponibilité de mon infrastructure BizTalk ? comment optimiser les flux de messages ? ...
C'est une lecture qui séduira les Architectes BizTalk par les scénarios concrets qu'il propose.
Un seul bémol : les aspects spécifiques à la R2 sont peu couverts, même si la quasi-totalité des concepts et solutions proposés s'appliquent non seulement à BizTalk 2006 mais aussi BizTalk 2006 R2.
L'équipe Connected Systems travaille actuellement sur la nouvelle version de l'adaptateur générique BizTalk pour SQL Server, qui viendra compléter le BizTalk Adapter Pack déjà disponible pour accéder à SAP, SIEBEL et ORACLE SGBDR de façon native avec WCF.
Vivek Krishna, chef de produit, est à la recherche de besoins terrain mais aussi de retours d'expérience d'utilisateurs de la version courante de l'Adaptateur BizTalk pour SQL Server (livré depuis BizTalk 2004, supporte SQL Server 2000 et 2005, ne repose pas sur le WCF LOB Adapter SDK).
Les fonctionnalités prévues sont :
- Support des nouveaux types de SQL2005 et SQL2008 (XML, FileStream et les types customs (UDTs))
- Opérations CRUD sur les tables et les vues
- Appel de procédures stockées (TSQL et CLR)
- 4. Possibilité de transmettre des paramètres de type tableau
Merci de transmettre vos inputs en anglais directement vers Vivek ou bien vers moi en français.
Au fil de mes conférences et interventions sur les scénarios d'interopérabilité Java - .Net, je rencontre régulièrement les mêmes écueils. Voici donc un B.A.BA pour une interopérabilité réussie (avec la contribution de Benjamin Bellon Serre :-) :
Générer un proxy client à partir du WSDL
Utiliser la commande svcutil sous WCF (ou bien son équivalent sous Visual Studio : Add Service Reference...) ou bien la commande wsimport si vous utilisez un framework Java qui implémente JAX-WS
Ecueil 1 : la génération du proxy client Java ne fonctionne pas.
Cela est généralement lié au fait que le WSDL généré par WCF comprend des includes (même si c'est prévu par les spécifications, certains frameworks Java ne l'implémentent pas).
Dans ce cas, il faut retravailler le WSDL ou bien demander à la partie .Net de "mettre à plat" son WSDL. Voir ce billet ...
Ecueil 2 : les formats SOAP supportés par les frameworks doivent être alignés
Si JAX-WS et WCF supportent la plupart de ces modes d'encodage, il faut tout de même les aligner. En principe, la simple génération à partir du WSDL permet de générer le bon formattage par le proxy client. Cependant, si le consommateur ne supporte pas un mode encodage, il faudra adapter le serveur au mode d'encodage supporté. Voici le moyen en WCF :
Pour adapter la partie JAX-WS, voici les attributs à positionner sur le service :
@SOAPBinding(style=SOAPBinding.Style.DOCUMENT, use=SOAPBinding.Use.LITERAL)
public class ServiceSomme { ...
Si vous souhaitez consommer en Java un Web Service exposé par un applicatif Microsoft, voici les encodages proposés par défaut pour les frameworks historiques (au sens avant WCF)
Et si ça ne fonctionne toujours pas, il faut aller regarder de plus près le fichier WSDL et les flux SOAP
L'outillage nécessaire pour soumettre des trames SOAP est SoapUI côté Java, et ServiceTester côté .Net (fourni avec le Managed Service Engine). L'intégration WCF dans VisualStudio 2008 permet aussi de soumettre des flux SOAP pour un service .Net hébergé grâce au moteur WCF intégré (WCFTestClient)
Si vous utilisez WCF, il suffit de mettre en place l'analyse (Diagnotics) pour pouvoir tracer les flux SOAP échangés.
<system.diagnostics>
<sources>
<source name="System.ServiceModel.MessageLogging" switchValue="Warning, ActivityTracing">
<listeners>
<add type="System.Diagnostics.DefaultTraceListener" name="Default">
<filter type="" />
</add>
<add name="ServiceModelMessageLoggingListener">
<filter type="" />
</add>
</listeners>
</source>
</sources>
<sharedListeners>
<add initializeData="...\app_messages.svclog"
type="System.Diagnostics.XmlWriterTraceListener, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
name="ServiceModelMessageLoggingListener" traceOutputOptions="LogicalOperationStack, DateTime, Timestamp, ProcessId, ThreadId, Callstack">
<filter type="" />
</add>
</sharedListeners>
</system.diagnostics>
Ressources
Pour approfondir les aspects théoriques des Services Web et les problématiques d'interopérabilité avec des exemples AXIS, JAX-WS et WCF, je vous invite à lire ce livre blanc et les vidéos associées.
Si vous êtes en environnement .Net + WebSphere 6, IBM a publié un guide dont la première partie couvre SOAP et WS-Adressing.
Jon Flanders présente comment utiliser conjointement les deux connectivités de BizTalk : 'à demeure' et 'dans les nuages'. Dans le scénario de démonstration, il s'agit de recevoir des messages depuis l'Internet Service Bus sur un port de réception (Receive Location) de BizTalk Server et transmettre un message d'un port d'émission (Send Port) vers l'Internet Service Bus.
Dans la mesure où la connectivité vers l'Internet Service Bus est assurée par un binding WCF de type RelayBinding, la démonstration met en oeuvre BizTalk Server 2006 R2 et son support de la technologie WCF - Windows Communication Foundation.
Cependant pour se connecter aux BizTalk Services, il est nécessaire de fournir un jeton d'identité. Par défaut, le relayBinding invoque le selecteur d'identité de CardSpace, ce qui ne fait pas de sens pour le serveur BizTalk.
La manipulation consiste donc à remplacer le fournisseur de jeton par défaut (de type CardSpaceTokenProvider) par le UserNameTokenProvider (associé à un couple utilisateur / mot de passe) fourni dans le SDK.
Pour associer le UserNameTokenProvider sans possibilité d'intervenir sur le ServiceHost, Jon propose d'ajouter une extension de comportement (BehaviorExtension) dont il fournit le code dans son billet.
Gianpaolo Carraro et Eugenio Pace signent un nouveau portail MSDN qui rassemble leurs réflexions autour de la construction, l'exécution, la consommation et la monétisation d'applications reposant sur le modèle Software + Services.
Suite à l'annonce Interopérabilité de Microsoft, les 30.000 pages d'API documentées dans le cadre notamment du procès avec la Communauté Européenne ont été mises à disposition. Pour information ou rappel, ce travail collossal a été réalisé sur plusieurs années et par près de 200 spécialistes.
Dans le cadre de l'interop et de la SOA, la documentation des protocoles de communication MCPP sont passionnants, ils offrent un bon complément à la documentation MSDN du framework .Net.
En les parcourant je me suis intéressé à l'encodage binaire des messages SOAP. La lecture de ces trois documents permet de découvrir et approfondir les choix et l'implémentation choisie par Microsoft pour optimiser la sérialization de documents XML.
- [MC-NBFS]: .NET Binary Format: SOAP Data Structure
- [MC-NBFX]: .NET Binary Format: XML Data Structure
- [MC-NBFSE]: .NET Binary Format: SOAP Extension
Du coup, voilà qui m'amène à me poser la question du choix de la solution d'encodage optimale, des options disponibles, ainsi que l'état des standards dans le domaine. Voici la synthèse de mes recherches au 6 mars 2008 :
-
Si souhaitez disposer de critères de choix d'une solution d'encodage ou bien de compression de messages SOAP, je vous invite à parcourir cette présentation qui fait état d'une expérimentation à l'aide de Sun Fast InfoSet et GZIP pour des messages de différentes tailles :
A Study of the Impact of Compression and Binary Encoding on SOAP. Dommage l'encodage SOAP binaire proposé avec Microsoft n'a pas été testé.
-
Côté spécifications, je vois 3 stratégies d'encodage XML émerger : Microsoft (spécifications juste au-dessus) utlisé par WCF, SUN XML Fast InfoSet (FI) et celle du W3C
Efficient XML Interchange(EXI) en draft depuis Decembre 2007.
Bilan vis à vis de WCF...
WCF propose 3 modes d'encodage des messages SOAP : Text (XML en clair), Binaire (optimisation en remplaçant les tags par une codification pré-établie, un peu comme une compression sur mesure qui a aussi l'avantage d'optimiser la phase de decoding), et MTOM (recommandation W3C qui cible l'intégration de données au format binaire au sein d'un message SOAP).
Warning de Nicholas Allen: The binary message encoder requires you to use SOAP 1.2 and any version of message addressing. Validation for the message encoder checks that you are using SOAP 1.2. A transport can supply its own native version of addressing, but the HTTP, TCP, and named pipe transports don't work with this for the binary encoding. The validation doesn't check to make sure that you have some kind of message addressing, so if you are using AddressingVersion.None, then that won't show up as an error until you try to send a message.
L'encodage binaire proposé par WCF optimise l'échange des flux, mais de façon non interopérable (même si les spécifications sont publiées, je n'ai pas connaissance d'implémentation Java de la sérialization proposée par Microsoft; voilà un projet de stage :-)).
Si vous souhaitez optimiser la transmission de vos trames SOAP tout en restant interopérable, vous avez l'option de miser sur les spécifications Draft EXI du W3C dont AgileDelta propose une implémentation pour WCF, mais aussi pour AXIS 1, AXIS 2 et WebLogic.
