Greg, On 11 July 2015 at 15:38, Thomas Koster <[email protected]> wrote:
> I'm not sure what you mean here. The generated C# is useless to everyone > else anyway. WSDL is just a fancy XML schema and Mr Java will feed it into > his equivalent of svcutil to generate POJOs. Mr Swift will do likewise. > Your WSDL is presumably generated from the DataContractSerializer > attributes on your data contracts and the WCF attributes on your service > contracts. Remember that DCS and WCF are all about contracts, not classes. > CORBA, Protocol Buffers, Thrift, you name it, are no different. The fact > that your contract specification happens to be grafted onto a class is > irrelevant to svcutil. You could just as well have written the contract as > an XML schema. It's not that svcutil is generating a "stub", but rather it > is generating classes that completely implement the contracts, and nothing > more. If you put extra code in your classes, DCS and svcutil ignore it. > Code can never be part of a web service contract. On 12 July 2015 at 16:56, Greg Keogh <[email protected]> wrote: > We're all aware of what service contracts are. It all boils down to: I > have to ensure that a variety of foreign platforms can easily consume the > basic http binding web service. > So how? Do the tools already exist and I don't have to do anything? > Things like Mr Java and Mr Swift sound great, but they never turned up in > any searches I've run and I still can't find anything useful (anyone used > them?). I have found code examples of Java and Swift reading a web service, > but they are all childishly simple. Most samples consume REST style > services. > > I think I might have to manually publish a REST style service in parallel > with the old one. Extra confusion surrounds the use of complex "types" in > my old contract, all of which get turned into class "stubs" by svcutil ... > will that hinder other clients? I could make the REST service receive and > respond with plain XML and avoid types completely, which I've done in > another working service. I can't decide until I know more about what the > various client platforms prefer. > Then I guess I have misunderstood your problem. Are you using svcutil to generate classes or are you using it to generate WSDL? If it's classes, what extra functionality do you require that svcutil is not generating? Why do you think the complex types in your service contract might be a hindrance and should be ignored by svcutil? Is it that you see mentions of mscorlib collection types in your WSDL schemas and fear that that will cause problems for your Java programmer? You would have to ask him, but if it does (and I suspect it will), then you should define your own (non-generic) collection types and put the CollectionDataContractAttribute [1] on them. You don't need to reinvent the wheel, just subclass List`1. Eventually your WSDL schemas should contain nothing but types from your own contract and the standard XML schema types. Then other platforms' WSDL tools should be happy. I have had to do this to deserialize the results of an SQL Server XML query, for example. Alternatively, if DataContractSerializer is too inflexible for you, you can tell WCF to use the plain old XmlSerializer instead. See XmlSerializerFormatAttribute [2]. [1] https://msdn.microsoft.com/en-us/library/system.runtime.serialization.collectiondatacontractattribute.aspx [2] https://msdn.microsoft.com/en-us/library/system.servicemodel.xmlserializerformatattribute.aspx -- Thomas Koster
