WS-Eventing and WS-Addressing
Hank Wallace posted a question recently about the <NotifyTo> element in a WS-Eventing subscription request, and whether it really needed to contain an <Address> element or not. You can read my response in the comments, but while I was looking over the specs I realized that the presentation of this containment is a bit confusing.
In WS-Eventing, the <NotifyTo> element is defined as follows:
<NotifyTo>endpoint-reference</NotifyTo>
In WS-Addressing, an endpoint-reference is defined as follows:
<EndpointReference>
<Address>xs:anyURI</Address>
</EndpointReference>
(Note that I’ve left out namespaces and optional elements for clarity.)
Gosh, this looks like you not only need the <Address> element, but also this <EndpointReference> guy! Maybe something like this?
<NotifyTo>
<EndpointReference>
<Address>https://MyServer/MyService</Address>
</EndpointReference>
</NotifyTo>
Wrong! Bad Bruce! You see, a closer reading of the WS-Addressing spec reveals this interesting tidbit:
“ /wsa:EndpointReference
This represents some element of type wsa:EndpointReferenceType
. This example uses the predefined <wsa:EndpointReference>
element, but any element of type wsa:EndpointReferenceType may be used.”
And another look at the WS-Eventing spec reveals more:
“/s:Envelope/s:Body/*/wse:NotifyTo
Where to send notification messages. MUST be of type wsa:EndpointReferenceType.”
So it turns out that the <NotifyTo> element is in fact an instance of the EndpointReferenceType; <NotifyTo> and <EndPointReference> are the same. For the more colorfully-minded:
<NotifyTo>endpoint-reference</NotifyTo>
<EndpointReference>
<Address>xs:anyURI</Address>
</EndpointReference>
Red elements are the same as red elements, blue are the same as blue. So the correct merging of the WS-Eventing and WS-Addressing specs is as follows:
<NotifyTo>
<Address>https://MyServer/MyService</Address>
</NotifyTo>