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>http://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>http://MyServer/MyService</Address>


</NotifyTo>

Comments (0)