WS-Eventing and WS-Notification? WS-RF? The problem with the “logical recipient of a message” again.

I wonder what’s going on behind the scenes. The new version of WS-Eventing has IBM as a co-author. What does this suggest about WS-Notification? Could it be the case that WS-Eventing is going to be layered underneath WS-Notification or are we going to see the two merging? Also, the ID of the subscription has become an EPR!!! This means that the ID of a subscription is coupled, if used, with the endpoint of the subscription manager service, which is remarkably similar to the way WS-RF does things. Instead of carrying the identification of the subscription in the body of the message, it is expected that event sinkssources will return an EPR with the “appropriate” reference properties or parameters to identify the subscription.The information from the EPR is used with every communication regarding the particular subscription.

Also, an example where a custom dialect for filtering on topics is given. This reminds me of WS-Topics.

A big “hmmmm“!!!

Don’t get me wrong. The less competing specifications the better. I just feel that there is a danger of going down the route of EPRs as resource pointers, as per WS-RF. For example, when you want to unsubscribe, you no longer include the identifier of the subscription into the body of the message. Instead, the message is logically targeted “directly” to the subscription (rather than the service) through the use of message information headers. This is similar to the problem I had previously identified in the WS-RF mailing list. If WS-Addressing message information headers are used in this way in specifications, we can’t define a message which can carry multiple subscription IDs; in the case, for example, one wanted to cancel multiple subscriptions with one message:

<soap:Body> <unsubscribe> <subscription>uuid:blabla1</subscription> <subscription>uuid:blabla2</subscription> ... </unsubscribe> </soap:Body>