Os expongo la situación,

Tengo implementado un servicio SOAP en .NET alojado en un IIS 8.0, el servicio está bien levantado, ya que si lo consumo con un cliente .NET recibo la respuesta esperada y todo guai.

El problema viene cuando lo intento consumir desde un cliente JAVA,

Arranco mi cliente JAVA, lanzo la petición, se tira la ostia con la petición y al final me devuelve una excepción con el formato de la petición (el content-type ).

Para darle una vuelta de tuerca más,

El WS lo he implementado en VS.

Si levanto en WS desde el VS y lanzo el cliente JAVA funciona correctamente

Esto me lleva a pensar que me falta algo en la configuración del IIS ?¿?¿

El problema está en el cliente JAVA?¿

No tengo mucha idea de JAVA la verdad.

Alguno ha consumido alguna vez un WS SOAP implementado en .NET desde un cliente JAVA??

Gracias de antemano.

Buenas,

No explicas en ningun momento como has hecho el cliente Java. Puedes detallar el proceso de generacion de este?

Por otro lado, si el problema es la configuracion del IIS, me temo que desde un foro de Java poco podremos ayudarte.

Un saludo

Guenas.

Yo he tenido problemas con un cliente java de un servicio java.
El problema venia dado por que el cliente usaba librerías del SE que NO FUNCIONAN.

Usando Netbeans lo que he hecho ha sido añadir las librerías JEE al classpath y se ha corregido "magicamente" el problema. Cosas de Oracle. SUN jamas hubiera permitido esto, pero Oracle sabe mucho de comercio y nada de software. Al menos los que deciden. He sufrido el software de Oracle durante muchos años y los considero casi peores que M$. Como ejemplo ¿Alguien ha usado Oracle reports? Mi vecina que es cocinera y jamas ha tocado un ordenador escribe un software menos patetico.

Para mi opinión es de puta pena que librerías del Java SE no funcionen y las equivalentes de JEE si que lo hagan.

Salut,
Paposo

Buenas Paposo,

¿Que librerias específicas de Java SE has utilizado para consumir el WS soap?

Para crear un cliente deberías utilizar alguna herramienta tipo axis/cxf o bien alguna implementación de la spec JAX-WS como la que proporcionan librerias como las nombradas enteriormente (axis y Apache CXF) o bien Metro en Glassfish, formando parte ya del stack J2EE full platform, nunca de Java SE.

No existen "librerias equivalentes a las de JEE en Java SE" como comentas, a no ser que lo que hayas intentado sea crear el cliente "a mano" generando y parseando los mensajes soap por alguna implementacion de jax xml y realizado directamente la comunicacion con java.net

Un saludo

Guenas.

Probablemente no me he expresado bien.
Uso Netbeans 7.2 para generar el cliente web que deberia ser capaz de enviar y recibir ficheros.
El código que genera es correcto y sin añadir bibliotecas extra encuentra todo lo que necesita. El sistema usado es el de enviar o recibir un Handler.

A la hora de ejecutarse no funcionaba ni por asomo, aunque no protestaba por la falta de ninguna clase sino que simplemente se quedaba esperando el envio o la recepcion hasta dar al final un timeout.

Añadiendo las librerias de JAX-WS en el jar del cliente y sin modificar ni una linea de código ni import ya funcionaba correctamente.

Un saludo
Paposo

Buenas,

Dices que el codigo es correcto y encuentra todo lo que necesita.
A mi me da que efectivamente el codigo es correcto, se genera correctamente y compila.... porque tiene enlazadas las librerias JAX-WS en tiempo de compilacion, cosa que hace por ti seguramente Netbeans de forma transparente.

Sin embargo estas librerias no son desplegadas y por lo tanto no estan disponibles en tiempo de ejecucion cuando se ejecuta el cliente. Solo funciona cuando tu explicitamente incluyes las librerias para que sean desplegadas.

Puede ser esto? Como decia en JavaSE no se incluyen las librerias para WS.

Un saludo

Guenas.

Si faltaran clases java hubiera saltado con la excepcion ClassNotFoudException, cosa que no ha hecho.

Por otra parte he revisado el codigo y absolutamente todos los import hacen referencia a clases que estan en de JSE.

Para hacer un cliente, por lo visto no es necesario usar JEE lo cual tiene mucho sentido. Eso si, se usaban clases de JAF (tambien incluidos desde 1.6). El particular el DataHandler, que NO FUNCIONA en este caso. Esta clase me temo que esta tanto dentro del JEE como del JSE y no son compatibles. Para que funcione es imprescindible usar el de JEE en lugar del JSE, aunque se llamen igual y el import sea idéntico.
O quiza en el servidor usar el de JSE, pero eso es dificil ya que el servicor de aplicaciones es quien define el classpath estandar (a los recursos java) usados por el.

Pruebalo. Crea un WS que devuelva un fichero via DataHandler y un cliente SE que lo consuma. Apuesto a que no funcionará.

Un saludo,
Paposo