SOA & Interop @ Microsoft France : Composons

BizTalk Server 2009 : nouveautés SOA et ALM

Steve SFARTZ — Tue, 12 May 2009 06:13:00 GMT

Disponible depuis fin avril, BizTalk Server 2009 consolide les avancées SOA et BPM des versions précédentes et s’aligne avec la dernière version de la plate-forme applicative Microsoft tant sur les aspects production (Windows Server 2008, virtualisation Hyper-V, SQL Server 2008), que développement (Visual Studio 2008 et .Net 3.5 SP1). Et le portail BizTalk France de nous rappeller que BizTalk compte près de 8.500 clients à travers le monde, dont les témoignages de Exane (BNP), Institut Gustave Roussy (IGR), SEB, UNESCO et le Groupe Acadomia.

Côté développement (le détail ici), BizTalk Server 2009 vous intéressera pour ses nouvelles capacités de travail en équipe, et une productivité accrue :

New Application Lifecycle Management (ALM) experience - with Support for TFS - integrated source control, bug tracking, unit testing, MSBuild automation
Enhanced Developer Productivity with Visual Studio project system updates & Map Debugging

Côté SOA (le détail ici), BizTalk Server 2009 renforce ses capacités d’intégration ainsi que ses fonctionnalités ESB :

ESB Guidance 2.0
New UDDI v3 Web Services Registry
New and enhanced LOB adapters (Oracle eBusiness Suite, SQL Server)
Enhanced host systems integration (WebSphere MQ, CICS, IMS)
Enhanced BAM support

Pour mettre en pratique ces nouveautés, je vous invite à consulter le centre de développement BizTalk MSDN, et notamment dérouler quelques travaux pratiques disponibles sous forme de laboratoires virtuels : Building your first BizTalk Solution, Working with Schemas, Working with Maps, Working with Pipelines, Processing Flat Files, Integration with POP3 and SharePoint and Routing Failed Messages, Creating BizTalk Server Orchestrations, Integrating Business Rules, Deployment and Management, Using the WCF Adapters in BizTalk Server 2009, What Is New In BizTalk Server 2009.

Et si vous souhaitez parcourir les fonctionnalités de BizTalk Server 2009 tout en touchant du doigt leur mise en oeuvre, je vous recommande la lecture de ce document technique (50 pages) : BizTalk Server 2009 Technical Overview.

CCR & DSS Toolkit 2008 versus WCF / WF

Steve SFARTZ — Tue, 04 Nov 2008 11:39:00 GMT

Annonce PDC 2008 : les technologies CCR et DSS seront disponibles de façon indépendante de Robotics Studio. Ce nouveau packaging est lié à la montée en puissance de l’utilisation de CCR et DSS pour des applications d’entreprise (orientées Services, Composition, et possibilité d’observer et rejouer des exécutions).

CCR – Concurrency & Coordination Runtime - et DSS – Decentralized Software Service – sont un ensemble de classes pour les frameworks .Net et .Net Compact pour faciliter la création d’applications distribuées avec un faible couplage et s’exécutant de façon concurrente. Les frameworks CCR et DSS sont légers, ils peuvent s’intégrer dans une implémentation SOA existante.

On retrouve des caractéristiques du couple WCF / WF telles que l’orientation services, le couplage faible et la composition mais dans le cas de CCR et DSS, il s’agit de frameworks spécialisés pour une exécution ultra-rapide et dans un contexte fortement concurrentiel.

Les références citées lors de la PDC sont “Windows Live” pour la navigation et la coordination des IO, “Tyco” pour gérer les évènements dans le cadre d’une solution de contrôles d’accès (je me souviens d’une vidéo sur Channel9…), et "Siemens Infrastructure Logistics" pour un système de manipulaiton d’emails.

“We deal in milliseconds and microseconds, and there are not very many commercial products that we can take off the shelf and integrate into our product that can meet our demanding performance criteria…” Hamid Salemizadeh, Director of Engineering, Reading & Coding, Siemens Infrastructure Logistics Inc.

Dans une future version de .Net, le runtime de CCR reposera sur le runtime Concurrency des Parallel Extensions pour .Net, soutenu par Intel.

Comment savoir si vous devez utiliser ou non CCR et DSS

