ws-rx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [ws-rx] Issue i024
- From: Doug Davis <dug@us.ibm.com>
- To: ws-rx@lists.oasis-open.org
- Date: Thu, 15 Sep 2005 08:40:23 -0400
Anish,
I've always thought they
were meant to be shared since it could influence
how the other side interacted with the
RM endpoint. For example, based on
the inactivity timeout advertized by
an RMD, an RMS may choose to modify
its retry interval to make sure the
sequence doesn't timeout. The thing I've
wondered about is whether these should
be static value (meaning they appear
on the WSDL and probably won't change),
or are they more dynamic and might
change on each sequence (perhaps based
on the RMS's identity). If they are
more dynamic then perhaps they should
be part of the CreateSequence handshake
just like some people have suggested
the DA in use be part of the CreateSeqResponse.
It might be useful to examine
the complete set of interactions between an RMS and
an RMD - starting with the first MDEX
Get through to the CreateSequenceResponse -
stating what bit of data we expect each
message to carry and how that is supposed to
be used (can't remember off hand if
one of Gil's use-cases fully describes this but I
have a vague recollection that one might
come close). I have a feeling that if we could
agree on the typical (or even 'suggested')
interaction pattern we expect people to
follow that coming up with a solution
will be easy and will probably cover all of these
issues (and include Chris' issue 9 too).
But I haven't done the legwork yet to know
for sure - just guessing here.
thanks
-Doug
Anish Karmarkar <Anish.Karmarkar@oracle.com>
09/15/2005 02:27 AM
|
To
| Doug Davis/Raleigh/IBM@IBMUS
|
cc
| ashok.malhotra@oracle.com,
ws-rx@lists.oasis-open.org
|
Subject
| Re: [ws-rx] Issue i024 |
|
Doug,
I think issues 6 and 9 make issue 24 more relevant/important and I can
see at least a solution that covers all three. It certainly makes sense
to think about them together and perhaps even find a single/common solution.
One question though I have about the existing RM policy assertions is:
are they (inactivity timeout, base retransmission interval, ack
interval) meant to be shared between RMS and RMD or are they meant as
configuration information for implementations? By shared, I mean shared
by both the RMS and RMD (and not just attached in a WSDL document).
Thanks.
-Anish
--
Doug Davis wrote:
>
> What's the relationship between this issue and issues 6, 9? They
seem
> very similar - almost like 6 and 9 are a subset of 24. Would
it make
> sense to try to find a single/common solution that covers all?
> thanks,
> -Doug
>
>
> Ashok Malhotra <ashok.malhotra@oracle.com> wrote on 09/14/2005
03:43:40 PM:
>
> > This is in response to Sanjay's note asking for a proposal
for issue
> i024.
> > In this case, though, what we are asking for may be a clarification
> and not a change.
> >
> > The WS-RM Policy spec defines a RM assertion. It
also specifies how
> this assertion
> > may be attached to WSDL. What is does not specify
is the motivation
> behind the
> > assertion, how it is used and the messages it applies to.
We would
> like this clarified.
> >
> > It is clear that the RM assertion is an 'informational
assertion' in
> that it is a
> > property of the sequence and not a property of the messages
in the
> sequence. As such,
> > it does not make sense for each message to include this
information.
> >
> > Second, policy information is meant to be conveyed by one
party in a
> conversation to
> > the other. In this case, the assertion seems to specify
> implementation parameters
> > that may be private to the RMS or the RMD. If so,
it does not need
> to be part of the
> > specification.
> >
> > If, indeed, the RM assertion is to be conveyed from the
RMS to the
> RMD it can be
> > done as a header in the CreateSequence message. The
RMD can respond
> with a header
> > in the CreateSequenceResponse by agreeing, disagreeing
or making a
> counter proposal.
> >
> > If the RM assertion has to be conveyed from the RMD to
the RMS, this
> has to be done
> > before the CreateSequence message and requires a new protocol
element.
> >
> > All the best, Ashok
> >
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]