I agree with Chris’ points below and
his alternate proposal.
From: Christopher B
Ferris [mailto:chrisfer@us.ibm.com]
Sent: Thursday, November 03, 2005
8:54 AM
To: Yalcinalp, Umit
Cc: ws-rx@lists.oasis-open.org
Subject: Re: [ws-rx] Proposal for
i056
-1
See
my previous post. I don't believe that there is any need for the RMS to have an
InactivityTimeout
nor
for the RMD to have any knowledge of what the RMS's policy is with regards to
when the RMS
might
become impatient and terminate a sequence for inactivity.
I
would propose that i056 be closed with no action.
Cheers,
Christopher
Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
blog: http://webpages.charter.net/chrisfer/blog.html
phone: +1 508 377 9295
"Yalcinalp,
Umit" <umit.yalcinalp@sap.com> wrote on 11/02/2005 05:12:27 PM:
> Issue 56:
> We are
making this proposal to address i056 [1] by building on our
> previous proposals to resolve issues i022[2],
i054[3], i055[4].
> By
exclusion of BTI and EB in the specification, the RMS does not
> have to communicate with RMD for setting up
the retransmission.
> However, there is one thing that is of
interest to the RMS which is
> its own Inactivity Timeout. This IT may be
specified to the RMD
> within the boundaries of RMD's
InactivityTimeout configuration on a
> per sequence basis.
> We
think that the proposal we made for closing issue i055 [1] can be
> used by RMS to communicate a specific IT for
the sequence. The next
> question is how RMS can specify the value of
IT on a per sequence basis.
> There
are two ways to look at this problem.
> (1) The
communication of this parameter value is out of scope and
> part of protocol preconditions which are
glossed over in Line 230
> and 231 of the WS-RM specification. This
means that either this
> configuration is done at some point in
deployment, or there is
> unspecified protocol between RMS and RMD that
determines the
> exchange of parameters prior to creating a
sequence.
> (2)
Since this exchange is establishing the RMSs choice of IT on the
> RMD side, it can be transmitted as part of
the CreateSequence
> message with the RMD. We note that this is a
per sequence basis and
> this optimization is of great value to RMS,
instead of leaving it
> out of scope.
> SAP
favors option (2) as there is a indeed cheap solution to support
> the use case without changing the protocol
with an optional simple extension.
> The
proposal below does not change proprietory deployment decisions
> and assumptions. It does not add additional
message exchanges to the
> protocol either. It is an optimization that
can be used within the protocol.
> Add the
following section to the wsrmp specification (which may be
> subject to further editorial modification)
>
{Section XX: Optimization for specifying parameters within WS-RM Protocol
> When
RMS needs to specify the InactivityTimeout value for a
> sequence, the selection of the inactivity
timeout may be part of the
> create sequence protocol as specified in
Section 3.4 of [WS-RM]. RMS
> MAY include the wsrmp:InactivityTimeout
element as a child of wsrm:
> CreateSequence element to designate the
Inactivity Timeout value.
> When specified as such, the maxValue and
minValue attributes MUST
> not be present.
>
<wsrm:CreateSequence ...>
> <wsrm:AcksTo ...>
wsa:EndpointReferenceType </wsrm:AcksTo>
> <wsrm:Expires ...> xs:duration
</wsrm:Expires> ?
> …
>
<wsrmp:InactivityTimeout>600000</wsrmp:InactivityTimeout>
> </wsrm:CreateSequence>
> This
specific optimization may be rejected by the RMD and the RMD
> MUST use the CreateSequenceResponse Fault as
the response to the
> Create Sequence request. In this case, the
RMD MAY include the
> specified InactivityTimeout element as part
of the [Detail] to
> indicate that the inactivity timeout value
specified by RMS is not valid.
> }
> We
think that this is a very cheap solution which specifies an
> optimization extension and RMD that do not
support this extension
> may reject the sequence with the specified
methods that are already
> within the protocol.
> Note
that there is a small issue with respect to the
> CreateSequenceResponse Fault [5] that has
been posted earlier that
> can be easily fixed to enable addition of
[Detail] content.
> This
optimization does NOT require changes to the existing protocol,
> but uses existing extensibility mechanisms to
allow RMS to
> configure the InactivityTimeout value.
> Cheers,
> --umit
> [1]
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i056
> [2]
http://www.oasis-open.org/apps/org/workgroup/ws-
> rx/email/archives/200511/msg00021.html
> [3] http://www.oasis-open.org/apps/org/workgroup/ws-
> rx/email/archives/200511/msg00023.html
> [4]
http://www.oasis-open.org/apps/org/workgroup/ws-
> rx/email/archives/200511/msg00037.html
> [5]
http://www.oasis-open.org/apps/org/workgroup/ws-
> rx/email/archives/200511/msg00017.html
>
> ----------------------
> Dr.
Umit Yalcinalp
> Standards Architect
> NetWeaver Industry Standards
> SAP Labs, LLC
> umit.yalcinalp@sap.com
> Tel: (650) 320-3095