Steve Loughran wrote:
I've come across a similar problem in the context of amendments (writes) to citizen data held by government. Unless you can coordinate agreemement at the application level that a client won't send a new amendment until the previous one was acknowledged and/or written, amendments are stateful because they need to be applied in order. At minimum this requires integer sequencing (agree on an offset!) a reference to the resource being amended, and the identity of the writer (if there are >1 writers). A correlation id or nested correlation ids held across the set of amendments might be useful for auditing purposes, but these aren't neccessary for data safety, nor is a session. Additionally, writes could also require application level acknowledgements that they will be applied and possibly that they have been applied if the writes are highly asynchronous (say if you had a service window). All this is somewhat incidental to session binding unless the session's semantics guarantee calls will be not be applied out of order (for example weird things might happen in Java with the OPs call sequence given Java's semantics).think about this for a moment. How are you going to specify bank account and auth info? If it goes with every request, then you could be stateless. Otherwise the caller needs to first 'bind' to an account, then make requests on it. We call that 'state', no matter how it is actually implemented.
Dates are flaky, unless your SOAP nodes are synchronized on the same timeserver or there's a human involved, or there's only one client (and maybe even then things will be unsound). They might be helpful for auditing purposes. You could use a logical clock, if that was agreed on beforehand (logical clock semantics for multiple writers are well understood).* the getbalance call includes not just the balance, but the time that balance was valid. I'd use xsd:long containg time_t in GMT, for that, as xsd:dateTime always causes problems for me wrt timezones.
Bill de hÓra
