SOAR-ity is intended to allow for "reliable" (this term is almost always a misnomer) messaging over HTTP. It achieves this goal by introducing two new request headers, MID which provides a unique ID for a message and MsgCreate which contains the date and time on which the first instance of the message with the associated MID was sent. The purpose of the MID/MsgCreate pair is to allow any HTTP request (e.g. any HTTP method can be used) to be repeated multiple times with a guarantee that the message will be processed no more than one time. In essence it makes any HTTP method call idempotent.
The SOA-Rity specification is now available as an Internet Draft. Below I provide links to different versions of the draft that are hosted locally so as to ensure accessibility if the draft should expire.:
- a text version,
- a HTML version,
- the XML source – I used XML2RFC to generate the text and Julian's XSLT translator for the HTML version and
-
the DTD – I made the organization element optional under author element to get rid of validation errors
I'd also like to take this opportunity to say that the Oxygen editor ROCKS! Make sure to check out their 'academic licenses' which are actually just for personal use in case you can't justify buying Oxygen for your job.
simple is beautiful :-)
I still think you need sender and receiver to agree on the time window. It’s no more complicated than negotiating protocol version or accepted content. By accepting the sender’s window, the receiver is merely communicating that it has no issue holding identifiers for that length of time.
I would prefer sender and receiver to negotiate this at run-time, but as we all know, someone plays with the configuration, 5 hours become 5 minutes, and all of a sudden sender assumptions are no longer valid.
I’d much rather see the receiver reject messages then agree to process on different terms.
I don’t see the real harm if the windows are different. But I do see very real harm if a transaction fails just because of a window difference.
For example, let’s say the sender is expecting a 5 hour window and the receiver is using a 5 minute window. The absolute worst case is that if a message fails (already an unlikely event) and the sender repeats it, after, say 10 minutes then all that will happen is the receiver will automatically reject the repeat for being outside the time window. So sure, someone gets notified, there is an investigation and a change is made. But meanwhile the other 99.9% of messages that worked just fine on the first try and so never really needed reliable messaging will go through without a problem.
Now compare the opposite situation. The client sends in a request for 5 hours, the server says “I’m only going to give you 5 minutes” and now all communication is dead including the 99.9% of messages that would have transmitted just fine while everyone argues over the right number.
I think in practice most folks will have a rough idea of what the time window will be for a service (and anyway it should be listed in human readable terms in the OPTIONS response) and relatively small mismatches won’t cause much damage. So I’d rather err on the side of making things simpler and more robust by omitting the time window negotiation or even declaration until the evidence requiring its use is overwhelming.
You should definitely consider submitting this to IETF. The IETF ATOM Publishing Protocol is trying to do something similar (see http://www.intertwingly.net/wiki/pie/PaceGenericTitleAndId) although your analysis of the problems seems more developed.
Yeah, I looked at the ATOM issue and just adding a message ID won’t do it. This is actually the second reliable messaging system i’ve designed so I’ve been through this before. The FI header (or equivalent) really is an important aspect. Is there anyone in the ATOM world I should work with on discussing the issues and how SOARity can be submitted as a way to solve their problem?
On second thought, I think you’re right and this doesn’t belong in the protocol.
I do have a use case where the sender has a known recovery window, and doesn’t want to talk to the receiver unless the time window is at least as long. But I can solve that at the URL level, without adding another layer of complexity to the protocol.
Re: xml2rfc
I think specifying an empty organization element will make xml2rfc do what you want.
(you may also want to try http://greenbytes.de/tech/webdav/rfc2629xslt.zip for generating HTML)
Best regards, Julian
Julian, yeah, using an empty organization element would have worked perfectly. But it meant a ton of extra typing for me. I would have to turn the 26 author elements in the bibliography from a simple element with attributes to an element with an empty child. It was just too much typing!
I used your XSLT transform and it is much prettier than XMLToRFC’s HTML transform. But it does have two problems:
#1 – The appendix entries don’t show up in the TOC
#2 – The artwork examples all seem to add in an extra space on the first line.
I also wish that the transform would render lists more tightly (XML2RFC has the same problem). All that white space and extra lines makes the IANA Considerations section difficult to read.
But these are nits. It’s great work and I’m changing the HTML file on the website to use your example.
Yaron,
thanks.
#1 – “appendix” currently is sort-of deprecated in xml2rfc (I think the DTD doesn’t even allow it) — just use “section” elements in the “back” section and everything should be fine.
#2 – I currently don’t see a problem with whitespace in artwork, but maybe this is because you worked around it already; please send details and I’ll try to enhance the XSLT.
Rendering lists is indeed problematic. Are you looking for something similar to what the deprecated “compact” attribute on HTML lists does?
Best regards, Julian
Julian,
#1 – D’Oh!!! I didn’t even realize I could put the section in back. I changed appendix to ‘section’, put it into the back element and voila, beautiful output.
#2 – The whitespace is my fault. Sorry. BTW, the ‘length’ check on artwork is VERY nice! I just wish it could include a standard message that says “max length = 78 characters” (or whatever it is).
#3 – Yes, I exactly want what the compact attribute did. Compare the IANA Considerations section of the HTML draft to the Text draft (both linked at the top of this page). The HTML draft is nearly unreadable while the text draft is clear.
But in any case thank you for your XSLT!
With docbook i know one has to use simplepara instead of para in unnumbered lists to make them render without empty lines, dont know about xml2rfc
XML2RFC though does a great job because it still supports the compact attribute. What I’m looking for is to get equivalent support in your XSLT script for generating HTML. Is there anyway to do that with your XSLT?
Hi Yaron,
generating proper HTML lists from rfc2629 source is definitively non-trivial. I’ll have a look at what exactly xml2rfc does in presence/absence of the compact attribute and see what I can do.
Best regards, Julian