users@jax-rpc.java.net

Re: DII client accessing .NET web service

From: Doug Kohlert <Doug.Kohlert_at_Sun.COM>
Date: Fri, 29 Oct 2004 12:01:41 -0700

Ryan,
If you are sure the WSDL is ws-i compliant then you probably don't need
to specify -f:wsi.

Ryan LeCompte wrote:

>Doug,
>
>When I use the -f:wsi and the -f:documentliteral together to produce the
>WSDL, I don't see any difference in the content of the generated WSDL
>compared to a generated WSDL when just the -f:documentliteral option is
>specified (and not the -f:wsi). Does this imply that the -f:documentliteral
>option causes a WSI 1.0 compliant WSDL to be generated? I guess I'm
>struggling with the fact that it doesn't seem that I need the -f:wsi option
>when going from a WSDL or a Java interface since -f:documentliteral appears
>to generate a WSI 1.0 compliant WSDL, and I can generated a .NET as well as
>JAX-RPC web service implementation using that WSDL without any problems. I
>just wanted to be sure that NOT using the -f:wsi option was not making my
>WSDL non-WSI 1.0 compliant, etc.
>
>-- Ryan
>
>-----Original Message-----
>From: Doug Kohlert [mailto:Doug.Kohlert_at_Sun.COM]
>Sent: Friday, October 29, 2004 1:48 PM
>To: users_at_jax-rpc.dev.java.net
>Subject: Re: DII client accessing .NET web service
>
>Ryan,
>The -f:documentliteral options has no effect when starting from a WSDL.
>The -f:wsi option verifies that the WSDL is ws-i compliant and also does not
>uwrap wrapper cases. You can use the -f:wsi flag with the -f:unwrap option
>to unwrap the wrapper cases though.
>Give that a try and see if it works for you.
>
>Ryan LeCompte wrote:
>
>
>
>>Doug,
>>
>>I also notice that the generated Java classes are a bit different when
>>going from a WSDL file to the Java interfaces with specifying the
>>-f:wsi option in addition to -f:documentliteral. If you specify the
>>-f:wsi option with the -f:documentliteral option, then the main Java
>>endpoint interface uses "wrapper" classes as the arguments to methods
>>corresponding to operations in the WSDL file. If you only specify the
>>-f:documentliteral option without the -f:wsi option, then the generated
>>Java endpoint interface doesn't specify the wrapper classes as the
>>method arguments but rather the regular Java class as the argument,
>>such as MyObject ( as oppposed to the generated wrapper). However, when
>>using DII you still need to wrap MyObject with the generated
>>wrapper/holder class. Should I be okay with just specifying the
>>-f:documentliteral and not the -f:wsi when starting with the Java
>>endpoint interface as well as when I'm starting with a WSDL file that was
>>
>>
>previously generated with just the -f:documentliteral option?
>
>
>>Thanks!
>>
>>-- Ryan
>>
>>-----Original Message-----
>>From: Ryan LeCompte [mailto:ryan.lecompte_at_pangonetworks.com]
>>Sent: Friday, October 29, 2004 1:25 PM
>>To: users_at_jax-rpc.dev.java.net
>>Subject: RE: DII client accessing .NET web service
>>
>>Doug,
>>
>>Thanks for responding. So this means that I can just use
>>-f:documentliteral and not specify the -f:wsi option and my generated
>>WSDL/classes will be WSI 1.0 compliant, correct?
>>
>>Thanks,
>>
>>-- Ryan
>>
>>-----Original Message-----
>>From: Doug Kohlert [mailto:Doug.Kohlert_at_Sun.COM]
>>Sent: Friday, October 29, 2004 12:56 PM
>>To: users_at_jax-rpc.dev.java.net
>>Subject: Re: DII client accessing .NET web service
>>
>>Ryan,
>>The -f:wsi switch really does not do anything when starting from Java
>>except that it changes the default from rpc/encoded to rpc/lit. To get
>>doc/lit you must specify the -f:documentliteral option.
>>
>>Ryan LeCompte wrote:
>>
>>
>>
>>
>>
>>>Hello Kathy,
>>>
>>>Thank you for your response on the mailing list. I was actually able
>>>to solve this problem by setting the Call.SOAPACTION_URI_PROPERTY
>>>property correctly in my DII client application. However, I have
>>>another question that you may be able to help me out with. I'm a bit
>>>confused on when I should use the "-f:wsi" feature for the wscompile
>>>utility. I have been using the "-f:documentliteral" feature with
>>>wscompile to generate a WSDL file that will work with .NET, etc. Is it
>>>true that I only need "-f:wsi" if I want to generate JAX-RPC
>>>stubs/ties on the server-side that are WSI 1.0 compliant? It appears
>>>that the WSDL file that is produced when I use BOTH the -f:wsi and
>>>-f:documentliteral features is exactly the same as if I just use only
>>>the -f:documentliteral feature. I have been using only the
>>>-f:documentliteral (and not -f:wsi) for generating all of my
>>>client/server stubs/ties as well as the seralizers used by the DII
>>>client, and I haven't had any trouble accessing my JAX-RPC or .NET web
>>>service implementation that is based on the same WSDL produced by
>>>using just -f:documentliteral. Also, .NET doesn't complain that the
>>>generated WSDL isn't WSI 1.0 compliant. Is there something that I'm
>>>missing here? Am I okay with not using the -f:wsi feature? Note that
>>>I am also generating my server side web service implementation based
>>>on the generated WSDL from passing only -f:documentliteral to
>>>wscompile (as opposed to building the server side implementation from
>>>the Java endpoint interface).
>>>
>>>Thank you,
>>>
>>>-- Ryan
>>>
>>>----------------------------------------------------------------------
>>>--
>>>From: Ryan LeCompte [mailto:ryan.lecompte_at_pangonetworks.com]
>>>Sent: Wednesday, October 27, 2004 2:17 PM
>>>To: 'users_at_jax-rpc.dev.java.net'
>>>Subject: DII client accessing .NET web service
>>>
>>>Hello,
>>>
>>>I'm attempting to access a .NET web service using document/literal via
>>>a DII client in JAX-RPC (JWSDP 1.4). I'm using the
>>>Call.invokeOneWay() method, everything appears to be sent correctly
>>>(there are no exceptions thrown in any of the DII client code).
>>>However, the request never seems to get to the .NET side. Are there
>>>any known issues with DII and .NET? Note that the DII client works
>>>fine when the web service is implemented with JAX-RPC and running in
>>>the Tomcat 5.0 web container.
>>>
>>>Thank you,
>>>-- Ryan
>>>
>>>
>>>
>>>
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
>>For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
>>For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
>>For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net
>>
>>
>>
>>
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
>For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
>For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net