@Steve, true but if you are trying to minimise work for the consumer /
client and they preferred SOAP than all I'm pointing out is that it
shouldn't be too hard to accommodate this. Going for the XML method as
the main web service interface make sense. Thanks everyone for your
help.

Cheers
Matthew

On Nov 11, 5:06 pm, "Steve Onnis" <[EMAIL PROTECTED]> wrote:
> And why would you do that?  All you are doing is creating more work for
> yourself.
>
> When it comes down to it, you need to make it as easy to manage and use as
> possible.  With consideration for the level of compatibility with
> ColdFusion's web service implementation and how it handles soap requests, I
> and a number of other people have already recommended to avoid using the
> native soap data types and use an xml method.  in the end, xml is xml and
> that's it.  No data type problems or anything.  If you need to check the
> data, check it and throw the error with cf.
>
> -----Original Message-----
> From: cfaussie@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf
>
> Of Matthew
> Sent: Tuesday, 11 November 2008 5:02 PM
> To: cfaussie
> Subject: [cfaussie] Re: Building a web service - can you pass in XML or
> should the arguments be data typed
>
> 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
-~----------~----~----~----~------~----~------~--~---

Reply via email to