views:

77

answers:

2

I have a simple web service. One of the exposed methods returns a java Object of type "Data". This Data class has a method called "getName()". I compile the project, run "wsgen" on it, and start the service (using the JDK6's embedded HTTP server, not tomcat or glassfish etc.)

So far so good, I can see the wsdl in my browser at the appropriate url.

However, when I try and import that wsdl into another project, the import process successfully creates the "Data" class (which is a class found in the server project), but there are no methods created for that class, so I can't do something like "data.getName()".

My problem is that the "getName()" method exists in the Data class in the server project, but in the client project, though the Data class gets created, the "getName()" method doesn't get created by the wsdl import process.

What am I doing wrong?

A: 

It can't work unless both client and server have a JAR file in their CLASSPATH that lets them both know what 'Data' means. You need to create a common JAR that you can distribute.

Putting objects in a web service signature is far too brittle. Non-Java clients can never use you; any changes to your classes will ripple throughout the system.

It's a more common practice to start with a contract and express it in terms of an XML schema, JSON, or REST and let clients and servers map that data into whatever objects they see fit. I'd recommend that your web service take that approach as well.

duffymo
I'm not concerned about other clients being unable to connect; this webservice is being built specifically for one (java) application.If you can't depend on anything other then primitive data types, that makes the service less then useful. I'm not going to (un)serialize everything to strings all the time...
A: 

The WSDL does not contain any info about logic in methods and therefor you can not generate code for the inner objects.

The simple solution is to replace the generated client side class with the same class you use server side, however this may be considered bad style.

The objects passed to a WS should be simple data holders without special logic to them you are not limited to primitive types, JAXB will handle even very complicated objects but you can not except custom logic to be copied from the server to the client such a behavior can not be standardized and would cause code duplication.

Meir