Building a web service - can you pass in XML or should the arguments be data typed
Matthew
I'm just checking over some code a developer wrote for me. The project
was to build a web service interface to our application. He has
programmed the web service component in a way that the methods only
require one attribute - an XML packet. He has then defined the
required XML packet in a document. I've never seen a web service
component built like this. I've always used simple and complex data
types as the required arguments for each method. Therefore when you
call the WSDL URL you get a proper definition of the web service. Am I
right or are both options correct?
Here's a sample:
<cffunction name="getMatchingProducts" access="remote" output="true"
returntype="string">
<cfargument name="xmlRequest" type="String" required="true"/>
</cffunction>
I thought it's meant to be like this:
<cffunction name="getMatchingProducts" access="remote" output="true"
returntype="string">
<cfargument name="criteriaA" type="String" required="true"/>
<cfargument name="criteriaB" type="Numeric" required="true"/>
<cfargument name="criteriaC" type="ComplexType" required="true"/>
</cffunction>
The way I see it the client who consumes the webservice in whatever
technology they use will have a web service decipherer which will
convert all complex types into types that will suit them.
Cheers
Matthew
Steve Onnis
You cant call web services using methods. A web services works very much
like a HTTP request. It is a stateless request so you have to pass
everything in at once.
You set the web service up much like a normal CFC, but you cant call
something like...
ws = createObject("WEBSERVICE", "bla.wsdl").init();
ws.setFirstName("foo");
ws.setLastName("bar");
result = ws.doName();
Each time you call a method on the web service it acts in its own request so
when you call setLastName() it will think FirstName was never set which is
why you pass it all in at once and have the doName() get the values from the
data.
You can pass in arguments though but that gets tricky when you have some
optional arguments. Our SMS webservice is XML based, set up an xml packet
and send it all to the web service.
IF you need to define the data types use CFPROPERTY, thats what its for.
Steve
Matthew
correctly. I'll try to explain myself again.
Perhaps there is a CF web service guru out there that can help?
When building a web service, should the input arguments be a single
XML document (which defines the input parameters) or should you just
have an argument for each parameter. Or are both options acceptable?
It makes more sense to me to have a argument for each parameter
otherwise if you have an XML doc as the input you have to write your
own XML parser / validator. This is all built right into CF when you
choose access="remote".
I've been doing a little more reading and noted that you can
distribute your web service as an RPC (default in CF) or as "document-
literal style". I think the RPC system is the way I've been discussing
and the "document-literal style" option is the alternative where you
pass in a full XML document. Is RPC easier but compatible with fewer
technologies?
Cheers
Matthew
Steve Onnis
Its either/or. I preferred the XML way so that's the way it was built. I
guess what I was trying to say in my last email is there isn't a right/wrong
way, just what ever fits better with what you are trying to do. Its easier
to search xml than it is to try and parse arguments if some arguments are
not required to be passed in. Also I don't know if you will have issues
with things like passing in arrays and stuff into the web service because of
the data types possibly not being maintained in the request. This is where
XML is better as you don't need to worry about it and you can handle it all
in your web service.
Steve
-----Original Message-----
From: cfau...@googlegroups.com [mailto:cfau...@googlegroups.com] On Behalf
Of Matthew
Sent: Tuesday, 11 November 2008 1:41 PM
To: cfaussie
Subject: [cfaussie] Re: Building a web service - can you pass in XML or
should the arguments be data typed
Matthew
a function where access="remote" would you build an XML document and
return it or would you just return the data in whatever datatype is
required e.g. string, numeric, array, struct etc. Then the underlying
CF builds it into an XML soap packet to send it back to the caller/
client? It just seems crazy to me to do all the dusiness work of your
function and then have to additionally build an XML packet for
returning. The whole point of CF is to make life easy so you just
return the array or whatever and CF converts it into XML.
Are both options correct?
NOTE: I'm aware that in some scenarios you would want to return an XML
document as part of the return package but lets keep it to returning
simple strings, numbers, arrarys for now.
Cheers
Matthew
Matthew
problem. All CF datatypes are converted to SOAP equivalents (http://
livedocs.adobe.com/coldfusion/7/htmldocs/00001547.htm#1186403).
As per my latest post it just seems crazy to have to write an
additional XML parser to deciffer the XML submitted by the client
(you'd need a whole lot of validation logic as well). Same goes for
sending the data back - why not just let CF covert the objects into
their equivalent SOAP datatypes.
I can't see any benefit for receiving XML packets and returning XML
packets!?!?!? Can anyone comment on reasons to do this?
Cheers
Matthew
Steve Onnis
conversion and datatyping issues, especially with .NET
Using XML you know exactly what you are getting. Thats my reason.
Adam Chapman
I second Steve on the point below.. I have pulled out many a hair trying to get
complex datatypes to send/parse correctly between different platforms. They work
nicely between CF and CF, but try with CF and .NET and the 'fun' begins.
Regards,
Adam
Matthew
and refactored all the code. Thanks a million. I'll be interested to
see what others have to say.
Kai Koenig
"All CF datatypes are converted to SOAP equivalents"
Matthew
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
Matthew
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
Steve Onnis
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: cfau...@googlegroups.com [mailto:cfau...@googlegroups.com] 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
Matthew
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
Kai Koenig
Terry Sasaki
I couldn't agree with you more.
My experience is limited, but I have spent a lot of painful time
working on serious CF-SAP integration with single-sign-on
authentication via web services.
(In my case, CF was a consumer.)
We have tried every possible way to pass a recordset, which is called
"internal table" in SAP world, without success.
The remote function doesn't throw any method signature errors, which
it usually does, but it just recognises the parameter as an empty
recordset.
I guess something wrong is going on with CF's stubs - I mean CF's
implementation of web services.
We eventually re-wrote the remote function so it expects a serialised
recordset, which is not in XML but sort of DSL.
So, while CF's implementation of web services is magical and handy,
its capability is limited.
As a side note, I was able to achieve the same thing with Flex in half
an hour. (grin)
ArrayCollection of VOs is correctly recognised and parsed as "internal table".
Cheers.
Terry
2008/11/12 Kai Koenig <k...@bloginblack.de>: