Preliminary Thursday WSRM Minutes
Thursday: Oct 30,
2003
8
Review of Homework Assignments/proposals
8.1
Group Termination
Email from Jacques with Tom Rutt
comments
> Jacques Durand wrote:
>
>> Here is a proposal which,
I believe, should address all concerns heard this afternoon,
>> first
and foremost from Sunil. (Close to what he proposed in fact, but with nicer
handling of "corner cases"
>> It looks a bit detailed,
but I believe is in fact very "implementable".
>>
>> Jacques
>>
>>
-----------------------------------------------------------------------------------------------
>>
>> Background:
>> Let us start with precise
semantics: We had 3 possible (non -exclusive)
>> semantics
for expiryTime:
>> (1) business semantics
(how long a message still makes sense for the application)
>> (2) RMP management
semantics (how long should we try to make available to the app
>> before giving-up)
>> (3) dup elim semantics: when "at most once" is required,
a message should be subject
>> to
dup elim as long as it has not expired.
>>
>> So far, our spec mostly
talks of (2).
>> Several of us believe it
is none of RMP business to enforce (1).
>> As for (3), there is an
obvious impact from (2), as by definition, a duplicate of
>> an
expired message would never be delivered, even if we skip the dup check.
>> That mostly spares us a
dup check.
>>
>> General approach: we
endorse semantics (2) and (3).
>> For individual messages
(group singletons), dup check is done over all past
>> messages
that have not expired yet, and we keep this mesg ID
store up-to-date.
>> But for groups, we do not
want to have to store each message expiry time,
>> along
with message IDs (GroupId + seq
number). That would undermine the
>> fast
and space efficient check that groups are supposed to provide in general.
>>
>> General Proposal:
>> - we keep everything of
what has been "decided" (or formulated for decision) so far.
>> - we still assume each
individual message of a group has expiryTime.
>> Like for singletons, a
message in a group would not be delivered to app if it has expired
>> when
received. However we do NOT memorize this expirtyTime
after first check.
>> (of course, in case we
need to keep all undelivered messages of a broken sequence on receiver,
>> we
keep the entire messages and therefore their expiryTime.
We decide to give-up
>> if the
max of all expiryTimes of waiting messages has
expired.)
>> - for the sake of
simplicity, the receiver RMP will keep the ID of all past
>> messages
for an active group, whether expired or not.
>> That is, once they have
been delivered to app, RMP will NOT try to
>> manage expiry time of past
delivered messages, and will NOT discard from memory
>> the
message IDs of those expired, like it would for singletons.
>> Duplicate checks would be
made over ALL past messages for the group, whether expired or not.
>> There is no added cost in
fact, as these IDs are remembered as seq num
intervals.
>> Will even be faster, as
not discarding means fewer intervals.
>>
>>
>> Refined Proposal when
groups terminate:
>>
>> NOTE: In the 3 following
termination cases, "discarding" a group means removing
>> everything
(state, msg IDs, message bodies), and not doing
anymore
>>
duplicate checks for these. Any late message from this group will be
treated
>> as
from a new group.
>>
>> Termination (t1): when a
group terminates because its GroupExpiryTime
is over,
>> it
is completely discarded from RMP (state, message Ids and payloads).
>> No duplicate check is done
against that group ever. If a "late duplicate" arrives,
>> it
would be automatically discarded due to its expiry time.
>>
>> Termination (t2): when a
group terminates because its MaxIdleTime
is past,
>> its
messages may not be expired yet. We do not keep expiryTime
of each message
>> of
the group, however we keep the max of all expiryTimes
of messages received
>> so
far. We use this max as the GroupExpiryTime, and wait
for this time -if needed-
>> before
discarding the group. We fall back then to termination (t1).
>> In case a new message
arrives after maxIdleTime expires but before the group
expires,
>> we
need to define what to do: I suggest we process it and keep bumping up the max
>> of
all expiryTimes if needed (so dup check still enabled
for the group).
>>
>> Termination (t3): when a
group terminates because it receives a status="end" message.
>> Note that this only tells
us "no greater seq number will be received
after".
>> Like in (t2), its messages
may not be expired yet. We treat it like in (t2): the max
>> of
all expiryTimes tells us when the group should be
discarded, and not subject
>> to
duplicate check. The group may still have missing messages that are late. Subcases:
>> (3.1)If
the group is complete, still use max of expiryTimes
before discarding it.
>> (so dup
checks still possible, but we know are useless after that.)
>> (3.2) If
group has missing messages, wait for these to the extent allowed by
>> either
GroupExpiryTime, or maxIdleTime (whichever was specified), then fall back on
>> either
(t1) or (t2) respectively.
>>
>>
>>
Tom Rutt:,
given we relax the condition of requiring at least one of the two groupExpiryTime or GroupMaxIdleDuration.
(i.e., both are truly optional presence):
add a new termination condition:
T4) If there is neither a groupexiryTime nor a GroupMaxIdleTime,
derive a CurrentGroupExpiryTime as the max expiryTime of all received messages in group. Then use t1 criteria.
Message ExpiryTime is under
control of the sender. If the receiver keeps
an ongoing calculated
statistic of the "maximum
expiry time over all messages received in this group", and uses that as
the
GroupExpiryTime, it will be a more
conservative algorithm than any of the three in Jacques proposal.
The MaxIdleInterval was there to
terminate open ended sequences. Keeping
a current statistic on the maxExpiryTime for messages
received for this group also terminates open ended sequences.
This also takes away what would be a source of error, users
not knowing how to determine
the correct groupExpiryTime,
before starting a group.
Sunil
>> Termination (t3prime):
when a group terminates because it receives a status="end" message –
Delete the group state information as soon as all the messages with smaller sequenceNo are delivered to app. Do not start group until the “start” message
is received.
Bob F – Duplicate elim has to work
the same within or without a group. We
have the messageId (groupID,OptSeqNO) and expiry time which are what is used for
duplicate elimination.
Bob F – we may not need group terminition
parameters for criteria. Construction of
group is complicated by allowing un-ordered group.
Sunil’s optimization is to save space for holding state on
the receiver side.
Bob: two conditions:
- Explicit Stop, - then wait for all received messages to expire
before removing group persistence
- Last message received for that group has expired.
General concensus
on Jacques proposal plus the additional t4 condition to cover case when neither
groupexpiryTime or GroupIdleInterval
are present for the group.
8.2
Figures for Section 2 Model
Iwasa presented his new figures
for section 2, at http://www.oasis-open.org/archives/wsrm/200310/msg00100.html
It was pointed out that “(reliable message)” must be
attached to the top arrows for the three proposed section 2 figures, as is done
for the (Poll), and (Ack, Fault)
In section 5, RM Request should be changed to (reliable
message) in all the figures, and “RM Reply (ack,
fault)” should be “(Ack, Fault).
9
Timing Issue Resolutions
9.1
Rel 50 semantics of ExpiryTime
Agreement that ExpiryTime has
following semantics (from Jacques proposal above):
>> 1) RMP management
semantics (how long should we try to make available to the app
>> before giving-up)
>> 2) dup elim
semantics: when "at most once" is required, a message should be subject
>> to
dup elim as long as it has not expired.
The first semantic, 1) is already in the spec,
however we need to add the second semantic, 2), to the spec.
Should clarify that the semantic 1) has repercussions on the
sender’s and the receiver’s persistence requirements.
Doug: What happens when app does not retrieve the messge on the receiving side, even though it is in the rmp queue for delivery to the app, and that message expires. This is a
distributed state management issue.
The text in 1) is ambiguous.
Doug::
we need to avoid the receiver Eventually giving up with the
sender not knowing the receiver has given up.
Do not want to have the sender think the message was delivered, when, in
fact, the rmp has given up before the message has
been delivered to the receiver app.
Can have either:
- Expiration
time is checked once and the receiver rmp never
gives up trying to deliver to the receiver app after it has acknowledged
that message, or
- have a way to return a fault to sender before giving
up.
Sunil: Alternative could be to send ack
only when the rmp makes available to the user. However, we dismissed this alternative at
past meetings.
There are places where we have acked
a message, but later it is thrown away because the group is terminated.
Doug would prefer the message is never thrown away once it
has been acked (except for terminating a broken
sequence).
Jacques;
as soon a message has been acked
(except for broken sequence condition) it must always be made available to the
user.
1) RMP management semantics - When
receiving a message, the RMP will not process it further if it expired).
The text in 2) is ambiguous.
There are two queues, one where the rmp is
holding an unordered message from being made available.
>> 2) dup elim
semantics - when "at most once" is required, a message should be
subject
>> to
dup elim as long as it has not expired, .or was not
discarded by the RMP due to an unrecoverable broken sequence with ordered
delivery in use.
Sunil case: Later message expiring while orderedDelivery
buffer is waiting for a message -
Doug: The broken
sequence case is not a problem, with the Jacques proposal. For the broken sequence case, the sender
knows that at least one of its messages in that sequence was not
acknowledged. The sender can throw a
message in its sending buffer always once that message and all the messages
before it have been acked.
Need to avoid:
Have a broken sequence, the missing message arrives and is acked
Ack means that the receiver rmp has received the message, and will deliver it to the
user unless
- any
messages with lower sequenceNo than that acked message have not been received by the time that:
the group persistence (groupID, receivedSeqNO list, outOFOrderMessages
not yet made available to receiving app) is removed by the receiver rmp, due to group termination conditions
Ordered example 1
group
expiry 10pm
1 – exp4pm
(start) sent at 0 pm
2 – exp8pm
(continue) sent at 0 pm
3 – exp 4pm (end) sent at 0 pm
receive 1
- at 1pm
ack and made avialble to
user
recieve 3
– 1.05 pm then ack and buffered (not made available
yet, waiting for 2 until group persistence removed due to termination
conditions firing, do not terminate at 4Pm
2 is never
received.
Group is terminate at 10:pm – terminate group, removed 3 from group persistence
buffer (i.e, will not
be made available to user)
Ordered example 2
without GroupExpiryTime and without GroupIdleInterval
1 – exp4pm
(start) sent at 0 pm –
2 – exp8pm
(continue) sent at 0 pm –
3 – exp 4pm (end) sent at 0 pm
receive 1 - at 1pm
ack, derived
get=4pm then make avialable
to user -
recieve 3 – 1.05 pm
then ack – derived get=4pm,
and buffered (not made available yet, waiting for 2
4pm
– group terminated, 3 removed from messageOrder
queue, will not be made available to use.
receive 2
– at 6:00 PM – acked
and start new sequence. Derived get=8pm,
will be buffered waiting for 1
8pm
– terminate new sequence, remove 2 from buffer will not be made available to
user.
Ordered example 2 has the problem that the sender has all three
messages acked, however 2 was not made available.
Ordered example 3
GroupExpiryTime
8:00pm
1 – exp4pm
(start) sent at 0 pm –
2 – exp8pm
(continue) sent at 0 pm –
3 – exp 4pm (end) sent at 0 pm
receive 1
- at 1pm
ack, derived
get=4pm then make avialable
to user -
recieve 3 – 1.05 pm
then ack – derived get=4pm,
and buffered (not made available yet, waiting for 2
8pm
– group terminated, 3 removed from messageOrder
queue, will not be made available to use.
8pm
– terminate new sequence, remove 2 from buffer will not be made available to
user.
receive 2
– at 9:00 PM – expired, not acked and do not start new sequence.
Sunil pointed out that the processing rule from wed minutes
no longer holds
- any information persisted in receiver RMP for a message
in the group is removed from persistent store when the message expires.
Need to leave all timing issues
open, for further discussion on email list.
We agreed at last f2f meeting to Weekly telecom hourly
meetings, (2:30 TO 3:30 pm , until end of December).
Starting Nov 4.
Rel-50 – semantics of expiryTime
REL-52: New rules for persistence
REL-57: Ordering and Missing Message Behavior
REL-97: GroupID lifetime (RemoveAfter)
10
Implementation Conformance Discussion
Conformance Matrix for Sender
|
|
Guaranteed Delivery
|
Duplicate Elimination
|
Message Order
|
|
ResponseReplyPattern
|
|
|
|
|
CallbackReplyPattern
|
|
|
|
|
PollingReplyPattern
|
|
|
|
Conformance Matrix for Receiver
|
|
Guaranteed Delivery
|
Duplicate Elimination
|
Message Order
|
|
ResponseReplyPattern
|
|
|
|
|
CallbackReplyPattern
|
|
|
|
|
PollingReplyPattern
|
|
|
|
Tom stated that the conformance matrix for sender
implementations should be granular. The
sending application must be able to do the things that it indicates in the
headers of the messages it sends.
Thus a sending RMP is free to implement any of the nine
cells of the conformance matrix.
To assist interoperability, we should partition the receiver
conformance matrix into a small number of conformance classes. One example follows with two conformance
classes for receivers (basic and enh):
Example 1) Receiver conformance with two levels of
conformance
|
|
Guaranteed Delivery
|
Duplicate Elimination
|
Message Order
|
|
ResponseReplyPattern
|
Level1, Level2
|
Level2
|
Level2
|
|
CallbackReplyPattern
|
Level2
|
Level2
|
Level2
|
|
PollingReplyPattern
|
Level2
|
Level2
|
Level2
|
Under example 1
- All receiver implementations MUST support Basic
conformance class, MAY support Enh conformance class.
Example 2: - nine independent conformance classes, sender
pick whatever it wants to implement
Conformance Matrix for Receiver
|
|
Guaranteed Delivery
|
Duplicate Elimination
|
Message Order
|
|
ResponseReplyPattern
|
1
|
2
|
3
|
|
CallbackReplyPattern
|
4
|
5
|
6
|
|
PollingReplyPattern
|
7
|
8
|
9
|
A receiver MUST
implement at least one of the nine conformance classes in the matrix.
Example 1 ensures greater interop
out of the box,
Example 2 will leave more senders unsatisified.
Another example
Example 3) Receiver conformance with another two levels of
conformance
|
|
Guaranteed Delivery
|
Duplicate Elimination
|
Message Order
|
|
ResponseReplyPattern
|
Level1
|
Level1
|
O2
|
|
CallbackReplyPattern
|
O3
|
O4
|
O5
|
|
PollingReplyPattern
|
O6
|
O7
|
O8
|
Under example 3
- All receiver
implementations MUST support Level1 conformance class, MAY
support one or more of the classes O2 thru O8.
Put this to the email list for discussion.
Discuss this further on the list.
11
Discussion of Committee Draft Timing
From the Procedures:
Approval of a Committee Draft
Upon completion of a specification
the TC may approve the work as a Committee Draft. The approval of a Committee
Draft shall require at least 2/3 of the total membership of a TC voting to
approve and no more than 1/4 voting to disapprove.
OASIS TC Administration must be
notified at the completion of any ballot to approve a Committee Draft,
regardless of the outcome of the ballot.
The name of a Committee Draft may
not include any trademarks or service marks not owned by OASIS. The Committee
Draft must use the OASIS-approved document templates and naming, and must
include the OASIS copyright.
(b). Approval of an OASIS Standard
Public Review
Before the TC can submit its
Committee Draft to OASIS membership for review and approval as an OASIS
Standard, the TC must conduct a public review of the work. The decision by the
TC to submit the work for public review requires a majority vote. The review
must be announced by the TC Administrator on the OASIS members
mail list and optionally on other public mail lists. Review must take place for
a minimum of 30 days, during which time no changes may be made to the document.
Comments must be collected via the TC's archived
public comment facility. The TC must record the comments received as well as
the resolution of those comments.
The TC may conduct any number of
additional review cycles (i.e. collecting comments, making edits to the
specification, sending out a revised version for review again, etc.) before
deciding that the review is complete. If substantive changes are made to the
specification after the start of the public review then the TC should conduct
another review cycle. After the conclusion of the review and final changes to
the document, the TC must re-approve the work as a Committee Draft before
submitting it to OASIS.
A first committee Draft requires a 2/3 yes vote of the
TC. However, the TC may have subsequence
ballots for further Committee Drafts, before attempting the vote to put out for
member review.
Thus, to have a “Committee Draft” at the time of the Demo on
Dec 9, we should have voted 2/3 yes on a ballot for First committee draft. To allow a two week ballot to be active on
Dec 9 (Monday) the Ballot for first committee draft must go out on Dec 2, after
the TC teleconference..The
ballot should close at 5:00 PM
Pacific time on Dec 15
Dec 2 – issue ballot for first CD
Dec 15 – ballot closes
Dec 16 – TC meeting to determine next step
Most likely we will need several weeks to produce a second
ballot for Committee draft.
Realistic target for the issuance of second ballot for
Committee draft is middle of January.
Agreed to have Next f2f during week of Jan
12, in the SF Bay area. Specific
days of that week and Host will be decided in the next few calls.
No conference call on demo day Dec 9
We will have weekly one hour TC conference calls, from 2:30 to 3:30
Pacific time on
Nov 4, 11, 18, 25
Dec 2, 16
Jan 6,
12
Resolving Issues with Proposals
12.1Rel 78– meet compatibility requirement R8.1
<issue-num>REL-78</issue-num>
<title>Meet <b>Compatibility,
R8.1</b> requirement</title>
<locus>Spec</locus>
<section />
<priority>Design</priority>
<topic>feature</topic>
<status>Active</status>
<originator />
<responsible />
<description>The Specification should be
usable with other
open standard technologies, if appropriate.<br />R8.1.1<br
/>The Specification shall not preclude the use of Web
Service message attachments. (see also issue
<a
href="#xREL-10">REL-10</a>)<br />R8.1.2<br />Insure
that
the Specification is usable in combination with
WSS SOAP
Message Security to implement secure reliable
messaging.
(see also issue <a
href="#xREL-25">REL-25</a>)</description>
<proposal />
<resolution />
--
Iwasa sent an email to resolve the
attachments part of this issue after editing the group came up with the
following proposal
:
Proposed Resolution regarding
attachments portion of the issue:
Create a new section "Section
2.9 Attachments" and include the following description:
2.9 Attachments
When this spec is used with W3C
note “SOAP messages with Attachments” specification, the following rules MUST
be met:
1) The first MIME part MUST include whole SOAP
envelope
with WS-Reliability header elements.
2) The charset of the Content-Header of the first MIME part MUST
be either UTF-8 or UTF-16.
3) Zero or more additional MIME parts MAY be
included in a reliable message.
4) The receiver RMP MUST make available, to
the receiving application, all MIME parts in a reliable message
--
W3C SOAP messages with Attachments:
http://www.w3.org/TR/2000/NOTE-SOAP-attachments-20001211
Agreed: Split
issue 78 to move attachments portion to a new issue 100.
Amend Issue 78 to remove reference to Soap With Atachments.
Agreed to record the proposed resolution above as a pending
resolution to new issue 100.
Confirm pending resolution at a future TC teleconf.
12.2REL-31:
Meaning of guarantee
--
REL-31 Spec 1.1.2 def Design Unassigned Peter Furniss
Title: Meaning of guarantee
Description: Meaning of guarantee needs to be defined (i.e.
it is OK to announce
failure of meeting guantee in a particular case)
Related to crash tolerance, see REL-5
When is a guarantee not a guarantee? Message corruption
issue may come up
here. Should be
specifying a protocol and its failure modes (relatively complete).
One case: Recipient loses all of their
message identifier store and can no longer
detect duplicates. Recipient system
failed and sender is not notified. Outside
the scope of the protocol, one of
the partners no longer playing. Need to
document the limitations of the
protocol. (Cannot document correct error
message for case where sender of
that error does not know what is going on.)
Iwasa sent the following mail:
Here is a proposal for REL31:
Guaranteed delivery - To deliver a
message from a sender RMP to a receiver RMP without failure, or to report
failure to the sender's application. To realize guaranteed delivery, the
message MUST be persisted in the sender RMP until it delivery to it's receiver is acknowledged, or until the ultimate failure
is reported to it's sender. There is a
requirement of the underlying transport protocol that the message MUST be
transported without corruption (i.e, the transport
protocol will not let corrupted messages arrive at the receiving RMP).
When message persistence is lost
for any reason, it is no longer possible to continue to guarantee message
delivery. Since the reliability of
message persistence is A property of the system implementation, the conditions
under which guaranteed message delivery holds is also a property of the system
implementation..
Example 1).
A PC Server may use a HDD for it's persistent Storage,
and those messages persisted in the HDD are reliably maintained even if the the system software crashes and the system is rebooted.
However, if the HDD itself crashes, it is no longer possible to guarantee
message delivery
Example 2) .
A message persisted in a mobile phone may be lost when it's
battery is detached. In this case, message delivery is only guaranteed by
proper battery maintenance of the mobile phone.
Agreed to record this as a pending
resolution to issue REl 31.
12.3REL-32: Add
new terms from requirements
--
REL-32 Spec 1.5 def Editorial Active Iwasa
Title: Add new terms from requirments
Description: See resolution for definition issues.
--
Iwasa email:
Here is a proposed resolution for
Rel-32:
Add the first seven definitions in
Requirement document
at Section
3.2 Definitions to the Specification
at 1.8
Terminology.
Thanks,
Iwasa
From Requirement document:
3.2.Definitions
Reponse RM-Reply Pattern :
We say that a
response RM-Reply pattern is in use if the
outbound
Reliable Message is sent in the underlying protocol
request
and the Acknowledgment Message (or RM-Fault
message)
is contained in the underlying protocol response
message
corresponding to the original request.
Callback RM-Reply Pattern:
We say that a
callback RM-Reply pattern is in use if the
Acknowledgement
Message (or RM-Fault message) is
contained
in an underlying protocol request of a second
request/response
exchange (or a second one-way message),
operating
in the opposite direction to the message containing
the
outbound Reliable Message.
Polling RM-Reply Pattern:
We say that the
polling RM-Reply pattern is being used if a
second
underlying protocol request is issued in the same
direction
as the one containing the outbound Reliable
Message
to act as a request for acknowledgement. The
Acknowledgement
Message (or RM-Fault message) is
contained
in the underlying protocol response to this request.
This polling
pattern is expected to be used in situations where
it
is inappropriate for the sender of reliable messages to
receive
underlying protocol requests.
Agreed to record the above as a pending
resolution to Rel 32.
12.4REL-34: Figure
4 needs refinement
Resolved by current Spec draft.
Close issue as resolved by current draft.
12.5REL-35: Header
processing order
REL-35 Spec meta Design Unassigned Scott Werden
Title: Header processing order
Description: Need to determine impact of header processing
order, particularly when used in conjunction with WSS.
Mail from Iwasa:
Here is a proposed resolution for Rel35:
Proposal:
Unless otherwise agreed between sender and receiver,
security related header(s) must be processed before any
reliable messaging header specified in this spec
is processed, when this specification is used with
security related specifications.
Thanks,
Iwasa
Sunil: Is this
requirement on the RMP or the soap processor?
It was agreed that such a statement is outside the scope of
this specfiction.
Agreed to pending resolution of
issue 35, as Closed with no action, because it is outside the scope of this
spec.
12.6REL-82 to
REL-86: Parameters
Agreed to leave open until after
resolution of the protocol timing parameters.
12.7REL-87: New
WS-R Headers
Leave open until after resolving protocol timing parameters
block of issues.
12.8REL-94:
Polling RM-Reply Pattern design
Agreed to pending resolution from Sunil’s
latest email (also in Wed minutes).
12.9New issue from
Tony Graham
Doug stated, for interop purposes
we need to describe what are the specific rules for comparing
URI values in our specification.
Eg, is case significant,
Eg. Is padded white space significant
“joe
“
:”joe”
Doug stated we should align with the W3C TAG discussions on
this matter.
Agreed to add this as a new issue Rel 101.
12.10
From and To
Jacques asked for clarification of why we removed from and
to elements from the earlier draft.
Tom Stated we made this decision because the protocol does
not use either of them.
Sunil stated that all headers are extensible, and an implementation
could put them in the extension, however that would
not be interoperable.
Jacques stated that we could add a clarification statement
into the specification on why from and to elements are not included in the
protocol.
If anyone provides such proposed clarification text, the TC
should review it.
12.11
Rel 38 –Timestamp
Agreed to pending resolution of closing
issue 38 by removing timestamp.
13
Wrapup
Action: Iwasa to provide the next
draft spec before the next TC meeting.
Action: Sunil will distribute a new pending schema document
to the email list, but will not post it to the server.
The meeting participants thanked Pramila
and France Telecom for the excellent hosting arrangements for the meeting.
Motion to adjourn by Marc G, seconded by Sunil
Adjourned at 4:25.
Put pending issues resolution as first thing on agenda for
Tuesday.