Request Processing State Digest Events (Action Item #31)
Context
We have definitions for notification events for changes in Request
Processing state (MOWS). We would like to have the ability to send a
digest per request.
Basic Proposal
We extend our currently defined MOWS event topics to include
RequestStateDigest [sub] topics. These will cause a single message to
be sent when a request's processing reaches the termination state. The
termination state is generally defined to be either
RequestCompletedState or RequestFailedState, although some other
mechanisms [non-standard] such as timeout may be included as well.
That is, a compliant system MAY send a digest notification under other
circumstances.
Details
- We add new subtopics to mows-events:{RequestProcessingObservation,
RequestProcessObservationWithAttachments} in the
ManageableEndpoint
topic space. These topics, namely RequestProcessingStateDigest
(under both topics) indicate that the subscriber is interested in
digest information about message processing state.
- Add new type: StateTransition
<StateTransition Time="xs:dateTime">
<EnteredState>RequestProcessingStateType</EnteredState>
<PreviousState>RequestProcessingStateType</PreviousState>?
</StateTransition>
This moves the time down a level, but allows consistency
for the digest case. Also, it might allow for a time both on the
RequestProcessingNotication (whose time might indicate the time of the
notification) to be different from that of the transition itself
(delay, whatever). Both could be useful. The outer time indicator (RequestProcessingNotification/@Time)
becomes optional.
- The <RequestProcessingNotification/>
message [type] changes to include a sequence of <StateTranstion/>
elements instead of the states themselves as currently
defined. Semantically, the topic about which the subscription is made
determines the cardinality of this sequence. That is, subscriptions
for individual states will always have cardinality of 1, while those
for the digest will have a cardinality of at least 1.
Discussion/Comments
- In a digest message, the previous state of a StateTransition
sequence member will usually be a duplicate of the previous members
entered state. However, there may be circumstances in which this
happens (e.g. some state is "lost" -- meaning not observed --
and one would still like an implementation to be able to report what it
knows).
- From an aesthetics standpoint, it is "strange" to have a
single topic (e.g. RequestProcessingObservations) with one set
of subtopics that are the observed states and another subtopic that is
a specification of the mechanism by which the report is to be made.
The benefit here is that we have exactly one notification message type.
Should we decide that the aesthetic issue is valid, the alternative is
as follows
- We define the new StateTransition type as above.
- For consistency, we change the <RequestProcessingNotification/>
message to include a single <StateTransition/>
element, replacing the <EnteredState/>...<PreviousState/>
pair.
- We add two new topics, mows-events:{RequestProcessingDigest,
RequestProcessDigestWithAttachments} in the ManageableEndpoint
topic space. These [currently] have no subtopics.
- We add a <RequestProcessingDigestNotification/>
message [type] which includes a sequence of <StateTransition/>
elements (instead of the single element as in the <RequestProcessingNotification/>
element. This message type is otherwise a duplicate of the <RequestProcessingNotification/>
message type.
I don't know that I have a strong feeling between these two. Having a
single message type/format is handier for the subscribees to deal
with. However, the topic collection is surprising and requires some
amount of rationalization.
--- End of Proposal ---
If there's time, we can discuss this at the F2F. I'll be traveling
most of tomorrow but comments are welcome. I may see them before the
F2F, maybe not (depends on internet @ hotel, actual arrival
time, etc.).
--
Fred Carter / AmberPoint, Inc.
mailto:fred.carter@amberpoint.com
tel:+1.510.433.6525 fax:+1.510.663.6301
|