instalar home generate from example crear con web-services wsdl axis2c

web-services - home - crear web service axis2 eclipse



Jabón WSDL relativo: ubicación de la dirección (3)

Después de una larga búsqueda, estoy casi seguro de que el atributo de location soap:address tiene que ser una URL absoluta. Esto se complica aún más si trabaja con diferentes entornos, como desarrollo, prueba y producción.

Tal vez una solución alternativa sería leer, en el lado del cliente, la primera parte de la URL de un archivo de configuración (por ejemplo, https://exampleserver.com ) y la parte final del WSDL (por ejemplo, /axis2/services/ExampleService ) y Combínalos para construir un camino absoluto. Lo primero te permitirá cambiar de entorno.

¿Puedo tener la ubicación de jabón: dirección en un WSDL en relación con la ubicación de WSDL, o al menos en relación con el servidor? Por ejemplo quiero escribir:

<soap:address location="https://exampleserver.com/axis2/services/ExampleService" />

como:

<soap:address location="/axis2/services/ExampleService" />

Esto permitiría una implementación más rápida en varios servidores, como servidores de prueba. Además, en el caso de axis2c, si quiero que mi servicio se use tanto de HTTP como de HTTPS, la vida se vuelve más difícil para los desarrolladores que usan mi servicio, ya que no pueden simplemente importar el WSDL desde su ubicación predeterminada "? WSDL".


El WSDL describe a los clientes los formatos de mensaje, los tipos, los parámetros, etc., necesarios para interactuar con el servicio web. Esto es utilizado por herramientas como WSDL2C para generar el código necesario para la interacción.

Pero incluso si expone su servicio en HTTP o HTTPS, el código de código auxiliar del cliente será el mismo. No regenera sus apéndices de cliente para cada dirección de punto final . El cliente se mantiene igual, es el punto de acceso que cambia.

Esta dirección no debe estar codificada en el código de cliente generado, debe ser una URL configurable dentro de la aplicación cliente.

Claro, tiene una URL especificada dentro del WSDL y es una molestia cuando implementa su servicio web en el servidor de desarrollo, y luego se pone en escena y se pone en producción. Los puntos finales serán diferentes en cada entorno (tal vez multiplicado por 2 para HTTP + HTTPS) pero en este punto sus desarrolladores no se verán afectados porque no regenere el código.

Cuando se trata de acceder al servicio web, aún tendrías diferentes direcciones (para servidores de desarrollo, de preparación y de producción) incluso si fueran relativas a algo o absolutas. Por lo tanto, no veo por qué es útil tener una dirección relativa dentro del WSDL, ya que todavía tiene que administrar los puntos de acceso en la configuración del cliente.


Hay dos formas de obtener el WSDL.

Uno donde se sirve un wsdl codificado, por ejemplo:

https://hostname/contextname/services/myAPIService/myAPI.wsdl

y otra donde se sirve un wsdl generado, por ejemplo:

https://hostname/contextname/services/myAPIService?wsdl

Si usas la opción dinámica, usará este código:

req.getRequestURL().toString();

para obtener la URL que se utilizará en el WSDL generado. Este código está en la clase ListingAgent (en el paquete org.apache.axis2.transport.http).

Por lo que mencionó en su pregunta, si desea tener una ubicación relativa, debe ser porque desea usarla en varios servidores, por lo que deberá usar la opción dinámica.

Un problema que encontré con las opciones dinámicas es que si en el WSDL original la ubicación está usando HTTP, entonces en el generado se seguirá usando HTTP incluso si ha usado HTTPS para acceder a él. (Esto sucede en la versión 1.5, que es la que está usando mi proyecto)

Otro problema es si está utilizando un equilibrador de carga, porque el WSDL generado se generará con la ubicación del servidor final en lugar del equilibrador. Una opción para esto sería extender las clases AxisServlet y ListingAgent para reemplazar el código mencionado anteriormente.