Steve Jones wrote: > While I bang on about technology not being important with SOA, I'd > like to kick a thread off around one of my perceptions. > > Anne said at the SOA event in Belgium this week that she'd recommend > XML gateways for performance reasons. >
Sorry I missed meeting up with you at the conference, Steve! As to the XML performance issue, I think Anne meant the gateway remark in reference to aspects of XML processing like schema validation and WS-Security. Both of these are very processing-intensive activities that can easily slow processing of requests and responses by an order of magnitude or more. Gateways generally can't do much to reduce the actual parser overhead of XML processing, though I did implement a binary interface between one vendor's gateway and Java applications that gave about a 3x performance advantage for a range of XML documents (as opposed to direct parsing of XML text, using a JAXP interface in both cases). > My view (and the experience I've had tends to back this up) is that > XML performance is rarely an issue. The cost of marshaling WS against > RMI is minimal in most cases, and when using a StAX parser for > fragments of a large document then the WS approach will be much > quicker than RMI. And generally with the current hardware performance > characteristics (My laptop is a 2-way 2GHz box) the challenge isn't on > the computational side for performance around XML processing but still > in elements like databases, transaction managers and of course the > actual IO (like disk) and bandwidth elements. > I'm not sure what you mean by "when using a StAX parser for fragments of a large document". Most WS applications involve processing the entire document, and for this case SOAP message exchange is definitely considerably slower than RMI. Part of this comes down to the size of the documents - RMI data representations are typically several times smaller than XML, though this depends partly on the type of data (SOAP suffers the least by comparison when your data consists mainly of long text strings - and you use short element names). See http://www.sosnoski.co.nz/presents/cleansoap/results.html for some timing comparisons using the older generation of SOAP frameworks for Java. I'll be publishing updated results over the next few months using the newer frameworks, which generally get performance down to about half the level demonstrated by JibxSoap (they take about twice as long to complete the tests, in other words). In addition to the base performance as shown by these timings, SOAP frameworks also tend to run into problems when handling large messages (roughly 10MB+). Here again, the newer generation of frameworks generally do better than the old ones, but none are designed for the type of streamed processing that would really be needed to make them work properly with these types of messages (though if the messages can be processed piecemeal, JiBX data binding with Axis2 or XFire would allow easy handling). - Dennis Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
