Steps similar to MTOM sample with file caching enabled. Received dataStream is loaded in XML object for further transformation.
regards Yogesh "robert lazarski" <[EMAIL PROTECTED]> 10/22/2007 05:17 PM Please respond to [email protected] To [email protected] cc Subject Re: Best way to realize stateful servicesarchitecturewithmassivedata? That's pretty kool. Did you use any streaming to avoid putting the data in memory and building the tree? Or did you just more or less follow the same steps in the mtom tutorial? Robert On 10/22/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Hi We were in similar situation we were planning to transfer 1GB file as SOAP as attachment. 1) Axis2 give pretty good support using MTOM and SWA for transferring any size file. 1GB file transferred in 67sec on local network. File caching feature is great. 2) But it is not good idea to transfer SOAP with such large attachment. We also hit some our app server & service bus handling limitation. So we decided to process data in chunk. We get file data in chunk and till we get all data correctly we dont send confirm to end point (which really delete file on source system . End of our getFile operation / confirming file received at server ). Same way on reverse we put data in chunk to some temp file on destination endpoint. after placing all data at end we rename it to required file. Let me know your thoughts Regards Yogesh Dhake "Walker, Jeff" <[EMAIL PROTECTED]> 10/22/2007 11:46 AM Please respond to [email protected] To <[email protected]> cc Subject RE: Best way to realize stateful servicesarchitecturewithmassivedata? Michele, I'm not sure JMS is a viable alternative if large amounts of data are transferred. That statement would imply there is some sort of size cutoff. There isn't. Just remember, that with JMS you can have persisted queues and then all of that data would have to be stored temporarily. Personally, I think some of the lessons from JMS (message queuing in general) can be applied to web services; keep the msgs as small as possible. Large data transfer (across the network) is a serious problem. There is no easy solution that I've seen. Having said that, there are quite a few posters who have used attachments with their web services. I have used the older DIME format, but other posters have used the newer MTOM. I would be interested to see what their performance was like, with large files (ie. around a Gigabyte, say). Since MTOM chunks up the files, transferring any sized file should theoretically be possible. Does anyone have any opinions on using MTOM for transferring Gb and and multi-Gb files?? -jeff -----Original Message----- From: Michele Mazzucco [mailto:[EMAIL PROTECTED] Sent: Monday, October 22, 2007 11:21 AM To: [email protected] Subject: RE: Best way to realize stateful servicesarchitecturewithmassivedata? Jeff, I mentioned JMS as possible choice if one has to transfer large amount of data since it is asynchronous. Michele On Mon, 2007-10-22 at 11:10 -0400, Walker, Jeff wrote: > You mentioned WS over JMS. Again, added delay, since another protocol > layer is employed. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ====================================================================================================== This transmittal and any attachments may contain confidential, privileged or sensitive information and is solely for the use of the intended recipient. If you are not the intended recipient, you are hereby notified that you have received this transmittal and any attachments in error and any review, dissemination, distribution or copying thereof is strictly prohibited. If you have received this transmittal and any attachments in error please notify the sender and immediately destroy the message and all its attachments. Any opinions herein expressed may be those of the author and not necessarily of Mizuho Corporate Bank, Ltd., Mizuho Corporate Bank (USA), Mizuho Securities USA Inc. or any other affiliates of Mizuho Financial Group ("Mizuho"). Mizuho accepts no responsibility for the accuracy or completeness of any information herein contained. E-Mail received by or sent from officer of Mizuho Securities USA Inc. (which is a registered U.S. broker-dealer and the entity through which Mizuho generally conducts its investment banking, capital markets, and securities business in the United States) is electronically archived and recorded and is subject to review and monitoring by and/or disclosure to persons other than the recipient, including (but not limited to) Mizuho Securities USA Inc. supervisory personnel. Such communications may be produced to regulatory authorities or others with legal rights to the information.
