 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / June 2007WebServices and .NET
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 > Hi there, > [quoted text clipped - 4 lines] > > 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.  SignatureLew > 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 >> Hi there, >> [quoted text clipped - 7 lines] > 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.. > 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 >> 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 [quoted text clipped - 20 lines] > > in their program to avoid confusing the servlet container. Which containers have you found this to be necessary for? >>> 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 [quoted text clipped - 21 lines] > > Which containers have you found this to be necessary for? Tomcat. Arne >>>> 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 [quoted text clipped - 23 lines] > > Tomcat. 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. >>> "Arne Vajhøj" <arne@vajhoej.dk> wrote in message >>>> For some servlet containers you will need to tell the .NET [quoted text clipped - 9 lines] > 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 On May 12, 3:56 pm, Arne Vajh?j <a...@vajhoej.dk> wrote: > MikeSchillingwrote: > >> MikeSchillingwrote: [quoted text clipped - 18 lines] > > 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. >> MikeSchillingwrote: >>>> MikeSchillingwrote: [quoted text clipped - 17 lines] > 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. SignatureLew >>> MikeSchillingwrote: >>>>> MikeSchillingwrote: [quoted text clipped - 26 lines] > 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. > 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 [quoted text clipped - 4 lines] > 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 >> 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 [quoted text clipped - 14 lines] > 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. > 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 [quoted text clipped - 4 lines] > 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 Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.