Steve, Check out this article: http://www-106.ibm.com/developerworks/library/ws-tip-noattach.html it gives some insight into what you ask.
I also know that sending binary data as a byte array increases the data's size by about 33%, according to what I've read. That's because of the base64 encoding that goes on. I did the same sort of thing in a web service I wrote recently. I looked into SOAP with Attachments, and I looked into sending DIME attachments. From what I read, .NET doesn't support S/wA, and DIME isn't a "real" standard. That's why I went with the byte[] solution in my case. -Ian -----Original Message----- From: Brammer, Steve [mailto:[EMAIL PROTECTED] Sent: Friday, January 28, 2005 12:33 PM To: [EMAIL PROTECTED] Subject: Sending binary data as byte array Hi, I have implemented a web service using axis and I consume the web service from .Net. I have a need to send and receive binary data (office documents) but I haven't been able to work out how to use DIME attachements, so I have worked around this by simply turning the filestream into a byte array and handling this inside the complex types I already pass back and forth. The solution works great and also seems pretty fast, although I have not tried it for really massive documents yet. Can anyone tell me this disadvantages of doing this (if there are any). This seems much easier than implementing attachments and it also gets around any interop issues as I am just passing the binary content as a simple type (byte[]). What is the downside, if any, and are there any 'gotchas' I am going to get caught out by?? /Steve ____________________________________________________________ Steve Brammer | Capgemini | Västerås IT Consultant | Technology Services | Portals & Mobility Tel: +46 8 5368 6204 | Mobile: +46 70 2438544 Fax: +46 21 127635 | www.capgemini.com Ingenjör Bååths Gata, SE-721 83, Västerås, Sweden Join the Collaborative Business Experience ____________________________________________________________ This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
