My suggestion would be to feed the WSDL generated by .Net into wsimport to
generate the client stub code. That way you should guarantee an exact
match. It's the only technique I've ever used to call .Net services, and I
haven't run into any problems.
That said I haven't got very far with JAX-WS 2 clients because of
completely unrelated problems getting it to run in my target environment (a
configurable applet) where 1.x ran fine, so maybe there are gotchas that I
haven't hit yet :-/
HTH
Rick Jones
--On 21 August 2006 16:40 -0400 Ryan LeCompte
<Ryan.LeCompte_at_pangonetworks.com> wrote:
¦ I just finished converting one of my web services from JWSDP 1.6 to
¦ JAX-WS 2.0, and I'm running into a bit of a problem. The actual service
¦ implementation is written in .NET, and the client is written using
¦ JAX-WS 2.0. The same client used to work fine with JWSDP 1.6, however
¦ I'm not seeing service operations go through with JAX-WS 2.0. My
¦ question is:
¦
¦ I know that JAX-WS 2.0 now accesses the WSDL remotely to determine which
¦ operations should be invoked (e.g.,
http://service/myservice.asmx?wsdl).
¦ By default, the .NET runtime auto-generates the WSDL at runtime when you
¦ use the ?wsdl extension in the URL. Could this be causing a problem? The
¦ interesting thing is that I don't see any errors on the Java side, and
¦ no errors in the log file on the .NET side. The data types involved are
¦ also polymorphic in nature (base type, sub-type, etc). This used to work
¦ fine in JWSDP 1.6. The only problem I can see is that the WSDL used to
¦ generated the client (in JAX-WS) is (slightly) different from the
¦ auto-generated WSDL when accessed as
http://service/myservice.asmx?wsdl.