Le toolkit CCR et DSS propose un modèle de programmation très léger pour créer des applications distribuées, à faible couplage et dans un contexte fortement parallèle. Voici quelques contextes d’utilisation :

Des applications orientées Input / Output (et non orienté logique métier) dont la gestion est effectuée de façon asynchrone
L’architecture peut être vue comme une série de pipes et de filtres (orientation données) avec un couplage faible et distribuée
La nécessité de s’exécuter sur des matériels sur lesquels on souhaite minimiser l’utilisation des ressources (.Net Compact)

Voici par ailleurs des cas où le toolkit ne s’applique pas :

Mise en oeuvre de transactions locales ou distribuées
Correlation de messages dans une conversation de plus haut niveau, incluant une gestion d’états
Mise en oeuvre de processus longs
Scénarios orientés algorithmique plutôt que données / messages.

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.

BizTalk au travers de 5 posters + 1 animation

Steve SFARTZ — Sat, 16 Feb 2008 01:59:00 GMT

En complément des 5 posters déjà disponibles (Capabilities, Scale out, Runtime Architecture DataBase Infrastructure et Host Integration), l'équipe BizTalk 2006 R2 propose un outil d'exploration des fonctionnalités de BizTalk : "BizTalk interactive Capabilities Reader".

Ludique : Cliquez sur une fonctionnalité (capability), vous obtenez l'explication de celle-ci. Etant donné le nombre de fonctionnalités de BizTalk, c'est très apréciable et surtout une bonne occasion d'utiliser les capacités vectorielles de SilverLight.

[Archive] Tirer parti des technologies Microsoft depuis Java au travers des Services Web

Steve SFARTZ — Thu, 03 Jan 2008 15:07:00 GMT

Avec le concours de Jean-Louis LEQUEUX et de Nasime EL FARTASSE d'ATOS ORIGIN, le RV de l'interop du 18 octobre 2007 a permis d'illustrer 4 scénarios d'interopérabilité : Excel (VBA & AddIn avec VS2008), SharePoint (MOSS2007), Génération de rapports (SQL Server Reporting Services) et Composition de Services (WF - Wndows Workflow Foundation 3.5)

Vous pouvez écouter les sessions et télécharger les PPTs sur Microsoft Audio & Video.

J'ai profité des vacances pour packager un minimum les démos, dont voici les codes des démonstrations.

Le scénario d'interopérabilité Composite avec Worflow Foundation demandait à être complété : un article détaillé illustrant un scénario de médiation de protocoles avec WF, entre JAX-WS et un client REST via WF et en utilisant les bindings WCF paraîtra courant Janvier.

Voici l'agenda d'étaillé du RV du 18 octobre :

Atos Origin, SOA et interopérabilité 2/13
Les opportunités liées aux Services Web en entreprise 3/13
Théorie des Services Web 4/13
Les profils d'interopérabilité du WS-I 5/13
Développement de Services Web en .NET 6/13
Développement de Services Web en Java 7/13
Quelques bonnes pratiques pour débuter 8/13
Consommer des Services Java depuis Excel en VBA 9/13
Consommer des Services Java depuis un AddIn .NET Excel 10/13
Intégrer en Java un référentiel SharePoint 11/13
Rechercher et générer des rapports SQL SERVER depuis Java 12/13
Invoquer un Workflow .NET depuis un Service Web Java et plus 13/13

Ce RV de l'interop vient compléter de sessions plus théoriques sur les Services Web et l' Interopérabilité entre les environnements .Net et Java :

Juin 2007 : Interopérabilité des stacks SOAP .Net et Java

WCF, Apache AXIS et SUN JAX-WS
Accompagné d'un livre blanc

Juin 2007 : Interopérabilité via les protocoles avancés WS-*

Sécurité, transactions entre WCF et WSIT / Metro / SUN Glassfish

Mai 2007 : 3 stratégies pour interopérer entre Java et .Net

Services Web, Bridges, COM

Disponibilité de .Net 3.5 : Du neuf pour vos Services

Steve SFARTZ — Thu, 22 Nov 2007 03:48:00 GMT

