I'll try and explain my original concern, although I'm pretty certain after reading your mail that it is actually of no concern. I was worried that someone could read the RP document while it was half-way through being written. I was thinking in terms of a chunk of memory being written by one thread, as another tries a read. But from what you say, i.e. that the results will be valid according to the schema, this is clearly not an issue. Given that updates to the component parts of an RP are atomic in some sense, I'm not aware of any coherence issues in the current WS-Agreement spec. Which is I guess what the comment from the telecon was saying also. Thanks for the clarification... Jon. On Mar 1, 2005, at 8:51 AM, Karl Czajkowski wrote:
I am not sure that I am following this concern, but to my knowledge WS-ResourceProperties does not define any coherency or consistency among resource properties. It only states that query results will be valid according to the schema. This is not about "writers" but about dynamic RP documents and the possible lack of synchronization in constructing the RP elements in query results. (WS-RF tries to be lenient about what infrastructure is required to implement the basic facilities.)
I think the best approach would be to define RPs that are meaningful in isolation from one another and only loosely associated with each other via their association to the resource identity; dynamic values that have temporal associations should probably be part of one RP element rather than spread across several. I do not think there is anything risky about stating that a particular RP will be updated coherently (coherence amongs its attributes and subelements).
A particular specification could add requirements, but of course this might restrict the WSRF tooling environments that are capable of hosting the standard. Also, I would be concerned if we required strong consistency and didn't make it so that a WS-Agreement environment would degrade gracefully if the consistency were violated; for example, references across terms could use temporally unique IDs for dynamic elements so that a consumer could detect a dangling reference rather than making an incorrect dereference. I suppose you could call this an implementation detail, but I would like to think we could encourage or even mandate some hygiene...
Can someone explain concisely what the consistency hazard is that has been raised?
karl
On Feb 28, Jon MacLaren loaded a tape reading:
Issue 13: The only thing that can change is the term states because there is no updates. So, there is no concern for consistency, and no need for consistent updates. **Action: Respond that we don't think this is a concern in the follow up. **Jim will add the comment to the tracker.
Just to clarify... I realise that no external parties able to update the monitoring information. However, the service/resource is changing state - is this state change any different from an external writer? I wasn't sure that WS-RF would guarantee the user sees a consistent state at these times - I thought you only needed one writer and one reader for consistency problems here.
Maybe someone who knows WS-RF better than me can clarify this.
Jon.
-- Karl Czajkowski karlcz@univa.com