Will this web service accept both raw xml and an object?

We have a web service that provides auto insurance quotes and a company that provides an insurance agency management system would like to use the web service for thier client but they want to pass the web service raw xml instead of using the wsdl to create a port, the object the service expects and calling the web method.

The web service has performed flawlessly by creating an object like so

    com.insurance.quotesvc.AgencyQuote service = new com.insurance.quotesvc.AgencyQuote();
com.insurance.quotesvc.QuotePortType port = service.getQuotePortType();
com.insurance.quotesvc.schemas.request.ACORD parameter = null;

Then create initialize the request object with the other ob开发者_如何学Gojects that make up the response.

  parameter = factory.createACORD();
  parameter.setSignonRq(signOn);
  parameter.setInsurancesSvcRq(svcRq);

And send the request to the web service.

  com.insurance.quotesvc.schemas.response.ACORD result = null;
  result = port.requestQuote(parameter);

By doing that I am able to easily marshall the request and the result into an xml file and do with them as I wish. So if a client was to send the web service via an http post as raw xml inside of a soap envelope. Would the web service be able to handle the xml without any changes being made to the web service or would there need to be changes made to the web service in order for it to handle a request of that type?

The web service is a JAX_WS and we currently have both Java and C# clients consuming the web service using the method described above but now there is another client who wants to send raw xml inside of a soap envelope instead of creating the objects. I feel pretty sure that they will be making the call to the web service using vb.

I'm sure I'm missing something obvious but it is eluding me at the moment and any help is greatly appreciated.

I think you'd need separate URLs to handle this situation. You'd still map your WSDL and its endpoint as you're doing. But then you'd need to configure a second, separate URL that would have a servlet that accepted an encoded XML stream from the HTTP POST and dealt with that separately.

In theory, it should be possible to hand-build XML that is indistinguishable from the XML that is created by a conventional WS client.

In practice, getting this right in all of the edge cases could be rather difficult. And if they (the clients who send raw XML to your service) get it wrong, they are liable to get a lot of obscure errors ... and you may need to help them with diagnosing these errors.

In the worst case, malformed messages might impact on your system's performance. But one would hope that the WS middleware layers and your application are hardened against the effects of malformed requests.

In short, @duffymo's approach of creating a second API is less risk for you, though the cost is more up-front work for you. But the simplest approach would be to just say "No!".

Should be no problem since your wsdltojava and wsdltocsharp will just do that for you behind the scenes. As long as they follow the contract set out by the WSDL.

But it is a lot of work doing it manualy and completely unneccesary since there is also a wsdltovb thing which should be eassier for them. ANd they have to do it all over again when you change something on your side.

They are just reinventing the wheel.