You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Samuel Meder <me...@mcs.anl.gov> on 2004/06/08 21:59:08 UTC
Re: SOAP streaming and faults, security everywhere and performance
implications [Re: opinion Axis' future ... [Re: Using SAAJ-1.2 API to
modify the soap header/body content
I completely agree on Alex's point that security (and other QoS aspects)
are very important for us working in the Grid world. It is hard to
justify to users that turning on security will cause a 10x slowdown (it
is actually even worse with larger payloads) and since grid scenarios
are generally multi organization security is a ubiquitous requirement (I
would think that the same is true for B2B scenarios).
/Sam
On Tue, 2004-06-08 at 13:29, Aleksander Slominski wrote:
> Sanjiva Weerawarana wrote:
>
> >Hi Alek,
> >
> >
> Hi Sanjiva,
>
> much more comments inline.
>
> >>but it seems that reality of current SOAP is not allowing any of
> >>those desirable features to be easily expressed ...
> >>
> >>
> >
> >I agree with your comment about streaming .. but I'm willing to
> >"break" SOAP semantics for it.
> >
> >
> :)
>
> >>now that we are stuffing more and into headers (such as binary
> >>security tokens) there seems to be quite common case that size
> >>of headers will well outweigh size of payload.
> >>
> >>
> >
> >I agree 100%. However, in the presence of such headers the
> >performance requirements change. For example, if RM is being
> >used with a QoS of exactly once, ordered delivery, then the raw
> >performance is not so critical in a business process that's
> >probably driving it. Most likely the process is a long running
> >business transaction (like a mortgage application) and then
> >there's not much point in focusing on whether a message takes
> >10ms or 20ms when the whole process runs over a 3 month period.
> >
> >
> >
> i think security will soon be required for any message exchange and the
> same may be about WS-RM when we have more multi-hop services and
> messages that must pass multiple gateways (next gen firewalls).
>
> >>also i think that MTOM (and attachment) can be referenced
> >>both from headers and payloads so binary large data can be
> >>
> >>
> >
> >WSDL 2.0 does not support that; MTOM is for the payload only ..
> >headers are not part of the fundamental description of a Web service;
> >they come into existence due to the application of certain QoS
> >(like RM or security).
> >
> >
> i will need to check this i thought MTOM can be applied to any base64
> content ...
>
> >>easily added anywhere in SOAP envelope and we should make
> >>sure that all this can be efficiently processed ...
> >>
> >>
> >
> >Sure, but you can't have the cake and eat it. My believe today is
> >that header processing is expensive and is going to be so. SOAP
> >requires that all mustUnderstand headers be processed correctly ..
> >that means you can't "stream" headers thru - the framework has to
> >process everything. Furthermore, as more and more QoS characteristics
> >(aka policies) are applied, header processing becomes even more
> >complex. In particular, it is quite non-trivial to determine which
> >order the various policy handlers can run .. in the case of transactions
> >and reliable messaging and security you can convince yourself that the
> >right order is security, then reliable messaging and then Tx. In the
> >general case there is no algorithm to compute the order AFAIK.
> >
> >
> yes we need policies about how to apply policies (and handlers) ...
>
> >>still clearly the one case to keep in mind is how to handle very
> >>large payloads as it may be very important case for some class of
> >>applications such as scientific computing.
> >>
> >>
> >Sure.
> >
> >
> >>i started with just considering generic XML messaging (and that
> >>is how XSOAP4/XSUL is designed) so i did not feel like there is
> >>a need to have a special separate treatment of header and body
> >>(payload) which seems to be now validated by current "core"
> >>WS-* specs (see below).
> >>
> >>
> >
> >I'm confused by the last comment; which WS-* specs blur the ditinction
> >between header and body?? (I couldn't see a clarification further
> >below; sorry.)
> >
> >
> for example: WS-RM has some special (infrastructure level) messages that
> has empty body and action is really part of header (but no payload ...)
>
> >>if you describe everything as XML infoset that it is very
> >>important to allow simple access to whole message XML infoset
> >>(and make possible to use such tools like XPath or XQuery) -
> >>runtime XML infoset is just optimized to take hints (such as
> >>provided by MTOM) to make decisions about in-memory
> >>materialization of XML content.
> >>
> >>
> >
> >Yep; I'm definitely +1 for an MTOM-aware Infoset model being the
> >default, dynamically typed representation of arbitray XML content.
> >
> >
> then why to make the distinction between XML elements <S:Header> and
> <S:Body> - isnt body like a special header targeted to ultimate receiver?
>
> >>so my thinking is that there needs to be set of flexible layers
> >>and developer can choose on which layer to plugin their code:
> >>transport, XML message infoset, SOAP headers/payload (header
> >>processors). XML Schema data binding, RelaxNG validation, whatnot ...
> >>
> >>
> >
> >IMO we need to classify different types of developers and provide
> >different programming models for them. I want to keep app developers
> >a level above all this .. basically at the level WSDL 2.0 is putting
> >them at; anything else are policies they express or are expressed
> >to them by someone else.
> >
> >
> i think it would be very valuable to have enumeration of roles (like
> EJB) but applied to building WS and SO(A).
>
> >The developers who write such policy handlers of course have a
> >different view of the world and get access to a different/additional
> >set of information .. for example, the security handler is someone
> >who will likely re-write the entire payload (if it were encrypted).
> >
> >
> yes - we do it all the time including dreaded conversion to DOM so
> existing XML security libs can work on the message.
>
> >>unfortunately XML is not designed for streaming and moreover
> >>streaming of payload is not supported in SOAP 1.1/1.2.
> >>
> >>
> >Yes, unfortunately.
> >
> >
> >
> unfortunately :(
>
> maybe we need SSOAP?
>
> >>i think i can make this bold (?!) statement based on my past
> >>experience: only by breaking SOAP semantics it is i possible
> >> to do limited streaming of vanilla SOAP envelopes with just
> >>
> >>
> >
> >I'm ok with "breaking" SOAP semantics a bit here ..
> >
> i wish it could be expressed without any breakage - the heart of it is
> that if you want to stream output you can not know if there some
> processor that produces output (such as serializer or actual service
> when it computes stream content) that may fail *during* output - in this
> case you can either buffer whole thing (preferably to DB or file for
> really large outputs so at least memory footprint is not too bad ...) or
> start sending it immediately but then you can not signal fault in
> mid-stream.
>
> the only robust but sub-optimal way to deal with it (i found and
> implemented in XSOAP1) is to close abruptly output stream.
>
> it would be much better if i could write <S:Fault> as last children of
> <S:Body> and have receiving processor to discard input and act on Fault.
>
> >in fact the
> >breakage would only be visible to an external observer in the form
> >of the error they will get.
> >
> breakage will be only if error happens but if you do what i did in
> XSOAP1 the receiver will not know what caused problem as no Fault is
> sent only that connection was lost ...
>
> >Two well-behaved SOAP processors will
> >not have any problem .. where well-behaved means that they basically
> >general well-formed XML; a very low bar to pass.
> >
> >
> >
> it is more complicated than that as i described above: Fault is special
> and is supposed to be first child of Body ...
>
> do you have some other solution in mind?
>
> >>payload (why no way to signal in-stream faults?) and it gets
> >>very difficult with WSS (why there is no footers so one could
> >>compute signature on the fly and then write it in footer!) and
> >>does not make sense for WS-ReliableMessaging (message is stored
> >> before sending so it can be easily re-sent ...) except of course
> >>for re-streaming out of (database) persistent storage later but
> >>that is just replay and will require coding to make sure it
> >>scales well ....
> >>
> >>
> >
> >Again, I believe the realistic business scenarios for WS-Security
> >and WS-Reliable Messaging have different performance characteristics
> >than a raw SOAP message exchange. Thus, I'm not convinced there's
> >much value in doing raw comparison of how long it takes an RM
> >exchange to occur .. that's not what RM is intended to be used for
> >IMO.
> >
> >
> IMHO as business and scientific worlds converges on Web services and
> Grids those distinctions are blurred.
>
> for example one of the most important requirements for grid services (if
> not the most important ...) is to have security.
>
> in current WS world security has serious impact on performance (like one
> order of magnitude slower for WSS and even more when you start doing SSO
> with capabilities ....).
>
> so the time of simple non secure and non reliable SOAP messages may be
> going away but i hope it will not require more and more complex WS-*
> specs that are harder and harder to understand and work with (WSS and
> WS-Policy comes to mind ....).
>
> alek
--
Sam Meder <me...@mcs.anl.gov>
The Globus Alliance - University of Chicago
630-252-1752
Re: Re: message/transport level security [Re: SOAP streaming and
faults, security everywhere and performanceimplications [Re: opinion Axis'
future ... [Re: Using SAAJ-1.2 API tomodify the soap header/body content
Posted by Samuel Meder <me...@mcs.anl.gov>.
On Wed, 2004-06-09 at 15:13, Davanum Srinivas wrote:
> I just browsed their code....No, they don't have WS-SecConv support as
> far as i can tell.
We ended up implementing our own equivalent (for timing and other
reasons). So no, we don't have WS-SecConv. From a protocol performance
perspective the issues should be exactly the same though.
/Sam
>
> -- dims
>
> On Wed, 09 Jun 2004 15:10:37 -0500, Aleksander Slominski
> <as...@cs.indiana.edu> wrote:
> >
> > Davanum Srinivas wrote:
> >
> > >Do you have a WS-SecConv impl? (open source?)
> > >
> > >
> > we looked on Globus Toolkit 3.2 which i think is an early/prototype
> > implementation and i am not sure about its long term status.
> >
> > i am sure that Globus guys will have more definitve answer to that :)
> >
> > thanks,
> >
> > alek
> >
> >
> >
> > >On Wed, 09 Jun 2004 11:15:58 -0500, Aleksander Slominski
> > ><as...@cs.indiana.edu> wrote:
> > >
> > >
> > >>Sanjiva Weerawarana wrote:
> > >>
> > >>
> > >>
> > >>>"Samuel Meder" <me...@mcs.anl.gov> writes:
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>>I completely agree on Alex's point that security (and other QoS aspects)
> > >>>>are very important for us working in the Grid world. It is hard to
> > >>>>justify to users that turning on security will cause a 10x slowdown (it
> > >>>>is actually even worse with larger payloads) and since grid scenarios
> > >>>>are generally multi organization security is a ubiquitous requirement (I
> > >>>>would think that the same is true for B2B scenarios).
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>Of course. However, that's a fundamental issue with XML security
> > >>>and not with the WS-* specs in particular. The XML sec stuff is
> > >>>defined in terms of DOMs and DOM hash's .. which can be computed
> > >>>in a streaming model for many XPaths ..
> > >>>
> > >>>
> > >>>
> > >>>
> > >>hi Sanjiva
> > >>
> > >>i think that it is true for verification but not for signing as you need
> > >>to compute signature: you *can* compute it in a streaming fashion but
> > >>then you need to put signature in header so you have to buffer whole
> > >>stream output (why, oh why, there is no footer element in SOAP ...)
> > >>
> > >>
> > >>
> > >>>Furthermore using WS-Security without WS-Secure Conversation is
> > >>>retarded (IMO).
> > >>>
> > >>>
> > >>>
> > >>>
> > >>there are many cases to consider and each situation is unique.
> > >>
> > >>WS-SecConv does not buy you much if you do very coarse grained messaging
> > >>(only one message sent to service) still the overhead is small enough
> > >>that may be doable to do WS-SecConv for every message.
> > >>
> > >>however there is a potential scalability problem as server needs to
> > >>remember all those opened sessions so implementation must be very
> > >>careful here (we did some testing and in one test setup after a thousand
> > >>or so connections server refused to accept any new connections ...)
> > >>
> > >>
> > >>
> > >>>In summary, IMO there's no reason why WS-Security/WS-Secure Conversation
> > >>>have to be any less performant than any other public key security
> > >>>technology IMO for many cases.
> > >>>
> > >>>
> > >>>
> > >>yes - if we do have better libs to do efficient
> > >>streaming/canonicalization/verification/signing and generally avoiding
> > >>excessive memory usage.
> > >>
> > >>
> > >>
> > >>>There may be degenerate cases where
> > >>>it is, but if we can make those rare then we're in business.
> > >>>
> > >>>
> > >>>
> > >>>
> > >>that is still to be seen :)
> > >>
> > >>currently SSL without keep alive (so it does key exchange each time) is
> > >>2-5x faster than WS-SecConv after first message (this is just estimate
> > >>...) and SSL with keep alive (no key exchange so it is comparable to
> > >>session in WS-SecConv) it is faster by *order of magnitude* than
> > >>WS-SecConv in what we tested (caveat emperor!)
> > >>
> > >>plus with SSL you can easily by hardware accelerator and load balancers
> > >>that will understand SSL it will take some time before WS-SecConv is
> > >>real standard and has this kind of support ...
> > >>
> > >>we are going to submit a paper (Satoshi did a great work on this) with
> > >>details on tests to Workshop on Grid Computing (Grid 2004) and hope that
> > >>it will lead to some discussion and ultimately faster (streaming?) code
> > >>in future :)
> > >>
> > >>thanks,
> > >>
> > >>alek
> > >>
> > >>--
> > >>The best way to predict the future is to invent it - Alan Kay
> > >>
> > >>
> > >>
> > >>
> > >
> > >
> > >
> > >
> >
> > --
> > The best way to predict the future is to invent it - Alan Kay
> >
> >
--
Sam Meder <me...@mcs.anl.gov>
The Globus Alliance - University of Chicago
630-252-1752
Re: Re: message/transport level security [Re: SOAP streaming and faults, security everywhere and performanceimplications [Re: opinion Axis' future ... [Re: Using SAAJ-1.2 API tomodify the soap header/body content
Posted by Davanum Srinivas <da...@gmail.com>.
I just browsed their code....No, they don't have WS-SecConv support as
far as i can tell.
-- dims
On Wed, 09 Jun 2004 15:10:37 -0500, Aleksander Slominski
<as...@cs.indiana.edu> wrote:
>
> Davanum Srinivas wrote:
>
> >Do you have a WS-SecConv impl? (open source?)
> >
> >
> we looked on Globus Toolkit 3.2 which i think is an early/prototype
> implementation and i am not sure about its long term status.
>
> i am sure that Globus guys will have more definitve answer to that :)
>
> thanks,
>
> alek
>
>
>
> >On Wed, 09 Jun 2004 11:15:58 -0500, Aleksander Slominski
> ><as...@cs.indiana.edu> wrote:
> >
> >
> >>Sanjiva Weerawarana wrote:
> >>
> >>
> >>
> >>>"Samuel Meder" <me...@mcs.anl.gov> writes:
> >>>
> >>>
> >>>
> >>>
> >>>>I completely agree on Alex's point that security (and other QoS aspects)
> >>>>are very important for us working in the Grid world. It is hard to
> >>>>justify to users that turning on security will cause a 10x slowdown (it
> >>>>is actually even worse with larger payloads) and since grid scenarios
> >>>>are generally multi organization security is a ubiquitous requirement (I
> >>>>would think that the same is true for B2B scenarios).
> >>>>
> >>>>
> >>>>
> >>>>
> >>>Of course. However, that's a fundamental issue with XML security
> >>>and not with the WS-* specs in particular. The XML sec stuff is
> >>>defined in terms of DOMs and DOM hash's .. which can be computed
> >>>in a streaming model for many XPaths ..
> >>>
> >>>
> >>>
> >>>
> >>hi Sanjiva
> >>
> >>i think that it is true for verification but not for signing as you need
> >>to compute signature: you *can* compute it in a streaming fashion but
> >>then you need to put signature in header so you have to buffer whole
> >>stream output (why, oh why, there is no footer element in SOAP ...)
> >>
> >>
> >>
> >>>Furthermore using WS-Security without WS-Secure Conversation is
> >>>retarded (IMO).
> >>>
> >>>
> >>>
> >>>
> >>there are many cases to consider and each situation is unique.
> >>
> >>WS-SecConv does not buy you much if you do very coarse grained messaging
> >>(only one message sent to service) still the overhead is small enough
> >>that may be doable to do WS-SecConv for every message.
> >>
> >>however there is a potential scalability problem as server needs to
> >>remember all those opened sessions so implementation must be very
> >>careful here (we did some testing and in one test setup after a thousand
> >>or so connections server refused to accept any new connections ...)
> >>
> >>
> >>
> >>>In summary, IMO there's no reason why WS-Security/WS-Secure Conversation
> >>>have to be any less performant than any other public key security
> >>>technology IMO for many cases.
> >>>
> >>>
> >>>
> >>yes - if we do have better libs to do efficient
> >>streaming/canonicalization/verification/signing and generally avoiding
> >>excessive memory usage.
> >>
> >>
> >>
> >>>There may be degenerate cases where
> >>>it is, but if we can make those rare then we're in business.
> >>>
> >>>
> >>>
> >>>
> >>that is still to be seen :)
> >>
> >>currently SSL without keep alive (so it does key exchange each time) is
> >>2-5x faster than WS-SecConv after first message (this is just estimate
> >>...) and SSL with keep alive (no key exchange so it is comparable to
> >>session in WS-SecConv) it is faster by *order of magnitude* than
> >>WS-SecConv in what we tested (caveat emperor!)
> >>
> >>plus with SSL you can easily by hardware accelerator and load balancers
> >>that will understand SSL it will take some time before WS-SecConv is
> >>real standard and has this kind of support ...
> >>
> >>we are going to submit a paper (Satoshi did a great work on this) with
> >>details on tests to Workshop on Grid Computing (Grid 2004) and hope that
> >>it will lead to some discussion and ultimately faster (streaming?) code
> >>in future :)
> >>
> >>thanks,
> >>
> >>alek
> >>
> >>--
> >>The best way to predict the future is to invent it - Alan Kay
> >>
> >>
> >>
> >>
> >
> >
> >
> >
>
> --
> The best way to predict the future is to invent it - Alan Kay
>
>
--
Davanum Srinivas - http://webservices.apache.org/~dims/
Re: message/transport level security [Re: SOAP streaming and faults,
security everywhere and performanceimplications [Re: opinion Axis' future
... [Re: Using SAAJ-1.2 API tomodify the soap header/body content
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Davanum Srinivas wrote:
>Do you have a WS-SecConv impl? (open source?)
>
>
we looked on Globus Toolkit 3.2 which i think is an early/prototype
implementation and i am not sure about its long term status.
i am sure that Globus guys will have more definitve answer to that :)
thanks,
alek
>On Wed, 09 Jun 2004 11:15:58 -0500, Aleksander Slominski
><as...@cs.indiana.edu> wrote:
>
>
>>Sanjiva Weerawarana wrote:
>>
>>
>>
>>>"Samuel Meder" <me...@mcs.anl.gov> writes:
>>>
>>>
>>>
>>>
>>>>I completely agree on Alex's point that security (and other QoS aspects)
>>>>are very important for us working in the Grid world. It is hard to
>>>>justify to users that turning on security will cause a 10x slowdown (it
>>>>is actually even worse with larger payloads) and since grid scenarios
>>>>are generally multi organization security is a ubiquitous requirement (I
>>>>would think that the same is true for B2B scenarios).
>>>>
>>>>
>>>>
>>>>
>>>Of course. However, that's a fundamental issue with XML security
>>>and not with the WS-* specs in particular. The XML sec stuff is
>>>defined in terms of DOMs and DOM hash's .. which can be computed
>>>in a streaming model for many XPaths ..
>>>
>>>
>>>
>>>
>>hi Sanjiva
>>
>>i think that it is true for verification but not for signing as you need
>>to compute signature: you *can* compute it in a streaming fashion but
>>then you need to put signature in header so you have to buffer whole
>>stream output (why, oh why, there is no footer element in SOAP ...)
>>
>>
>>
>>>Furthermore using WS-Security without WS-Secure Conversation is
>>>retarded (IMO).
>>>
>>>
>>>
>>>
>>there are many cases to consider and each situation is unique.
>>
>>WS-SecConv does not buy you much if you do very coarse grained messaging
>>(only one message sent to service) still the overhead is small enough
>>that may be doable to do WS-SecConv for every message.
>>
>>however there is a potential scalability problem as server needs to
>>remember all those opened sessions so implementation must be very
>>careful here (we did some testing and in one test setup after a thousand
>>or so connections server refused to accept any new connections ...)
>>
>>
>>
>>>In summary, IMO there's no reason why WS-Security/WS-Secure Conversation
>>>have to be any less performant than any other public key security
>>>technology IMO for many cases.
>>>
>>>
>>>
>>yes - if we do have better libs to do efficient
>>streaming/canonicalization/verification/signing and generally avoiding
>>excessive memory usage.
>>
>>
>>
>>>There may be degenerate cases where
>>>it is, but if we can make those rare then we're in business.
>>>
>>>
>>>
>>>
>>that is still to be seen :)
>>
>>currently SSL without keep alive (so it does key exchange each time) is
>>2-5x faster than WS-SecConv after first message (this is just estimate
>>...) and SSL with keep alive (no key exchange so it is comparable to
>>session in WS-SecConv) it is faster by *order of magnitude* than
>>WS-SecConv in what we tested (caveat emperor!)
>>
>>plus with SSL you can easily by hardware accelerator and load balancers
>>that will understand SSL it will take some time before WS-SecConv is
>>real standard and has this kind of support ...
>>
>>we are going to submit a paper (Satoshi did a great work on this) with
>>details on tests to Workshop on Grid Computing (Grid 2004) and hope that
>>it will lead to some discussion and ultimately faster (streaming?) code
>>in future :)
>>
>>thanks,
>>
>>alek
>>
>>--
>>The best way to predict the future is to invent it - Alan Kay
>>
>>
>>
>>
>
>
>
>
--
The best way to predict the future is to invent it - Alan Kay
Re: message/transport level security [Re: SOAP streaming and faults, security everywhere and performanceimplications [Re: opinion Axis' future ... [Re: Using SAAJ-1.2 API tomodify the soap header/body content
Posted by Davanum Srinivas <da...@gmail.com>.
Alek,
Do you have a WS-SecConv impl? (open source?)
-- dims
On Wed, 09 Jun 2004 11:15:58 -0500, Aleksander Slominski
<as...@cs.indiana.edu> wrote:
>
> Sanjiva Weerawarana wrote:
>
> >"Samuel Meder" <me...@mcs.anl.gov> writes:
> >
> >
> >>I completely agree on Alex's point that security (and other QoS aspects)
> >>are very important for us working in the Grid world. It is hard to
> >>justify to users that turning on security will cause a 10x slowdown (it
> >>is actually even worse with larger payloads) and since grid scenarios
> >>are generally multi organization security is a ubiquitous requirement (I
> >>would think that the same is true for B2B scenarios).
> >>
> >>
> >
> >Of course. However, that's a fundamental issue with XML security
> >and not with the WS-* specs in particular. The XML sec stuff is
> >defined in terms of DOMs and DOM hash's .. which can be computed
> >in a streaming model for many XPaths ..
> >
> >
> hi Sanjiva
>
> i think that it is true for verification but not for signing as you need
> to compute signature: you *can* compute it in a streaming fashion but
> then you need to put signature in header so you have to buffer whole
> stream output (why, oh why, there is no footer element in SOAP ...)
>
> >Furthermore using WS-Security without WS-Secure Conversation is
> >retarded (IMO).
> >
> >
> there are many cases to consider and each situation is unique.
>
> WS-SecConv does not buy you much if you do very coarse grained messaging
> (only one message sent to service) still the overhead is small enough
> that may be doable to do WS-SecConv for every message.
>
> however there is a potential scalability problem as server needs to
> remember all those opened sessions so implementation must be very
> careful here (we did some testing and in one test setup after a thousand
> or so connections server refused to accept any new connections ...)
>
> >In summary, IMO there's no reason why WS-Security/WS-Secure Conversation
> >have to be any less performant than any other public key security
> >technology IMO for many cases.
> >
> yes - if we do have better libs to do efficient
> streaming/canonicalization/verification/signing and generally avoiding
> excessive memory usage.
>
> >There may be degenerate cases where
> >it is, but if we can make those rare then we're in business.
> >
> >
> that is still to be seen :)
>
> currently SSL without keep alive (so it does key exchange each time) is
> 2-5x faster than WS-SecConv after first message (this is just estimate
> ...) and SSL with keep alive (no key exchange so it is comparable to
> session in WS-SecConv) it is faster by *order of magnitude* than
> WS-SecConv in what we tested (caveat emperor!)
>
> plus with SSL you can easily by hardware accelerator and load balancers
> that will understand SSL it will take some time before WS-SecConv is
> real standard and has this kind of support ...
>
> we are going to submit a paper (Satoshi did a great work on this) with
> details on tests to Workshop on Grid Computing (Grid 2004) and hope that
> it will lead to some discussion and ultimately faster (streaming?) code
> in future :)
>
> thanks,
>
> alek
>
> --
> The best way to predict the future is to invent it - Alan Kay
>
>
--
Davanum Srinivas - http://webservices.apache.org/~dims/
message/transport level security [Re: SOAP streaming and faults,
security everywhere and performanceimplications [Re: opinion Axis' future
... [Re: Using SAAJ-1.2 API tomodify the soap header/body content
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Sanjiva Weerawarana wrote:
>"Samuel Meder" <me...@mcs.anl.gov> writes:
>
>
>>I completely agree on Alex's point that security (and other QoS aspects)
>>are very important for us working in the Grid world. It is hard to
>>justify to users that turning on security will cause a 10x slowdown (it
>>is actually even worse with larger payloads) and since grid scenarios
>>are generally multi organization security is a ubiquitous requirement (I
>>would think that the same is true for B2B scenarios).
>>
>>
>
>Of course. However, that's a fundamental issue with XML security
>and not with the WS-* specs in particular. The XML sec stuff is
>defined in terms of DOMs and DOM hash's .. which can be computed
>in a streaming model for many XPaths ..
>
>
hi Sanjiva
i think that it is true for verification but not for signing as you need
to compute signature: you *can* compute it in a streaming fashion but
then you need to put signature in header so you have to buffer whole
stream output (why, oh why, there is no footer element in SOAP ...)
>Furthermore using WS-Security without WS-Secure Conversation is
>retarded (IMO).
>
>
there are many cases to consider and each situation is unique.
WS-SecConv does not buy you much if you do very coarse grained messaging
(only one message sent to service) still the overhead is small enough
that may be doable to do WS-SecConv for every message.
however there is a potential scalability problem as server needs to
remember all those opened sessions so implementation must be very
careful here (we did some testing and in one test setup after a thousand
or so connections server refused to accept any new connections ...)
>In summary, IMO there's no reason why WS-Security/WS-Secure Conversation
>have to be any less performant than any other public key security
>technology IMO for many cases.
>
yes - if we do have better libs to do efficient
streaming/canonicalization/verification/signing and generally avoiding
excessive memory usage.
>There may be degenerate cases where
>it is, but if we can make those rare then we're in business.
>
>
that is still to be seen :)
currently SSL without keep alive (so it does key exchange each time) is
2-5x faster than WS-SecConv after first message (this is just estimate
...) and SSL with keep alive (no key exchange so it is comparable to
session in WS-SecConv) it is faster by *order of magnitude* than
WS-SecConv in what we tested (caveat emperor!)
plus with SSL you can easily by hardware accelerator and load balancers
that will understand SSL it will take some time before WS-SecConv is
real standard and has this kind of support ...
we are going to submit a paper (Satoshi did a great work on this) with
details on tests to Workshop on Grid Computing (Grid 2004) and hope that
it will lead to some discussion and ultimately faster (streaming?) code
in future :)
thanks,
alek
--
The best way to predict the future is to invent it - Alan Kay
Re: SOAP streaming and faults, security everywhere and performanceimplications [Re: opinion Axis' future ... [Re: Using SAAJ-1.2 API tomodify the soap header/body content
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
"Samuel Meder" <me...@mcs.anl.gov> writes:
> I completely agree on Alex's point that security (and other QoS aspects)
> are very important for us working in the Grid world. It is hard to
> justify to users that turning on security will cause a 10x slowdown (it
> is actually even worse with larger payloads) and since grid scenarios
> are generally multi organization security is a ubiquitous requirement (I
> would think that the same is true for B2B scenarios).
Of course. However, that's a fundamental issue with XML security
and not with the WS-* specs in particular. The XML sec stuff is
defined in terms of DOMs and DOM hash's .. which can be computed
in a streaming model for many XPaths ..
Furthermore using WS-Security without WS-Secure Conversation is
retarded (IMO).
In summary, IMO there's no reason why WS-Security/WS-Secure Conversation
have to be any less performant than any other public key security
technology IMO for many cases. There may be degenerate cases where
it is, but if we can make those rare then we're in business.
Sanjiva.