RE: [ws-rx] Proposal for issue i075 resolution (b)

I believe the CS could be sent to an RMD manager (as you suggest) but
it could also be sent to the AD endpoint -

<JD> I came to agree on this, but I will try to show below that this is not like there is no flipside to this solution either.

Also Section 3.4 might need to be updated to suggest that CS is not just to be sent to an RMD but may be sent to an endpoint behind it.

and I don't think the RM
spec should say which one it goes to.

<JD> But: the RMD must still prevent this CS message to actually go to the AD endpoint ! (if different from the RMD endpoint) In other words, if we allow (some) sequence operation messages to be sent to an endpoint beyond the RMD, shouldn't we add a spec requirement that the RMD must block them ?

But I guess you meant to say that the spec should not tell whether or not to send to AD or to RMD in the first place, which I agree, provided we require that the RMD blocks any sequence operation message send to an AD.

I think we probably agree on that.

What I'm pushing back on is the notion of explicitly exposing the split
between the RMD and the AD through this EPR you want to include. As I
mentioned in my previous note today, I believe the relationship between
the RMD and the AD is out of scope for this spec. If an implementation
wants to have a single RM manager support multiple AD endpoints then
there will need to be quite a bit of communication/setup between them
to ensure that not only Policy info is correctly communicated but other
things like DAs. A single RM manager could support lots of different
ADs each with different DAs - how this information is shared and
supported at runtime is out of scope and an implementation detail. I
view this Policy information in the same light.

<JD> You may decide to keep the AD enpoint info outside the CS header, though it will still be in the CS message in some form. The tradeoff I see is that the RMD will need to do "more" on this info - and sometimes in a trickier way - than if CS was always sent to RMD only, with explicit endpoint info in it.

The two ways I see an RMD can support CS-to-ADenpoint today are:

Sol 1. All AD endpoints served by the RMD actually share the same Internet domain, are deployed on the same WS stack. Their URLs differ at the end (in this case the RMD is deployed e.g. as a Java handler (JAX-RPC) or as SOAP extension in .NET) So if the CS is sent to one of these URLs, this assumes that the stack let the RMD access the URL value in order to resolve the policy, and let the RMD block the CS on its way to AD.

Sol 2. The RMD is deployed as a SOAP node that can forward to the AD endpoint implemented as another SOAP node. The CS may "indicate" the AD endpoint by using wsa:To, although it is sent to the RMD URL. This assumes that the RMD has knowledge of wsa headers and/or that wsa:To is interpreted differently for a CS and for regular messages, when it comes to forwarding.

So sure, there is a way to make this work without spec support, but the handling of a CS intended to an AD endpoint is more tricky.

Besides, in the RM manager case its very possible that the RM sequence
could be established long before ANY app message is sent - this would
mean that there isn't any AD endpoint to associate with (yet).

<JD> in that case, I assume that the RM manager itself will make the decision (implementation-specific), like you assume too in your solution.

So overall I do not object to the CS-sent-to-ADendpoint solution: I can see that it "should" work, but it will put more requirements on the deployment context.

Thanks,

Jacques

-Doug

ws-rx message