Jonas Johansson wrote:
>Aha, so for document/literal mode you don't really need any special
>SOAP-engine at all then, you can just use your ordinary SAX-or-similar
>XML parser? Yes, I can see how that works...
>
>I guess that streaming of SOAP messages in RPC mode would be unnecessary
>or impossib
Aha, so for document/literal mode you don't really need any special
SOAP-engine at all then, you can just use your ordinary SAX-or-similar
XML parser? Yes, I can see how that works...
I guess that streaming of SOAP messages in RPC mode would be unnecessary
or impossible since RPC's would not be pr
Thanks for the response Chris,
Nice to hear that I'm not alone in doubting that buffering of entire
SOAP messages before sending is a must at the server!
I just read something interesting ("Investigating the Limits of SOAP
Performance for Scientific Computing" found at
http://www.extreme.indiana.
In the past I've implemented a gazetteer service with a WFS that simply
auto-detected if the request was wrappen in SOAP (which is just an
envelope if you dont use the intrinsically non-interoperable RPC mode)
and responded with a SOAP wrapper if appropriate.
It is unclear to me where and when
Jonas Johansson wrote:
Hi list,
Maybe someone here has some knowledge on SOAP. I have been looking into
the OGC move towards W3C Web Services standards for geospatial services
and I have a question regarding performance when using SOAP.
It is mentioned by many that large data sets is a perfor
Hi list,
Maybe someone here has some knowledge on SOAP. I have been looking into
the OGC move towards W3C Web Services standards for geospatial services
and I have a question regarding performance when using SOAP.
It is mentioned by many that large data sets is a performance issue when
using SOAP
