CWWSS7200E: Unable to create AxisService from ServiceEndpointAddress

This is what I got back when I tried to bounce a JAVA WebSphere Axis service from a WCF client:

CWWSS7200E: Unable to create AxisService from ServiceEndpointAddress

Took me a while but eventually figured out what was wrong and ,long story short, WebSphere did not like the HttpHeaders generated by the WCF bindings (basicHttpBinding) when sending the request.

I started sniffing traffic with Fiddler, but initially I was paying attention only to the SOAP envelope. I then tried to directly invoke the service using SoapUI and it basically seemed to work fine (no Unable to create AxisService error message and I was getting back the result I expected). With the SOAP envelope ruled out, the next logical consequence needed to be the HttpHeader, so I compared the header generated by WCF with the one automatically generated by SoapUI (by pointing the tool to the endpoint url):

WCF Generated HttpHeader:

POST /MyWebServiceDomain/aWebService HTTP/1.1

SoapUI Generated HttpHeader:

POST http://xx.xxx.xxx.xx:9080/MyWebServiceDomain/aWebService HTTP/1.1

At this point it was fairly obvious that I needed to tweak the POST line of the HttpHeader to include the full definition of the endpoint, hopefully by WCF configuration - and after asking around a co-worker pointed me in the right direction: hostNameComparisonMode="Exact" on the WCF binding is what I was looking for (it seems to be set to StrongWildcard by default).

Couldn't find anything on the web about any of the above - I hope this helps someone else with the same problem.

Add Service Reference duplicates properties on Faults

Spent the last few days fighting with this, finally found what seems to be a workaround so I thought I'd share hoping that it can be of some use to some other poor devil who's stuck.

Dealing with WebSphere generated web services, the curious occurrence of duplicate properties on Faults (on different partial classes) was encountered when generating proxies through add service reference on Visual Studio 2008, pretty much in a very similar way as described in this post on the msdn forum.

Solution: Long story short, you have to use svcutil to generate your proxy classes and data types with the /useSerializerForFaults attribute, this will cause the XmlSerializer to be used for reading and writing faults (but only those), instead of the default DataContractSerializer (which will still be used for the rest of the stuff).

Note 1: using the option /serializer:XmlSerializer instead of /UseSerializerForFaults on svcutil will cause the Faults to be wrapped in a sub-namespace (the same namespace they were defined in the xsd contract).

Note 2: setting the corresponding option item UseSerializerForFaults to false in the ServiceMap file does not give the same results (instead of generating duplicated properties it started generating duplicated attributes, two on each partial class).

This seems to be a genuine bug. Let's just hope it gets fixed because it's a pain to import stuff manually.

Note that if you kick it old school and import the service as web reference (the .NET 2.0 way) it should work fine as well, but for me this was not a choice.