Axis2 Web Service Client Generation - Types without modifying the client

Question

Is it possible with Axis2 and Eclipse to generate a Web Service client and have it use java types that you already have in packages instead of creating it\'s own types. Rea

Answer 1

If you use eclipse as your ide, that is waht you need: http://www.eclipse.org/webtools/. It does beyond other things exactly what you want.

Answer 2

In case this post is still of any use to someone I read the axis2 generating clients guide: http://axis.apache.org/axis2/java/core/docs/userguide-creatingclients.html.

It seems that the Axis2 Eclipse plugin is configured to call ADB code generation in integrated mode (see http://axis.apache.org/axis2/java/core/docs/adb/adb-howto.html), thus creating inner classes in the Web service stub. I don't know if changing the generation mode to expanded mode (generate data classes out of the stub class) is possible, but you can do it command line using Wsdl2Java:

    %AXIS2_HOME%\bin\WSDL2Java -uri <wsdl file path> -p <package name> -u

The -u option tells the ADB code generator to create data classes as separate classes and not inner classes in the stub.

Answer 3

You are generating the web service client from wsdl, correct?

The only thing that the wsdl2java tool knows about is the information in the wsdl, so it won't know about any types that you have already created.

If you can get the type information into the wsdl you may get it to work, although I have never tried.

If you want an easy way to copy from Type A to Type B then you could try BeanUtils.copyProperties, as long as the setters and getters of Type A and Type B match.

Answer 4

You can directly use ServiceClient class to call web service, which provides call using XML only and returns XML response. For different methods of web service, you have to convert the XML response to some java POJO to use it. Only Response handling needs to be done at your end. that you can do like from XML to Map etc...

So you won't need any other stub classes to call any web service, only needs to handle response XML. You can convert XML to POJO using Castor or JAXB libs.

This is the way you don't need to modify your client every time for diff. web services. You can develop like providing a response handler to client externally. So that for every different web service you will have diff. response handler class which is implementation of you interface.

//common interface for response handlers...
//implement this for diff. web service/methods
public interface WSRespHandler{
    public Object getMeResp(Object respData);
}


//pass particular handler to client when you call some WS
public class WebServiceClient {
    public Object getResp(WSRespHandler respHandler) {
        ..

        return repHandler.getMeResp(xmlData);
    }
}

reference:

http://www.developer.com/java/web/article.php/3863416/Using-Axis2-and-Java-for-Asynchronous-Web-Service-Invocation-on-the-Client-Side.htm

http://www.devdaily.com/blog/post/java/java-web-service-client-read-array-list/

thanks.

www.techlads.com

Answer 5

If you really want to reuse existing classes, you can call the Axis2 API directly without generating a client using wsdl2java. Below is some relatively simple code to call a web service. You just need to fill in the web service endpoint, method QName, expected return Class(es), and arguments to the service. You could reuse your existing classes as the return values or arguments.

If your web service is pretty complicated then you may find that you have to go deeper into the API to get this approach to work.

serviceClient = new RPCServiceClient();
Options options = serviceClient.getOptions();

EndpointReference targetEPR = new EndpointReference("http://myservice");

options.setTo(targetEPR);

QName methodName = new QName("ns","methodName");

Class<?>[] returnTypes = new Class[] { String.class };

Object[] args = new Object[] { "parameter" };

Object[] response = serviceClient.invokeBlocking(methodName, args,
                returnTypes);

Answer 6

pretty much most java webservices projects go through this. I don't know if the .NET/C# world have a more elegant solution.

It makes sense, as Mike mentioned, to use BeanUtils.copyProperties.

BR,
~A