¿Cuál es la mejor manera de exponer un servicio WCF para que se pueda consumir fácilmente desde Java/CXF?

Question

Hemos escrito un servicio WCF para ser utilizado por una tienda de Java, que está utilizando CXF para generar los adaptadores. No estamos tan familiarizados con Java, pero hemos expuesto el servicio utilizando basicHttpBinding, SSL y autenticación básica. Las pruebas de integración muestran que un cliente .NET puede consumir el servicio sin problemas. Sin embargo, la tienda de Java tiene problemas para consumir el servicio. Específicamente, obtienen el siguiente error JAXB: Dos declaraciones causan una colisión en la clase ObjectFactory. Esto generalmente se produce si 2 operaciones tienen el mismo nombre y espacio de nombres cuando CXF intenta crear clases de adaptadores.

No podemos encontrar ningún nombre de tipo o operación que pueda causar cualquier tipo de colisión. Nos hemos asegurado de que todos los tipos personalizados especifiquen un espacio de nombres, y tempuri.org no se especifica en ningún lugar en el WSDL. La tienda de Java sospecha que el error se debe a que el WSDL generado contiene < xsd: import elements.

lo tanto, mi pregunta:

• ¿Hay alguna forma mejor que CXF para la tienda de Java consumen el servicio WCF? Project Tango parece interesante, pero no sé lo suficiente como para decirles que consideren usarlo. ¿Es CXF un estándar de facto en Java?
• BasicHttpBinding/SSL/Basic Auth se recomiendan MS para escenarios de interoperabilidad, pero el cliente parece tener problemas de interoperabilidad. ¿Deberíamos considerar otras fijaciones o configuraciones para que esto sea más fácil de consumir?
• ¿Hay alguna manera de configurar WCF para generar siempre un solo WDSL sin importaciones de esquema?

Answer 1

El mensaje de error "Dos declaraciones causan una colisión en la clase ObjectFactory" generalmente no tiene nada que ver con las importaciones. Ese es un mensaje de error JAXB que normalmente es causado por tener varios elementos o similares que hacen que los nombres de campo generados sean los mismos. Por ejemplo, si tiene elementos como:

< element name = "Foo" .../> y < element name = "foo" .../>

que pueden causar que el error. Otra es usar algo como guiones y guiones bajos y de tal manera que por lo general se eliminan + cubiertas: < element name = "doFoo" .../> y < element name = "do_foo" .../ >

Con 2.1.4, puede TRY ejecutar el archivo wsdl2java con el indicador -autoNameResolution. Eso A VECES ayuda con esto, pero no siempre. Desafortunadamente, la información que proporciona JAXB en estos casos es casi inútil y muchas veces es solo de prueba y error encontrar los tipos conflictivos. :-(

Answer 2

La única forma de que su cliente java hable con un componente WCF será uno de los métodos HTTP - basicHttpBinding, ws *, etc, tal como recomienda MS. Java no puede hablar con WCF sobre TCP o namedPipes o MSMQ, etc.

Comenzaría con un componente WCF súper simple, algo con un único método que escupe una cadena. Haz que funcione con Java y luego sigue tu camino hacia arriba. Asegúrese de que todo lo que expone funciona con tipos base o objetos bien definidos [DataContract].

Answer 3

He desarrollado WCF con clientes Axis2. Los métodos de autenticación que he utilizado con éxito son BasicHttpBinding/SSL/Basic (Transporte) y WS-Security con nombre de usuario (y MTOM).

aplicación El metro es utilizado por Sun y Microsoft para probar la interoperabilidad: http://weblogs.java.net/blog/haroldcarr/archive/2007/11/metro_web_servi.html

este momento ninguna pista sobre la importación generada por la WCF para la definición de esquema.

Answer 4

El problema con xsd: import es muy común Algunos juegos de herramientas o tiempos de ejecución no pueden hacer frente a los que hacer frente a esta, se puede aplanar el WSDL que se genera por la WCF Comprobar this post

En cuanto a.... si CXF es la pila correcta de Java, nunca he oído hablar de ella. He utilizado AXIS con éxito, así como JAX-WS. Ambos han sido bastante sencillos.

Answer 5

Estoy profundamente inmerso en Java & WCF interoperabilidad. Dijo que necesita aplanar su WSDL si está trabajando con WSDL basado en archivos. Sin embargo, uso Netbeans 6.5 y si apunta a una url real como http://myservice/?wsdl, Netbeans puede hacer frente fácilmente al wsdl predeterminado generado por WCF. En la vida real, otras cosas que debe tener en cuenta son las versiones de servicio, los datamembers opcionales (no funciona bien en java, entonces sugiero que todos los datamembers sean IsRequired = true), orden, etc.

Lo más difícil de conseguir ir era seguridad. Tuve que hacer que la autenticación de certificado mutuo funcionara y todavía tiene algunos problemas.

Answer 6

Este es un problema de Jaxb. Me encontré con el mismo problema, pero usé la opción xmlbeans en lugar de la generación del cliente wsdl2java. Para ser honesto, parece que prefiero los objetos xmlbeans más que jaxb como consumidor de este servicio web.