William, an ex-HP colleague, has some interesting things to say about EPRs and how people tackle them. I'm broadly in agreement with what he has to say; he even references our paper, which is nice. Unfortunately there are a couple of places where he's wrong:
(i) on the implication that WS-Coordination is the same as WS-Context. However, I think Greg has responded to that here (though since his blog seems down I can't check).
(ii) on the implication that this formal objection we've raised is somehow against EPRs and ReferenceParameters. It isn't (though that's not to say I don't believe the latter is inherently wrong, but that is a completely different issue). As I say here this is about keeping EPRs symmetrical. To summarise, the current state of affairs is that EPRs are encapsulated entities until you need to use them, and in what case their constituent elements (e.g., the endpoint URI, ReferenceParameters etc.) appear as first-class elements in the SOAP header). As the objection describes, this can lead to a number of problems and we believe it's worth fixing now rather than try to retro-fit something later.
Hopefully given the pitfalls that William's original blog entry describes, he'll agree that this change we're after only makes things better.
Hi William. I understand what you want to accomplish, but disagree that ReferenceParameters are the right approach in this case. Use something like WS-Context because what you're trying to do is narrow contextually. Use WS-Addressing to *address* endpoints and not to encode any application specific or invocation specific information. That doesn't scale and results in the brittleness you mention in bullet 5.
ReplyDeleteBTW, the symmetry aspect is only one reason I don't like exploding the EPR into the SOAP header. Ignoring esthetics, if you read the full text of the objection you'll notice that there are several significant risks to the approach.