Thanks for the feedback Sara. > 1. Are we still going for service level scope for this ie all the operations > on a service? My understanding is that the way this is written piggybacks off the existing RMAssertion, which allows on a per message or per service basis. I think the main point is that this makes sense in the scope of any sequence, and should therefore match the semantics for sequences.
> 2. You previously wanted to allow this to be turned on/off for request and > responses to imitate the pattern in MQ or JMS to have a temporary > reply to a persistent message. Is that still the plan? Yes I'd still like to make this possible to have a persistent out with non-persistent responses, since that is a common pattern in messaging. > 3. Adding a policy assertion cannot guarantee the messages are written to > disk. It means that this is the intention, but this is different to adding > security headers to messages for example, which would be verifiable by the > message. The client has to trust the server to do what it says and vice > versa which is ok but we should be clear about this. but, to split some > more hairs, are we abusing policy in some way by adding this kind of > assertion that can't be verified? The assertion that the RMD only accepts messages that have the same security token as the initial sender is similar. You can test it by breaking it, but its really an assertion of the internal behaviour of the system. Even more so, the delivery assurances are not testable from the other end. So I don't think this goes beyond the usage of policy we have already defined. > 4. How are we defining persistent? Paul you referred to XA spec which from > a quick scan frequently assumes a database or file system as the storage but > this was written in pre-historic times. Do we need to define what we mean > by persistent, ie kinds (database or file system), recoverability quality > (after server failure, time based). This becomes a rabbit warren to start > down, but makes point 3 more important as if we can't define what we require > when someone says they are persistent, then users of this can't be certain > what they are getting when they add the xml to their message. This could > then be seen as overhead on the message that adds limited value? I think it might be nice to define persistent in some "quality of service terms". In other words this should support restart after failure, and acknowledgements should positively indicate that the message has been persisted. So rather than define the mechanics, it would be better to define the behaviour: if the RMS is persistent, then a Nack will *always* cause a resend of the missing message, even if the client has restarted. If the RMD is persistent, the system will *always* deliver any acknowledged message, even when there has been a system restart. However, I don't want to go too far. I know the XA spec was written in pre-historic times, but the main point I was making was that they didn't feel the need to go into too much detail about the mechanisms. > > I don't want to be a nay-sayer here .. I think persistent RM is valuable. I > just want to make sure we aren't adding something because we can, rather > than because we need to. +1 > > thanks, > Sara > > > > -- Paul Fremantle Co-Founder and CTO, WSO2 Apache Synapse PMC Chair OASIS WS-RX TC Co-chair blog: http://pzf.fremantle.org [email protected] "Oxygenating the Web Service Platform", www.wso2.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
