WS-Eventing and WS-Addressing

  • Article

 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>