Fwd: SOAP performance

Thought you folk might be interested in a practitioners view of all of  
this.

Cheers

Steve T (the honest broker).


Begin forwarded message:

> From: "Swan, Chris" <[email protected]>
> Date: 29 October 2004 11:05:06 BST
> To: "'Steve Ross-Talbot'" <[email protected]>
> Subject: RE: SOAP performance
>
> Thanks,
>  
> I don't buy the argument about both sides knowing the XSD a priori as  
> defeating the point of SOAP/XML, but I guess I've spent the past year  
> advocating an XSD first development style and cursing people who've  
> developed 'letterbox' style interfaces that accept xsd:any or  
> xsd:string. A 'good' WSDL should take care of this aspect of the  
> service contract anyway, so it shouldn't be necessary for consumers  
> (or intermediaries) to figure things out on a message by message  
> basis.
>  
> When it comes to compression I don't see why anything needs to be done  
> at the WS-* level; it's a network problem and so it should be solved  
> in the network. There are plenty of WAN p2p compression appliances out  
> there, and most of the common HTTP servers and clients have supported  
> HTTP compression for years. Services (be they SOAP or REST) should be  
> able to sit on top of lower level plumbing that takes care of  
> compression transparently (NB there's a strong argument here for  
> compression token optimisation being better over a number of messages  
> within a conversation rather than on a per message basis).
>  
> Finally (and stating the bleeding obvious a little) I'd add that using  
> a well known schema will help with compression tokenisation as much as  
> it does with parsing optimisation so it's a double win.
>  
> PS I've attached another paper on this topic - one of the best I've  
> read so far (and though it spends a little too much time talking about  
> databases the points are equally valid for many other use cases).
>
> --  
> Chris Swan
> GTI Architecture & Engineering
> Internal *443 8805
>  DDI +44 (0)20 7883 8805
> -----Original Message-----
> From: Steve Ross-Talbot [mailto:[email protected]]
> Sent: 29 October 2004 00:56
> To: Chris Swan
> Subject: Fwd: SOAP performance
>
>
> Woops meant to send this to you too. Cheers Steve T Begin forwarded  
> message:
>
>  From: Steve Ross-Talbot <[email protected]> Date: 29 October 2004  
> 00:55:49 BST To: [email protected], John Davies  
> <[email protected]>, [email protected] Subject: Fwd: SOAP  
> performance Thought you might be interested in what the great and good  
> are thinking. Cheers Steve T Begin forwarded message:
>
>  Resent-From: [email protected] From: "David Orchard" <[email protected]>  
> Date: 29 October 2004 00:18:10 BST To: "Michael Champion"  
> <[email protected]>, <[email protected]> Subject: RE: SOAP performance I  
> wonder if gzipping the body is sweet spot for use with SOAP. Maybe the  
> ebXML guys got it right - the body is in the first mime attachment.  
> Can't recall whether xop/mtom allows the soap body to optimized. Dave
>
>  -----Original Message----- From: [email protected]  
> [mailto:[email protected]] On Behalf
>
>  Of
>
>  Michael Champion Sent: Thursday, October 28, 2004 12:31 PM To:  
> [email protected] Subject: Re: SOAP performance On Oct 27, 2004, at 12:55  
> PM, Robert van Engelen wrote:
>
>  The gSOAP toolkit [4][5] essentially generates a recursive descent  
> parser for an XML schema, i.e. the parser is specifically optimized
>
>  to
>
>  consume instances of that schema [2][5]. The results of this  
> "schema-specific" parsing approach on performance are available in
>
>  [3]
>
>  and a comparison to even faster techniques is presented in [1]. To  
> corroborate Steele's results, another interesting real-world  
> application (SNMP) is discussed in [6] and [7], which also  
> investigates native formats compared to XML with and w/o
>
>  compression.
>
>  I'm a bit unclear on real-world use cases for schema-specific XML  
> parsing. That seems to create a tight coupling between the sender and  
> receiver (both have to know the schema to interoperate), and  
> intermediaries such as WS-Security aware firewalls that can't
>
>  plausibly
>
>  know the schema are infeasible. In other words, that defeats the
>
>  whole
>
>  purpose of SOAP/XML, as far as I can tell: If both sides know each  
> other's schema, why not just exchange serialized objects? If you
>
>  can't
>
>  use the SOAP processing model (e.g. intermediaries that can add and  
> process headers), why bother with SOAP? What am I missing?
>
>   
> ======================================================================= 
> =======
>  This message is for the sole use of the intended recipient. If you  
> received this message in error please delete it and notify us. If this  
> message was misdirected, CSFB does not waive any confidentiality or  
> privilege. CSFB retains and monitors electronic communications sent  
> through its network. Instructions transmitted over this system are not  
> binding on CSFB until they are confirmed by us. Message transmission  
> is not guaranteed to be secure.
>   
> ======================================================================= 
> =======
>