Bug/flaw in JAX-RPC xrpcc generated output (JWSDP EA1)

Question

I believe I have found a bug (or flaw) in how xrpcc (JWSDP EA1) is generating stubs and WSDL code as follows:
If you use simple parameter types (ints, doubles, Strings et al) then xrpcc generates a name that is based on the type (eg. String_1) rather than the
parm name (senderID) in the WSDL and stub code. I have noticed, however, that if you are using a JavaBean as an input/output parameter to/from a remote method, it generates an XMLSchema ComplexType with the proper names of subelements, so that situation seems to be OK.
I think this is a bug/flaw in xrpcc...
For example, if you try to use a remote method that looks somewhat like:
public int SendTrajectory( String senderID )
You get the following fragment generated in the WSDL output from xrpcc:
<message name="sendTrajectory">
<part name="String_1" type="xsd:string"/>
whereas I think it should use the actual parameter name for simple parameters and should look like:
<message name="sendTrajectory">
<part name="senderID" type="xsd:string"/>
I read the JAX-RPC Spec (v 0.7....pdf on the Sun web site) and it seems to allude to the fact that the names SHOULD be based on the parameter name in
section 5.5.5. where it specifically states:
"Each Java parameter (in the Java method signature) is mapped to a message part in the wsdl:message. This wsdl:message corresponds to the wsdl:input element for the mapped wsdl:operation. Each message part has a name attribute that is mapped based on the name of the Java parameter and a type attribute (an XML data type)"
...and the example the shown further down in that section of the JAX-RPC spec re-inforces this opinion.
The generated code works with the current version of JAX-RPC and xrpcc, that is not the problem. There is a bigger issue with this situation, since you
cannot (and should not) assume that a web service (even if generated with JAX-RPC) will be invoked by a client that was generated with JAX-RPC tools.
The problem is really evident when you don't use JAX-RPC to talk to a JAX-RPC generated service, since you have to use these funny names like String_1, Double_3 which have no application context semantics and thus will invariably lead to some really subtle bugs in remote calls.
We have used JAX-RPC to generate our server side web service in the normal manner. However, our client is running on an embedded Java (CLDC/MIDP
level device....on an aJile Java chip in fact) where the JAX-RPC footprint is way too massive for the confines of the MIDP/CLDC platform. So we are using the Enhydra kSoap API and libraries on the client end to invoke the back end JAX-RPC service. This works fine by the way! We have successfully invoked JAX-RPC wrapped services from the embedded Java platform. The
difficulty stems from the fact that the kSOAP api (and others) require you to bind the values of the parameters for the SOAP invocation by using the WSDL <part> name, and so these funny type-based names become visible in your client application code. Ouch!
For example, my kSOAP calls to invoke our JAX-RPC service look like this (where request is a SOAP web services request using the kSOAP API's):
request.addProperty ( "String_1", "SaJe314159" );
request.addProperty ( "Double_2", pvt.getLatitude() );
request.addProperty ( "Double_3", pvt.getLongitude() );
request.addProperty ( "Double_4", pvt.getBearing().floatValue() ) );
request.addProperty ( "Double_5", pvt.getVelocity() );Whereas it should really look like the following, based on our interface definitions:
request.addProperty ( "senderID", "SaJe314159" );
request.addProperty ( "latitude", pvt.getLatitude() );
request.addProperty ( "longitude, pvt.getLongitude() );
request.addProperty ( "bearing", pvt.getBearing().floatValue() ) );
request.addProperty ( "velocity", pvt.getVelocity() );The problem is that xrpcc generates the names as in the first example (String_1, Double_2) instead of using the parameter names (eg. "senderID, latitude).
We can work around this in two ways for now: 1) use the type-based generated name labels for the moment, or 2) go into the xrpcc generated stub code and WSDL and make manual changes. In the longer term, I'm sure you appreciate why either of these workarounds are not acceptable.
Based on the above, I think that there is a bug/flaw in this version of xrpcc (it's using a parameter type rather than a parameter name to generate the <message>/<part> element in the WSDL (and of course in the generated stubs and such).
Thoughts? Fix in EA2 perhaps?
Thanks!
....Andrzej

Answer 1

I've got the same problem. I edited the WSDL and regenerated both Server and Client classes and it then didn't work. Forget the error but it seemed to have incorrectly capitalised a letter in a class/method name.
I am trying to define a common WSDL doc that our suppliers must conform to when providing us with a web service. My aim is that the common WSDL will be OK for both Java-based web services and .NET based web services. I have succeeded in this task apart from the method parameter name issue. .NET (of course) does it correctly, and its WSDL correctly names the method parameters. However Java Web Services via xrpcc produce this ridiculous String_1, String_2 etc which bear no relation to the method parameters. I cannot very well go to our suppliers who are using .NET and demand that their method/function parameters are named String_1, String_2 - and wouldn't Bill be pleased with my excuse that I'm trying to get equivalence with the deficiencies of Java ?