 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / ASP.NET / Web Services / October 2005MTOM on WSE 3.0
What is the deal with MTOM. From what I can see (in the example), you still need to populate the whole byte[] in memory, then do something with that byte[]. For ~small files, this may be ok. But for large files, you need to chunk the reads and writes to and from a stream (e.g. 4K chunks, etc) Without this, I don't see great value in MTOM. Am I just missing something basic here? Even the Steaming example method appears to populate the whole byte[] in memory first, then does a single write to create the file. Does Indigo change this to allow chunking reads and writes to a stream when using MTOM? TIA  SignatureWilliam Stacey [MVP] This is just an implementation issue to me. Practical value of MTOM/XOP, in the least, is that it reduces size of messages by transferring some data in binary form instead of base64-encoded. Ales Pour > What is the deal with MTOM. From what I can see (in the example), you > still need to populate the whole byte[] in memory, then do something with [quoted text clipped - 5 lines] > create the file. Does Indigo change this to allow chunking reads and > writes to a stream when using MTOM? TIA Thanks. So the inplementation does not allow stream chunking per your understanding? SignatureWilliam Stacey [MVP] > This is just an implementation issue to me. Practical value of MTOM/XOP, > in the least, is that it reduces size of messages by transferring some [quoted text clipped - 11 lines] >> create the file. Does Indigo change this to allow chunking reads and >> writes to a stream when using MTOM? TIA There's an example included with WSE3 distribution that shows both non-streamed and streamed file transfer, where the streaming is done by the application itself. I'm not sure whether the implementation could have support for transparent streaming (eg. WDSL compiler could map xsd:base64 to a Stream, and then the streaming could be handled by the implementation itself during the serialization of a message to a XOP package), and unfortunately I do not know if it is anyhow possible with WSE3... Regards, -AP > Thanks. So the inplementation does not allow stream chunking per your > understanding? [quoted text clipped - 14 lines] >>> write to create the file. Does Indigo change this to allow chunking >>> reads and writes to a stream when using MTOM? TIA Thanks. I saw that, but it does not appear to stream at all, but reads the whole byte[] first then writes the single byte[] to disk. Maybe the example just needs to be expanded to use a while loop or something. Thanks Ales. SignatureWilliam Stacey [MVP] > There's an example included with WSE3 distribution that shows both > non-streamed and streamed file transfer, where the streaming is done by [quoted text clipped - 27 lines] >>>> a single write to create the file. Does Indigo change this to allow >>>> chunking reads and writes to a stream when using MTOM? TIA The specification also highlights the use of attachments, via MIME. It sounds like the WSE 3.0 stuff may be a partional solution. > Thanks. I saw that, but it does not appear to stream at all, but reads the > whole byte[] first then writes the single byte[] to disk. Maybe the example [quoted text clipped - 31 lines] > >>>> a single write to create the file. Does Indigo change this to allow > >>>> chunking reads and writes to a stream when using MTOM? TIA > This is just an implementation issue to me. Practical value of MTOM/XOP, in > the least, is that it reduces size of messages by transferring some data in [quoted text clipped - 11 lines] >> create the file. Does Indigo change this to allow chunking reads and >> writes to a stream when using MTOM? TIA one advantage is that the binary data is "inside" the message so if you add encryption and signature the binary data is included. that does not happen with dime attachments. IIRC, the mtom byte[] is outside the msg using a ref (althougth it could also be inside the message if the byte[] is small as base64). It would still be possible to encrypt and sign the mtom stream as separate entity. SignatureWilliam Stacey [MVP] >> This is just an implementation issue to me. Practical value of MTOM/XOP, >> in the least, is that it reduces size of messages by transferring some [quoted text clipped - 15 lines] > add encryption and signature the binary data is included. that does not > happen with dime attachments.
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.