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)
- From: Doug Davis <dug@us.ibm.com>
- To: ws-rx@lists.oasis-open.org
- Date: Tue, 10 Jan 2006 08:44:30 -0500
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]