Issue-9610 Eventing: Support WS-Management's heartbeat events http://www.w3.org/Bugs/Public/show_bug.cgi?id=9610

Thanks Bob for the suggestion of the approach A3 (i.e. option b) . We
did some study to see how this applies to WS-E and we share our thoughts
below.

A1. " heartbeat event" is a type of "alive event", and it will be
referred thereafter.

A2. Receiving "alive event" in WS-E (WS-Eventing) means both event
subscription and event delivery channel (from event source to event
sink) are alive.

A3. (No Change to WS-E) -  A3 is option (b) from Bob, i.e. domain
defined event type that could be subscribed / filter. But (b) is also
another version of (f) (close without action and kill current verify) as
elaborated below.

Under WS-E, alive event can be treated as one type of event that an
event source will generate and deliver (e.g. same as WindReport). An
event source can declaratively indicate this pseudo alive event type in
its Notification WSDL or EventDescription. 

This special type of pseudo event can be published according to the
Appendix B of WS-E. For example a notification WSDL of the event source
(EPR) can contain application specific event type operations, e.g.
<wsdl:operation name="WindReportOp">, as well as a special event type
operation <wsdl:operation name="EventAliveReportOp"> for the alive
event.

WS-E specifies a standard filtering mechanism for event subscriber to
describe which subset of events to be delivered to the event sink.
Specifically, WS-E [1] recommends using of X-Path 1.0 and 2.0 for
filtering, both of which supports 'path-A or path-B' expressions, such
that filtering multiple events can be expressed. 

For example, assuming the event source generates two types of events,
WindReport and EventAliveReport, a subscriber can use filter to indicate
if both WindReport and EventAliveReport must be delivered as oppose to
only WindReport events should be delivered in its event subscription. 

This framework in WS-E is generic and agnostic to transport protocols.
It is a standard mechanism and can support other QoS events associated
with the event source (EPR) as well.

The only concern is that X-Path might be slow. But this is an
implementation issue and event source can use its own dialect and
algorithm to do the same thing at a much faster speed.

As such, an event source can determine its own frequency of the
periodically sending pseudo alive events (something similar to the
default TCP keep-alive) to report the event is alive, that can depend on
the event source resources and needs/constraints of the application.

Summary: No change to WS-E protocol  (another version of cwna & kill
current verify) 

A4. (add an optional EventAliveReport operation) -  A4 is A3 with an
optional operation EventAliveReport for event source to include the
alive event if needed.

WS-E may choose to define an optional operation, EventAliveReport, for
the periodically emitting pseudo event of alive, e.g. <wsdl:operation
name="EventAliveReportOp">, whose message schema can be
"wse:VerificationEventType", etc. It may even include an attribute,
RepeatPeriod, e.g. in <VerificationInilized RepeatPeriod = "5s" ...>,
for event source to publish its alive event  emitting frequency.

As such, the Qname, schema, and its periodic  emitting  behavior are
standardized. It has the benefit that each event source can use it
directly without re-invent /define  the Qname, schema, and delivery
behavior specification, etc.  for support the alive event in its
offering. It is closer to the heartbeat pseudo event of WS-Man as it is
a signatured operation and it offers an opportunity to allow
applications to profile/include it to become a required common feature. 

No matter A3 or A4 are considered, they both have following distinct
advantages:

1)     No change to WS-E protocol, e.g. no changes to Subscribe,
Unsubscribe, GetStatus, Renew.

2)     Alive event type is declaratively specified in the event source
Notification WSDL or EventDescription. 

3)  No constant polling of the event source in the option of using
GetStatus for heartbeat (or alive).

Comparing to heartbeat pseudo event in WS-Man, it differs only in that
the subscriber (client) cannot arbitrarily change the delivery frequency
of these pseudo alive events.  Our feeling at this moment is: such
flexibility and related negotiation mechanism should be more appropriate
for future QoS extensions of WS-E, but  may not  be  for the base
protocol of WS-E. 

Thanks,

- Wu Chou/Li Li