I used sudzc to access web services. However the jboss server side didn't like the soap message generated by sudzc. I suspect that this issue is about namespace... Have anybody exprienced this before?
I had the same problem and was able to fix it by removing the default namespace (xmlns=) altogether and search/replacing all method names, adding an explicit namespace as prefix
to all names.
The main differences I see is Sudzc not including an empty header, and uses different namespaces such as soap instead of soapenv as well as set the default namespace of the document. I have no experience with JBoss but it may not be able to handle these differences (although I would think it would) but you can first try including an empty header. SudzC is open source if you want to check out what is happening.
Check the response from web service. Then modify the source code according to the response error. Check this post as an example.
sudzC SOAP web service namespace problem
Related
I have an xsd-file with which I generate dataclasses (with xsd.exe or WSCF-blue) for building a WCF-service.
Then I add the generated classes to the operations in the WCF-service like this:
MyGeneratedClassOUT operation1(MyGeneratedClassIN request)
When I call that operation from a client, the client gets back MyGeneratedClassOut request filled with null-values, even tough i fill them up server-side.
Does anyone have an idea how to solve this?
Could this be a problem in the XSD-file or in the WCF configuration?
This is most probably a namespace issue. Check with Fiddler if the request and response have the same namespaces.
I have a web service that will be deployed to multiple domains. I would like to get rid of the WCF default namespace of "http://tempuri.org/," and replace it with the domain on which the web service is deployed, such as "http://mydomain.com/." I know the best solution here is simply to have the web service exist in one place, and use that one domain as the namespace, but that is not an option for me at the moment.
I found a partial answer to this question here. In this post, the suggested answer is to set a URL property in the config file, but I am afraid I don't quite understand the answer. Where is this URL property, exactly? Also, for reasons beyond my control, the client app that will be consuming this web service does not have an app.config file, so all configs in that client app will have to be set in code. I am not sure if that matters, but figured I would mention it, just in case.
EDIT: To clarify, the reference to "http://tempuri.org" that I am trying to remove is inside the .cs file that is generated by svcutil.exe.
e.g.
[System.ServiceModel.OperationContractAttribute(Action = "http://tempuri.org/IEmailService/SendEmail", ReplyAction = "http://tempuri.org/IEmailService/SendEmailResponse")]
void SendEmail(Services.Internal.CorrespondenceWebService.Email email);
You may be confusing XML namespaces with URLs. Here's an example of a namespace which is not a URL: urn:schemas-microsoft-com:datatypes.
Since a namespace is not necessarily a URL, you do not have to change it for each environment.
On the other hand, you should pick a namespace, and use it consistently. Perhaps something like http://services.mydepartment.mycompany.com/myservice/. You really don't want to ship a service that still uses http://tempuri.org/, as that demonstrates a lack of understanding of namespaces.
In response to your updated question: those namespaces are present in the .cs file generated by svcutil.exe because they are present in the metadata from the service. You need to change them in the service, and when the client is created or updated, it will have the correct namespaces.
I want to remove the default xmlns (namespace) added to my service's response (see image below)
Is there a way to do this? This because in order to consume this service from a C# windows app, I have to add the namespace to every data object's header - DataContract that I will be serializing.
I think if you just use
[DataContract(Namespace="")]
on the Bookmarks class, that should do it.
I just tried this and got the following:
<CompositeType xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
<BoolValue>true</BoolValue>
<StringValue>Hello </StringValue>
</CompositeType>
Actually, WCF REST Contrib proved to be the perfect solution using their PoxDataContract.
Expanding on #Tawani's answer, if you want to support attributes or otherwise customize your XML serialization you can easily extend WcfRestContrib by creating a custom IWebFormatter. Here's my answer to a similar question explaining how to do this using an XmlSerializer.
Can we identify if WCF Request is coming from our Silverlight APP or some place else?
You could possibly declare a [MessageContract] and define a header in there, which your Silverlight app could set to a known, defined value.
Marc
The headers should already have requester info in them, and you should be bale to parse it out and tick up a counter or whatever on the server side. I would think marc_s's suggestion of MessageContract would be the simpler solution however.
I am using WCF as a client for a java web service. I have not control over the server side.
In the response I get from the web service there is no xmlns attribute on the first element inside the soap headers. Because of this WCF returns null as the result of web service call.
Apart from the missing xmlns the response is perfect and if I add the xmlns using fiddler then everything works as expected. I don't know enough about SOAP to know if the xmlns attribute is really required.
Is there a way to avoid this problem, either getting WCF to ignore the missing xmlns attribute or even a hook that would allow me to manually munge the response before it gets to WCF?
This appears to be a pretty old question, so I'm not sure if you ever addressed this. If you are working with a WCF client for a Java Axis service, you will find that you will need to get used to using MessageInspectors to override the behavior of the request and response.
Using the AfterReceiveReply method you should be able to copy the original message and alter the headers. Also check out Step 5 from this MSDN article.
You can't alter the response headers directly in this method as far as I can see, because they are read-only, therefore copying and then replacing the reply with a doctored version is the only way I can think of to correct the missing namespace.