[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Prelim Minutes of 6/14 teleconf
The prelim minutes are attached. Please provide comments before friday. Tom Rutt WSRM TC charir -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; [email protected] Tel: +1 732 801 5744 Fax: +1 732 774 5133Title: Draft Agenda to WSRM TC Conference Call � May 06, 2003
|
Preliminary Minutes of WSRM TC
Conference Call � The meeting of the WSRM TC� took 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 Scheduled Vote for CD (not likely) 7 Scheduled Vote to Submit to OASIS for member vote (not likely) 6 Discussion of FAQ for WS-Reliability 2
Roll
Call
Attendance:
�Meeting� is� quorate. 3
Minutes
Discussion
3.1 Appointment of Minute TakerTom Rutt will take minutes. Minutes will serve to record issue resolutions. 3.1 Approval of previous meeting minutesThe minutes of the June 08 teleconf are posted at: �http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/7245/MinutesWSRMTC060804.htm Alan moved to accept minutes, Jacques seconded. No opposition minute approved. 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 060804-1 (Doug Bunting) closedAction: Doug will
propose text for� in
4.5 to clarify that when you cannot deliver due to rm
fault, then send back a soap fault, Complete, Text incorporated in 1.01I 4.4 Action 060804-2 (Jacques) closedJacques took an �action to describe the response reply pattern to work with our abstract model to sneak around to allow response correlation, and how it can be used for duplicate elimination.� Jacques provided as contribution 1.01J. Need further discussion with new technical issues PC 24 and 25 Jacques asked all to read these changes.� 5
Discussion
of Issues and editorial Comments
The following issues list includes items which need further discussion: 5.1 Approval of Outstanding Editorial Comments Reflected in 1.01IThe following editorial comments need to be formally approved, to apply the agreed edits within 1.01I� to become a new Editor�s draft 1.02. http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/7246/EditingDraft101Idiff101.pdf
5.1.1 PC 16
Action: Iwasa to incrrporate into next draft. 5.1.2 PC20
No objection to Iwasa incorporating these changes. 5.1.3 PC21
Agreed to remove the sentence: from 1.02. �However, an RMP is not requried to disinguish WSDL operation types.� Jacques wants to have discussion on the awareness of correlation.� Doug: I have a general concern about many versions in less than 7 days.� No objection to incorporating edits, but removeing the paragraph. All this text is subject to change in resolving the new issues. 5.1.4 PC22
No objection to changes. 5.1.5 PC23
No objection to acceptance. Action: Iwasa will produce new version 1.03 as the new editors draft as baseline. 5.2 PC24
�� Summary of
WS-Reliability 1.01* issues discussed over past week �� RE: [wsrm]
Summary of WS-Reliability 1.01* issues discussed over past week Title:
RE: [wsrm] Summary of WS-Reliability 1.01* issues
discussed over past week Solution
proposed for (2a) below: (removing the sentence�
"However,� an RMP� is� not
required� to distinguish� WSDL operation types.") We
can remove this sentence if: (1)
we tighten the RMP definition (terminology): Keep
defining RMP as a "SOAP Node" (as defined in SOAP 1.2) as we did, but remove the unnecessary and possibly misinterpreted "or
a subset or superset thereof". The
RMP is the entity that has all functions needed to transmit reliable SOAP
messages, from the Submit/Deliver/Respond/Notify operations layer down
to the wire. (I
think Doug made a similar point) (2)
we replace this sentence with a statement independent
from WSDL, and getting at the core of why the sentence above needed be removed: "When
invoking Deliver operation on a payload, an RMP is required to know whether a related Respond invocation is expected or not." (I
would not mind narrowing further this statement to make it conditional to the
binding of Deliver/Respond to an underlying request-response MEP) Jacques -----Original
Message----- From:
Doug Bunting [mailto:Doug.Bunting@sun.com] Sent:
To:
wsrm@lists.oasis-open.org Subject:
[wsrm] Summary of WS-Reliability 1.01* issues
discussed over past week The
following is intended to help get everyone caught up. Most� of� this�
derives� from� the abstract�
model� in� our�
specification, resulting in� a
number� of contradictions� between it and� the rest�
of the document, underscoring�
a few over-general restrictions�
or indicating some under-specified� concerns.�� While� some�
of� the� issues�
below� could� be considered editorial, the bulk are at least minor technical
concerns. When� reading� the� following,� it��
is� very� important�
to� remember� the distinction between�
the capabilities the�
WS-Reliability protocol provides to� the producer� and consumer�
and how� that protocol� maps to�
use� of an underlying� protocol.��� Producer� /�
consumer�� interactions� occur�
using WS-Reliability� and� WS-Reliability� uses�
SOAP messaging� (our� underlying protocol).� The RMP� always has
complete control over the� bits on the
wire though� the
producer� and� consumer may�
provide� the bulk� of the�
message content in a "pass through" fashion. The
example� "solutions"
are provided� primarily to make the� issues clear. While
some� of these
approaches may resolve� the issues, we
must� come to a common understanding of the problems before working on
solving them. 1)
The� existing
descriptions of� the callback� and poll�
RM-Reply patterns ��� assume�� the��
underlying�� protocol� supports��
request-response�� SOAP ��� interactions but
do� not explain what goes into� the underlying response ��� of� the�
separate �message� exchanges.��
In� detail,� the�
response� and ��� synchronous� RM-Reply� patterns may�
be� used� only�
with an� underlying ��� protocol that
supports request-response (a less general restriction than ��� currently
specified).�� For the callback and� asynchronous poll
RM-Reply ��� patterns,� we are using�
only one-way� messaging;
though� the underlying ��� protocol� might support� request-response, we� should rely�
on� the SOAP ��� binding to
describe� or profile how the
underlying� response is used (or ��� ignored).� For� example, we might� clarify that these� RM-Reply patterns ��� involve two� separate one-way� SOAP message exchanges� (callback), three ��� separate� one-way message� exchanges�
(asynchronous poll)� or a� one-way ��� followed� by a�
request-response� exchange
(synchronous� poll).� Such� a ��� clarification
might also address part of (2) below -- though at the cost ��� of some
generality. Tom: is there disagreement we need to fix this problem. Jacques: we currently assume a request/ response underlying� protocol, we are not talking about broadening. Doug: Even with http we are using it in a one way fashion.� However we have not described it properly.� It states nothing about using the binding in a one way fashion. 1a)
The� "non-essential
assumption"� that the
underlying� protocol supports ���� request-response
SOAP� interactions, stated� in section 2.1,� should be ���� removed.� This is no longer a general assumption but
something specific ���� to two of our four RM-Reply pattern options. Agree to remove as general restriction.� Need to fix this to be only the restriction which is actually required. Doug: less about the restriction but more about we need to describe how to use the underlying protocol. Sunil: from day one we had an implicit assumption that it would work on half duplex. Doug: even for the
cases where the general restriction is too strong, we are not leaving it 1b)� The� HTTP Binding� should�
be an� instance� of� the
general� semantics ���� described in� the main body of� the specification and� not extend those ���� semantics.�� The current� section� provides examples� of semantics�
not ���� described
elsewhere. �After resolving the areas
left under-specified or ���� over-generalized
in the rest of the document, we must recheck section 6 ���� for conflicts
with these semantics.� In addition, any
transfer protocol ���� responses that
may� be unclear because we are �using a request-response ���� underlying� protocol� in�
a� one-way� fashion should� be�
described� by ���� reference to the
appropriate SOAP over HTTP binding. Doug: Some things are only described in section 6.� They need to be readdressed after we have the general semantics. 2)
Section� 5.2 is
completely� about the� producer /�
consumer interactions ��� though some of its
text has been applied to the RMP use of an underlying ��� protocol.� The matrix� in section 5.2 states that� all RM-Reply patterns ��� may be used
with� consumer-generated payload(s) or
application responses ��� on� the receiving� RMP side.��
However, the�
callback and� poll RM-Reply ��� patterns� provide multiple opportunities� to return�
payload information ��� (as they are� currently described, see (1) above)� and the specification ��� does� not�
describe� which� option�
is� recommended.�� Our� new �Respond ��� operation� (possibly restricted� to specific�
RM-Reply� pattern choices) ��� must be
mapped� to the underlying protocol at
least as� far as timing is ��� concerned.� We may also decide to further restrict when
the consumer may ��� invoke the Respond
operation. Doug: this talks about application payloads than can come back.� But we do not talk about these consumer payloads.� It does not quite work without specifying something more.� This is a problem and added words are needed. Doug: One proposal was to return in immediate response.� There are multiple options, we are not saying how the responses will come back. Jacques:� There are different expectations on table 5.2.�� The table was just a summary of recommended usage of reply patterns to wsdl operation types.� There is not enough explanation before the table.�� Doug: I think this is getting into the solution space, we need to describe the possibilities in the document. 2a)� The sentence� "However,� an RMP�
is� not requried� to disinguish� WSDL ���� operation
types."� [please
note� new spelling errors] was introduced
in ���� a recent edit to
section 5.2,� enshrining an assumption a
few of the TC ���� had previously
made.� This� assumption contradicts the complete
control ���� an RMP� has over the�
bits on� the wire.� The� consumer may or� may not ���� provide
payload� information (the� consumer interface may� be described ���� using either a
request-response or� a one-way operation
type).� Even if ���� the receiving
RMP� is only passing the information� through, it must be ���� aware of when to
wait for the consumer to invoke the Respond operation. ���� This sentence should be removed. We removed this sentence.� However Jacques has proposed a new solution for this.� This sentence conflicts with the info the receiving RMP needs. Already agreed to remove the sentence, and to resolve the problem indicated by Doug. Need to discuss Jacques proposed solutions to this problem. 2b)
The� one-way
consumer� interface and Response� RM-Reply pattern� is the ���� most� direct combination to� reliably deliver� one-way messages� from a ���� producer
"hidden" behind a firewall.��
The matrix in section 5.2 should ���� not� disallow this� combination.��
While synchronous�
polling at� least ���� works, it always
requires an additional round trip. Doug: Sunil�s objections are mixing up restrictions at producer consumer level with underlying protocol level.� Ws reliability is a soap binding, but we should be able to map to underlying that does not require request/response interaction.� At an abstract level there are two soap bindings.� WS reliability offer to application level is a way to deliver and exchange messages.�� Our sending and receiving multiple messages in both directions, regardless of whether producer and consumer are aware of those messages. The WSDL doc which describes how to use our messages would be different than the one the user made. Sunil: 5.3 is particular about WSDL one way operation type.� Send RM-reply in the same channe. Doug: I am suggesting to send one way message at application level, you can use the response reply pattern.� The underlying response that will occur is an rm artifact that the producer is not aware of. Sunil the no in 5.2 table is appropriate. Doug: I am sorry, but for everything I have seen, section 5.3 is about the producer consumer interface view.� From its point of view it is about producer.� Sunil: WSDL is for consumer interface period, it is not for RM information.� If a consumer operation is wsdl 1.1 one way operation, you cannot use response reply pattern. Doug: lets move on, If Sunil thinks there is a need for a restriction here, lets talk about it on the email. 2c)
The matrix in section 5.2 also was the first to
introduce the idea that ���� the consumer� could provide information intended for� the producer.�
We ���� needed to extend
the abstract model to introduce this earlier and avoid ���� a contradiction
between the matrix and the model.� I
believe this issue ���� has become
editorial as we discuss the details of the edits necessary. Will get back to this. 2d)� When using� the Response� RM-Reply pattern,� the�
immediate underlying ���� response� may be�
lost� and the� sending�
RMP may� query� using a�
Poll ���� request.�� Should the response� to such� a "spontaneous"� Poll indicate ���� which� referenced messages� included consumer� payloads in�
the earlier ���� response?� The sending RMP might� "just know" a consumer
payload may be ���� available
from� information the consumer� provides (WSDL, say)� or some ���� other means;
an� indication of a consumer payload� in the Poll response ���� informs the
sending� RMP directly.� The sending RMP� can already decide ���� when a resend
might be� necessary and any indications
the receiving RMP ���� provides would be
a new extension to the WS-Reliability protocol.�
Such ��� �an� extension
would,� primarily, reduce� the size�
of the� known subset ���� requiring
resends� since any a� priori information would� indicate only ���� that a consumer
payload had been possible. Doug: when sending rmp uses request pattern, it may later use poll to querry response.� There is some additional info it might have to indicate a consumer payload was sent with the original response.�� Because the sending RMP has some info about consumer payloads being possible, this might be an optimization. Jacques: I agree we need to discuss this, but I do not want to extend the scope of what we mean by reliability 3)
The� description
of� duplicate� elimination in� section�
3.2.2 does� not ��� describe� the�
content� of� either�
the� immediate� underlying�
protocol ��� response nor an
RM-Reply that may be sent later (in the callback or poll ��� RM-Reply cases).�� In particular, whether or not� consumer payloads from ��� the response sent
the first time� (in the case when the
earlier response ��� had� been�
lost)�� may� be�
returned� during� this��
iteration� is� left ��� unspecified.� As Sunil has� stated, some have implementation
issues with ��� caching�
payloads� in� the�
receiving�� RMP� though�
this� is� the�
most ��� appropriate way to
handle the� duplicate message.� We might thus avoid a ��� new requirement
but concentrate on ensuring caching is allowed. Doug: we are not specifying much at all about how the receiving RMP needs to respond about a duplicate message.� How often the notify is called. Tom: There are a lot of possible solutions to this problem. Jacques: my last mail discusses about how we discuss this problem. Talk about details of Jacques counter proposal in next section. Doug: we are in the solution space about this problem, we agree there is a problem 3a)
Sunil mentioned� in
a private email that no RM-Reply� pattern
at all is ���� used unless an
acknowledgement was� requested.� I have not searched but ���� am� pretty sure� we have�
not described� RM fault� semantics, duplicate ���� elimination nor
consumer payloads in this situation.� For
example, will ���� the� callback be� invoked or�
the� poll include� any information� about ���� successfully
delivered messages when AckRequested did not appear
in the ���� original
message?� I suspect we moved the ReplyPattern element out from ���� under the AckRequested� to
allow more generality here� but the
existing ���� text implies an
RM-Reply is always publicized. Tom: I agree there is clarification needed if poll� response in response reply pattern, would the receving RMP need to remember ack without ack requested. Doug: we need to clarify this. 4)
The� RM� Fault processing� model�
described� in� section 4.5�
previously ��� attempted to cover
responses to duplicate messages though the reader was ��� not directed here
from 3.2.2 "Duplicate Elimination".�
I believe we have ��� agreed� not to�
lump� faulting� and responding� to� a
duplicate� message ��� together� in the�
document and� have addressed� the editorial�
issues in ��� section 4.5. agreed to separate the duplicate elimination as a separate issue. 4a)� Sunil has� outlined a� few�
issues with� including a� SOAP fault�
when ���� returning an� RM fault.�
If� I
remember correctly, the� original reason ���� for this addition
was avoiding an� empty SOAP Body when the
sending RMP ���� expected a
consumer payload.� If� we accept all of the restrictions and ���� clarifications
mentioned above (in (1) especially), the problem will be ���� limited� to�
use of �the� Response�
RM-Reply pattern�
(request-response ���� underlying� protocol utilization)� with a�
consumer� response expected. ���� The SOAP� Fault would cause� the underlying protocol response� to match ���� the� signature expected� in that�
case but� may� cause interoperability ���� problems� in other� cases.��
Sunil� would
like� to�
avoid the� inherent ���� redundancy
of� a message containing both� SOAP and RM�
faults.� He also ���� points out that
"send a SOAP fault" is not specific enough. Need to clarify these points in the soap processing model. 5)
The�� specification�� is��
generally�� vague� about��
the�� meaning�� of ��� "application-level"� and talks� about WSDL�
primarily as� describing the ��� producer /� consumer interaction without making� this distinction clear. ��� In some� cases, WSDL operation or� MEP types are applied� at all levels. ��� As a� relatively editorial matter, we
must� clarify distinctions between ��� exchanges� controlled by� the RMP�
processing ("underlying�
protocol" or ��� SOAP� message exchanges)� and how�
the� RM-Reply patterns� map to�
those ��� exchanges� and the� producer /�
consumer interface� (sometimes
described ��� using
consumer-provided WSDL).� In effect, the
producer and consumer sit ��� on top� of an RMP that� is (abstractly) implemented� using an underlying ��� SOAP�� processor.�� That��
SOAP� processor�� provides�
the�� one-way� or ��� request-response
message deliveries used for the RM-Reply patterns.� The ��� RMPs� effectively� provide�
another,� higher quality� of�
service,� WSDL ��� binding that the
producer and� consumer use to
interact.� We probably do ��� not need to
include the SOAP processor explicitly in our model but we do ��� need� to�
be clear� throughout� or�
document� what level� is�
discussed. ��� Primarily, section� 5.2 will be the� main place in which� the producer / ��� consumer
interface� come to the fore.� And,� no, this is not� as large a ��� change as it
seems. Doug: we need to add clarity in the document to fix this explanation. Doug: I hope we do not have to change the HTTP bindings chapters.� We may not have to change the HTTP binding of our protocol. 5.3 PC25
�� RE: [wsrm]
clarification on Respond primitive Title: RE: [wsrm]
clarification on Respond primitive I think we need to state clearly the problem we
try to solve here, as it seems to exceed the one
summarized in #3: (A) Are we trying to guarantee the delivery of
the response in an underlying�
request-response MEP, �("Respond" invocation on receiving
RMP)? (or of a complete request-response transaction?) Which, as we have investigated long ago (study
September 03), is not that simple and subject to severe implementation
limitations, not just caching. I thought we had decided to leave it out for
this release. (note that in such case, a duplicate
generated by resending should be treated differently from a duplicate generated
from network problem). Jacques: the discussions on the Mailing list have been about A.� Doug: in this thread you have described a related, but somewhat different problem.� Two ways for the receiving rmp to response can happen.� The sending RMP needs to ensure the notify is not sent more than ones.� Tom: we need to add text about not having the notify sent twice. Jacques: the respond and notify message flow is not subject to reliability. Doug: I was no suggesting that.� There are many ways to get duplicate response. Tom: we should allow the caching solution for the duplicate response, but we should not require. Jacques: we had earlier proposed a reliable response.� We cannot guarantee delivery of response. Tom: Are you concerned about the receiving RMP being allowed to send a cached response. Doug; I would prefer recommended to cache, but I have not proposed a must for the cached response.� No one has suggested a three way handshake to ensure the response is received.� I am hoping to allow the consumer payloads to ride on the duplicate response.� I do not want to require a soap fault in this condition, which will prevent invisible reuse of cache payload. (B) Or, more modestly, are we trying to avoid
some side effect of acknowledging duplicates in underlying� request-response MEP, which translates into
the receiving RMP sending back a response (to the duplicate) that looks like a
valid message to the sending RMP (with an RM Reply, and whatever payload) but
that the sending RMP must NOT pass to its
Producer ("Notify")? The safest way to do allow this filtering, I believe, is for the
RM Reply to tag the message ID in the RM Reply, as "duplicate"
instead of ack. (That is what I was suggesting,
though that is more than editorial...) Tom: are you suggesting a new reply type, acked duplicate.� This would not be a fault. Jacques: this is getting into the solution space.� We need to clarify the spec in this area. Tom: I am not sure we need this new reply type.� We need to discuss it further. Doug: I am not entirely sure that this new indicator would solve the problem. Jacques I suggest we leave this for discussion. NOTE:�
messages produced by a Consumer via "Respond" could still have
guaranteed delivery even if we don't solve (A). The problem lies in the
underlying request-response MEP, so we don't have to tie - in our spec - the
use of "Respond" with the response leg of such an MEP. Note also that if a Producer could be notified -
e.g. by a subsequent Poll - that its request has been well delivered (acked) even if the response is lost, that might be quite
sufficient, and allow the Producer to take appropriate action, which may vary
depending on whether the request was idempotent or not. Jacques; where we bring value with WS reliability, is that an independent spontaneous poll, the sender would know whether the request was correctly delivered is valuable.� If the request/response failed should not depend on whether the response is delivered. Tom: this needs to be discussed further on the list. Thx, Jacques -----Original Message----- From: Doug Bunting [mailto:Doug.Bunting@sun.com] Sent: To: Jacques Durand Cc: wsrm Subject: Re: [wsrm]
clarification on Respond primitive Jacques, On ... > Now, here is a position on the duplicate
issue: > - The response to a duplicate - whether
acknowledged or not - should never > be passed through the WS stack of the
sending side. It should be caught > by the RMP > and discarded. The
Producer should never be aware of it, simply because > the Producer > in the first place
did not / cannot have generated this duplicate ! (it > has to originate > at RMP level,
because a duplicate Submit call on an RMP will translate > into different message
IDs.) > - so the question is :
how can the receiving RMP "mark" this response so > that > teh
sending RMP will not pass it to the Producer? This question implies an all-powerful receiving
RMP that also has complete control over the
underlying protocol and can assure itself that no duplicates or unequal
delays will occur during message transfer.�
The sending RMP must be
responsible for filtering duplicate RM-Replies it receives and preventing
redundant Notify invocations.� Such a
requirement is entirely reasonable
since the sending RMP already tracks message identifiers for which
RM-Replies are outstanding. Unless, of course, you have reversed our
abstract model's identification of the sending and
receiving RMP?� In the model, the
receiving RMP publicizes information and
"sends" RM-Replies to the sending RMP. > Jacques thanx, ������� doug 6 Discussion of Document Progression.Tom: do we want a small team. Jeff: lets use the full email list. Tom: I am hearing that all discussion should be on the full list at this point. Doug: the only time I have seen things moving off the mail list is to remove people to not see things that were not required for all to see.� I think that all should see the discussion. Take the entire discussion to the list. Try to make jule 15. Full CD ballot ending before prior July 15 meeting. Tom: we should try to meet July 15 deadline for submitssion. Tom: Should be schedule two hour meetings on Tuesday starting at 530 eastern time. 7 Potential Vote for CD progressionDraft Not ready, due to new issues 8 Potential Vote for OASIS Submission for Member vote of CDDraft no Ready, due to new issues 9 Frequently Asked QuestionsTom posted the following: �� Approved
FAQ set for WSRM TC This is low priority, will keep open 10 New businessSunil will put new schemas on the draft folder.. Jacques: I would liked to talk about underling protocol.� Request response vs. one way is alternatives.� Doug has stated that one way can be done with http.� When we look at soap binding, all we have is one, http is request/response protocol we have to straighten up our terminology.� We need to be more precise here.� If we no longer make assumption of underlying request/response, we have to make the difference of bindings to one way underlying (say smtp), and the request/response underlying binding. Doug: I am not sure what the best words are, but we can come up with proper terminology. Jacques: I am pointing out things that need to be clarified in our messaging model. Bob F moved to adjourn, Mark Peel seconded. Adourned. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]