Sponsored By Aspose - File Format APIs for .NET

Aspose are the market leader of .NET APIs for file business formats – natively work with DOCX, XLSX, PPT, PDF, MSG, MPP, images formats and many more!

Spare a DIME?

No, I’m not raising money for a charity — I’m doing work with files and binary data via .Net web services.  You probably don’t hear that in the same sentence very often!  Several months ago, DIME (Direct Internet Message Encapsulation) was the latest buzz-word in transmitting files over http for web services; web service enhancements (WS-E) relied on DIME for attachments; there was a flurry of articles (like this one) on how DIME was THE way to include documents in your web service communications.  Recently, however, luminaries such as Don Box and Gudge have reported DIME is dead.  They offer an alternative:  Proposed Infoset Addendum to SOAP Messages with Attachments (or the catchy acronym: PASWA). But as far as I know, this is an abstract alternative.  There isn’t a concrete implementation of PASWA or WS-E version that incorporates PASWA. 


What’s a guy with a laptop and a customer with a large document-centric web service requirement to do?  I don’t want to use DIME if it’s current implementation is not likely to continue, but DIME via WS-E (WS-E Attachments as it’s known) is considerably faster than xml encoding all the bytes in a file.  If you’re curious, WS-E Attachment is well-documented in articles such as this one by Mike Gunerloy; the “old fashion“ way is to move your attachment into a byte array and shuttle it like any normal web service parameter, like this from the client side:



FileStream fsm = File.Open( “File.doc”, FileMode.Open, FileAccess.Read );
byte[] byteArray = new byte[ fsm.Length ];
fsm.Read( byteArray, 0, int.Parse( fsm.Length.ToString() );
//invoke webservice, passing byteArray as a parameter . . .


And this from the webservice side:



MemoryStream mem = new MemoryStream( byteArrayParam ) );
FileStream fsm = new FileStream( “New File Name”, FileMode.Create );
mem.WriteTo( fsm ); mem.Close(); fsm.Close();


Simple and sophisticated, but not quick.  So, the 10 cent question is do I stick with the slower option or go with the “Dead“ DIME solution?  Is there another path?  I’m sure if I’m patient enough, I could wait for a new release of some package and be up and running with PASWA; if I was more enterprising and had more time, I might take a stab at implementing PASWA as an extension to what I’ve got right now — sounds fun, but not a viable option.


I guess I avoid DIME (afraid that future web service / SOAP stacks won’t implement it) and go with the byte array approach?  Am I missing something?


Happy .Netting!


Grant


 

This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

One Response to Spare a DIME?

  1. JosephCooney says:

    I implemented a solution using DIME in early – mid 2002 (and haven’t done anything in that area since). At that time DIME was not part of the SOAP stack by any stretch. The DIME implementation I used was a soap extension (IIRR) that I downloaded from the MSDN, and included the full source. I’m not sure what DIME implementation you plan on using (there is one in WSE 2.0 right?), but if there are implementations with full source out there and they just use standard parts of the .NET framework then why not use them? How concerned are you with exposing your DIME-enabled service to non-.NET clients? Reading the post on Gudge’s blog it says "Microsoft no longer see DIME as an interoperable attachments technology " (note the word interoperable) so depending on who you want to expose the service to you might be OK. My experiences with DIME (even way back at the start of 2002) were all good, but I was just talking .NET -> .NET.

Leave a Reply