OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[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 5133


Title: Draft Agenda to WSRM TC Conference Call May 06, 2003

Full Agenda of WSRM TC Conference Call June 29, 2004

 

The meeting of the WSRM TC will take place by teleconference 

Tuesday, June 29, 2004, from 5:30 to 7:30 PM Eastern Standard Time

 

 

Conference Bridge number
Toll only : 1-512-225-3050
Participant code: 716071

 

 

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 Taker

Tom Rutt will take minutes.

 

Minutes will serve to record issue resolutions.

3.2      Approval of previous meeting minutes

The 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 Items

 

4.1      Action 052503-1 (Tom Rutt) pending

 
Tom took an action item to complete the status column of 
pre public review issues list, with correct URLs.

 

4.2      Action 060104-5 (Jacques) Pending

 

Action: Jacques, will propose further edits, on the FAQ for composability.

 

Still open

 

 

4.3      Action 062204-1 (Jacques) Closed

 

Action: 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:

 

http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/7512/PublicCommentsIsssues-062904InputB.html

5.1      PC24

 

PC24

Spec

Technical

Open

Doug Bunting

 

Title: Payload inclusion and MEPs other than request/response

Description: Re: more on payload(s) inclusion and MEPs than our Request-ResponseMEP discussion covers

Proposal: under discussion

Resolution:

 

Summary of WS-Reliability 1.01* issues discussed over past week
From Doug Bunting <Doug.Bunting@Sun.COM> on
13 Jun 2004 22:10:30 -0000

 

Groups - COntribution-JD-WS-Reliability-2004-06-21.pdf uploaded
From jdurand@us.fujitsu.com on
25 Jun 2004 09:33:16 -0000

 

Re: [wsrm] Groups - COntribution-JD-WS-Reliability-2004-06-21.pdfuploaded
From Sunil Kunisetty <sunil.kunisetty@oracle.com> on
25 Jun 2004 21:52:45 -0000

 

comments on Jacques Update on mep mappings
From Tom Rutt <tom@coastin.com> on
29 Jun 2004 00:19:51 -0000

 

5.2      PC25

 

PC25

Spec

Technical

Open

Doug Bunting

 

Title: Duplicate message responses

Description: http://www.oasis-open.org/archives/wsrm/200406/msg00078.html

Proposal: under discussion

Resolution:

 

RE: [wsrm] clarification on Respond primitive
From Jacques Durand <JDurand@us.fujitsu.com> on
14 Jun 2004 06:19:04 -0000

 

Re: [wsrm] Discussion on Duplicate elimination issue from 6/14 minutes
From Tom Rutt <tom@coastin.com> on
28 Jun 2004 23:06:35 -0000

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      PC26

PC26 Spec Technical Open

Sunil Kunisetty

Title: Soap Fault with RM-Fault

Description: Sunil Mail 1Sunil Mail 2Sunil Mail 3

Proposal: under discussion Resolution:

 


  
http://www.oasis-open.org/archives/wsrm/200406/msg00085.html

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
From Doug Bunting <Doug.Bunting@Sun.COM> on
24 Jun 2004 15:43:22 -0000

 

Re: [wsrm] Minor technical issue (or two) in the reference.xsd schema
From Anish Karmarkar <Anish.Karmarkar@oracle.com> on
25 Jun 2004 22:10:52 -0000

 

 

6         Discussion of Document Progression.

 

For discussion

 

 

7         Frequently Asked Questions

 

Tom posted the following:

 

Approved FAQ set for WSRM TC
From Tom Rutt <tom@coastin.com> on 3 Jun 2004 13:57:21 -0000

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]