You need to create a WSDL description of your service. A .NET client should
be able to automatically consume a WSDL file and talk to the Web service,
although interoperability between .NET and Apache SOAP can sometimes be
problemmatic.
I suggest that you use the Apache Axis java2wsdl tool to gener
Hi Anne ,
Thanks a lot..
Any simple examples for this??
Regards
--- Anne Thomas Manes <[EMAIL PROTECTED]> wrote:
> You need to create a WSDL description of your
> service. A .NET client should
> be able to automatically consume a WSDL file and
> talk to the Web service,
> although interoperability
Thanks Anne for elucidating. I'm stuck with the legacy system and infrastructure that supports it.. I need to find a clumsy way to get around to make things work..
I don't concur with you on thing you mentioned below in the first paragraph. If you factor interoperability & infrastructure issues
From my perspective you should always use
Doc/literal. SOAP Encoding has been the source of many interoperability issues,
because the mechanism of mapping language types isn't defined concretely by SOAP
Section 5. Hence you should always use literal encoding. And many
implementations don't s
Pl see my response below..Anne Thomas Manes <[EMAIL PROTECTED]> wrote:
From my perspective you should always use Doc/literal. I agree with you..SOAP Encoding has been the source of many interoperability issues, because the mechanism of mapping language types isn't defined concretely by SOAP Secti
> I don't concur with you on thing you mentioned below in the first paragraph. If you
> factor interoperability & infrastructure issues in, your design would be definitely
> affected accordingly. If your service is going to be consumed by a VB6 client or
> .net client (or any non-java consumer)
In what way does doc/lit define language type mappings? I've never
really understood why doc/lit is better than rpc/encoded. If you
have no WSDL, you have problems with complex types either way. If
you do have WSDL, you have XML type information either way, and I
don't see why you would bind
One more comment. I consider it out of the ordinary for the code
implementing a service method to manipulate XML in any way. As such,
your method that returns a DOM element seems quite odd to me. One
typically uses constructs more native to the implementation language,
such as a class instan
You have motivated me to finally post a page with a simple VB.NET
client for an Apache SOAP service. The page is
http://www.scottnichol.com/vbnetclientapachesoap.htm. It uses the
stockquote sample. That sample uses a third party from which to get
the quote. Unfortunately, the third party th
Hi All.
I'm using soap and it's workign great for low load requests.
However when the number of requests start increasing there seems to be a significant time lag associated with them.
The requests are sent off using threading. The responses seem to come back in no specific order such th
Doc/lit doesn't define type mappings, but it definitively specifies the
structure of the message via XML Schema. Because the two applications know
in advance exactly what the message structure is, the details of how the
SOAP message processor maps the XML Schema to language types doesn't matter
to
Vishal,
Your response implies that you expect doc/literal to deliver the SOAP body
to the service as XML. I think this is your source of misunderstanding. A
SOAP message processor normally transforms the SOAP body into language
objects -- it doesn't matter whether you use rpc/encoded or doc/litera
On Wed, 18 Jun 2003 23:17:24 -0400, in soap you wrote:
>Doc/lit doesn't define type mappings, but it definitively specifies the
>structure of the message via XML Schema. Because the two applications know
>in advance exactly what the message structure is, the details of how the
>SOAP message proces
13 matches
Mail list logo
