- From: David Orchard <dorchard@bea.com>
- Date: Thu, 28 Oct 2004 16:18:10 -0700
- To: "Michael Champion" <mc@xegesis.org>, <www-ws@w3.org>
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: www-ws-request@w3.org [mailto:www-ws-request@w3.org] On Behalf Of > Michael Champion > Sent: Thursday, October 28, 2004 12:31 PM > To: www-ws@w3.org > 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? >
Received on Thursday, 28 October 2004 23:18:12 UTC