Perhaps the answer is to provide 2 web service interfaces - one for XML consumers and the other for SOAP consumers. If you build the XML version first it shouldn't be that hard to build a SOAP version as well... as long as the web service's have absolutely no business logic in them. The SOAP web service CFC would have inputs parameters and forward everything onto a service object. The XML web service CFC would be a little more complicated because it would have all the XML parsing, validating etc and then forward the request onto the same service object.
Cheers Matthew On Nov 11, 3:55 pm, Matthew <[EMAIL PROTECTED]> wrote: > One potential argument against "XML in and XML out" is that this is > more work for the consumer / client. They have to covert build an XML > packet to submit to the web service and then they have to parse / > validate / pull apart the XML packet which I return to them. Where as > if I was to use the scenario where your input and output parameters > are strings, numbers, arrays, objects etc (and let CF covert them to > their SOAP equivalents - which Kai obviously hates) then surely it > would be easier for the consumer. > > From experience with web services that I've consumed in the past the > web service must be returning SOAP data types to CF because I end up > with a object which as you unpack it you get objects within objects > and eventually you get down to the string, numbers, arrays etc. This > makes sense to me because otherwise I'd have to parse the returned XML > and then convert it all into CF data types before I could do anything > with it (i.e. store some of it in the DB and display some of it to the > user). > > What have other people experienced? > > Cheers > Matthew > > On Nov 11, 2:41 pm, Kai Koenig <[EMAIL PROTECTED]> wrote: > > > Yeah, Dream on! :-) > > > Well - they are coverted to SOAP equivalents, nothing wrong so far. > > > As Steve has pointed out - there are various complex issues when it > > comes to complex data types cross-platform interoperability - converting > > types to .NET is one of the easier tasks. Start about including proper > > webservice security, authentication etc. and you're totally lost with > > CF. > > > CF's Axis-integration follows the code-first principle, i.e. you write > > code > > and "all the magic" (WSDL) is done for you. Unfortunately that's one > > of the worst approaches one could follow when it comes to web services, > > it should always be "contract first" and the implementations should be > > derived from a shared interface in WSDL. > > > CF to CF webservices though are expected to work fine. When it comes > > to any serious webservice integration with CF though (WS-*, complex > > types to .NET etc.) I'd not use it or rather go with a custom XML API. > > > Cheer > > Kai > > > > "All CF datatypes are converted to SOAP equivalents" > > > _________________________________________________ > > Kai Koenig - Ventego Creative Ltd > > ph: +64 4 476 6781 - mob: +64 21 928 365 / +61 450 132 117 > > web:http://www.ventego-creative.co.nz > > blog:http://www.bloginblack.de > > > _________________________________________________ > > Kai Koenig - Ventego Creative Ltd > > ph: +64 4 476 6781 - mob: +64 21 928 365 / +61 450 132 117 > > web:http://www.ventego-creative.co.nz > > blog:http://www.bloginblack.de > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "cfaussie" group. To post to this group, send email to cfaussie@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~----------~----~----~----~------~----~------~--~---
