I use xceed's streaming compression for .net component to return large (2-4 mb) xml docs from web services. It does a fantastic job and was easier than writing my own soap extension <g>. Also note that compression will be built in to whidbey.
Julie Lerman -----Original Message----- From: Unmoderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Kamen Lilov Sent: Friday, March 25, 2005 9:35 AM To: [email protected] Subject: Re: [ADVANCED-DOTNET] Bulk data transfer of xml-based data: Best methods Have you considered using a third-party component (available in COM and .NET flavors, as this is what you require) to ZIP - or otherwise compress - your data? If it turns out that your 3MB chunks shrink a couple of times, you can continue using web services - just transfer a zipped image of the data and unzip at the receiving end. Plus, it has the added benefit of integrity checking (practically all compressed formats place a checksum, MD5 or some other form of check on the original data to detect corruption in the archive blob) -----Original Message----- From: Unmoderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Bill Bassler Sent: Friday, March 25, 2005 2:44 PM To: [email protected] Subject: [ADVANCED-DOTNET] Bulk data transfer of xml-based data: Best methods I have a requirement to download fairly sizable blocks of xml (~3 MB) to externally located client pcs machines(across the Internet). The received data will then be persisted to a small client side database by a local VB6 application. Plus, for some client sites, this amount of data would need to be moved across dial up lines. I'm trying to determine the most robust, most efficient and easiest to deploy and maintain method (in that order of importance) to accomplish this. Some methods that I've considered are: Direct download request from a web method. Pros 1. Easy to do. 2.Web services interfaces are already available to potentially expose ways to get at the data. Cons 1. Potentially less efficient transfer mechanism to FTP? I don't know. Web service attachment file. Pros - 1. We're currently using web services to message data between disparate applications quite a bit within the existing applications so there's at least some web services interfaces already available to potentially expose ways to get at the data. 2. Don't have to open port 21. Cons - 1. Not sure of the actual status of the spec for WS-Attachment. i.e. I see something about it possibly being obsolete and more about a spec called Swa. It's confusing. 2. Not sure of the client-side requirements to extract the WS-Attachment when received. Can the file easily be extracted by a VB6 application? 3. Potentially less efficient transfer mechanism to FTP? I don't know. File FTP'd Pros - 1. I assume an efficient data tranfer mechanism. 2. Simple client side data read operation to get at the data. Cons - 1. Need to open port 21. 2. There are a bunch of files left on the client machine that need to be locally managed. =================================== This list is hosted by DevelopMentor- http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentor. http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentor� http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
