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

image

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 :

image

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)

image

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.