Re: [wsrm] Rel 44: Duplicate Elimination and Time To Live (TTL)

[Sunil Kunisetty <sunil.kunisetty@oracle.com>]

 Paolo,

Paolo Romano wrote:

> A
>
>  > Unresolved Issue:  If the message exchange pattern is  1-way only, then
> should we
>  >still allow fault messages to be sent in opposite direction?  In other words,
> permit
>  >1 way SOAP message transfer, but require 2-way control/ error messaging at
> WS-RM
>  >layer (above SOAP).
>
>  I think an easy solution to this issue might be the following. When an

 How does "using the Headers" solution solve the above case? If we have
 to send the Fault in Headers (as HeaderFault), that will still result in
 sending a SOAP response and the MEP gets altered.

 So I fail to understand how the above unresolved case is solved?

 -Sunil

>
>  application is layered upon ws-rm, its wsdl defined MEPs should not be modified.
>  Whereas its WSDL should import the ws-rm headers description, to advertise its
>  supported (ws-rm) capabilities. ws-rm processors must also define and advertise
>  in a WSDL their ability to receive asynchronous fault and acknowledgment
>  messages.
>  I have already posted this idea some time ago, but I did not get much
>  feedback... Please, let me know what you think about it.
>
>  Best Regards
>
>  Paolo Romano
>
> >
> > Alan Weissberger <ajwdct@technologist.com> ha detto:
> >
> > > All
> > >
> > > The Issues List indicates that Rel 44 Duplicate Elimination and Time to Live
> > (TTL)is CLOSED, but on last week's conference call I believe we decided to pursue
> as
> > follows:
> > >
> > > New Spec issue: What should receiver do if it receives an Expired message?
> > > Related issue: better define semantics of TTL
> > >
> >
> ------------------------------------------------------------------------------------
> > >
> > > 1.  Time To Live
> > >
> > > I always wondered how the receiver knows that the message it just received has TTL
> > expired?
> > >
> > > I was told by a colleague that TTL is not the duration of the message (as one
> > would expect from its meaning in networking), but it's the actual time that the
> > message expires.  If that is the case than it should be renamed "message expiration
> > time."  (It's like the "Expires" entity of an HTTP header)
> > >
> > > We make the following assumptions on the sender and receiver that can handle TTL
> > (or Expiration Time):
> > >
> > > (a) They have agreed on the Maximum Duration for expiration (the receiver does not
> > want to keep messages forever).  This could be done as part of a subscription/SLA
> or
> > as a capability exchange/configuration message sequence at start-up time (i.e.
> prior
> > to sending WS data messages).
> > >
> > > Suggest we include this Maximum Duration value into the list of configurable
> > parameters.
> > >
> > > (b) Their clocks are properly synchronized to avoid pre-mature or late expiry of
> > the message (i.e. the time difference between sender and receiver clocke should be
> > less than some agreed upon threshold)
> > >
> >
> ------------------------------------------------------------------------------------
> > >
> > > 2.  What should receiver do if it receives an expired message
> > >
> > > (a) First, if the receiver detects the Message Expiration time (now known as TTL)
> > is greater than the agreed upon Maximum Duration, then the message should be
> > discarded and a Fault Message generated with Cause Code= Coding error in Message
> > Expiration field.  This is detected by the receiver when Message Expiration (of
> > received message) - Current Time > Max duration.
> > >
> > > (b) Second, if the receiver detects Message Expiration time is later than current
> > time, then message should be discarded and Fault Message generated with Cause Code=
> > Message arrived after Expiration time.
> > >
> > > Unresolved Issue:  If the message exchange pattern is  1-way only, then should we
> > still allow fault messages to be sent in opposite direction?  In other words,
> permit
> > 1 way SOAP message transfer, but require 2-way control/ error messaging at WS-RM
> > layer (above SOAP).
> > >
> > >
> > > Alan Weissberger
> > > NEC Labs America
> > > 2013 Acacia Ct
> > > Santa Clara, CA 95050-3482
> > > 1 408 863 6042 voice
> > > 1 408 863 6099 fax
> > >
> > >
> > > You may leave a Technical Committee at any time by visiting
> > http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php
> > >
> > >
> >
> >
> >
> >
> > --
> > Paolo Romano
> >
>
> --
> Paolo Romano
>
> You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php