Quelle est la meilleure façon d'exposer un service WCF afin qu'il puisse être facilement consommé de Java / CXF?

Question

Nous avons écrit un service WCF pour être utilisé par un magasin Java, qui utilise CXF pour générer les adaptateurs. Nous ne sommes pas familier avec Java, mais nous avons exposé le service à l'aide basicHttpBinding, SSL et l'authentification de base. Les tests d'intégration montrent qu'un client .NET peut consommer le service très bien. Cependant, la boutique Java est la difficulté à consommer le service. Plus précisément, ils getthe l'erreur suivante JAXB: Deux déclarations provoquent une collision dans la classe ObjectFactory. Cela est généralement causé si 2 opérations ont le même nom et espace de noms lorsque CXF tente de créer des classes d'adaptation.

Nous ne pouvons trouver aucun nom de type ou opération qui devrait causer toute sorte de collision. Nous avons fait en sorte que tous les types personnalisés spécifier un espace de noms, et tempuri.org est spécifié nulle part dans le WSDL. La boutique Java soupçonne l'erreur est parce que le WSDL généré contient

Alors, mes questions:

• Y at-il de mieux que CXF pour la boutique Java consomment le service WCF? Le projet Tango semble intéressant, mais je ne sais pas assez pour leur dire à envisager de l'utiliser. Est-CXF une norme en Java defacto?
• BasicHttpBinding / SSL / Basic Auth sont MS recommandé pour les scénarios Interop, mais le client semble encore avoir des problèmes Interop. Si l'on considère d'autres fixations ou paramètres pour vous faciliter la tâche à consommer?
• Est-il possible de configurer WCF pour toujours sortir un seul WDSL sans les importations de schéma?

Answer 1

Les « Deux déclarations provoquer une collision dans la classe ObjectFactory » message d'erreur a généralement rien à voir avec les importations. C'est un message d'erreur JAXB qui est habituellement causée par plusieurs éléments ayant ou similaires qui causent les noms de champs générés soient les mêmes. Par exemple, si vous avez des éléments tels que:

et

Cela peut provoquer cette erreur. On peut aussi utiliser chose comme des traits d'union et underscores et ce qui sont habituellement éliminés + plafonnés: et

Avec 2.1.4, vous pouvez essayer d'exécuter le wsdl2java avec le drapeau de -autoNameResolution. Cela aide PARFOIS avec cela, mais pas toujours. Malheureusement, les informations que JAXB donne dans ces cas est presque sans valeur et beaucoup de fois, il est juste tâtonnement pour trouver les types contradictoires. : - (

Answer 2

J'ai developpé WCF avec les clients Axis2. Les méthodes d'authentification que j'ai utilise est BasicHttpBinding sucessfully / SSL / Basic (Transport) et WS-Security avec Nom d'utilisateur (et MMD).

La mise en œuvre Metro est utilisé par SUN et Microsoft pour tester l'Interop: http://weblogs.java.net/blog/haroldcarr/ archives / 2007/11 / metro_web_servi.html

Désolé, pas la moindre idée de l'importation générée par WCF pour la définition du schéma.

Answer 3

Je suis profondément dans l'interopérabilité Java et WCF. Comme quelqu'un d'autre dit que vous avez besoin d'aplatir votre WSDL si vous travaillez avec WSDL à base de fichiers. Cependant, j'utiliser Netbeans 6.5 et si vous pointez sur un vrai URL comme http: // myservice / wsdl , Netbeans peux faire face facilement avec la wsdl par défaut généré par la WCF. Dans la vraie vie d'autres choses que vous devez prendre en compte est un service versioning, en option DataMembers (ne va pas bien en java, donc je suggère de faire tous les DataMembers isRequired = true), etc ordre.

La vraie chose difficile à y aller était la sécurité. Je devais rendre le travail d'authentification de certificat mutuelle et il a encore quelques problèmes.

Answer 4

La seule façon pour votre client java pour parler à un composant WCF sera l'une des méthodes HTTP - basicHttpBinding, ws *, etc comme MS recommande. Java ne peut pas parler WCF sur TCP ou namedpipes ou MSMQ, etc.

Je commence par un composant WCF super simple - quelque chose avec une seule méthode qui recrache une chaîne. Obtenez que le travail avec Java et travailler votre chemin vers le haut. Assurez-vous que tout ce que nous exposons travaille avec des types de base ou bien définis [DataContract] objets.

Answer 5

Le problème avec xsd: import est très courante. Certaines boîtes à outils ou runtimes ne peuvent pas faire face à cela. Pour résoudre ce problème, vous pouvez aplatir le WSDL qui est généré par la WCF. Consultez ce post.

Quant à savoir si CXF est la bonne pile Java - Je ne l'ai jamais entendu parler? Je l'ai utilisé avec succès AXIS, ainsi que JAX-WS. Tous deux ont été assez simple.

Answer 6

Ce problème est JAXB. Je suis tombé sur la même question, mais a utilisé l'option xmlbeans place dans la génération de client wsdl2java. Pour être honnête, je semble préférer les objets xmlbeans plus sur JAXB jusqu'à un consommateur à ce webservice.