Avec la disponibilité du framework .Net 3.5, ce sont deux années d'investissements Microsoft qui bénéficieront progressivement à toute la plate-forme applicative (SQL Server, BizTalk et SharePoint), et dès maintenant pour vos développements spécifiques. Pour plus d'informations sur .Net 3.5, consulter ce billet.

Nous nous intéressons ici aux nouveautés concernant les frameworks WCF et WF, ainsi que l'outillage proposé par Visual Studio 2008 lui aussi disponible en version finale.

Nouveautés WCF et WF avec .Net 3.5

Côté protocoles :

WCF supporte des versions de spécifications WS-* supplémentaires : Web Services Atomic Transaction (WS-AtomicTransaction) 1.1, WS-ReliableMessaging 1.1, WS-SecureConversation, and Web Services Coordination (WS-Coordination) 1.1.

Les amateurs d'une stack de services plus orientée Web qu'Entreprise (j'entends par là l'utilisation exclusive du transport des messages via HTTP, ainsi que l'utilisation du protocole Web incarné par le vocabulaire GET, POST, PUT, DELETE) ne seront pas en REST.

Les attributs WebGet (HTTP GET) et WebInvoke(HTTP GET, POST, PUT, DELETE) peut maintenant être spécifiés au niveau de l'OperationContract

Côté formats :

WCF simplifie dorénavant la publication d'informations au format XML POX (XML sans enveloppe SOAP) et supporte nativement les formats d'échanges sur le Web, à savoir RSS, ATOM ainsi que JSON

Pour mettre en œuvre ces formats, on privilégiera le protocole HTTP via l'utilisation du WebHttpBinding, et l'attribut d'opération WebGet présenté précédemment

Côté composition :

WF peut maintenant être hébergé dans un hôte WCF, le WorkFlowServiceHost qui permet ainsi de déclencher un Workflow dès la réception d'un message sur un point d'exposition WCF. Il s'agit donc de démarrer un WorkFlow depuis une réception TCP, Pipe Nommé, HTTP, MSMQ voir SAP ou SIBEL en ayant recours au BizTalk Adapter Pack ou encore via JMS via le connecteur proposé par JNBridge.
Par ailleurs, un workflow WF peut désormais invoquer des services externes via WCF.

Côté consommation :

Le support de JSON permet à WCF d'être positionné comme un fournisseur de données pour les technologies AJAX, dont les applications Web ASP.Net AJAX.

Pour aller plus loin, je vous recommande ces trois livres blanc de David Chappell :

Introducing_WCF_in_NET_Framework_35_v1.doc : remarquable introduction à WCF.
WCF_Diversity_Paper_v1.doc : entre dans l'architecture de WCF, à réserver à un public averti. Introduction au WCF LOB Adapter Pack et aux bindings associés à la communication vers les BizTalk Services (Connectivité / Relais et Identité)
Introducing_WF_in_NET_Framework_35_v1.doc : remarquable introduction à WF.

Les bénéfices apportés par Visual Studio 2008

Visual Studio 2008 constitue la première version d'un environnement packagé pour des développements WCF et WF, au bénéfice de la productivité et de l'industrialisation.

Parmi les nouveautés VS2008, vous apprécierez la possibilité de tester vos services sans passer par la création de host. VS2008 se charge de créer un host pour vous avec exploration des méta-données et soumission de messages (requêtes / réponses).

Le designer WF permettant de déclencher l'invocation du workflow sur réception d'un message est aussi intéressant quoiqu'un peu complexe à prendre en main (avec un effet désagréable un peu boîte noire)

Configurations de développement

Dans les mois qui viennent, les technologies reposant sur le framework .Net 3.5 et Visual Studio 2008 s'aligneront sur ces dernières versions. En attendant, vous devrez maintenir 2 configurations si vous utilisez BizTalk ou bien la Service Software Factory :

.Net 3.5 / VS 2008 : permet de développer des projets .Net 2.0, 3.0 et 3.5

Attention, possibilité d'upgrader un projet VS2005 en VS2008, mais pas l'inverse

.Net 3.0 / VS2005 : permet de développer des projets .Net 2.0 et 3.0 (via des extensions à VS2005)

BizTalk 2006 R2 requiert VS2005 (pas de date de support de VS2008 annoncé), ainsi que l'ESB Guidance par voie de conséquence
La Service Software Factory repose sur le SDK de VS2005 (on devrait disposer d'un support de VS2008 pour le premier trimestre 2008 - dixit Don Smith à la conférence SOA & BPM)

Oslo : Une SOA ambitieuse et différentiante selon le Gartner

Steve SFARTZ — Fri, 09 Nov 2007 12:55:00 GMT

Suite à l'annonce d'Oslo le 30 Octobre 2007, les équipes du Gartner ont pu accéder à ce que les équipes de développement Microsoft avaient dans les cartons. En attendant les premières CTP courant 2008, il en ressort que le Gartner positionne ces investissements comme la future technologie permettant de faire un bon en avant en terme de SOA , de BPM et de SaaS.

Le Gartner rappelle tout d'abord qu'Oslo correspond à la stratégie Microsoft pour concevoir, construire, déployer et administrer les applications composites.Les applications composite basées sur Oslo peuvent être déployées de façon flexible pour des cibles locales (Applications, Départements), entreprises (ESB), ou internet (ISB).

Oslo-based composite applications can be deployed "on premises" and "in the cloud," following an application-platform-as-a-service model and a dynamic scale-out deployment architecture.

La stratégie Oslo consiste en la mise en œuvre d'un référentiel de modèles comme socle de configuration, déploiement et administration des applications composites. Dans ce sens, l'approche Microsoft "SOA par les modèles" va au-delà des approches MDA traditionnelles pour 3 raisons selon le Gartner :

Its meta-modeling language - the most complex aspect of modeling — which promises to be much simpler than previous languages
Its approach to weaving together a much broader fabric of domain-specific models such as process, identity, security, topology, policy and management
Its ability to bind those models to heterogeneous realization environments

Oslo s'appuie sur les fondations SOA Microsoft à savoir BizTalk Server, BizTalk Services, .Net, Visual Studio et System Center. En intégrant la SOA à toute une gamme de produits et en respectant l'existant des entreprises plutôt que de se concentrer sur des produits serveurs dédiés, Oslo permet de mettre en œuvre une infrastructure de services décentralisées, capable d'une meilleure montée en charge et de supporter les aspects composition d'une façon hétérogène et globale.

Oslo is based on a decentralized service bus and application platform architecture that is intended to be more naturally capable of the scalability and heterogeneity needed for global composite applications than other more centralized architectures.

Nous verrons dans un prochain billet comment ces fondations SOA s'articulent pour mettre en œuvre une SOA d'entreprise dès aujourd'hui.

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...)

2 heures pour installer BizTalk 2006 R2

Steve SFARTZ — Mon, 24 Sep 2007 15:15:00 GMT

Prévoyez environ 2h pour réaliser l'installation, à partir d'une configuration Visual Studio 2005 SP1 et SQL Express sous Windows XP.

Remarques :

BizTalk 2006 R2 Developper Edition supporte SQL Express
Les composants Portails et BAM ne sont proposés que sur Windows Serveur puisqu'ils reposent sur les Windows SharePoint Services - WSS
Pour un exemple de configuration de développement, consulter ma config Vista en Avril 2007. L'installation ci-après a été réalisée à partir d'une configuration identique sous Windows XP.

[Facultatif] Ajouter les fonctionnalités IIS (un serveur Web) et MSMQ (gestion des files de messages)

A partir des accessoires / fonctionnalités
Attention, il est nécessaire de disposer du CD Windows XPDisposer du CD Windows XP

[Indispensable] Télécharger et enregistrer les composants complémentaires obligatoires (sous la forme d'un CAB)

A partir de http://go.microsoft.com/fwlink/?LinkId=81450
Ne pas les installer, les conserver pour l'étape suivante

Télécharger et lancer l'installation de BizTalk Server 2006 R2

A partir de http://technet.microsoft.com/en-us/bb738059.aspx
En précisant d'utiliser le CAB précédent dans l'assistant d'installation
A la fin de l'installation, BizTalk propose de configurer l'installation (définir le compte d'exécution des hosts BizTalk, créer les instances de données pour abriter les bases de management et la messagebox notamment…)

Phase de configuration

Choisir une configuration basique en spécifiant l'instance locale SQLExpress

Créer un compte local chargé d'exécuter les services BizTalk (BTS dans la figure ci-dessous)

L'assistant vous présente alors les composants qui seront installés, finaliser l'installation

5. L'installation de BizTalk 2006 R2 terminée, charger les exemples

BizTalk 2006

BizTalk 2006 R2

Biztalk 2006 R2 contribue à la SOA d'entreprise

Steve SFARTZ — Thu, 13 Sep 2007 09:36:00 GMT

BizTalk 2006 insistait sur la connectivité en standard (plus de 50 adapteurs) et la facilité d'administration (console centralisée, organisation sous forme d'applications...). Dans la version 2006 R2, BizTalk se concentre sur les scénarios SOA/BPM et SupplyChain RFID/EDI (news InfoQ).

Au coeur de la stratégie SOA de Microsoft, vous apprécierez dans cette nouvelle version de BizTalk :

La connectivité vers les protocoles FTP, SOAP, MQSeries... et les ERP : PeopleSoft, SAP, and Siebel, ainsi que les mainframes et les legacy IBM AS/400.
Un support étendu de XML, des Services Web et des protocoles WS-*
L'intégration des technologies .Net et serveurs Microsoft : WCF, SharePoint, SQL Server
Sans oublier les scénarios complémentaires disponibles sur CodePlex, dont l'ESB guidance.

Au delà des scénarios SOA, BizTalk 2006 R2 regorge de fonctionnalités (Messaging, Business Activity Monitoring, Business Rule Framework, B2B integration, Orchestration...) qui sont illustrées dans cette nouvelle édition du poster BizTalk Capabilities. Pour découvrir BizTalk 2006 R2, notez que WinWise organise un petit déjeuner le 27 septembre de 9h à 11h, s'inscrire sur le blog de Florent Santin ou directement depuis le site de Winwise.

Une version d'essai est disponible ici, les abonnés MSDN y auront accès à partir de semaine prochaine. Sous le téléchargement de la version d'essai, vous trouverez les guides de migration des versions 2004 et 2006 vers 2006 R2, ainsi que les procédures d'installation pour XP, Vista et Windows Serveur 2003.

Le Forrester positionnait déjà Microsoft parmi les leaders SOA, dès la version 2006 de BizTalk. Il y a fort à parier que cette version de BizTalk fera encore grimper la côte de la proposition SOA Microsoft. Retrouver l'étude complète ici.

Recommandations pour sécuriser ses Services Web

Steve SFARTZ — Mon, 03 Sep 2007 17:16:00 GMT

La division Sécurité des laboratoires de l'IT de l'institut national américain des standards et de la technologie (NIST) publie ses recommandations quant à la sécurisation des Services Web : "Guide to Secure Web Services". Ce guide constitue une excellente introduction à la problématique de sécurisation des échanges via les Services Web.

Le guide débute par une présentation rapide des concepts associés aux Services Web : la mise en relation des services, la transmission de messages, l'accès aux services, les intervenants dans la chaîne d'invocation d'un service (le consommateur, le fournisseur et les intermédiaires), et enfin la nécessaire orchestration.

De façon classique, la sécurité des Services Web reprend les éléments standards de sécurité (Identification, Autorisation, Intégrité, Non répudiation, Confidentialité, et Restriction de l'accès). Ces caractéristiques se traduisent par les dimensions.

La sécurisation des messages : au niveau du transport ou bien du message SOAP

La protection des ressources : au travers de l'authentification et la gestion des autorisations

La négociation des contrats : afin d'établir la future communication, il est nécessaire de

L'établissement de relations de confiance : basées sur une authentification point à point ou la mise en place d'une gestion fédérée des identités

La prédictibilité, la disponibilité et la conformité sont aussi requis comme pour tout logiciel se prétendant sécurisé.

La pile des protocoles concourant à la sécurisation des Services Web y est présentée sous la forme originale d'une stack OSI.

La couverture des fonctionnalités de sécurisation SOA proposée par chaque protocole y est synthétisée comme suit.

Si bien que le guide présente l'ensemble des menaces de sécurité encourues par les Services Web, et comment les standards WS-* se complètent pour endiguer ces menaces sur la figure suivante :

Les rédacteurs soulignent qu'il n'y a pas de standards pour contrer les attaques de type Deny Of Service, et qu'il est bien sûr du ressort de l'infrastructure de préserver la disponibilité des services. Les technologies utilisées pour les applications Web seront de mises sur ce point : Load Balancing, utilisation de clusters et la réplication …

J'ajoute sur ce point que la stack de communication orientée services WCF de Microsoft ainsi que les fonctionnalités intrinsèques des OS Windows Serveur 2003 (complété par IIS) et Windows Serveur 2008 (complété par IIS 7 et le WAS - Windows Activation Service) sont riches de mécanismes complémentaires pour assurer la disponibilité des services Web ou non (TCP…) .Les articles MSDN suivants présentent ces aspects : Etendre ses services au-delà de HTTP avec WAS, Load balancing avec WCF.

Le guide rappelle ensuite les risques les plus courants auxquels sont confrontés les Services Web, en plus des risques traditionnels encourus par tout logiciel connecté à un réseau :

L'utilisation des FireWall est limité puisque les messages sont routés sur un port HTTP, et il est difficile pour des raisons de performances de scruter tous les messages SOAP traversant un firewall
La possibilité de router (intercepter, et transmettre) un message un intermédiaire introduit des failles supplémentaires et empêche l'utilisation des protocoles classiques de sécurité HTTPS et SLL sur tous les nœuds de la chaîne de transmission d'un message SOAP
Le contrat WSDL présente lui aussi un risque de sécurité, s'il n'est pas correctement filtré, il peut exposer des fonctionnalités dépréciées, des points d'exposition réservés aur développement, bref, autant de zones d'attaques clairement exposées.
De la même façon, les annuaires UDDI décèlent des informations telles que les versions de protocoles utilisés, si bien qu'il sera simple d'exploiter une faille de sécurité connue sur tel ou tel protocole. De plus, les annuaires UDDI n'intègrent la possibilité de signer leurs contenus qu'à partir de la version 3, si bien qu'un Service Web malicieux pourrait introduire de fausses entrées !
Enfin, les frameworks .Net ou Java utilisés pour implémenter des services Web, mettent en œuvre des mécanismes de sécurité intégrés à la CLR ou la JVM. Les scénarios de sécurité mettant en œuvre des jetons sont intéressants car indépendant de telle ou telle plate-forme. Néanmoins , les frameworks proposent cette fonctionnalité de façon plus ou moins intégrée si bien que le développeur pourra être amené à réaliser des développements sur mesure, source de faille de sécurité.

Remarque : WCF intègre nativement la gestion des jetons de sécurité. La documentation MSDN présente l'architecture de la sécurité dans WCF, ainsi que l'article Security in Windows Communication Foundation.

La section 3 présente les principes d'utilisation des protocoles WS-* pour répondre à des besoins précis

Gérer l'authentification entre 2 deux services
Utiliser un système de gestion des identités
Etablir une relation de confiance entre deux services
Mettre en œuvre des politiques de sécurité
Mettre en œuvre une authentification et des autorisations distribuées
Garantir l'intégrité et la confidentialité des échanges entre deux services
Tracer les échanges SOA
Assurer la disponibilité de ses services
Sécuriser la découverte des services

Pour plus d'informations la sécurité de la SOA Microsoft

Gestion des identités, consulter l'interview de Bernard Ourghanlian
http://www.magsecurs.com/spip.php?article7820

Stéphane Goudeau propose un livre blanc qui couvre la mise en œuvre de scénarios d'échanges sécurisés entre Services Web avec Windows Communication Foundation
https://www.netfxfactory.org/files/folders/documents/entry105.aspx

MSDN : Windows Communication Foundation et la sécurité
http://msdn2.microsoft.com/en-us/library/ms732362.aspx

Qu'est-ce que le NIST ? Et le CSD ?

Le National Institute of Standards and Technology (Institut national des standards et de la technologie), aussi connu sous le sigle NIST, est une agence du Département du Commerce des États-Unis. Son but est de promouvoir l'économie en développant des technologies, la métrologie et des standards de concert avec l'industrie. Cette agence a pris la suite en 1988 du National Bureau of Standards, fondé en 1901 avec substantiellement les mêmes missions (ref Wikipedia).

Le NSIT dispose d'un budget de 843 millions de dollars et emploie environ 2900 personnes dont scientifiques et administratifs,plus 1800 scientifiques externes.

La division Sécurité des ordinateurs (CSD) de la NSIT fait partie des laboratoires spécialisés dans les technologies de l'information. Cette division a pour objectifs

d'améliorer la sécurité des systèmes en augmentant le niveau d'informations concernant les risques IT , en particulier concernant les technologies nouvelles et émergentes.
d'effectuer des recherches et prodiguer des conseils en ce qui concerne les zones de fragilités de sécurité de l'IT
De promouvoir des standards et des programmes de tests et validation
Et enfin de produire des recommandations afin d'améliorer la sécurité des systèmes d'infomation

Microsoft ESB Guidance : Un bus de services ouvert et reposant sur vos infrastructures existantes

Steve SFARTZ — Fri, 31 Aug 2007 19:03:00 GMT

Vos infrastructures sont dotées de Windows Serveur 2003 et de Biztalk 2006, téléchargez l'ESB Guidance pour constituer votre bus de service d'Entreprise !
Sans licences supplémentaires, mettez en place votre infrastructure SOA en vous appuyant sur des produits éprouvés (.Net 3.0, Windows Communication Foundation, SQL Serveur 2005, Biztalk 2006 R2, MSMQ…)

Historique du projet

Annoncé en Octobre 2006, le kit ESB de Microsoft est en preview, une version finale est prévue pour Octobre 2007, dans le mois qui suivra la sortie de Biztalk 2006 R2. Pour rappel, au menu de Biztalk 2006 R2, de nouvelles fonctionnalités EDI et RFID, ainsi que le support du framework .Net 3.0 (WF et WCF) et notamment le Biztalk Adapter Pack permettant de se connecter à toutes sources de données en WCF.

De façon originale, ce kit est un co-développement des équipes Patterns & Practices ainsi que la division Connected Systems de Microsoft Corp.Bref, le meilleur de la connectivité chez Microsoft (WCF, identité, sécurité, …) allié à la méthodologie et l'expérience terrain de Patterns & Practices.
Côté expérience, une vingtaine de projets utilisent déjà ce kit.
Des témoignages sont déjà disponibles : Kaiser Permanente qui a été à l'origine du projet, NewEgg.com….

Proposé dans sa première version uniquement aux partenaires spécialisés sur la problématique ESB , le kit est désormais disponible pour tous, le projet étant hébergé sur le site communautaire CodePlex.

Que comprend l'ESB Guidance

Le kit est composé d'un code destiné à packager Biztalk 2006 sous la forme d'ESB (les fonctionnalités d'un EAI + celles d'un MOM - Message Oriented Middleware), de documentation et d'exemples.
Pour faire le tour des fonctionnalités proposées, consulter les PPTs ESB Overview et ESB Technical Overview.
Le kit propose 6 catégories de fonctionnalités :

L'exposition sous forme de Services Web des modules internes de l'ESB tels que la résolution de points d'exposition, les indirections, et les transformations opérables sur les messages
Les modules built-in tels que les agents chargés des transformations et de la livraison des messages
Les canaux de réception des messages aux formats variés : SOAP, JMS (WebSphereMQ) …
Les canaux d'émission de messages aux mêmes formats : SOAP, JMS (WebSphereMQ) …
Le gestionnaire d'exceptions qui peut déléguer le traitement de celles-ci ou bien les transmettre au portail d'administration de l'ESB
Le portail d'administration, hébergé par SharePoint, qui permet de configurer l'ESB, gérer les exceptions et qui fournit les informations et métriques opérationnelles.

Ces fonctionnalités sont implémentées en majeure partie à partir des modules d'Orchestration, de Transformation, de Gestion de règles métier, et la Message Box de Biztalk, et permettent de réaliser des transformations dynamiquement, du routage basé sur des règles dynamiques , fonction du message, de la résolution de nom...

Avec qui démarrer mon projet ?

Le Microsoft Technology Center, les équipes Microsoft Consulting Services et nos partenaires intégrateurs sont là pour vous accompagner.
Revenez vers l'équipe des Architectes Microsoft France et nous qualifierons ensemble la meilleure forme d'accompagnement de votre projet.