views:

604

answers:

4

I have a "simple" task. I have an existing project with a web service written in C# which has a method that will send a huge XML file to the client. (This is a backup file of data stored on the server that needs to be sent somewhere else.) This service also had some additional authentication/authorization set up. And I have an existing Delphi 2007 application for WIN32 which calls the web service to extract the XML data for further processing. It's a legacy system that runs without a .NET installation. Only problem: the XML file is huge (at least 5 MB) and needs to be sent as a whole. Due to system requirements I cannot just split this up into multiple parts. And I'm not allowed to make major changes to either the C# or the Delphi code. (I can only change the method call on both client and server.) And I'm not allowed to spend more than 8 (work) hours to come up with a better solution or else things will just stay unchanged.

The modification I want to add is to compress the XML data (which reduces it to about 100 KB) and then send it to the client as a binary stream. The Delphi code should then accept this incoming stream and de compress the XML data again. Now, with a minimum of changes to the existing code, how should this be done?

(And yes, I wrote the original client and server in the past and it was never meant to send that much data at once. Unfortunately, the developer who took it over from me had other ideas, made several dumb changes, did more damage and left the company before my steel-tipped boot could connect to his behind so now I need to fix a few things. Fixing this web service has a very low priority compared to the other damage that needs to be restored.)


The server code is based on legacy ASMX stuff, the client code is the result of the Delphi SOAP import with some additional modifications. The XML is a daily update for the 3000+ users which happens to be huge in it's current design. We're working on this but that takes time. There are more important items that need to be fixed first, but as I said, there's a small amount of time available to fix this problem quickly.

+3  A: 

This sounds like a good candidate for an HttpHandler

My good links are on my work computer (I'll add them when I get to work), but you can look to see if it will be a good fit.

-- edit --
Here are the links...

http://www.ddj.com/windows/184416694
http://visualstudiomagazine.com/articles/2006/08/01/create-dedicated-service-handlers.aspx?sc_lang=en&sc_mode=edit

Brad Bruce
Sounds good, as long as it's quick to implement. :-) Otherwise, I won't get the time to make the modification. (Too many more important issues to fix first.)
Workshop Alex
Now all I need is something for the client side to handle this stream. (And hoping it's easy to implement in Delphi/WIN32.)
Workshop Alex
And I found it! :-) Just use the URL to download the page. At least, it's better than the current service...
Workshop Alex
+1  A: 

What is the problem with a 5MB file in a soap message? I have written a document server that runs over soap and this server has no problem with large files.

If the size is a problem for you I would just compress and decompress the xml data. This can easily be done with one of the many (free) available components for compression of a TStream descendant.

birger
The problem is that the client application might be installed on a simple netbook with a GPRS-whatever wireless network at 7MBits. With the additional overhead for firewalls, virusscanners and the possible bad connections, our "field agents" would have to wait a long while to receive their daily update...
Workshop Alex
A: 

If you get that kind of compression, merely convert each byte to its hex equivalent, which will only double the size, and send this. Then do the opposite on the other end. Or am I missing something?

xcramps
Yes, that would work too, although the current level of compression isn't guaranteed. Also, taking the limited bandwidth of the end-users into account, the less data that needs to be sent, the better. Am already glad that no user will use an old dial-up connection.
Workshop Alex
A: 

I would agree with Brad Bruce, HttpHandler would be fast, and using GZIP or Deflate Compression with I might be wrong... browsers support natively. you can get easy great compression on text based data for cheap cpu time.

System.IO.Compression.GZipStream GZipStream = new System.IO.Compression.GZipStream("Your XML Doc Stream",System.IO.Compression.CompressionMode.Compress)
BigBlondeViking