The doclit example is hard-coded to a particular public service URL. If
that service is down, or if you need to go through a proxy, the sample
will fail as written. Hopefully, the proxy problem will be taken care
of shortly.
The method call
call.setDocLitSerialization(true);
specifies literal serialization. It is not a smart implementation: it
simply suppresses generation of xsi:type and encodingStyle attributes.
It does not actually read WSDL, and it will not generate xsi:type where
it is required, e.g. where the WSDL specifies xsi:anyType. Regardless,
it provides interop for at least 90% of the document/literal services
I've seen.
As was mentioned in a separate posting, using RPC encoding in your .NET
services improves interoperability across the many SOAP implementations
that exist.
Scott Nichol
----- Original Message -----
From: "penguin" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, September 26, 2002 6:04 AM
Subject: Re: InterOp. between Java Client and .NET Web Service and vice
versa
> Thanks so much for yours helping.
> The VB Client works well :-)
> And about Java Client Code> I realized that the doclit
> example is as same as my Java Client Code, except the
> line:
> call.setDocLitSerialization(true);
> What is it used for ?
>
> P/s: I cannot run the doclit example, it tells that:
> "Caught SOAPException (SOAP-ENV:Client): Error opening
> socket: java.net.ConnectException: Operation timed
> out: connect" :-(
>
> __________________________________________________
> Do you Yahoo!?
> New DSL Internet Access from SBC & Yahoo!
> http://sbc.yahoo.com
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
