SOA & Interop @ Microsoft France : JavaMS

[TechDays 2009] Tour d'horizon REST en environnement Microsoft et hétérogène

Steve SFARTZ — Tue, 17 Feb 2009 13:45:00 GMT

Afin de faire un tour d’horizon de l’architecture REST et son implémentation en environnement hétérogène .Net et Java, cette session a été co-animée avec Thierry Boileau de la société Noelios Technologies, spécialistes REST et concepteurs du framework Restlet.

Nous avons choisi de consacrer 30 minutes aux principes d’architecture REST et à la méthodologie ROA/D préconisée par Noelios : identification des ressources, constitution des URI, choix des méthodes, conception des représentations, définition des statuts HTTP. En conclusion, de cette première partie, REST est un style d’architecture, chacun doit se positionner depuis les positions les plus pragmatiques ou plus puristes (au sens respectueuses de la thèse de Roy Fielding).

Nous avons ensuite parcouru les implémentations proposées par Microsoft et Noelios, en présentant des implémentations permettant de parcourir et mettre à jour une liste de clients :

WCF : depuis la version 3.5, WCF propose un binding adapté au style REST (WebHttpBinding) qui permet de construire ses URI (URI template), de définir ses styles de représentation (XML, JSON…) et de spécifier ses Méthodes (GET, PUT, POST, DELETE). WCF constitue ainsi une fondation pour les frameworks cités ci-après.

WCF REST Starter Kit : annoncé en octobre 2008, ce framework opensource proposé sur CodePlex implémente les scénarios REST les plus courants, à savoir exposer une ressource sous format XML ou JSON, une collection de ressources, un flux Atom… Le kit est complété de template Visual Studio.

ADO.NET Data Services : Ce framework est une extension standard de .Net 3.5 et de Silverlight 2, et une API javascript est aussi disponible. En pratique, il s’agit ici d’exposer et consommer des ressources très facilement au travers d’interfaces REST qui permettent de parcourir le graphe de ressources, avec une intégration de sources de données relationnelles au travers du framework ADO.Net Entity. Remarque : il est aussi possible d’exposer des sources de données mémoires. Ce framework est largement utilisé par les services en ligne Microsoft (notamment Azure Storage et SQL Services), et il a le gros avantage de simplifier la manipulation des ressources côté client au travers d’une API dédiée (qui permet de s’affranchir de l’écriture de requêtes REST, mais aussi de la gestion des états des données – notion de “Unit of Work / Persistance Unit” pour les familiers de TopLink / JPA). Les flux échangés sont de type Atom pour les collections et possibilité de choisir XML/JSON pour les éléments atomiques.

Restlet : le framework opensource Java de Noelios a la caractéristique d’implémenter l’ensemble du paradigme REST, en étant nativement orienté Composants et Connecteurs. En pratique, une application expose des Ressources qui proposent des représentations.

Nous avons ensuite présenté une synthèse qui positionne ces implémentations. Remarque : s’il est possible d’accéder en REST à l’API ADO.NET Data Services, cette communication sera simplifiée si on utilise une API client ADO.NET Data Services.

Figure : Synthèse REST en environnement hétérogène

Nous avons conclu en présentant 2 scénarios d’interopérabilité :

Une application Silverlight qui accède à des ressources REST exposées en Java Restlet. Dans la mesure où la technologie Silverlight limite les méthodes HTTP à POST et GET, nous avons du surcharger l’URI de mise à jour avec une extension Restlet pour supporter le PUT (?method=PUT). Pour une meilleure interopérabilité, je vous invite à utiliser l’extensibilité HTTP au travers d'un header X-HTTP-Method-Override.

Une intégration Restlet des queues de messages de Windows Azure, qui permet donc de manipuler les queues de messages en Java, cad, pousser et retirer des messages mais aussi créer et supprimer des queues. Cette démonstration a été réalisée grâce à l’intégration de la technologie d’authentification SharedKey et SharedKeyLite par les équipes Noelios Technologies dans les derniers builds de la version 1.2. (unstable build du 16 février).

Interopérabilité des Services Web ... sur le terrain

Steve SFARTZ — Wed, 12 Mar 2008 13:13:00 GMT

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.

[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

[13 décembre] RV de l'interop : Anticipez le support de SDO.Net par l'OASIS

Steve SFARTZ — Tue, 20 Nov 2007 12:05:00 GMT

Le 25 octobre 2007, l'OASIS a annoncé la création d'un comité technique autour des spécifications SDO. Pour faire bref, disons que SDO (Service Data Objects) permet de décrire une grappe de de données au format XML, mais aussi les modifications opérées sur ces données (cad, un diff) de façon à pouvoir soumettre ces modifications à un service d'exécution de ces modifications (Data Access Services). Pour compléter ces éléments, un communiqué de presse est disponible.

Le premier objectif du comité sous 6 mois sera de livrer des spécifications SDO 2.1.1 comprenant des fix ainsi que le support de C++. Dans un second temps, et sous un délai de 15 à 18 mois, le comité livrera SDO 3.0 :

Enhancements to Static SDO : SDO Metadata, API for generation, Defining name mangling and package to namespace mappings, Consolidation with data objects from standard frameworks (JAX-B)
Service Level Programming API : readOnly properties modification, enable or disable SDO runtime features
Features related to the Data Access Services (DAS) Specification : Support for a concept of identity in SDO, and its relationship to other, Support for partially loaded graphs.
SDO XML Path Support
Improved XML/XSD Support : Improve tolerance for malformed XML, API to perform validation.
Cleaning up/ Enhancing the SDO API
Organization of SDO Type System and Helpers
Enhancements to SDO Metadata : Support validation against the metadata, where appropriate, Provide support for versioning of types, Provide a mechanism for identifying an ID property when defining Types, and Properties, Provide a mechanism to externalize the SDO-to-XML mapping.
Interoperability with .NET : Define interoperability with ADO .NET diffgrams
Relaxing Containment Requirements
Notification Support : Define a callback mechanism to inform clients of changes to properties
Programming Language Support : Language Specifications for Java, C++, and for all languages that are compliant with the .NET platform, May define additional programming language support for SDO 3.0 : C, COBOL, PL/I, JavaScript,PHP, Python, Perl, Ruby, Groovy

Pour découvrir les Data Access Services, et comment les spécifications SDO.Net s'articulent avec Linq et ADO.Net, inscrivez-vous au rendez-vous de l'interopérabilité du 13 décembre 14h.

La société XCALIA, éditeur de XICS (XCALIA Intermediation Core Server) et membre du comité technique SDO de l'OASIS, vous présentera ses travaux autour de SDO.Net et l'intégration avec l'environnement Visual Studio 2008 et Linq.