SOAP-over-UDP Multicast Streaming
Messages within a multicast stream should have an application sequence number to allow a receiver to order messages and to notice packet loss.
A possible solution would be the AppSequence SOAP header from WS-Discovery (sec. 7). The SequenceId should be set to the wsa:action URI and the MessageNumber MUST be incremented by 1 (this is more restrictive).
Requesting missed messages
In some application scenarios it would be practical in case of packet loss to request a retransmission of lost streaming messages. The retransmitted SOAP message could be send to the multicast address or directly to the requesting node (UDP unicast/HTTP). To request the retransmission the device must implement a HTTP operation where the appropriate sequence numbers could be passed. Depending on the retransmission (multicast / HTTP response) this operation is oneway/request-response MEP.
For the multicast retransmission the device just retransmits the SOAP message with the same wsa:MessageID and d:AppSequence to the multicast address, thus all clients missed the packet receive it. Of cause, clients should skip the message in case they already received it.
For the HTTP response variant the message is just embedded. The problem might be, that the response message could not completely be specified in a general WSDL since it is not known.
This feature is comparable with the HISTORY QoS in DDS.
Early loss detection
Typically a client (consumer) detects a packet loss when a new SOAP message arrives with a larger sequence number than expected. In case of sequent packet loss the client has no possibility to detect the packet loss. In this scenario a timer on the client side would solve the problem if the client knows how often messages are send. In DDS (Data Distribution Service) exists a DEADLINE QoS ( Sec. 18.104.22.168) that specifies a duration (seconds, nanoseconds) for periodically updates. In addition to the multicast address this duration might be provided.
This suggestion starts the way a stream consumer might find the stream and retrieve available meta data to subscribe the stream.
Similar to WS-Eventing 9.1 EventSource Assertion it is embedded within a WSDL file in a Endpoint Policy Subject. Thus, it can be placed in a WSDL 1.1 port, portType or binding. This way, the information about a stream source are available at design time for code generation.
Inside this StreamSource policy a StreamDescriptions element (similar to the EventDescriptions element) is used for further information about the stream:
<wsstm:StreamSource> <wsstm:StreamDescriptions targetNamespace="xs:anyURI" ...> <wsstm:types> <xs:schema ...> ... </xs:schema> xs:any* </wsstm:types>? <wsstm:streamType name="xs:NCName" element="xs:QName" actionURI="xs:anyURI"? ...> <wsstm:streamPeriod> duration-type </wsstm:streamPeriod>? <wsstm:streamAddress> endpoint-reference-type </wsstm:streamAddress>? xs:any* </wsstm:streamType>+ xs:any* </wsstm:StreamDescriptions> xs:any* </wsstm:StreamSource>
- This policy assertion has Endpoint Policy Subject. When present in a policy alternative, it indicates that the subject is a stream source.
- This element contains the declarations of all the Stream Types that apply to a given context.
- This attribute defines the namespace affiliation of the Stream Types declared within the StreamDescriptions element. Its value MUST be an absolute IRI [RFC 3987]. It SHOULD be dereferenceable.
- This OPTIONAL element encloses data type definitions that are relevant to the declared Stream Types.
- As described earlier, a Stream Type is defined by a Global Element Declaration (GED) in XML Schema. This element contains collections of imported and inlined schema components that describe the GEDs that are used to define Stream Types.
- This element describes a specific Stream Type.
- This attribute provides a name for this Stream Type which MUST be unique amongst all the Stream Types defined by the enclosing wsstm:StreamDescriptions element. In conjunction with a Prefix that is associated with the value of /wsevd:StreamDescriptions/@targetNamespace namespace URI, the value of this attribute MAY be used as the LocalPart of a QName that identifies this Stream Type outside the context of the enclosing wsstm:StreamDescriptions element.
- This attribute refers to a GED defined or imported in the /wsstm:StreamDescriptions/wsstm:types element. The referenced GED serves as the definition of this Stream Type.
- This OPTIONAL attribute provides a value for the 'action' property used to transmit the Stream, serve as a potential aid to identifying the semantics implied by the message. When not present the implied value of this attribute is the concatenation of the wsstm:StreamDescriptions' @targetNamespace attribute and the wsstm:streamType name attribute separated by the '/' character.
- This element (XML schema duration type) contains the duration with a fractional second (If the stream source publishes data with 50 Hz it is PT0.02S).
- This element (endpoint reference type according to WS-Addressing) specifies the address to join for receiving the stream (e.g., soap.udp://22.214.171.124:12345)
Note: Instead of specifying a streamPeriod it could be used a deadlinePeriod that specifies the maximum duration between two stream packets. (Further discussions required!)
The history functionality for data streams is currently out of scope. Theoretically a history endpoint reference could be added, where it is possible to request previously streamed SOAP messages (previous n). It is necessary to specify the GetHistory operation that the history epr must implement in this case. This could be done similar to the Subscription messages in WS-Eventing.
<wsp:Policy> <wsstm:StreamSource> <wsstm:StreamDescriptions targetNamespace="http://www.example.org/oceanwatch/stream" xmlns:ow="http://www.example.org/oceanwatch"> <wsstm:types> <xs:schema targetNamespace="http://www.example.org/oceanwatch"> <xs:include schemaLocation="http://www.example.org/schemas/oceanwatch.xsd"/> <xs:element name="WindReport" type="ow:WindReportType"/> </xs:schema> </wsstm:types> <wsstm:streamType name="RealTimeWindReportStream" element="ow:WindReport" actionURI="http://www.example.org/oceanwatch/2010/WindReportStream"> <wsstm:streamPeriod>PT0.02S</wsstm:streamPeriod> <wsstm:streamAddress>soap.udp://126.96.36.199:12345</wsstm:streamAddress> </wsstm:streamType> </wsstm:StreamDescriptions> </wsstm:StreamSource> </wsp:Policy>
It is also useful to make the StreamDescriptions available via WS-MetadataExchange. Especially, to extract the streamAddress and streamPeriod that might not be included in a general StreamDescriptions within a StreamSource policy.
The value of the @Dialect attribute MUST be equal to wsstm:StreamDescriptions. The value of the @Identifier attribute, if present, for this MetadataSection MUST be equal to the value of its wsstm:StreamDescriptions/@targetNamespace. An stream source MUST NOT have more than one StreamDescriptions document.
<mex:MetadataSection Dialect="wsstm:StreamDescriptions" Identifier="http://www.example.org/oceanwatch/stream"> <wsstm:StreamDescriptions> <!-- Stream descriptions data removed for brevity --> </wsstm:StreamDescriptions> </mex:MetadataSection>
Similar to the binding in WS-Eventing ( WS-Eventing A.1.2.1 Binding for Unwrapped Notifications) stream message are embedded in SOAP messages unwrapped.
Due to the fact that SOAP-over-UDP is restricted in the message size that could be transmitted over network. It might be useful to compress the SOAP message using some sort of compression algorithm. To indicate that the SOAP message is compressed, the scheme of the streamAddress should be prefixed with the compression format used.
exi.soap.udp://188.8.131.52:12345 indicates that the Efficient XML Interchange (EXI) format is used to compress the SOAP message.