Hello.
My name is Tomohiro Ikeda.
I'm a mere java user, and studying Web Service technology with java using GlassFish application server.
And I found some problems in the specification of JAX-WS.

The first problem is about name collisions of wrapper beans.
I issued this problem to issue tracker of glassfish, and it was registered as Issue 482.
But this is a problem of specification of JAX-WS, not of implementation,
so there seems to be no point that I issued to GlassFish project.
Therefore, please let me offer some comments on JSR-224.
See chapter 3.6.2.1 Document Wrapped.
According to the current specification, in case starting from java, default request bean name is the same with the method name.
But if two or more Service Implementation Beans (henceforth SIB) in the same package have methods with the same name,
the names of the corresponding request beans will conflict.
In the same way, default response bean name is the method name + "Response", so names of response beans may conflict too.
Therefore, I think that default wrapper bean name should include the name of SIB to avoid name collisions of request beans and of response beans.
Additionally, if there are two methods one of which has the name of the other name + "Response" in the same SIB,
request bean name and response bean name will conflict.
For example, a SIB has "putMessage()" and "putMessageResponse()".
So, I think that default request bean name should have suffix such as "Request" like in case of response bean.
And as well as wrapper bean name, wrapper element name in the generated wsdl should not conflict because they are qualified names of xml document.
This problem seems significant.
Actually, in some cases fatal errors occur in GlassFish application server.
If nothing is done, name collisions will occur here and there, and I am afraid that JAX-WS will become difficult to use.

The second problem is about the "name" attribute of "xs:complexType" element in the wsdl (or the external document).
When starting from java, it seems impossible to control the name of xs:complexType,
which defines the type of wrapper element corresponding to input or output of operation in the wsdl generated automatically.
It is inconvenient.
To avoid the above name collisions of wrapper beans,
I used the "className" property of javax.xml.ws.RequestWrapper and javax.xml.ws.ResponseWrapper annotation.
Primarily, I specified only className.
It is true that wrapper beans were generated according to the annotations,
and I could avoid the name collisions at the server side.
But, I could not avoid the name collisions of wrapper beans at the client side.
In the client side, wrapper bean name is derived from the "name" attribute of "xs:complexType" element in the wsdl.
So, if it is possible to control the name of xs:complexType in the wsdl at the server side,
we can extricate developers at the client side from these name collisions.
I think that the name of xs:complexType should be the value of className property, but className does not affect the wsdl actually with GlassFish.
I issued this problem to issue tracker of glassfish (Issue 584) and of jax-ws (Issue 12),
but it was treated as invalid because it is not a bug.
Is it correct as specification?
The answer says that only the "localName" and "targetNamespace" properties affect wsdl.
If it is true, is there any means to control the name of xs:complexType in the wsdl when starting from java?
And is there any means to control wrapper beans when using wsimport command at the client side?
I think that even in case starting from java, we want to control the wsdl generated automatically,
so there should be means to specify the name of xs:complexType as well as the operation name and the wrapper element name in the wsdl.

The third problem is about "parameterStyle" property of javax.jws.soap.SOAPBinding annotation.
Let me touch on it for the record although it is defined in JSR-181 not in JSR-224.
Especially in the client side,
it seems complicated whether the parameterStyle of a method in the stub class generated by wsimport becomes "WRAPPED" or "BARE".
And it seems impossible to control this property.
It is inconvenient and complicated.
To make it possible to avoid above name collisions at the client side,
I reluctantly specified the "localName" of Request/ResponseWrapper annotation in the SIB at the server side.
With specifying localName, we can control the name of xs:complexType in the wsdl,
but of course the name of the wrapper element will be changed from default name.
It is true that I could avoid name collisions at the client side, but another problem occurred.
The method in the stub class generated by wsimport is specified with "BARE" as the parameterStyle of SOAPBinding annotation,
perhaps because the input and/or output wrapper element name is different from the default name.
I want a method of the stub class to be specified with "WRAPPED" because "BARE" is inconvenient,
but it seems impossible to make it "WRAPPED".
The parameterStyle seems to be derived from only relations between the wrapper element names and the operation name in the wsdl.
Altogether, to avoid name collisions, we have to use localName of Request/ResponseWrapper in the SIB at the server side,
but if we do so, the wrapper element name becomes different from the default name and the method of the stub class becomes "BARE".
So, it seems impossible for me to avoid above name collisions of wrapper beans both in server side and client side,
and make the method of the stub class "WRAPPED".
Cannot we control parameterStyle of SOAPBinding?
The rule deciding whether "WRAPPED" or "BARE" seems complicated for me.
Is it true that if the input wrapper element name is the same with the operation name,
and the output wrapper element name is the operation name + "Response", the method of stub class becomes "WRAPPED", otherwise "BARE"?
It is very complicated.
Under the present situation, it is difficult to understand whether stub will become "WRAPPED" or "BARE" without trying to execute wsimport actually.

I think that we can construct Web Services very easily and simply with using JAX-WS,
but without resolving the problems like above, it will become difficult to use and complicated as a result.
I hope you will take good care of this. Thank you.

************
Tomohiro Ikeda
E-mail : tomo-ikeda@apost.plala.or.jp
************