C# client consuming java-websphere SOAP service - c#

I am trying to consume a java-based service from .Net 4.0. (C# Console/Windows Service)
I have added the service reference using VS's Add Service Reference Dialog.
The service is hosted on WebSphere 8 and WSDL definition is generated using cxf.
Client app is running on Windows Server 2008 R2 SP1. But I don't think any windows update is applied after SP1.
Problem is from time to time All the calls to service methods return an exception. The error is as follows:
The content type text/xml;charset=UTF8 of the response message does not match the content type of the binding (application/soap+xml; charset=utf-8).
If using a custom encoder, be sure that the IsContentTypeSupported method is implemented properly.
The first 1024 bytes of the response were: '<?xml version="1.0" encoding="UTF-8"?><wsdl:definitions name="MyServiceImplService" targetNamespace="http://impl.webService.myService.com/" xmlns:ns1="http://webService.myService.com/" xmlns:ns2="http://cxf.apache.org/bindings/xformat" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/" xmlns:tns="http://impl.webService.myService.com/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<wsdl:import location="http://10.1.1.1/myService/webService/myService?wsdl=myService.wsdl" namespace="http://webService.myService.com/"></wsdl:import>
<wsdl:binding name="MyServiceImplServiceSoapBinding" type="ns1:myService">
<soap12:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"></soap12:binding>
<wsdl:operation name="disableCard">
<soap12:operation soapAction="" style="documen'..
Here's my client app's WCF config:
<system.serviceModel>
<bindings>
<customBinding>
<binding name="MyServiceImplServiceSoapBinding">
<textMessageEncoding messageVersion="Soap12" />
<httpTransport />
</binding>
</customBinding>
</bindings>
<client>
<endpoint address="http://10.1.1.1/myService/webService/myService?wsdl"
binding="customBinding" bindingConfiguration="MyServiceImplServiceSoapBinding"
contract="MyServiceReference.myService" name="MyServiceImplPort" />
</client>
</system.serviceModel>
I don't think this has anything to do with WCF configuration since all the methods work fine and all of a sudden, All of them return this exception.
The error seems to show up randomly with no apparent reason. Sometimes after 2 days and ~1,000,000 requests and sometimes after half an hour. But when this exception shows up, every call to the service returns this exception.
On the service side, there's no log that the call even reaches the java application. Seems like WebSphere sends the wsdl definition instead of passing my call to service.
Closing and relaunching the client app does not make the error go away. Only a complete system restart makes the error to disappear. (Update: it seems like removing ?wsdl from the endpoint address, removed the need to restart the system and restarting the client app is enough to make it work again.)
When facing the error, I have called the service methods with Soap UI and got the results with no exception. So there's probably nothing wrong on the service side.
My only guess is that this is a bug in .Net Framework 4.0.
Any help is greatly appreciated.

Related

WCF Security Header Removal

I have read countless forum posts and articles on this issue and am still unable to find a solution.
I am running a WCF service with the following binding:
<customBinding>
<binding name="BasicBinding">
<security authenticationMode="UserNameOverTransport" />
<textMessageEncoding messageVersion="Soap11" />
<httpsTransport />
</binding>
</customBinding>
Everything is working fine and I am locally able to make requests using the appropriate credentials and the response is served as expected. I have just received information from the consuming client that the Soap security header is causing issues for them:
<s:Header>
<o:Security s:mustUnderstand="1" xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<u:Timestamp u:Id="_0">
<u:Created>2017-12-20T19:17:29.322Z</u:Created>
<u:Expires>2017-12-20T19:22:29.322Z</u:Expires>
</u:Timestamp>
</o:Security>
They inform me that the 'mustunderstand' part is incompatible with their system. I have read that changing to a custom binding will fix it, however as you can see above this has been done and is still showing the security header.
I have read about interceptors and manipulating the response object but I've been unable to see how it all fits together. Has anyone actually solved this problem completely? I am basically looking to remove all header information from the response.

"Could not get any response" from WCF service using secure bindings, timeout settings ignored?

I have a service on a remote machine using secure bindings. All of my service configurations are in config files (and I have checked to make sure the right config files are being adjusted.) I have tried to tell the service to timeout at 3 minutes, but every time I make a request that takes longer than a minute, Postman gives me the generic "Could not get any response" page. (It doesn't even give me an error or a stack trace.) This happens exactly at 1 minute. Yes, I even used the stopwatch on my phone to verify it's exactly a minute.
In a different environment that uses non-secure bindings, I know this particular call takes about 90 seconds. I just need this secure environment to wait a little longer!
I'm sorry if my jargon isn't on key, I'm slightly new at this.
My services config file for the WCF service in question looks like this:
<service name="XXX.SolrIndexService.Host.Services.EventIndexService">
<endpoint address="ajax"
behaviorConfiguration="ServerReadCookie"
binding="webHttpBinding"
bindingConfiguration="webHttpsBinding"
contract="XXX.SolrIndexService.DataContracts.IEventIndexService" />
</service>
The actual binding configuration is here:
<webHttpBinding>
<binding name="webHttpBindingWithJsonP" crossDomainScriptAccessEnabled="true">
<security mode="None" />
</binding>
<binding name="webHttpBindingUnsecure" crossDomainScriptAccessEnabled="true">
<security mode="None" />
</binding>
<binding name="webHttpsBinding" crossDomainScriptAccessEnabled="true"
closeTimeout="00:03:00"
openTimeout="00:03:00"
receiveTimeout="00:10:00"
sendTimeout="00:03:00">
<security mode="Transport" />
</binding>
</webHttpBinding>
These are snippets from the entire configs file, I can post the whole thing if anyone thinks that would be helpful. I also used XXX in place of the client's name just because I'm not sure what the etiquette is with that sort of thing.
I've seen lots of posts regarding WCF timeouts and my general impression is that they're mysterious and picky. I've also checked IIS limits for the site that hosts the service, and it has a general Connection Timeout setting of 120 seconds.
Thanks!
Rather than using postman you should use the WCF Client tool
this might give you more feedback
Turns out in my particular case I was hitting my service through a load balancer. I did not attempt to change any settings on the load balancer. Instead I decided to hit the service using the specific machine that it was hosted on. After doing that, my timeout settings were obeyed and I'm no longer timing out before the call can be completed.
I'm not sure if that will help anyone in the future, it's rather specific, but you never know.

SOAP version in Envelope from code generated by WSDL

I'm working on a solution with a service generated by WSDL. When I call the service I get a Bad Request-Error. I've enabled tracing and the message sent has the following envelope:
<s:Envelope xmlns:a="http://www.w3.org/2005/08/addressing" xmlns:s="http://www.w3.org/2003/05/soap-envelope">
When I try to use cURL I get an error saying "InputStream does not represent a valid SOAP 1.1 Message" and of course works perfectly fine when I change xmlns:s to use SOAP version 1.1.
In the WSDL the binding is:
<soap:binding transport="http://schemas.xmlsoap.org/soap/http" />
which as, from what I've found, SOAP 1.1.
How can I modify the WSDL or the generated code to send the message with correct SOAP version?
All there was to it was to add textMessageEncoding in the binding
<customBinding>
<binding name="wsHttpEndpointBinding">
<textMessageEncoding messageVersion="Soap11" />

Web Reference works, but A Service Reference complains about Soap version

I have to connect to a legacy web service.
In visual studio, if I do a Add Service Reference, then enter the url of the WSDL file on server. My service shows up, and I write the code against it. But when I run the code I get this error:
System.ServiceModel.CommunicationException: The envelope version of
the incoming message (Soap12
(http://www.w3.org/2003/05/soap-envelope)) does not match that of the
encoder (Soap11 (http://schemas.xmlsoap.org/soap/envelope/)). Make
sure the binding is configured with the same version as the expected
messages.
My app.config looks like this:
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="LoginServiceSoap" />
</basicHttpBinding>
</bindings>
<client>
<endpoint address="http://server/Service.asmx" binding="basicHttpBinding"
bindingConfiguration="LoginServiceSoap" contract="Stuff.Login.LoginServiceSoap"
name="LoginServiceSoap" />
</client>
</system.serviceModel>
However, I am able to communicate with the service fine, if I add a 'Web Reference'. But my understanding is that I am supposed to use Service References now, instead of WebReferences. I am assuming I have something wrong in my above config.
Or am I forced to use a Web Reference, because of the type of service I am connecting to?
Sheamus,
You could (theoretically) add the version number to the binding definition.
envelopeVersion="None/Soap11/Soap12"
With, of course, the right value for your service.
So it would look more like:
<basicHttpBinding>
<binding name="LoginServiceSoap"
envelopeVersion="Soap12" />
</basicHttpBinding>
Hope this helps you do things your way.

Call Sharepoint Web Service over SSL with Silverlight

I have a Silverlight 5 app that gets some data from a couple Sharepoint lists. It was all working correctly, then we set up the site to allow SSL and I tried to update the service reference to call the webservice using https. It updated the client config binding to use security mode Transport. But when it calls the service it's giving an error:
System.ServiceModel.CommunicationException: An error occurred while trying to make a request to URI 'https://devlpadmin.thelittlegym.com/_vti_bin/Lists.asmx'. This could be due to attempting to access a service in a cross-domain way without a proper cross-domain policy in place, or a policy that is unsuitable for SOAP services. You may need to contact the owner of the service to publish a cross-domain policy file and to ensure it allows SOAP-related HTTP headers to be sent. This error may also be caused by using internal types in the web service proxy without using the InternalsVisibleToAttribute attribute. Please see the inner exception for more details. ---> System.Security.SecurityException ---> System.Security.SecurityException: Security error.
Does anyone know what the problem is or how to get more info than "Security error."?
I've gone through so many different combinations of things that I'm not sure exactly what has happened when, but it's now working. I think originally the site/service was having some weird problem that prompted me to try to manually configure Silverlight to pass NTLM transport credentials. In doing so, I might have created an invalid config file causing the error. The configuration that is working is:
<bindings>
<basicHttpBinding>
<binding name="ListsSoap" maxBufferSize="2147483647" maxReceivedMessageSize="2147483647">
<security mode="Transport" />
</binding>
</basicHttpBinding>
</bindings>
<client>
<endpoint address="https://devadmin.mydomain.com/_vti_bin/Lists.asmx"
binding="basicHttpBinding" bindingConfiguration="ListsSoap"
contract="SPListsService.ListsSoap" name="ListsSoap" />
</client>
So if you're having this error and not making a cross-domain call, suspect some kind underlying service error. If you're not using Silverlight, you can enable tracing to track down the error. If you are using Silverlight, I still don't know what can be done to narrow it down, but be aware that Silverlight only supports a fragment of the configuration options that a normal .net WCF client does.

Categories