GetCurrentMessage

[David Hull <dmh@tibco.com>]

I would be interested to know the original driving use cases for GetCurrentMessage.  To my mind, there are basically two, and it may not come as a surprise that I'm going to argue neither of them is central to notification.

Case 1: Incremental Updates.  Suppose the current state of some device is represented by a fairly large record.  Most of that record changes seldom, but some of it changes quite frequently.  To contrive an example, suppose we are monitoring the state of an automated factory floor.  Each machine involved may carry quite a bit of state -- various status indicators, configuration regarding what task it's performing, whatever, but in practice we hope to see little more than a steady rise in the "widgets produced" indicator.

In this case, it might be most efficient to publish only the changes in the machine's state, and rely on some out-of-band mechanism to establish the entire state.  That is, the monitor would subscribe to updates, query the full current state once, and then apply the incoming stream of updates to its cache of the entire state.  There are technical issues with this approach, to do with the form of updates and a possible race between the query and the updates, but these are solvable, and the approach can work in practice.

In this case, GetCurrentMessage is of limited use, as it will only give the latest change to the state, not the actual state.

Case 2: Infrequent Updates.  I believe this was the original driver, but I may be wrong.  Living in North Carolina, I would like to be aware of hurricane conditions in the Caribbean and Atlantic.  The NOAA publishes bulletins on active  tropical storms every six hours, with more frequent updates as large storms approach populated areas.  If I were able to subscribe to such updates, I would rather not wait until the next bulletin -- I'd like to get the latest bulletin now, and then hear about new ones as they come in.

Note that this is technically a special case of Case 1 -- the updates are essentially the entire state -- and the same conceptual model works.  The GetCurrentMessage operation is independent of creating a subscription, as GCM is associated with a topic and not a particular notification stream.  I can do it as many times as I want, whether I have a subscription open or not.  From this point of view, GCM is the "out-of-band mechanism" from Case 1.  There are only two things special about it: We have associated Subscribe and GCM in the same port type, which to me is incidental, and we have associated Subscribe and GCM through the use of topics, which to me may or may not be incidental.

Describing the linkage between Subscribe and GCM solely in terms of topics and notifications seems difficult.  The semantic is essentially "This is the message you would have got if you had subscribed before the previous update, if any, whenever it was."  Not what I'd call "crisp."  You could say "This is the last message published on this topic," but for at least some use cases (e.g., the WS interface to a legacy notification system) publishers are explicitly out of scope.  Not surprisingly, the operation makes much more sense in the context of stateful resources: "This is the current state of the resource associated with this topic."

But from Case 1, we see that the connection between resources and notifications may not be trivial.  I'm not saying that incremental updates are rocket science, just that they're not trivial, and that there may be other non-trivial approaches to synchronizing state with a consumer of notifications.  To me, this argues that GCM is orthogonal to the core concepts of notification.  I realize it's not orthogonal to the core concepts of WSRF.  This comes back to the central contention the space of possibilities for WSN is at least as large as that of  WSRF, and probably larger.

As it is, GCM seems like an 80/20 rule convenience added to the basic subscription operations.  Nice, perhaps, but not central, and certainly not worth renaming central architectural concepts.