OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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



Jacques Durand <JDurand@us.fujitsu.com> wrote on 01/09/2006 10:29:02 PM:

> Doug:

>  
> We do not seem to have the same premises in mind when talking about
> this, so let me try to clarify:

>  
> > The CS _is_ associated with an endpoint - its the endpoint that
> the CS is sent to  :-)

> > What that endpoint/EPR is is not defined by the spec nor should it
> be.  It could be the same EPR as one of the app messages, it could
> be some common broker or it could be some 3rd party (RM manager) endpoint.

>  
> So you assume that the CS could be sent to an AD EPR, like any
> application message. I always assumed that a CS and other sequence
> operation messages, are sent to the RMD endpoint, whatever it is. In
> some cases this is the same endpoint as the application behind. But
> in i075 use cases, it can be distinct. Are we saying that in such
> cases, unlike for application messages, the RMD would "block" the CS
> to make sure it never reaches the endpoint it was technically sent to?

> In that case, sure the RMD would have a clue about which policy to
> apply - but it is rather odd to send a CS to another endpoint than
> an RM manager, which is the actual consumer of all operations on sequences.

>
> > I don't think the spec should say anything about how the RMS or AS
> chooses a sequence - which is the direction I think your examine leads.

>  
> No. I am only indicating a way the RMS can convey in the CS which
> destination endpoint should be associated with the new sequence
> (regardless of who decides to create this sequence), when the RMS is
> given this opportunity. Sending the CS to this destination endpoint
> as you seem to suggest is just another way to do the same thing -
> sure it does not use a new element (though relies on wsa headers
> that must be understood by RMD?) but our developers clearly dislike
> the trick....

>  
> Always sending the CS and other sequence ops to the RMD endpoint (in
> the same way as CSR are always sent back to the RMS endpoint and not
> an AS endpoint behind) is another way to keep things simple...

>  
> Am I at least restating the options correctly?

I think I'm the one not being clear  :-)
I believe the CS could be sent to an RMD manager (as you suggest) but
it could also be sent to the AD endpoint - and I don't think the RM
spec should say which one it goes to.  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.

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).

-Doug


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]