Robert, We have a web service used for the state of California that wraps image files up as base64 - exactly as you suggest below. The image files are obviously much smaller than media files (mostly less than half a meg), but I can tell you that you are on the right track thinking that it is a resource intensive way to go. If we were doing larger files we would probably use something much "dumber" than a web service (also as you suggest) - a URL to retrieve the file via HTTP. Of course you can pass a token or something that is good for only 1 retrieval and then serve the file from a location outside the web root (for security). You could also zip it. But after zipping and using cfcontent and checking credentials you now have a second request that could be resource intensive as well. The bottom line is that there is no great "low resource" way to securely send files around in an SOA type architecture.
-Mark Mark A. Kruger, CFG, MCSE (402) 408-3733 ext 105 www.cfwebtools.com www.coldfusionmuse.com www.necfug.com -----Original Message----- From: Robert Rawlins [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 27, 2008 2:48 PM To: CF-Talk Subject: Sending File Data Over Webservice Hello Guys, I'm after a little advice on refactoring a web service which I have running on one of my applications. The webservice isnt a standard ColdFusion webservice running over SOAP, this is a custom REST service which simply recieves POST data into the FORM scope and then spits back an XML document for the client to read. Now, I basicly offer a bunch of multimedia content over this webservice, anything from text, through to images, sound and video. With the current setup, when a request is made to the service for a particular piece or set of multimedia, the media is zipped on the server into an archive file, the binary data of which is then read into a base64 encoded string and this is then passed back to the client wrapped in some XML over the web service. The challenge I meet with this is not knowing how to weigh up the cost of bandwidth and security against the load hit this causes on the server. See, at the moment, with zipping the content I'm saving a substantial amount of bandwidth, also with zipping the files and sending them as a string I have the ability to be able to produce a HASH key checksum for the file, then when the file arrives the other end, the client can rebuild the file and checksum to make sure all is alive and well after the transmition. Now, the real downside to this option is that it must be hungry on the system, all the checksumming and zipping must be making some form of performance hit, right? especialy on what will likely become a very busy little web service in the comming months. My other planned method of attack is to not pass the files through the webservice at all, but simply pass a web accessible path for them, the client application could then simply loop through the returned XML and make http requests to download the media, this would obviously up the bandwidth but does offer less load involved with compressing the media. I'm sorry the question isnt a little more specific about what I'm asking, I'm just thinking out loud really, hoping somone will chime in and offer thier thoughts. How would you tackle this challenge? what would your priority be? bandwidth or reducing the load on the server? is it plausable to offer a checksum solution even if we're not sending the binary data over the service directly so we can still offer that level of security without the overhead of the zipping? I'm looking for the best ballance. I'd be interested to get your thoughts. Rob ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Adobe® ColdFusion® 8 software 8 is the most important and dramatic release to date Get the Free Trial http://ad.doubleclick.net/clk;160198600;22374440;w Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:300020 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
