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 3.6.2.1 chapter of Document Wrapped.
According to the current specification, in case starting from java, default request bean's 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's name is the method's name + "Response", so names of response beans may conflict too.
Therefore, I think that default wrapper bean's 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's name + "Response" in the same SIB, request bean's name and response bean's name will conflict.
For example, a SIB has "putMessage()" and "putMessageResponse()".
So, I think that default request bean's name should have suffix such as "Request" like in case of response bean.
And as well as names of wrapper beans, names of wrapper elements in the generated wsdl should not conflict because they are qualified names of xml document, and a wrapper element's name should include the name of the SIB too.
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 mapping style i.e. wrapper style and non-wrapper style.
It's not fatal error but complicated and difficult to use.
See 2.3.1.2 chapter of Wrapper Style.
According to the current specification, when generating java artifacts from a wsdl, the mapping style is determined by the wsdl, and we can only specify whether wrapper style is enabled or disabled by customizations such as binding language.
But even if we set "enableWrapperStyle" to "true" in binding language, non-wrapper style is still used if some criteria described in this chapter are not met.
These rules are very complicated.
I feel that some of the criteria are needless for wrapper style.
At least, the criterion of (ii) seems needless.
Even if the wrapper element's name is different from the operation's name, it is possible to use wrapper style.
And even if an output message does not meet the criteria, it may be possible to use wrapper style about an input message.
I think that there should be means to choose mapping style more flexibly, and to make it possible, the criteria for wrapper style should be necessity minimum.
And when we choose wrapper style mapping, a tool such as wsimport should use wrapper style if it is possible.
If it is impossible, a tool should reject to use wrapper style with appropriate reason why it is impossible.
At present, we have to confirm the mapping style of methods in the stub class generated from a wsdl every time.
And even though we want to use wrapper style, we cannot if the wsdl does not meet the criteria.
It is very inconvenient.
Actually, I am in a difficulty.
Present situation is as follows.
To avoid above name collisions of wrapper beans, I used "localName" property of javax.xml.ws.RequestWrapper/ResponseWrapper annotation at the server side.
It is true that wrapper beans were generated according to the annotations, and I could avoid the name collisions at the server side.
But of course the wrapper element's name was changed from the operation's name, and at the client side, I could not use wrapper style.

I think that we can construct Web Services very easily and simply with using JAX-WS, but without resolving above problems, 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
************