This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
WS-Management v1.1 [1] Section 10.2.9.4 defines a Batched Delivery Mode in which multiple events are bundled into a single notification. WS-Man notes: "Batching events is an effective way to minimize event traffic from a high-volume event source without sacrificing event timeliness." It is the opinion of the WS-Man WG that this feature is sufficiently general as to warrant inclusion in the base specification. The WS-Man WG requests that the WS-RA WG incorporate this extension as an optional feature of WS-Eventing. [1] http://www.dmtf.org/standards/published_documents/DSP0226_1.1.pdf --- Proposal: 1. Define a new wrapper element that contains a sequence of wse:EventType. 2. Define a new abstract WSDL, similar to that in Appendix D of WS-Eventing, that describes the interface that the Event Sink must implement to receive Batched Notifications. It should define a message with the type described in (1) and a one-way operation that accepts this message as its input. This operation should be assigned a wsam:Action of http://www.w3.org/2002/ws/ra/edcopies/ws-evt/BatchedSinkPortType/NotifyEvent. 3. Define a new delivery format with the URI http://www.w3.org/2002/ws/ra/edcopies/ws-evt/DeliveryFormats/Batched that indicates the use of the above.
Gil, Some comments on the proposal points: On 1: This would rule out event source using Notification WSDL to advertise event structures as defined in Appendix A.2. On 2: It seems that 1 and 2 can be covered by the current Wrapped WSDL defined Appendix D. Assume the event structures (event-i) are advertised according to Appendix A, then batched events can be delivered as a sequence of child elements of wse:Notify: <wse:Notify> <ns1:event-1>...</ns1:event-1> <ns2:event-2>...</ns2:event-2> ... </wse:Notify> Therefore, current WS-E may support 1 and 2 without change by wrapped delivery format. On 3: If the batched delivery can be handled by wrapped format, then the subscriber can use the standard Wrapped URI in the subscribe request. Moreover, introducing new batched delivery format URI requires to define the subscriber/event source behavior associated with it. However, we think the behavior of event batching is highly service dependent, for example, deadline based or frequency based batching rules, etc. Therefore, it seem better to leave it to the extension services. Wu, Li
Response issue 9611 WS-Man batched delivery format The WS-RA WG discussed the comment from WS-Man on the batched delivery format in the F2F meeting. The current WS-E specs allow delivery of multiple events with the same action URL in one wrapped format event delivery. Beyond that, the group feels: the behavior of event batching is service and domain dependent, and various batching rules can be applied, e.g. deadline based, frequency based, and special trigger based batching, to just name a few. The protocol behavior on how to handle multiple types of events in one batched format event delivery requires to be fully specified for the targeted applications. Therefore, it is more appropriate to leave it as extension services. After the consideration, the WG decides to close this issue with no action.
Response issue 9611 WS-Man batched delivery format The WS-RA WG discussed the comment from WS-Man on the batched delivery format in the F2F meeting. The behavior of event batching is service and domain dependent, and various batching rules can be applied, e.g. deadline based, frequency based, and special trigger based batching, to just name a few. The protocol behavior on how to handle multiple types of events in one batched format event delivery requires to be fully specified for the targeted applications. Therefore, it is more appropriate to leave it as extension services. After the consideration, the WG decides to close this issue with no action.
Reviewer Satisfied http://lists.w3.org/Archives/Public/public-ws-resource-access/2010May/0056.html