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"??
Related
I am on a WCF project that is going to be interfacing with WebSphere.
They have told me that they will create a WSDL for me to call from my WCF solution.
I know ZERO about WebSphere. So I am asking if the term WSDL is universal. Or is it kind of like "SQL" (meaning the basics are the same, but an Oracle/WebSphere query/call may not run on SQL Server/WCF).
Has anyone tried this? Are there hidden "gotchas"?
From a purely semantic perspective both WCF WSDL's and JAX-RPC (Websphere) WSDL's are compliant with both SOAP 1.1 and SOAP 1.2. However they both tend to have some slight variations in out of the box endpoint generation, wsdl location to endpoint mapping external references location, soap:action generation and WS-* compliance that could present you issues.
IBM mentions the following as a common issue when integrating WCF generated WSDL's with their products which are based on JAX-RPC
Note: Web services allow applications to interoperate by using standard descriptions of services and standard formats for the messages they exchange. For example, the Web service import and export bindings can interoperate with services that are implemented using Web Services Enhancements (WSE) Version 3.5 and Windows Communication Foundation (WCF) Version 3.5 for Microsoft .NET. When interoperating with such services, you must ensure that:
The Web Services Description Language (WSDL) file that is used to access a Web service export includes a non-empty SOAP action value for each operation in the interface.
The Web service client sets either the SOAPAction header or the wsa:Action header when sending messages to a Web service export.
I have created a WCF service and hosted it through self hosting. This service doesn't have any metada published.
First Question
Can I consume it through Visual Studio, Add Service Reference? Hopefully not.
Can I consume it by creating manual proxy, i.e. ChannelFactory<ServiceContract>....?Hopefully yes.
Now in the second scenario, the client must be .Net, right?
So it implies that, to consume a wcf service on a non-.net platform, we have to expose its metadata?
Can't a WCF service without metadata, consume by Ajax client, or say Java client??
There are 3 options to consume a WCF Service:
If the service exposes a WSDL use "add service reference" from VS (or an equivalent from another platform). Note that if you do not want to expose the WSDL you could expose it just temporarly, save the WSDL in a file, and then send it to user in any platform to generate proxy from it. You can turn off the WSDL immediately after you save it. Also note that even if the WSDL is not exposed still you need to protect the web service from unauthorized access.
If this is a .Net client it can compile with the same Service Contract assembly and use ChannelFactory etc.
Any platform can send raw soap message (e.g. XML) to the service. Of course they need to know what is the right format. A WSDL can help but even without it if they have a working sample they can imitate it.
WCF provides REST (Representational State Transfer) support to consume it by non .NET client like JavaScript (AJAX), java, Objective C, web browser, etc...
Basically WCF REST is exposes methods and transferring data over the HTTP protocol and it supports all HTTP operations (GET, POST, PUT, and DELETE). This feature is making it platform independent as well as it doesn’t require metadata exposed.
Please refere below links to get more about WCF REST:
An Introduction To RESTful Services With WCF
WCF REST Programming Model Overview
WCF Rest vs. WCF SOAP
Create RESTful WCF Service API: Step By Step Guide
is that correct that the default Web Service created using WCF will have WSDL but the message transmission required should not have SOAP tags like
<soap:envelope>, <soap:header>, <soap:body> ?
Are they still using SOAP 1.1 in this case then?
And then, how can I create another web service using JAX-WS that is following this standard?
Thanks a bunch,
Robert
It's not clear to me what you're asking but if you're trying to invoke java based services (Apache, Metro, etc...) with a WCF client, take a look at the WCF Express Interop bindings.
I want to host my WCF web service in the public domain (on internet) so that any client application (java, .net etc.) can consume it.
The WSDL will give details of the service (what it offers etc.). But,
How to inform the binding details to the clients?
I want to know how do we inform binding details to the outside world when you are on internet and you do not know who the client will be. WSDL gives the details of the service; similarly what mechanism is there to inform the binding that's required to communicate with the service.
Do I need to stick to some specific bindings when I want to publish my web service over internet where anybody can consume it?
svcutil or Visual Studio (using svcutil in background) will understand binding specification provided by metadata exchange binding (look here)
it wouldn't. If You want Your web service to by used by technologies other than .NET You shouldn't use .NET specific implementations.
basicHttpBinding works with soap 1.1. wsHttpBinding with soap 1.2 and WS-*. You shouldn't use other bindings if you want your web service to be interoperable.
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.