2008/11/25 Mark Baker <[EMAIL PROTECTED]>: > On Tue, Nov 25, 2008 at 4:05 AM, Steve Jones <[EMAIL PROTECTED]> wrote: >> 2008/11/24 Mark Baker <[EMAIL PROTECTED]>: >>> On Mon, Nov 24, 2008 at 11:45 AM, Steve Jones <[EMAIL PROTECTED]> >>> wrote: >>>> A little bit pie in the sky here, nice in theory but a killer in >>>> practice >>>> >>>> So as an example. >>>> >>>> Imagine a message about a prisoner requesting a specific training class. >>>> >>>> The message would have to include >>> >>> No, it wouldn't. The author is talking about stateless messaging - >>> though it's a little difficult to tell - and all that requires is that >>> the message contain all the information needed to understand its >>> meaning. If the sender doesn't want the message to communicate why >>> the prisoner is behind bars, then they shouldn't include it. If they >>> do, then they should. It's just that simple. >> >> Which makes it redundant from an archival perspective as it just >> includes the message which says A-B happens. > > Archival for what purposes? I think it's completely suitable to > archive the message as evidence of the information some other party > sent to you. It might, for example, have been the first message > submitted as part of some business process and so be needed in the > future in case there's any legal issues.
Sorry I should have been more clear, I meant archival from the perspective of recreating the RWE. Clearly its okay from an Audit perspective. > >> This can be a reasonable >> approach (although I'd still recommend references, sending a URI for >> instance if using REST). You end up with a view of the messages >> (execution context from an RM perspective) but not the broader service >> interaction (policy, etc). > > Sending references is, of course, also of great value. But from the > point of view of the article which motivated this thread, I believe > what the author was trying to say - similar to my blog post - is that > if the sender wants the message to convey certain information, that > information needs to be in the message itself, not referenced. You > would include references only when the reference itself is what you > want to communicate, not whatever value the reference currently > dereferences to. > > For example, if I wanted to send a (separate) message to tell you what > time I sent this email, this wouldn't be a very good way to do it > (although it is 100% accurate at the moment I hit "Send"); > > <time>http://www.timeanddate.com/worldclock/city.html?n=188</time> Ah temporalisation what a wonderful challenge it presents us with. Part of the piece here though is that something like Time is pretty much defined (Quantum and Relativistic issues aside) so its syntax and semantics are unlikely to change over time. If you start adding customer into the mix then you get the old issues of schema evolution and management. Hence the reason for something like customer I'd be more inclined to just do either a key passing (SOAP) or URI passing (REST) as if the customer changes some information (e.g. moves house) then actually I want to know the latest information in my order not just what it happened to be at the time of the event. This is an area that I tend to see people completely ignore when looking at complex systems, the temporal (geo and time) nature of certain capabilities. > > Since you mentioned archival, IMO, archival of stateful messages is > pointless, because it means that the meaning of the message can change > over time as a function of the state of some database someplace (which > isn't archived). Agreed. This was my understanding of what Jack was saying around future consumers. Steve > >>> I wrote a blog post last year on some of the subtleties of stateless & >>> self-descriptive messaging; >>> >>> http://www.markbaker.ca/blog/2007/11/users-and-self-description/ >> >> Interesting post. > > Thanks. > > Mark. >
