2010-01-19 19 views
7

Hemos recibido un esquema wsdl y xsd de una empresa con la que estamos trabajando por correo electrónico. Se accede a los servicios web con los que estamos interactuando a través de un túnel IPsec. Existen referencias locales (en su extremo) en el WSDL publicado, lo que significa que no podemos consumirlo.Creación de un cliente de servicio web con wsdl conocido pero inaccesible

1ª pregunta: ¿Es esta una configuración común? Pensé que el objetivo de tener un WSDL no era solo definir el contrato sino también exponer el servicio a los consumidores.

Puedo generar fácilmente código de cliente/servidor fuera del WSDL provisto usando wsimport, wsconsume, etc. Sé cuando mi cliente generado realiza una llamada a mi servicio generado y produce el mensaje correcto que necesito.

2da pregunta: ¿Hay una manera fácil de dirigir esto a una dirección de jabón diferente?

Sólo quiero ser capaz de hacer algo como:

SalesTaxService svc = new SalesTaxService(); 
SalesTax tax = svc.getSalesTaxPort() 
tax.getRate("NY"); 

Pero no utilice la dirección de jabón definido en el WSDL. Me gustaría evitar escribir un grupo de clientes de envío para cada método.

¿Echo de menos algo?

* En respuesta a skaffman: Esto es lo que se generó. Es por defecto en wsdlLocation como un nombre encogimiento

@WebServiceClient(name = "SomeService") 
    public class SomeService_Service extends Service { 

    public SomeService_Service(URL wsdlLocation, QName serviceName) { 
     super(wsdlLocation, serviceName);    
    } 

    public SomeService_Service(URL wsdlLocation) { 
     super(wsdlLocation, new QName("urn:some_service", "SomeService")); 
    } 
    } 
+0

Ver también http: // stackoverflow. com/a/863561/147763 –

Respuesta

3

Así que descubrí por qué estaba teniendo un problema. Asumía que el wsdlLocation tenía que ser el WSDL que el servicio real estaba publicando. Esto, por supuesto, no es el caso. La solución es empaquetar un WSDL local con el SOAP correcto: dirección para el servicio real en el cliente.

edición descubrí que se puede modificar la dirección de punto final mediante programación sin tener que alterar el WSDL real:

HelloService service = new HelloService (
    this.getClass().getResource("originalHello.wsdl"), 
    new QName("http://example.org/hello", "HelloService ")); 
HelloPort proxy = service.getHelloPort(); 

Map<String, Object> ctxt = ((BindingProvider)proxy).getRequestContext(); 
ctxt.put(JAXWSProperties.HTTP_CLIENT_STREAMING_CHUNK_SIZE, 8192); 
ctxt.put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, "http://new/endpointaddress"); 

proxy.sayHello("Hello World!"); 

crédito va a: Jianming Li

5

pensé que el punto de tener un WSDL era no sólo para definir el contrato sino también para exponer el servicio a los consumidores .

No, WSDL es puramente una herramienta descriptiva, no tiene una función real de tiempo de ejecución. El servicio web opera de manera completamente independiente del WSDL. No es raro que el WSDL no esté expuesto.

¿Hay una manera fácil de dirigir esto a una dirección de jabón diferente?

Eso depende completamente de la implementación del servicio web que estés usando, y no lo dices, aunque supongo que JAX-WS. Si ese es el caso, creo que los artefactos que generan las herramientas de JAX-WS te permiten pasar la URL a los constructores de stub del cliente.

+0

+1 para generar stubs. –

+0

Gracias por la respuesta.Sí, estoy usando JAX-WS. El problema es que la URL que pasaría es la del WSDL que es inaccesible. Puedo generar mi propio servicio y dirigir al cliente hacia mi propia implementación de servicio, pero eso no va al SOAP real: dirección con la que quiero interactuar. – jgrowl

+0

¿Estás seguro? Pensé que la URL del constructor de stub era la URL del punto final del servicio web, no la URL del WSDL. Esta es la razón por la cual no me gusta JAX-WS ... bueno, una de las razones ... – skaffman

Cuestiones relacionadas