Currently, consumers use a subscription-end notification to determine when a provider has finished delivering the available history notifications. Suggested adding a LastReport attribute to the ChangeSequenceReportType as well.
From discussion at plug-a-thon 18:
- no strong dissenting views, though it was noted this may not be strictly necessary as consumers can figure out when the history service has finished by listening for optional
EndTo notifications, or processing wse:UnableToRenew faults.
- it may be necessary to make subscription end notifications [WS-Eventing-2004:§3.5] mandatory for the history service because they are optional (best effort) in the draft eventing specification used by SDC.
- it may be necessary to impose additional restrictions on the end-point for subscription end notifications to avoid race conditions. For example, consumers should use the same end-point (IP address and port) to avoid race conditions (such as the subscription end notification arriving before the last change sequence report).
- including the attribute in the report may be considered as mixing data and transport information.
Currently, consumers use a subscription-end notification to determine when a provider has finished delivering the available history notifications. Suggested adding a
LastReportattribute to theChangeSequenceReportTypeas well.From discussion at plug-a-thon 18:
EndTonotifications, or processingwse:UnableToRenewfaults.