I have a WCF client & service, where service (which is hosted inside a console app) calls back to client using ever so standard WSDualHttpBinding with WSDualHttpSecurityMode.None. It's all fine and dandy when hosted on a local machine, but as soon as I move service to a computer other than my local machine (but on the same network), client cannot connect to the service anymore.
MEX is working fine, I can get hold of WSDL and all that. After capturing outbound traffic with Fiddler, here's what I got:
POST /chinchillin HTTP/1.1
Content-Type: application/soap+xml; charset=utf-8
Host: 192.168.0.98:8080
Content-Length: 916
Expect: 100-continue
Connection: Keep-Alive
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing">
<s:Header>
<a:Action s:mustUnderstand="1">http://schemas.xmlsoap.org/ws/2005/02/rm/CreateSequence</a:Action>
<a:MessageID>urn:uuid:aa317faa-f32e-4cbc-a6a3-5fdbc9f80fe6</a:MessageID>
<a:ReplyTo>
<a:Address>http://agogolev.ad.alponline.ru/Temporary_Listen_Addresses/f423a1ae-573a-4c14-9a64-c4ed26fc6366/3069625c-d37a-4de2-8f92-e078b51f01d5</a:Address>
</a:ReplyTo>
<a:To s:mustUnderstand="1">http://192.168.0.98:8080/chinchillin</a:To>
</s:Header>
<s:Body>
<CreateSequence xmlns="http://schemas.xmlsoap.org/ws/2005/02/rm">
<AcksTo>
<a:Address>http://agogolev.ad.alponline.ru/Temporary_Listen_Addresses/f423a1ae-573a-4c14-9a64-c4ed26fc6366/3069625c-d37a-4de2-8f92-e078b51f01d5</a:Address>
</AcksTo>
<Offer>
<Identifier>urn:uuid:7d198ab8-4fed-4f62-a76b-6e2ae2a13dda</Identifier>
</Offer>
</CreateSequence>
</s:Body>
</s:Envelope>
HTTP/1.1 202 Accepted
Content-Length: 0
Server: Microsoft-HTTPAPI/2.0
Date: Mon, 08 Feb 2010 08:41:48 GMT
I tried turning off firewalls on both machines, registered URL ACL with netsh -c http add urlacl url=http://+:8080/chinchillin user=domain\user. None of this helped.
How can I get callbacks to work in this scenario?
Got it figured. The server I moved the service part of my app to was not inside an AD domain and could not resolve http://agogolev.ad.alponline.ru.
Related
I'm having a problem with a web add-in for Outlook.
The Outlook client is 2016 (MSI) which I believe means that it supports no higher than JavaScript API 1.4, opposed to Outlook 2016 (C2R) which, as I recall it, supports JavaScript API 1.6 or maybe even higher.
Anyway, I'm trying to use the method Office.context.mailbox.getCallbackTokenAsync(asyncResult) which has previously worked just fine on the server where it is used, but now it has stopped working for some odd reason.
The asyncResult is now empty or rather the token is empty.
{"value":"","status":"succeeded"}
How can the token be empty all of the sudden when this add-in used to work perfectly?
According to the admin of the server, it has received Windows updates on the date that this stopped working for both Office and Outlook specifically.
The Outlook clients connect to an Exchange 2013 (CU7 December 9, 2014 : 15.0.1044.25) which has also received some updates.
Both servers have been rebooted since then, but nothing has changed. The token remains empty.
Can anyone shed some light on what could be the cause of this if anyone knows that is, because all I can really do myself at this point is guess?
UPDATE 1
I have now been given permission to install Fiddler and I have found the request and respond regarding the attempt to retrieve the token.
Can any of you who know the Exchange server inside out see what is going on here, because I don't see any reasoning as to what is failing, except that the response message indicates that the request is faulty somehow (which hasn't been changed for more then a year at least).
Here is the request (some names have been replaced with something generic).
REQUEST
POST https://<domain>/ews/Exchange.asmx HTTP/1.1
Cache-Control: no-cache
Connection: Keep-Alive
Pragma: no-cache
Content-Type: text/xml; charset=utf-8
User-Agent: Microsoft Office/16.0 (Windows NT 6.3; Microsoft Outlook 16.0.4849; Pro)
X-User-Identity: <account>#<domain>.com
Depth: 0
Content-Length: 801
Host: <host>
Authorization: Negotiate TlRMTVNTUAADAAAAGAAYAJ4AAABCAUIBtgAAAAAAAABYAAAANAA0AFgAAAASABIAjAAAABAAEAD4AQAAFYKI4gYDgCUAAAAPGSbYTqZVeCx7cnQxM336pnMAeQBzAHQAZQBtAGMAbwBuAG4AZQBjAHQAQABlAHMAdABpAGMAaABlAG0ALgBjAG8AbQBFAFMAVABJAC0AQwBUAFgAMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAT6dTWGCCv/rRor0Srrxd9AQEAAAAAAADJcWWYQo7VATtznMo8smALAAAAAAIACABFAFMAVABJAAEAFABFAFMAVABJAC0ARQBYAEMASAAxAAQAFABFAFMAVABJAC4AbABvAGMAYQBsAAMAKgBFAFMAVABJAC0ARQBYAEMASAAxAC4ARQBTAFQASQAuAGwAbwBjAGEAbAAFABQARQBTAFQASQAuAGwAbwBjAGEAbAAHAAgAyXFlmEKO1QEGAAQAAgAAAAgAMAAwAAAAAAAAAAAAAAAAIAAA77CK35CNnSd54Hy6NnToh6W3Oxa6tsihxlCrQ8jwDWMKABAARs+Rq8MKQZq+cmQJ8nL9/gkALABIAFQAVABQAC8AbQBhAGkAbAAuAGUAcwB0AGkAYwBoAGUAbQAuAGMAbwBtAAAAAAAAAAAAeHckPR2HOLOW0y2ri7TR1A==
Cookie: OutlookSession="{994C5944-A93C-4830-9E6F-605881790815}"; ClientId=PRHSVIWKYUDISQLQPQ
<?xml version="1.0"?>
<q:Envelope
xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types"
xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages"
xmlns:q="http://schemas.xmlsoap.org/soap/envelope/">
<q:Header>
<ex12t:RequestServerVersion Version="Exchange2012"></ex12t:RequestServerVersion>
</q:Header>
<q:Body>
<ex12m:GetClientAccessToken>
<ex12m:TokenRequests>
<ex12t:TokenRequest>
<ex12t:Id>214c1212-e3ff-45eb-9218-2deb35d6b8b9</ex12t:Id>
<ex12t:TokenType>ScopedToken</ex12t:TokenType>
<ex12t:Scope>ParentItemId:AAMkADRiMzkyMjhmLWQ1NGItNDY0Mi04Nzk0LWYyNzMzZWQ2ZGE5MABGAAAAAAApHj7qoKF1QY4+pcwfu7uCBwCHPrayw2+bT5ByF4j5Y8QZAAAAAAEMAACHPrayw2+bT5ByF4j5Y8QZAAAAAAFxAAA=</ex12t:Scope>
</ex12t:TokenRequest>
</ex12m:TokenRequests>
</ex12m:GetClientAccessToken>
</q:Body>
</q:Envelope>
RESPONSE (some names have been replaced with something generic).
HTTP/1.1 200 OK
Cache-Control: private
Content-Type: text/xml; charset=utf-8
Server: Microsoft-IIS/8.5
request-id: 1a7cbf79-8ba3-4a73-bfa2-1733d841b2b1
X-CalculatedBETarget: <server>.local
X-DiagInfo: <server>
X-BEServer: <server>
X-AspNet-Version: 4.0.30319
Set-Cookie: exchangecookie=2cd797c5290345a7861dfe60e16ecc12; expires=Thu, 29-Oct-2020 10:21:15 GMT; path=/; HttpOnly
Set-Cookie: X-BackEndCookie=S-1-5-21-2060358956-2462126529-2132206371-1263=u56Lnp2ejJqBmpzHns+cypzSncaZzdLLmprH0p3HxsvSm5yaycuazMieys/MgYHNz87G0s7O0s3Hq87Pxc3Oxc7K; expires=Thu, 28-Nov-2019 09:21:15 GMT; path=/ews; secure; HttpOnly
Persistent-Auth: true
X-Powered-By: ASP.NET
X-FEServer: <server>
Date: Tue, 29 Oct 2019 10:21:15 GMT
Content-Length: 1148
<?xml version="1.0" encoding="utf-8"?>
<s:Envelope
xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Header>
<h:ServerVersionInfo MajorVersion="15" MinorVersion="0" MajorBuildNumber="1044" MinorBuildNumber="21" Version="V2_22"
xmlns:h="http://schemas.microsoft.com/exchange/services/2006/types"
xmlns="http://schemas.microsoft.com/exchange/services/2006/types"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
</s:Header>
<s:Body
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<m:GetClientAccessTokenResponse
xmlns:m="http://schemas.microsoft.com/exchange/services/2006/messages"
xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types">
<m:ResponseMessages>
<m:GetClientAccessTokenResponseMessage ResponseClass="Error">
<m:MessageText>The token for this extension could not be retrieved.</m:MessageText>
<m:ResponseCode>ErrorInvalidClientAccessTokenRequest</m:ResponseCode>
<m:DescriptiveLinkKey>0</m:DescriptiveLinkKey>
</m:GetClientAccessTokenResponseMessage>
</m:ResponseMessages>
</m:GetClientAccessTokenResponse>
</s:Body>
</s:Envelope>
We've registered our service on the customsd page, and we're able to select it from the Add Music Services menu option. However, we're running into some difficulty during authorization.
When we start the sign in process, Sonos makes a getAppLink request to our service, we respond, and the button successfully takes the user to our sign-in page. That piece appears to be working.
However, we're running into issues with the getDeviceAuthToken polling that Sonos is doing. Once the sign-in process starts, Sonos consistently sends three getDeviceAuthToken requests and then gives up, sending no more requests even though we give back the necessary retry responses.
The requests from Sonos look like this (with some information partially or fully redacted and formatting added to the body for readability):
POST <our_soap_endpoint> HTTP/1.1
Connection: Keep-Alive
Content-Type: text/xml; charset="utf-8"
Accept-Encoding: gzip
Accept-Language: en-US
Host: <our_site>
Max-Forwards: 10
User-Agent: Linux UPnP/1.0 Sonos/51.1-67300 (ICRU_iPhone11,8)
X-Sonos-Controller-ID: 02A4****
X-Sonos-Api-Key: 4348****
X-Sonos-Corr-Id: 0b99****
SOAPACTION: "http://www.sonos.com/Services/1.1#getDeviceAuthToken"
X-FORWARDED-PROTO: https
X-FORWARDED-PORT: 443
X-ORIGINAL-HOST: <our_site>
X-Original-URL: <our_soap_endpoint>
X-Forwarded-For: <some_ip_address>
X-ARR-SSL: 2048|256|C=US, O=DigiCert Inc, CN=DigiCert SHA2 Secure Server CA|C=US, S=Ohio, L=Cleveland, O="OverDrive, Inc.", OU=OverDrive IT, CN=*.overdrive.com
X-ARR-LOG-ID: 5188****
Content-Length: 548
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Header>
<credentials xmlns="http://www.sonos.com/Services/1.1">
<deviceId>78****</deviceId>
<deviceProvider>Sonos</deviceProvider>
</credentials>
<context xmlns="http://www.sonos.com/Services/1.1">
<timeZone>-4:00</timeZone>
</context>
</s:Header>
<s:Body>
<getDeviceAuthToken xmlns="http://www.sonos.com/Services/1.1">
<householdId>Sonos_sIGu****</householdId>
<linkCode>ab76****</linkCode>
</getDeviceAuthToken>
</s:Body>
</s:Envelope>
Our responses look like this (again with some information partially or fully redacted and formatting added to the body for readability):
HTTP/1.1 500 Internal Server Error
Transfer-Encoding: chunked
Content-Type: text/xml; charset="utf-8"
Server: Microsoft-IIS/10.0
Date: Fri, 30 Aug 2019 13:25:25 GMT
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Body>
<s:Fault>
<faultcode>Client.NOT_LINKED_RETRY</faultcode>
<faultstring>No token found for link code ab76****. Please retry.</faultstring>
</s:Fault>
</s:Body>
</s:Envelope>
From what we can tell based on the documentation for getDeviceAuthToken and error handling / faults, our responses appear to match what's expected for telling Sonos to try again. Are we missing something or doing something incorrectly?
Your response does not look correct. It should be something like this:
. . .
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns="http://www.sonos.com/Services/1.1">
<soap:Body>
<soap:Fault>
<faultcode>Client.NOT_LINKED_FAILURE</faultcode>
<faultstring>Access to token failed</faultstring>
<detail>
<ns:ExceptionInfo>Restart authentication.</ns:ExceptionInfo>
<ns:SonosError>6</ns:SonosError>
</detail>
</soap:Fault>
</soap:Body>
</soap:Envelope>
See HANDLING ERRORS DURING AUTHENTICATION for details.
I am writing a RESTful web service and have a big trouble in getting the basic step up itself.
I could do the below:
Could create RESTful web service and send and receive the XML (not soap+xml) back to the client with webHttpBinding
Could create RESTful web service and send and receive the soap+xml using the contract as defined below:
[OperationContract]
[WebInvoke(Method = "POST",
UriTemplate = "",
BodyStyle = WebMessageBodyStyle.Bare,
RequestFormat = WebMessageFormat.Xml,
ResponseFormat = WebMessageFormat.Xml)]
XmlElement PostRequestXML(Stream xmlData);
Is the point (2) is right way to send and receive the soap+xml data?
I did a lots of search on web, but could not find better link which explains the detailed steps on creating web service to send and receive soap+xml.
I would like to know :
what is better way to design my RESTful web service to send and receive soap+xml? Can you show me operation contract definition?
which binding do I need to use? SHare if any example.
can you share me the detailed information on writing OperationContract and configuring web.config?
The request and respond should like as below.
REQUEST:
Header:
POST /EnrollmentServer/Discovery.svc HTTP/1.1
Content-Type: application/soap+xml; charset=utf-8
User-Agent: Windows Phone 8 Enrollment Client
Host: EnterpriseEnrollment.Contoso.com
Content-Length: xxx
Cache-Control: no-cache
<?xml version="1.0"?>
<s:Envelope xmlns:a="http://www.w3.org/2005/08/addressing"
xmlns:s="http://www.w3.org/2003/05/soap-envelope">
<s:Header>
<a:Action s:mustUnderstand="1">
http://schemas.microsoft.com/windows/management/2012/01/enrollment/IDiscoveryService/Discover
</a:Action>
<a:MessageID>urn:uuid: 748132ec-a575-4329-b01b-6171a9cf8478</a:MessageID>
<a:ReplyTo>
<a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address>
</a:ReplyTo>
<a:To s:mustUnderstand="1">
https://ENROLLTEST.CONTOSO.COM/EnrollmentServer/Discovery.svc
</a:To>
</s:Header>
<s:Body>
<Discover xmlns="http://schemas.microsoft.com/windows/management/2012/01/enrollment/">
<request xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
<EmailAddress>user#contoso.com</EmailAddress>
<RequestVersion>1.0</RequestVersion>
</request>
</Discover>
</s:Body>
</s:Envelope>
RESPONSE:
Header:
HTTP/1.1 200 OK
Content-Length: 865
Content-Type: application/soap+xml; charset=utf-8
Server: EnterpriseEnrollment.Contoso.com
Date: Tue, 02 Aug 2012 00:32:56 GMT
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing">
<s:Header>
<a:Action s:mustUnderstand="1">
http://schemas.microsoft.com/windows/management/2012/01/enrollment/IDiscoveryService/DiscoverResponse
</a:Action>
<ActivityId>
d9eb2fdd-e38a-46ee-bd93-aea9dc86a3b8
</ActivityId>
<a:RelatesTo>urn:uuid: 748132ec-a575-4329-b01b-6171a9cf8478</a:RelatesTo>
</s:Header>
<s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">>
<DiscoverResponse
xmlns="http://schemas.microsoft.com/windows/management/2012/01/enrollment">
<DiscoverResult>
<AuthPolicy>OnPremise</AuthPolicy>
<AuthUrl/>
<EnrollmentPolicyServiceUrl>
https://enrolltest.contoso.com/ENROLLMENTSERVER/DEVICEENROLLMENTWEBSERVICE.SVC
</EnrollmentPolicyServiceUrl>
<EnrollmentServiceUrl>
https://enrolltest.contoso.com/ENROLLMENTSERVER/DEVICEENROLLMENTWEBSERVICE.SVC
</EnrollmentServiceUrl>
<FederatedServiceName/>
<FederatedServicePolicy/>
</DiscoverResult>
</DiscoverResponse>
</s:Body>
</s:Envelope>
I have created many WCF API, some of them are REST.
My main understanding is - don't use it!
WCF is good in enabling you to choose the type of protocol to use between server and client.
Using it you pay in performance and durability.
If you already set your mind on REST (which is an excellent choice) I suggest you dig into ServiceStack. This is by far the most mature, maintained and advanced REST framework for .NET
It is easy to use and helps you build the API correctly, by making many smart choices on the way.
Give it a shot and never look back!
I need some help posting some XML to a WCF service. In essence, the issue I am experiencing is a HTTP response of "400: Bad request" - as descriptive as that sounds, i'm struggling to find any answers!
First of all, the service I have built in WCF is based on an existing WSDL, originally from an IBM WebSphere web service. After some manipulation (removal of MIME attachments, downloading of some remote schemas) I managed to get svcutil to generate a service interface which for all intents and purposes seems valid.
I have implemented the interface in to my WCF service and when running the WCF test client, I can attach to the service, submit a request and receive a response no problems. So far so good!
When moving to a test application for posting XML to web services via the HttpWebRequest class I start receiving "400: Bad request" responses even though I am using the XML provided by the WCF test client.
I've used WCF tracing to dump out the messages it is receiving and there is one striking difference - all of the WCF test client messages are populating correctly and displaying their header information etc, all of the once from my SOAP test utility are showing as "Malformed". Looking in to the message tab, the manual POST messages I am sending have the body wrapped in a element:
<MessageLogTraceRecord><![CDATA[<?xml version="1.0" encoding="utf-8"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Header>
<To s:mustUnderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">http://localhost:57567/Service1.svc</To>
<Action s:mustUnderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">http://www.nowhere.co.uk/RequestService/RequestOperation</Action>
</s:Header>
</s:Envelope>
]]></MessageLogTraceRecord>
Whereas the WCF messages appear as:
<MessageLogTraceRecord>
<HttpRequest xmlns="http://schemas.microsoft.com/2004/06/ServiceModel/Management/MessageTrace">
<Method>POST</Method>
<QueryString></QueryString>
<WebHeaders>
<Connection>Keep-Alive</Connection>
<Content-Length>185</Content-Length>
<Content-Type>text/xml; charset=utf-8</Content-Type>
<Accept-Encoding>gzip, deflate</Accept-Encoding>
<Expect>100-continue</Expect>
<Host>localhost:57567</Host>
<VsDebuggerCausalityData>uIDPo4VLDcJD5AZDjB5sdmoeakEAAAAAH/hWABuWQ0iiq47QDHh0GlelCLcEx7FLibxRvpq1tTgACQAA</VsDebuggerCausalityData>
<SOAPAction>"http://www.nowhere.co.uk/RequestService/RequestOperation"</SOAPAction>
</WebHeaders>
</HttpRequest>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Header>
<To s:mustUnderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">http://localhost:57567/Service1.svc</To>
<Action s:mustUnderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">http://www.nowhere.co.uk/RequestService/RequestOperation</Action>
</s:Header>
</s:Envelope>
</MessageLogTraceRecord>
I've tried tracing in Fiddler to no avail - I can't get the WCF test client to submit requests through the proxy it creates despite modifying it's app.config file. I have traced my SOAP request however can can see the following:
Content-Type: text/xml; charset="utf-8"
Accept-Encoding: gzip, deflate
Host: 127.0.0.1:57567
SOAPAction: "http://www.nowhere.co.uk/RequestService/RequestOperation"
Content-Length: 459
Expect: 100-continue
Connection: Keep-Alive
<?xml version="1.0" encoding="utf-8"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Header>
<To s:mustUnderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">http://localhost:57567/Service1.svc</To>
<Action s:mustUnderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">http://www.nowhere.co.uk/RequestService/RequestOperation</Action>
</s:Header>
</s:Envelope>
As far as I can tell, the message I am sending should be ok - outside of the headers and the message content I can't see what else could be sent.
Last thing I should say is that I am by no means a WCF expert and I have had to change the specific SOAPAction value due to commercial sensitivity..
Can anyone offer any help on this rather frustrating problem?
Thanks in advance
Thanks for the Fiddler comment - I managed to get the WCF request traced and using the xml from the request seems to work! I've since tried a full message which works against the WebSphere service against the WCF client and that works too!
I think the issue was the Action header. I believe WCF only support a couple of revisions of WSA, none of which are the one this particular WSDL was using. Looking at the original requests that were failing (pulled out of the WCF Test Client front end) the addressing namespace it was using was declared as:
xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none"
Whereas the actual WCF request that goes across to the service is declared as:
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing"
The actual element itself was populated with the same value, just the difference in namespace:
<wsa:Action>http://www.nowhere.co.uk/RequestService/RequestOperation</wsa:Action>
So using the correct addressing version and omitting the newer, WCF compatible version appears to have fixed the problem!
I am trying to post data from InfoPath using the WebServiceConnection, to a WFC service inside of AppFabric.
The messgae never arrives in AppFabric, and I think I know why.
My WCF service is configured like this
<endpoint address="Workflow1.xamlx" binding="basicHttpBinding" contract="WorkflowOperation" />
And when it is called by WCF Test Client, it generates the header
<s:Header>
<a:Action s:mustUnderstand="1">http://tempuri.org/WorkflowOperation/ReceiveFormPayload</a:Action>
</s:Header>
However, InfoPath does not generate this Soap header, it only generates the HTTP header
POST /Workflow1.xamlx HTTP/1.1
SOAPAction: "http://tempuri.org/WorkflowOperation/ReceiveFormPayload"
Content-Type: text/xml; charset="UTF-8"
User-Agent: SOAP Toolkit 3.0
Host: localhost:51842
Content-Length: 1893
Connection: Keep-Alive
Cache-Control: no-cache
How do I configure my WCF endpoint to only need the HTTP-header action, and not the Soap Action?
Well, I'm back again, with the answer for anyone who is interested in getting InfoPath to submit data to an AppFabric service.
The .NET BasicHttpBinding uses a combination of Soap1.2+WSAddressing1.0 - while the InfoPath client will ONLY submit to web services using Soap1.1 (with NO WSAddressing support) - rending the two completely incompatible.
I actually ended up having to write an intermediary broker which would adapt the invocations.
Many thanks to "codemeit" for a very descriptive page of the composition of the various WCF binding types.