OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsdm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Request Processing State Digest Events (Action Item #31)

Request Processing State Digest Events (Action Item #31)


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.


  • 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">
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.


  1. 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).
  2. 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.

tel:+1.510.433.6525 fax:+1.510.663.6301

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]