I've been struggling for a few days with this problem, learning a lot of things on bindings in the process.
One thing puzzles me, though: various links (see this or that for example) explicitly state "By default, WCF project is created using WsHttpBinding", but that's not what I see.
This is what I do:
Open Visual Studio 2010 and choose New Project / Visual C# / WCF Service Application
Don't touch anything inside the code, set a local IIS Url for the service (say http://localhost/WcfService7)
Open soapUI and choose File / New Soap UI Project / enter the url of the newly created wsdl: http://localhost/WcfService7/Service1.svc?wsdl, not touching any other option
Interface properties: SOAP Version = SOAP 1.1, Binding = "BasicHttpBinding_IService1" (even though it's just a name, it's a hell of a hint)
Open Altova XmlSpy and choose SOAP / Create new SOAP Request / enter the url of the wsdl / select any operation
SOAP / Change SOAP Request parameters / Ensure that "Send as SOAP+XML (SOAP 1.2)" is checked
SOAP / Send request to server: i get the errors
HTTP error: could not POST file ‘/WcfService7/Service1.svc’ on server ’localhost’ (415)
Error sending the soap data to ‘http://localhost/WcfService7/Service1.svc’ HTTP error: could not POST file ‘/WcfService7/Service1.svc’ on server ’10.51.0.108’ (415)
Any explanations? Thanks
When hosting WCF service in IIS (using WCF Service application project template) with default .svc file (without changing its service host factory) the default binding is basicHttpBinding. If you want to change default binding to wsHttpBinding you must use:
<protocolMapping>
<add scheme="http" binding="wsHttpBinding"/>
</protocolMapping>
In your service's configuration file but it will not solve your problem because you don't need wsHttpBinding and as I remember Altova XmlSpy is not able to send valid request for wsHttpBinding because it supports only basic SOAP stack without WS-* protocols.
The default is basichttpbinding using SOAP 1.1.
That is why you get an error sending it as SOAP 1.2.
Related
I have a web service running outside of .net that I need to invoke from a .NET client.
I was given a .NET client written in Visual Basic to test with.
The .NET client can access the web service with a clear-text SOAP message using basicHttpBinding.
I can configure a policy/binding for the external web service to use the Kerberos token for Message Level Protection and authentication. I can access this web service from the .NET client by modifying the configuration file to use wsHttpBinding.
Now, the requirement is to use the Kerberos token for authentication only and not sign/encrypt the SOAP message. That is, I only need the tags in the SOAP header. I have this configuration working on the external web service, but now I want to modify the configuration file so the .NET client only sends the and does not sign/encrypt any part of the SOAP message.
Is it possible to modify the .net client's .config file to do this?
My understanding is that basicHttpBinding can not be modified to use a Kerberos token (only UserName/Certificate).
I've tried disabling signing/encryption in wsHttpBinding via an attribute such as "defaultProtectionLevel=Sign/SignEncrypt/None", but this isn't available in wsHttpBinding (or I can't find it). I can only disable or enable message level protection and authentication with .
I've also tried building a customBinding, but can not disable signing/encryption and use the Kerberos token for authentication only.
Does anyone have a solution or some tips that could point me in the right direction to go about solving the above issues?
I'm developing a simple web service using MS Visual Studio 2008, C# and .net 4. I used the WCF project template, and thru this, I was able to create a site and deploy it to IIS 7.5. It pretty much has all the default settings that, just that I added a new binding configuration for the wsHttpBinding where "security mode=None".
Using Soap UI 4.0.1, i wanted to test this service, but found that I had to add the endpoint URL again in the WS-A "To:" field.
Is there a way to change the wsdl or endpoint so I dont need to use the WS-A "To:" field in Soap UI? I don't understand why Soap UI requires the endpoint url again in the WS-A "To:" field when I already provide the wsdl to create the request.
I found that if I changed the configuration from wsHttpBinding to basicHttpBinding, then the WS-A field is not required anymore in SoapUI. However, I still dont know why SoapUI requires the WS-A "To" field for the wsHttpBinding configuration. Maybe its a bug/"feature" of SoapUI.
The difference is huge! wsHttpBinding is using SOAP 1.2 (vs 1.1), your authentication elements move to WS-* ones, and more. Here's a good example app that breaks it all down: http://www.codeproject.com/Articles/36396/Difference-between-BasicHttpBinding-and-WsHttpBind
I am connecting to a DFS(Documentum Foundation Services) instance from a WCF client.
I am using basicHttpBinding and I have set the messageEncoding="Mtom". However, when I inspect the soap, I see the document within the SOAP envelop. The document part in the SOAP is about 1.33 times the actual doc size. So the message is getting Base64 encoded.
Do I have more settings to change on the WCF side Or is there a MTOM setting that is not enabled on the DFS side?
Does wsoma:OptimizedMimeSerialization have to be there in the WSDL?
Thanks
http://www.w3.org/Submission/WS-MTOMPolicy/
I guess, my question is: does the Java web service WSDL has to have this wsoma:OptimizedMimeSerialization element, otherwise it implies that the web service does not support MTOM?
Which also implies that if the Java based web service did support MTOM and then if I add a service reference using the WSDL, Visual Studio should automatically create the appropiate binding with messageEncoding="Mtom"??
I am using wsHttpBinding with a WCF service.
I've added a web reference and I've got the web proxy (it is based on SoapHttpClientProtocol).
Also I've tried to build a proxy using wsdl.exe and the actual wsdl generated by the wcf service (http://zzzz/zz.svc?wsdl).
When the client calls the service, I get the following error:
The SOAP action specified on the message, '', does not match the HTTP SOAP Action, 'http://tempuri.org/Service1/Operation1'.
Why doesn't the client (the web proxy) work with my WCF service?
What steps should I take to make them work?
I am running .NET FW 3.5 and ASP.NET 2.0.
You cannot consume service exposed on wsHttpBinding with default configuration by old ASMX proxy. You must either use add service reference / svcutil or change your binding to basicHttpBinding. Default configuration of wsHttpBinding uses advanced security and ASMX doesn't support it.
Is anybody familiar with setting up WCF-nettcp adapters for BTS?
When I create a WCF-netTcp adapter for a Receive location, I am unsure how/when BTS will open up port 808 to listen on the address URI specified. It appears to only happen if I restart the entire BizTalk application. If it closes for some reason, I do not see any way of reconfiguring and reopening the port.
Furthermore, since that is only the net.tcp binding, there is no mex endpoint exposed. I believe client applications that wish to use that exposed WCF service needs mex metadata initially. Accessing that endpoint direct from a Visual Studio project would just yield
Metadata contains a reference that cannot be resolved: 'net.tcp://biztalkserver/PostReceiveLocation_TCP/PostReceiveService.svc'.
Metadata contains a reference that cannot be resolved: 'net.tcp://biztalkserver/PostReceiveLocation_TCP/PostReceiveService.svc'.
If the service is defined in the current solution, try building the solution and adding the service reference again.
Cannot tell for such how to properly expose a mex endpoint to the service. the BizTalk WCF Service Publishing Wizard is confusing me; I cannot get it to reference the WCF adapter/Receive location I setup. I find no document that teaches what one ought to do for netTcp services; it is all about Http.
Funny, it took the walkthrough about publshing Net-Msmq WCF service to nudge me thinking how the WCF Service Publishing Wizard really works.
The issue is this: When I manually created the WCF-netTcp Receive location, it has its endpoint URI e.g. net.tcp://biztalkserver/PostReceiveLocation_TCP/PostReceiveService.svc. When selecting the option to publish just an mex endpoint in the WCF Service Publishing Wizard, it will eventually ask for the WCF Service Location, which i confused to be the actual service location. Since it would accept nothing but Http URLs, it appeared to only support Http-based WCF endpoints.
But for that textbox, one is supposed to place the Http URL that for just the mex endpoint, not the actual net.tcp WCF endpoint. That is the location in IIS where the wizard will create the necessary meta-data files. Once finished, that location, hosting a mex endpoint will inform clients of the real service located at the net.tcp endpoint.