Hi Dan,

The reason for going this kind of a model is persisting the message at the end of the handler chain. If we persisted the message at the middle of the chain we would have had to vertually persist the message context completely (most probably properties from other contexts as well). But by persisting it at the end of the handler chain, we can simply persist the SOAP envelop which seems to be a much cleaner approach.
But the problem you mention is there. When security encryption or signing is enabled, the Sender will not be able to work correctly.

Here is one workaround I see. It should be possible to mark some phases (or handlers) as post-persist. Those will be invoked only after persistence, and they will be called in each retransmission. So the users can mark security handlers as post-persist. Encryption and signing will happen in every retransmission (probably SOAP envelopes will have to be cloned before doing this). Also some security properties set by the client may have to be persisted as well.
So, yes we do not support thie scenario at the moment. But we will soon :-)

Thanks,
Chamikara






On 3/2/06, Daniel Millwood <[EMAIL PROTECTED] > wrote:




Hi,

In an earlier post to the list, Ruchith stated that in his opinion, the
security handler should be the last to run when sending a message.  This
would enable the WSRM Sequence Header (SequenceId and SequenceNumber) to be
added to the message and signed so it couldnt be tampered with.

If Ive understood the client side code correctly, messages run through all
the handlers once, and are assigned to the Sandesha2 Sender thread, which
then directly invokes the messages TransportSender to send each outbound
message 1 or more times. While the messages are assigned to the Sender
thread, they could be updated with a real sequence id, but this will happen
after the security handler has run, so the WSRM Sequence Headers cannot be
signed.

Is my understanding correct?

Thanks,  Dan


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Reply via email to