WebServices and .NET

L

Lord0

Hi there,

Im currently exposing functionality of an existing application as a
Web Service - Im using Axis 1.x for this. I have read that the only
style of Web Service supported by .NET is "wrapped" as opposed to,
say, "document".

Anybody got any experience/thoughts on this?

Cheers

Lord0
 
L

Lew

Lord0 said:
Hi there,

Im currently exposing functionality of an existing application as a
Web Service - Im using Axis 1.x for this. I have read that the only
style of Web Service supported by .NET is "wrapped" as opposed to,
say, "document".

Anybody got any experience/thoughts on this?

It's the other way around. .Net prefers "document literal" and has specific
conventions on how you name the WSDL elements.
 
L

Lord0

It's the other way around. .Net prefers "document literal" and has specific
conventions on how you name the WSDL elements.

Hi,

Thanks for the reply. Do you have any links/docs with more info on
this?

Cheers

Lord0
 
M

Mike Schilling

Lew said:
It's the other way around. .Net prefers "document literal" and has
specific conventions on how you name the WSDL elements.

This is all good stuff to know, but not terribly important. The WSDL
produced by a .NET service is standard, and any web service toolkit
(including Axis) should be able to build a client for it. Conversely, the
..NET tool that builds clients should be able to use Axis-produced WSD,
whether the Axis service follows .NET conventions or not..
 
?

=?ISO-8859-1?Q?Arne_Vajh=F8j?=

Lord0 said:
Im currently exposing functionality of an existing application as a
Web Service - Im using Axis 1.x for this. I have read that the only
style of Web Service supported by .NET is "wrapped" as opposed to,
say, "document".

Anybody got any experience/thoughts on this?

Create your web services with Axis.

Let the .NET coders generate stub code based on the URL of
the WSDL.

Then everything will work fine.

No problems.

Maybe one problem.

For some servlet containers you will need to tell the .NET
developers to put:

ServicePointManager.Expect100Continue = false;

in their program to avoid confusing the servlet container.

Arne
 
M

Mike Schilling

Arne Vajhøj said:
Create your web services with Axis.

Let the .NET coders generate stub code based on the URL of
the WSDL.

Then everything will work fine.

No problems.

Maybe one problem.

For some servlet containers you will need to tell the .NET
developers to put:

ServicePointManager.Expect100Continue = false;

in their program to avoid confusing the servlet container.

Which containers have you found this to be necessary for?
 
M

Mike Schilling

Arne Vajhøj said:

Odd. At my workplace, we combine .NET clients and services deployed in
Tomcat (4.0 and 5.5) with some frequency (e.g. in the nightly unit tests),
don't set that flag, and haven't seen any problems.
 
?

=?ISO-8859-1?Q?Arne_Vajh=F8j?=

Mike said:
Odd. At my workplace, we combine .NET clients and services deployed in
Tomcat (4.0 and 5.5) with some frequency (e.g. in the nightly unit tests),
don't set that flag, and haven't seen any problems.

It may very likely only be certain combinations of versions.

If you google for it, then you find several stories where it
was necessary to make it work.

Obviously those without the problem never posted so.

Arne
 
D

DTLLLUmpireSchedules

MikeSchillingwrote:


It may very likely only be certain combinations of versions.

If you google for it, then you find several stories where it
was necessary to make it work.

Obviously those without the problem never posted so.

And now we've run into it, and this information is invaluable. score
one for Usenet, and thanks, Arne.
 
L

Lew

And now we've run into it, and this information is invaluable. score
one for Usenet, and thanks, Arne.

At a project last year our team used Apache Web server as a front end to
Tomcat running Apache Axis to do Web services connecting to both J2EE clients
and .Net clients. All we had to do was make the WSDL specify
"document-literal" and follow certain Microsoftisms to assure interoperability.

Could it be that we were lucky that either Apache Web Server lacks the issue
or that that version did?

I'm with DTLLLUmpireSchedules - I'm really glad you showed us this tip.
 
M

Mike Schilling

Lew said:
At a project last year our team used Apache Web server as a front end to
Tomcat running Apache Axis to do Web services connecting to both J2EE
clients and .Net clients. All we had to do was make the WSDL specify
"document-literal" and follow certain Microsoftisms to assure
interoperability.

Could it be that we were lucky that either Apache Web Server lacks the
issue or that that version did?

DTLLLUmpireSchedules is me, by the way (it's the gmail account I use to
send out Little League schedules, and the thread was old enough that I could
only access it from Google Groups).

We see the issue with .NET 2.0 clients communicating with Tomcat 5.5
services running under JDK1.5. All three of these versions are different
from the situations where we didn't see it, and I don't know which are
important. The issue seems to be a Microsoft bug pure and simple. The
clients issue requests with the "Expect:100-continue" header, which means
that they'll wait to get a status message back before sending the body of
the request. They then send the body of the request without waiting,
confusing the hell out of the service.
 
G

Guest

Lew said:
At a project last year our team used Apache Web server as a front end to
Tomcat running Apache Axis to do Web services connecting to both J2EE
clients and .Net clients. All we had to do was make the WSDL specify
"document-literal" and follow certain Microsoftisms to assure
interoperability.

Could it be that we were lucky that either Apache Web Server lacks the
issue or that that version did?

There are a bazillion possible combinations of Axis version, Tomcat
version, Java version, .NET version, web service style.

Since it is an HTTP protocol thing, then I am pretty sure that
neither Java version or web service style has anything to say.

I have some C# code that calls a plain JSP page where I also
have set that property - unless that was just a copy paste,
then Axis version is in the clear to.

So we are left with Tomcat version and .NET version.

When I found the problem it must have been Tomcat 5.5 and
..NET 1.1.

Arne
 
?

=?ISO-8859-1?Q?Arne_Vajh=F8j?=

Mike said:
We see the issue with .NET 2.0 clients communicating with Tomcat 5.5
services running under JDK1.5. All three of these versions are different
from the situations where we didn't see it, and I don't know which are
important. The issue seems to be a Microsoft bug pure and simple. The
clients issue requests with the "Expect:100-continue" header, which means
that they'll wait to get a status message back before sending the body of
the request. They then send the body of the request without waiting,
confusing the hell out of the service.

I don't think it is very nice of MS to have that option on by default.

Default should be standard HTTP.

And if necessary an option to do something non-standard.

And even though it is described in RFC 2616 (HTTP 1.1)
section 8.2.3, then I will still call it non-standard
in the sense that it is a very rarely used feature.

Arne
 
M

Mike Schilling

Arne Vajhøj said:
I don't think it is very nice of MS to have that option on by default.

Default should be standard HTTP.

And if necessary an option to do something non-standard.

And even though it is described in RFC 2616 (HTTP 1.1)
section 8.2.3, then I will still call it non-standard
in the sense that it is a very rarely used feature.

It's required behavior for HTTP 1.1 servers:

Upon receiving a request which includes an Expect request-header
field with the "100-continue" expectation, an origin server MUST
either respond with 100 (Continue) status and continue to read
from the input stream, or respond with a final status code.

The problem isn't that Microsoft uses the feature, it's that they implement
it it correctly.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,900
Latest member
Nell636132

Latest Threads

Top