Question

Is there any way to consume a SOAP based Spring web service without generating stubs on the client (as suggested by umpteen threads pointing to JAX-WS)?

Here is my complete scenario:

I have 2 web applications, say APP1 & APP2, both of which have Spring support. APP2 exposes it’s APIs as Spring-WS that accept POJOs (Reqeust and Response objects) via. SOAP. Now, I want to call these web services from APP1, but would like to avoid having to create stubs using the WSDL frmo APP2. Is this possible?

For more detail, here is one of my web service’s operation:

@PayloadRoot(localPart = "CreateNewRequest", namespace = "myNameSpace")
public CreateNewReqResponse createNewRequest( CreateNewReqRequest requestObj ) throws Exception
{
    NewCase newCase = this.localSpringService.createNewCase( requestObj.getParam1(), requestObj.getParam2() );
    CreateNewReqResponse response = this.objectFactory.createCreateNewReqResponse();
    CreateNewReqResponseObject responseObject = this.objectFactory
            .createCreateNewReqResponseObject();
    if( null != newCase )
    {
        responseObject.setParam1( newCase.getParam1() );
        responseObject.setParam2( newCase.setParam2() );
        }
        responseObject.setCaseRequestedDate( caseRequestedDate );
    }
    response.setResponseObject( responseObject );
    return response;
}

Now, as you can see, the web service method accepts CreateNewReqRequest and returns CreateNewReqResponse. What I am trying to figure out is how can I call this web service from APP1, which does not have any clue about these classes – CreateNewReqRequest and CreateNewReqResponse? Is there no other way other than creating stubs in APP1 (from the WSDL) using JAX-WS?

Both the applications in question are our own (that is we have developed them) but run on different servers, because of which APP1 can not call the web service directly – cross-domain policy. Hence, I will writing a servlet in APP1 which will consume the web service exposed by APP2.

Answer 1

At the end of they day SOAP is simple a protocol on top of HTTP. So if you wish to forgo the usage of JAX-WS, you could start using raw http connections and hand code the SOAP requests and manually parse the SOAP Response on your own. This would simply mean you are re – inventing the wheel which is JAX-WS Client stubs.

So If you absolutely want to avoid Stub creation, have a go it at with HTTP post and get Messages at the WSDL end point URL.

What the client Stub does is simply abstract out that implementation for you. i.e. you will not have to deal with nitty gritty of SOAP/WSDL and http connection, you would be dealing with SOAP at a higher level, i.e through Java Objects.

You could also look into other libraries such as Apache CXF or Axis, but even there you will have to generate client stubs.

Thus the question you want to ask is, Do you want to really go in and manually muck around with http connections and SOAP XMLs or let the a framework take do that grunt work for you.

Reply to Nitin’s comment follows below

To answer your questions, 1. Yes you will have to re-create the stubs if the WSDL changes, if you are not using the stubs but parsing everything manually you will have to change that code. So effectively there is no difference between the two. Your program will have to change if the WSDL (i.e. the contract between client and service) changes. This would be same even for REST, i.e. if the contract published by the service changes(Maybe the parameters, or the action etc), you will have to Change your client code. There is no escaping that. Hopefully, the public Webservices would have been designed in such a way to allow future modification, and such modifications wouldn’t happen overnight thus giving you enough time to modify your code. This issue has nothing to do with how the web service has been implemented i.e. Spring Web Service has nothing to do with.

You seem to be missing the point of the Client stubs that a SOAP framework like JAX-WS, Axis, CXF generate for you. The Client Stub is one way to talk to the Web service. It is not the only way. The Client stub is the preferred method, because it abstracts outout the nitty gritties of handling SOAP calls manually. So, rather then you re inventing the wheel and implementing a SOAP(XML) parsing library, you can concentrate your efforts on the actual application that you are writing. In your actual program you would only have to deal with POJOs and never have to worry about how the SOAP magic happens i.e. how to convert your data and package it up in a SOAP message, send that SOAP Message to the Service using a HTTP connection, handle the response, Parse the response SOAP Message and retrieve the data you care about. All of this you avoid by using the POJOs. You set the properties for request, make a method call to the client stub service method, and recieve an object, everything else is you don’t have to worry about (ideally).

I hope this clear things up a bit.