Friday, December 18, 2009

Developing Interoperable WCF

Recently I have been tasked with developing interoperable WCF services. My services are to be consumed by .net stack as well as by Tibco. As of this writing Tibco is not very supportive to WCF. Some issues are caused by WCF and some are due to laziness of Tibco. Following are the problems that I faced while developing this service:
  1. I was not able to get wsHttpBinding working with Tibco. Tibco has announced Support for WCF but I still to see that support in any of their product. I tried coordinating with our Tibco team but they were not able to get wsHttpBinding working. So we decided to live with basicHttpBinding. basicHttpBinding is very close to ASMX and having this binding means that you won’t have any funky thing possible with WCF. But it enables me to move to better binding once my clients are able to understand that.
  2. WCF does not include schema in one WSDL document. Rather WCF puts those schema into the network location and refer to those external locations in main WSDL document like this:

    <xsd:schema targetNamespace="">

    <xsd:import schemaLocation="http://localhost:1282/Service.svc?xsd=xsd0" namespace=""/>

    <xsd:import schemaLocation="http://localhost:1282/Service.svc?xsd=xsd3" namespace=""/>

    <xsd:import schemaLocation="http://localhost:1282/Service.svc?xsd=xsd1" namespace=""/>

    <xsd:import schemaLocation="http://localhost:1282/Service.svc?xsd=xsd2" namespace=""/>



    Most of the legacy client tools won’t be able to recognize this. At least Tibco is waste and can’t understand it. My Tibco team has to manually download these schemas and then change the WSDL document to refer to those local schemas. This is a pain.

    There is a way to put all your WSDL in one document. There are tools such as FlatWSDL and WCFExtras which can pull all your schemas and put them together in one single WSDL document. But in this world everything comes with a price ;). Once you convert your WSDL to a single document schema, your WSDL loses some information in such a way that all collections become arrays. This is not good when you have .net stack also consuming your service along with non .net stack. Non .net stack anyway will get arrays but it would be good if .net stack can still see collections. More on this here....

  3. Designing exception handling approach. While starting to work on this service we had two options a) throw exception when we have exceptions b) never throw exceptions, instead respond to request and in response you let the client know that request was not processed successfully.

    Initially we went with first approach where we throw exceptions because Tibco didn’t want to introspect each message. This is good also because a broker should not inspect a message. This is basicHttpBinding so they are able to inspect; what if it was secure message? Brokers would anyway be not able to inspect message. But in this approach Tibco was not able to bind FaultCode and FaultString. This is because .net exception itself does not have FaultCode and FaultString as part of their data field. At runtime framework will populate these two fields. I tried working with FaultException as well but somehow that also didn’t help. Tibco team was not able to see FaultCode and FaultString in the schema of FaultException. I am not sure if I was missing something or my Tibco team.

    But due to this then fell back to plan B and now we are using response object to let client know that request failed. Now my response object have FailureCode and FailureReason that Tibco team can bind to FaultCode and FaultString.

This was my exposure interoperability and I consider this as a tip of iceberg. There is so much more to explore if you have more clients of different nature and you are planning to expose more bindings but all that for some other day.

No comments: