Avec un projet récent, notre équipe de développement basée sur .Net a été chargée d'intégrer une multitude de services Web basés sur Java dans le monde entier, et nous avons vraiment eu un nombre surprenant (enfin, nous ne sommes certainement plus surpris) d'un grand nombre de problèmes car le XML généré par WCF n'est pas accepté par les services java.
Il semble également qu'il n'y ait pas vraiment beaucoup de bonnes informations à trouver sur le sujet, nous avons obtenu de bons conseils de l'excellent blog WCF de Yaron Nave, http://webservices20.blogspot.com , et également sur le forum MSDN WCF http: //social.msdn.microsoft.com/Forums/en-US/wcf/threads .
Y a-t-il quelqu'un ici qui a vraiment l'impression d'avoir compris cela et qui connaît la ressource définitive sur le sujet? Serait intéressé par des conseils sur des livres, des blogs ou des sites Web.
Edit:
Je suis déchiré sur la définition de la réponse acceptée sur ce fil, car chacune des deux meilleures réponses a une certaine valeur:
1. Nous finirons probablement par faire plus d'implémentations de Webrequest HTTP au lieu de combattre WCF.
2. Mais le WCF Express Interop Bindings 1.0 était également une astuce très judicieuse.
Réponses:
Ah oui ... SOAP, le Saint Graal vanté de l'informatique. Une lingua franca qui promettait l'interopérabilité entre les systèmes du monde entier.
Et puis vous entrez dans les différences entre les implémentations SOAP sur Java et PHP et .NET. Ou même entre le service WebSphere SOAP et le client Apache SOAP. Ne vous occupez jamais des différentes normes de compatibilité WS-I. Maintenant, dites-moi pourquoi vous avez besoin d'une norme de compatibilité pour un protocole qui a été conçu pour la compatibilité , parlez d'ironie (et je veux dire de la vraie ironie, pas de la marque d'ironie Alanis Morrissette ).
La seule fois où vous ne rencontrerez pas de problèmes lors de la communication de deux points de terminaison SOAP, c'est lorsqu'ils sont tous les deux sur la même plate-forme et dans la plupart des cas, la plate-forme aura un protocole d'opération à distance plus efficace.
Ce que je dis ici, c'est que pour la plupart, le savon est inutile. Maintenant, du savon en minuscules, je l'utilise tous les jours et je suis reconnaissant à la plupart des gens de faire de même.
Cela étant dit, si vous insistez pour vous battre la tête contre un mur de briques. Voici un bon point de départ. Microsoft dispose d'un ensemble de liaisons pour permettre l'interopérabilité avec la plupart des principaux serveurs Java. La partie amusante est bien sûr de savoir lesquels fonctionnent avec quels services vous intégrez.
la source
À mon avis, votre observation est assez exacte. Les implémentations de haut niveau de la communication basée sur XML ne sont généralement pas compatibles avec différentes plates-formes, même si elles sont toutes deux appelées "SOAP". Des différences subtiles dans la mise en œuvre, probablement dans le cadre de la norme implémentée, créent des problèmes dans l'utilisation réelle.
Ma recommandation pour les prestataires de services: utiliser une implémentation simple plutôt qu'une implémentation très complexe et théoriquement meilleure. Par exemple, n'incluez aucun schéma d'authentification extrêmement complexe si vous n'en avez pas besoin.
Ma recommandation pour les consommateurs de services (vous, je présume): lorsque vous communiquez avec une implémentation de haut niveau sur une plate-forme différente de la vôtre, dégradez-la en une implémentation de niveau inférieur. Cela devient soudainement assez simple si vous découvrez simplement quel est le XML réel à envoyer, puis utilisez les bonnes pratiques de codage normales pour y parvenir, au lieu d'insister sur l'utilisation de l'implémentation de haut niveau de votre propre plate-forme.
J'espère que ce n'était pas trop abstrait. En bref , lorsque vous êtes sur la plate-forme .NET et que vous vous connectez à une plate-forme Java, vous souhaiterez peut-être simplement assembler les en-têtes et le xml dans un HttpWebRequest et l'envoyer de cette façon.
la source
Vous aurez également les mêmes problèmes en consommant les services Web PHP.
Notre seule réponse à cela a été de changer le type de protocole en REST plutôt qu'en SOAP. Nous n'avons jamais réussi à faire interagir le SOAP, tant pis pour Simple!
la source