What are the repercussions of changing a ColdFusion-generated WSDL web service from RPC-encoded to document-literal?

Question

I inherited a few web services that are WSDLs generated by ColdFusion 9. The CF9 default is RPC-encoded, so that's what they are. However, it's recently come to my attention that newer versions of the .NET framework (or maybe it's newer versions of Visual Studio) don't like RPC-encoded WSDLs. In testing (in C#), I verified that VS 2013 only properly consumed the service when it was in the document-literal style.

I'm of course open to changing the style to be more universally usable, but this web service has been in the wild for some time (and is used by a number of people, I'm sure), so I want to ensure I have a handle on what the possible repercussions might be. I'm also wondering if it's possible to get ColdFusion to generate two different WSDLs (or allow setting of the encoding on the fly?). Basically I'd appreciate any advice on the best way to make this compatible (while maintaining backwards compatibility). Thanks.

Answer 1

If you're OK with having a second URL for the document-literal style web service you could just extend your existing CFC. Your new CFC would have all the same functions and logic of the main web service. It would also prevent a There would be no additional code to maintain. The only unknown for me is if this will create any significant additional overhead.

<cfcomponent extends="yourExistingCFC" style="document" output="false"></cfcomponent>

I did try setting the document type to document-literal on one of my test web services. SoapUI was unable to parse the document-literal WSDL once changed, but Visual Studio could. From this, I would be hesitant on changing the document style of your existing CFC, for you cann't tell how all the client environments will handle the change.