Wow, 800K is not that big, relatively speaking. Currently, the way these distributed apps communicate is by sending entire complex objects (which can be very large.) In a perfect world, we would like to change this inter-application communication to a more real-time, update of only what has changed - a web service. This should then result in manageable messages in the single or double digit K range. We'll still have to work out a process for pushing the creation of one of these large complex objects out to other apps - which will probably end up being an XML file securely ftp'd. Currently, they send ascii delimited files.
Any thoughts/musings on how to tackle this problem are welcome. Thanks. > > From: "Neil Blue" <[EMAIL PROTECTED]> > Date: 2004/03/09 Tue AM 03:11:36 CST > To: <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> > Subject: RE: SOAP message size limitation > > Hello Sean, > > We ahve had large message problems and are moving to soap with attachments now. > Messages of about 800k where causing a lot of problems even after increasing the > server memory allocation to about 256M, but it does appear that the problems are due > to a mixture of large content size and a large number of XML elements (or object > encoded XML elements). We send large messages from client to server and server to > client, so we need to address the problem as 256M clients are a bit fat :) > > Neil > > -----Original Message----- > From: Sean Cohan [mailto:[EMAIL PROTECTED] > Sent: 09 March 2004 03:20 > To: [EMAIL PROTECTED] > Subject: SOAP message size limitation > > > We are analyzing current application functionality and identifying which > functionality could be exposed as web services. Some of the data that would > need to be embedded into the soap body part (or added as an attachment) > could be quite large. > > How large of a SOAP message can you send before it doesn't make sense to > send the data in a SOAP message? > > In other words, what is the upper size limit for a SOAP message? > > What sizes do you start seeing performance problems? > > If we have messages that exceed this threshold, what are good work arounds? > Breaking the messages up into blocks and sending multiple blocks? Yuck. > ftp'ing compressed files? Yuck. > > Yes we will have to encrypt, probably using XML enryption. We will be using > WLS 8.1+, J2EE, Solaris, Oracle. > > Thanks. > > > > >
