Re: Support WS-Management's heartbeat events

The WS-RA WG reviewed your issue on "Eventing: Support WS-Management's 
heartbeat events" [1] on May 11th [2], 12th [3], and 13th [4]  2010, 
during its face to face meeting. After extensive discussion and several 
proposals, the WG agreed to resolve this issue by changing  the 
WS-Eventing specification in the following manner:

   1. Add a wse:Verify element to the wse:GetStatus message. This
      element is described as follows:

    This OPTIONAL element can be used by the subscriber in its GetStatus
    request to ask the subscription manager to verify that notifications
    can be transmitted from the event source to the event sink.
    Conformant subscription managers MAY elect not to perform the
    requested verification.

    If the subscription manager opts to support the wse:Verify request,
    it MUST include a wse:VerificationInitiated element in its GetStatus
    response, and it MUST cause the event source to transmit a single
    notification, containing a single verification event (defined in
    Appendix B), from the event source to the event sink using the
    delivery method and format in effect for this subscription. Any
    filters in effect for the subscription MUST NOT be applied to this
    notification.

   2. Add a wse:VerificationInitiated element to the
      wse:GetStatusResponse message. This element is described as follows:

    The presence of this OPTIONAL element in the GetStatusResponse
    indicates that the subscription manager has honored the verification
    request. This element MUST NOT appear in the GetStatusResponse
    unless the corresponding GetStatus request contained the wse:Verify
    element. The absence of this element in a GetStatusResponse
    indicates that verification was not initiated.

    Note, the relative timing of the verification and the
    GetStatusResponse message is unconstrained by this specification.
    The presence of the wse:VerificationInitiated element in a
    GetStatusResponse message does not indicate the success of the
    verification

   3. Add an Appendix B that describes the verification event using both
      an EventDescriptions document and a Notification WSDL.

The following points motivated the design of these changes:

   1. There are scalability issues inherent in the use of heartbeats as
      they are defined by WS-Man v1.1. The fact that heartbeats are
      essentially "set and forget" and continue automatically until the
      subscription dies creates a situation in which it is easy to
      unintentionally bog down the event source and/or flood the network
      with heartbeat notifications.
   2. It is a relatively complex matter to negotiate the heartbeat
      interval. What is the event source willing to support and how is
      this advertised? What is the subscriber willing to accept and how
      is should this be represented? How strict are either parties
      requirements?
   3. Allowing the subscriber to request the transmission of a single
      "verification event" solves the underlying use case (how can the
      event sink determine whether the event source is capable of
      transmitting notifications to it) without creating the problems
      described in (1) and (2).

Please indicate via an email response to the WS-RA public comment list 
[5] as to whether this resolution of your issue is satisfactory.

[1]http://www.w3.org/Bugs/Public/show_bug.cgi?id=9610

[2]http://www.w3.org/2002/ws/ra/10/05/2010-05-11.html

[3]http://www.w3.org/2002/ws/ra/10/05/2010-05-12.html

[4]  http://www.w3.org/2002/ws/ra/10/05/2010-05-13.html

[5]mailto:public-ws-resource-access-comments@w3.org