All Things Distributed

WS-Eventing Feedback

I was going over my notes from the ws-eventing workshop at Tibco last week, and condensed them down to a list of items that I thought were the topics/changes that people cared about. Given that documents such as minutes, etc. are not accessible unless you sign the ws-agreement, I would like to publicly post my recollection of the meeting. This list is not necessarily congruent with the general consensus of the workshop participants. Jorgen already posted some general remarks about the attendance at the workshop.

• The required use of ws-addressing. The proposed use of ws-addressing has a few people worried. Not so much in the subscription request body, but requiring the header to carry wsa:SendTo and wsa:To puts extra requirements/limitations on the bindings that can be used.
• Composability of ws-addressing. This is a more general issue with using multiple layers that each use wsa, are there any assurances that each of these layers will use the wsa elements in an identical semantic fashion?
• Time. There was quite a bit of discussion of absolute time and duration specifications, and what exact semantics operations will have (e.g. does renew(duration), extend you existing subscription or create a new starting point). How to deal with devices that can only handle one type of spec (e.g. don't have a rt clock).
• Load management. There was discussion about whether there should be facilities in terms of API or message attributes that assist load management of intermediaries/brokers and publishers. Priorities, time-to-live, drop policies, a rate policy/contract, etc. I believe that non of these will make  this into the spec. The specs deals with the minimalist form of asynchronous event delivery, and load control is outside of that scope.
• Flow control. This is of course a technique to get a grip on load management, but I believe it has a wider application area as flow control can also be seen as end-to-end mechanism, which plays an important role in reliable delivery of events. I don't think many people got very excited about this issue (except me and maybe the guys from  KnowNow).
• Formal Semantics. Is Renew with a 0 duration the same as an unsubscribe? Does subscribe with a 0 duration give you a single shot of the publisher's state?
• Event Message. it is important to deliver a RAW event to an endpoint, as it is in the spec now, but should there be a second possibility for encapsulating the event in a Event Message structure, that could carry additional information about the event? The counter argument is that under SOAP you stick these extra properties in the header and do not invent a message-inside-a-message format.
• Boxcarring. Of course the previous problem immediately brings up the issue of boxcarring, how to stick multiple bodies (in this case events) in a single message, given that you want to place their metadata in the header. There was no desire to fix this as it is seen as a larger SOAP problem. People were hoping for a sort of ws-boxcarring spec to solve this in a more general sense.
• Reliability. Can a reliable message transfer provide all the ordering and reliability guarantees we need? How do the sinks find out whether sources have failed? Should a heartbeat mechanism be available? I believe a number of these can be addressed by having the subscription carry some policy requests (I can handle up to x messages/sec, please send a null event every 60 seconds, if there are no events to publish, etc.). Or draw on the reliability layers to provide you with this info. I guess nobody has read the Service Tracking paper for more thoughts on failure detection...
• Crash behavior. What is the behavior under crash scenarios, should subscriptions be persistent at the publisher? There was a request for an API extension that would allow the sinks to probe for the subscriptions that it is part of.
• Unsollicited event delivery. Given that 3rd parties can subscribe endpoint to an event stream, there was discussion about what access control policies would be appropriate to avoid spam events.

Overall the workshop was rather productive, I was impressed with how quickly all the issues with such a relatively simple spec came on the table. I can image that the feedback-workshop for ws-notification would need a few more days to get through that spec.

I don't think there will be another feedback workshop on this spec. There is sufficient clarity now to start building prototypes and get ready for interop testing.