[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: full agenda for 6/29 TC teleconf meeting
The full agenda , with links and some imports for 6/29 meeting I have added Sunil's fault issue as a formal technical issue for discussion. Tom Rutt -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133Title: Draft Agenda to WSRM TC Conference Call – May 06, 2003
|
Full Agenda of WSRM TC Conference Call – The meeting of the WSRM TC will take place by teleconference
1
Draft
Agenda:
Draft Agenda to WSRM TC Conference Call 1 Roll Call 2 Minutes Discussion 2.1 Appointment of Minute Taker 2.2 Approval of previous meeting minutes – 3 Action Item Status Review 4 Discussions of unresolved comments 5 Discussion of Document progression 6 Discussion of FAQ for WS-Reliability 2
Roll
Call
Attendance: Meeting ?? quorate. 3
Minutes
Discussion
3.1 Appointment of Minute TakerTom Rutt will take minutes. Minutes will serve to record issue resolutions. 3.2 Approval of previous meeting minutesThe minutes of the June 22 teleconf are posted at: http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/7489/MinutesWSRMTC062204.htm 4 Status of Action Items4.1 Action 052503-1 (Tom Rutt) pendingTom took an action item to complete the status column of pre public review issues list, with correct URLs.
4.2 Action 060104-5 (Jacques) PendingAction: Jacques, will propose further edits, on the FAQ for composability. Still open 4.3 Action 062204-1 (Jacques) ClosedAction: Jacques will propose text to resolve Binding model issue. Jacques provided text in: 5
Discussion
of Issues and editorial Comments
The following issues list includes items which need further discussion: 5.1 PC24
· Summary of WS-Reliability 1.01* issues
discussed over past week · Groups -
COntribution-JD-WS-Reliability-2004-06-21.pdf uploaded · Re: [wsrm]
Groups - COntribution-JD-WS-Reliability-2004-06-21.pdfuploaded · comments on Jacques Update on mep mappings
5.2 PC25
· RE: [wsrm] clarification on Respond primitive · Re: [wsrm]
Discussion on Duplicate elimination issue from 6/14 minutes Tom Rutt wrote: > I propose to allow both 1) and 3) behaviours ,
that is: > > 1) Sending rmp
allowed to return buffered response from previous > invocation with rm-acknolwedgement indication, or I meant the behavour
to apply to Receiving RMP for 1) above, as well as for 3) below 1) Receiving RMP is allowd
to return buffered response from previous invocation with rm
acknowledgement indication, or, > > 3) define a new RM-Fault called
"Response Payload Not Available for > Duplicate request" which gets sent
with > a soap fault in
the case where the duplicate invoke requires
a > response which is
not available because of duplicate request elimination. > > Tom Rutt > > > > Sunil Kunisetty
wrote: > >> Tom Rutt
wrote: >> >>> I have one question inserted below. >>> >>> Tom Rutt >>> >>> Sunil Kunisetty
wrote: >>> >>>> Here is the mail I sent on
Duplicate Elimination a week ago. >>>> It has the summary, possible
solutions and my preferred solution. >>>> >>>>
-----------------------------------------------------------------------------------------------------
>>>> >>>> I'd like to summarize the
options of using Duplicate Elimination for a >>>> Request-Response MEP. >>>> >>>> 1) Cache the message until the
original request expires and Send the >>>> "payload response" for every subsequent
request. >>>> 2) Send an empty SOAP envelope. >>>> (Note that when there is no AckRequested, there won't be any >>>> Ack
and >>>> hence the SOAP envelope will have empty
Header/body). >>>> 3) Send a signal that it is a
"Duplicate Message". >>>> 4) Spec. says that this is combination is
not supported. >>>> >>>> While I personally like (4), we can't do it as
the TC voted to >>>> support >>>> this
combination. >>>> >>>> I'm very un-comfortable with
(2) as it will cause all kinds of >>>> issues
and >>>> as
such it is meaningless/un-informative to send "empty signal". >>>> >>>> As per (1), while it is theoritcally reasonable and easy to implement, >>>> it is
impractical from a product/solution perspective. >>>> >>>> Here are few reasons: >>>> (i) Potentially can throttle the server with memory being sucked
up. >>>> Generally speaking, expire time is used
optimistically and will >>>> have a >>>> large life span.
Caching responses that long is not too good . >>>> (ii) I believe this thing (async. responses) is beyond the scope >>>> of this
specification and should be handled in
the "OASIS >>>> Asynchronous >>>> Service Access Protocol TC" [1] >>>> (iii) There are many subtle
things about caching responses: >>>> - there should be mechanism to
invalidate the cache >>>> - what if the request has time
sensitive information. for ex., >>>> if I ask
for getStockQuote for Oracle with a duration of >>>> say 1 hr... >>>> Assume the first message is lost. >>>> Say the RMP resent the same message
after 10 mins... they >>>> may >>>> get a stock quote that was 10 mins. ago. >>>> So if time sensitive data exists,
there should be mechanism >>>> for data resync.. >>>> >>>> So for these reasons, I just
like a RM signal [3] solution so that >>>> the
application can resend the request. >>>>
>>>> >>> The situation that causes the most
trouble is when the response had >>> been previously sent, so the
responder RMP >>> has no response payload to return
since it did not invoke the second >>> deliver. Thus the sender resending
will >>> not help
all all. >>> >>> The reason to give an indication is
so the sender will not continue >>> to resend
the duplicate, in cases where the original >> >> >> >> Right. That's why I said I like to send
a RM signal so that the >> Sender can either resend the Message >> with a
different MessageId or query as you suggested. >> >> Option 2 (sending an empty SOAP
envelope) is the wrong thing to do. >> 5.1 PC26Sunil Kunisetty Title: Soap Fault with RM-Fault Description: Sunil Mail 1Sunil Mail 2Sunil Mail 3 Proposal: under
discussion Resolution:
I'm cataching up with email, so I apologize upfront if this
issue is already discussed and/or
resolved already. Doug Bunting wrote: > > We have not
previously discussed the second or third sentences of this > draft. The above
changes remove some duplicate text from the second > sentence, moves
some into the first sentence and rewords the > remainder. If the
group prefers less editorial changes and limiting > the updates to the first sentence, I would suggest at least
removing > an extraneous "then" from the second. The new first sentence for this > alternative would be: > > " > When the Response
RM-Reply Pattern is in use and the message cannot > be delivered to
the Consumer, a > SOAP Fault MUST
be generated in addition to the RM Fault. > " > Is the above comment specific to Duplicate
Elimination case or a generic failure (to deliver) case? If former, then there is NO RM fault for
Duplicate messages. So the above should be better qualified as "in addition to the RM
Fault if exists one". If it is the latter, why do we need to send
*both* RM fault and SOAP Fault. The Sending RMP will convert/translate a RM Fault either
as a SOAP Exception or a API specific exception. So we don't need both. If we have to say SOAP Fault is sent, don't we
need better sub-codes for interoperability? -Sunil http://www.oasis-open.org/archives/wsrm/200406/msg00110.html Tom Rutt wrote: > whenever the request causes any rm-fault,
it cannot be delivered to > the consumer. All RM
faults > have this
property that for response reply pattern no response payload > is avialable, unless > the sending RMP caches prior responses. In this case, we will be semding
a SOAP Envelope with one Header (that has the RM Fault) and with no SOAP Body. The specific qn. I've is in what cases, we need to send BOTH SOAP
Fault and a RM Fault? I can't think of any. Sunil Kunisetty: http://www.oasis-open.org/archives/wsrm/200406/msg00115.html Sunil: > <ter> The reason to send both is
that one is targeted to the sending RMP the > other is targeted to the consumer. > > It does not hurt
to send both in this case. </ter> I think it hurts. I'm a big proponent of not
sending information when not needed,. I believe in not sending unnecessary and duplicate
information as it will cause confusion, mutual conflict, unnecessary bandwidth etc. Specifically the problems I see in this case
are: i) The duplicate
message may either be triggered by the RMP itself or accidentally by the application itself. Most likely by the former
because of Guaranteed
Delivery. In that case, RMP itself is
the consumer, so sending separate faults doesn't make much sense. ii) Just saying "send a SOAP Fault"
is very bad for
a spec. as it is not interoperable. We need to be very specific about the
Fault information to
be sent. Is it Client/Sender or Server/Receiver or what sub-code
etc.? iii) In most cases, the Sending RMP will
formulate a Fault/Exception to the Consumer if required based on the RM fault itself. A
combination of RM Fault and SOAP Fault could be problematic in such cases as they
could conflict. > 5.2 Comment on the ref Schema· Minor
technical issue (or two) in the reference.xsd schema · Re: [wsrm]
Minor technical issue (or two) in the reference.xsd schema 6 Discussion of Document Progression.For discussion 7 Frequently Asked QuestionsTom posted the following: · Approved
FAQ set for WSRM TC | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]