Wednesday
AM:
8:30 Coffee
9:00
6
Review of Homework Assignments and Continued
Issue Resolution
6.1
Updated Messaging model
Iwasa presented his updated
messaging model, http://www.oasis-open.org/archives/wsrm/200310/msg00093.html
.
The group participated in edits to the diagrams, to use
terms RM Request and RM Reply..
Agreed that requirements 3.2 section should be used as basis
for what is explained in section 2.
Agreed to have three pictures in section 2, using arrows for
Underlying transport request and Underlying transport response.
Add text from 3.2. of requirements
to section 2 of spec.
Leave figures for section 5 as amended by Iwasa email..
6.2
Polling Mechanism homework – Rel94
Sunil presented his homework on the Polling model and
schema.
FINAL REL 94 Proposal.
The group agreed to
accept the proposal with one change:
- Move the
"request for poll" into a new Header rather than
overloading "AckRequested".
Here is a final proposal
for REL-94 with the required changes.
<Rel94ProposalBegin/>
So the initial msg.
with the intent for Poll ReplyPattern Binding will
have
ReplyPattern
set to Poll and it will have AckRequested sub-element
<MessageHeader>
....
<ReplyPattern>Poll</ReplyPattern>
</MessageHeader>
<Request>
<AckRequested/>
...
</Request>
The poll request will
have a new Header called PollRequest.
An example is as
follows:
<PollRequest>
<GroupId value="a.b.c.com/xyz/001" >
<SequenceNumberRange From="1" To="10"
/>
</GroupId>
<GroupId value="a.b.c.com/xyz/002" />
</PollRequest>
Specifics:
* Intent for Poll
pattern is done using ReplyPattern set to Poll and
existence of the AckRequested
sub-element in Request Header.
* Actual Poll
request will be sent in a
separate Header called
PollRequest
* PollRequest Header could be the one of following:
o If it has one or more GroupId
sub-elements, then it is a
indication
that sender wants to Poll previously
sent message(s).
o There can be one or more GroupId
sub-elements.
+ Values
can be same or different.
o There can be zero or more SequenceNumberRange
sub-elements under a
GroupId.
o If there is no SequenceNumberRange
sub-element, Response should
include all received messages in that Group.
* For Poll Request,
it should only have MessageHeader and PollRequest
Header. It shouldn't have the Request Header. So essentially
one can't
Ack a Poll
request. No useful use case to support it.
* For simplicity
sake, we should mandate that all the messages in a group
should use the same ReplyPattern.
* The Response for
a Poll request will have a MessageHeader and the
ReplyPattern sub-element will be set to Poll.
* The group agreed
to generalize the rule
for all patterns.
[AI: Add this as
a new issue and close it as Resolved.]
So possible requests
are (assume ReplyPattern is Poll for all the below):
1) <PollRequest>
<GroupId value="a.b.c.com/xyz/001" >
<SequenceNumberRange From="1" To="12"
/>
</GroupId>
</PollRequest>
2) <PollRequest>
<GroupId value="a.b.c.com/xyz/001" >
<SequenceNumberRange
From="1" To="5" />
<SequenceNumberRange From="7" To="7"
/>
<SequenceNumberRange From="10" To="12"
/>
</GroupId>
</PollRequest>
3) <PollRequest>
<GroupId value="a.b.c.com/xyz/001" >
<SequenceNumberRange
From="1" To="5" />
</GroupId>
<GroupId value="a.b.c.com/xyz/001" >
<SequenceNumberRange From="6" To="12"
/>
</GroupId>
</PollRequest>
While all the 3 cases
are valid, (1) will be the most efficient and should
be recommended.
And the receiver is
REQUIRED to send back requested Acks for message(s)
that were
received
already.
Note that the
Response will include all received messages in the range
mentioned in
the Request, not just previously un-acked messages.
<Response>
<RefToGroupId value="a.b.c.com/xyz/001">
<RefToSequenceNumberRange From="1"
To="5" />
<RefToSequenceNumberRange From="7"
To="7" />
<RefToSequenceNumberRange From="10" To="12
/>
</RefToGroupId>
<RefToGroupId value="a.b.c.com/xyz/002">
<RefToSequenceNumberRange From="1"
To="8" />
</RefToGroupId>
</Response>
It was also decided
to use the same syntax for bataching acks in
all
the patterns. [REL 75]
[Open Issue: Whether
we need to restrict the semantics for Response
Reply
pattern has to be decided.]
Tdibits:
1.This
request will be sent to the same endpoint as the original
message(s) are sent..
2.Poll
request for a message sent to another endpoint MAY result in
InvalidGroupId fault.
3.Since
it is defined as a Header, it could be defined in the SOAP Binding
part if it is desired.
Possible failure faultcodes are:
1.InvalidGroupId: Even if one of the GroupIds
are wrong or invalid, this
fault will be sent.
2.InvalidSequenceNumber:
Even if one of the SequenceNumbers is wrong or
invalid,
this fault will be generated and sent.
Essentially, all or
none approach wrt to Faults. We should be able to
share
the above
Status values with Fault Codes. Note both are QNAME types
and hence
shareable.
Piggybacking of a
Poll request could either be disallowed or should be
tackled along
with
the general piggybacking problem.
<ProposalEnd/>
This proposal was agreed by the meeting.
7
France
Telecom Executive Briefing
Jean-Jacques Damlamian: (Senior
Vice President of Corporate Technology and Innovation at France Telecom, in
charge of the Group R&D activities, the Directorate of Innovation and the
Directorate of the Intellectual Property and Licensing) gave a short
presentation on the importance of the group finishing its work in a pragmatic
and timely manner.
He addressed concerns about competing efforts, but told us
to focus on producing an easily implementable
standard in minimal time.
7.1
Interop demo status
Bob Freund gave a presentation of the Demo Subgroup status
The presentation was uploaded to give url
December 9 early evening is the demo time at xml show.
Schedule:
New
troublemaker distributed
(Fujitsu)
Oct 6, 2003
Financial services app distributed (Oracle/Fujitsu) Oct
22, 2003
Distribution of binary rmp for
test
Nov 3, 2003
First draft presentation and
handouts Nov
18, 2003
Pre-test at Fujitsu San Jose
CA Nov
18-20, 2003
Final-test at Oracle, Morristown
NJ Dec
8-9, 2003
Demonstration at XML
2003 Dec
9, 2003
Sunil asked which spec version will be used.
Bob F , now using .52 reference
plus errata.
If we get stable, can go for the newest
version.
Bof F: this is a Public demo, no
egg on face allowed. The subgroup will
consider the output of the meeting.
8
Continue resolution of WS-Reliability
Specification Issues
8.1
Timing parameters
Bob F suggested the following:
- The
first message in a non-singleton group with (i.e., a message with the statusAttribute of the sequenceNo
element =start) must have the ack requested
element present. It can have an
empty body, or may have data in the body
- The ExpiryTime of the first message serves to idendify the expiry time for the group.
- All
messages in the group must have an expiryTime
which is less than or equal to the ExpiryTime
for the group.
With the above there is no need for the removeAfter
attribute.
Bob F stated this ensures the delivery of the establishment
of a group
Jacques asked, is it required that
an ordered group requires the messageOrder element to
be present?
Need to add clarification in spec that:
- All
messages in an ordered group MUST have the MessageOrder
element present in the RequestHeader.
- All
messages in an un-ordered group MUST NOT have the MessageOrder
element present in the RequestHeader.
A message in a non-ordered group can either contain the duplicateElimination or not.
All messages in an ordered group MUST have the duplicateElimination element present.
The Expiry time for each message in a group MUST be less than
or equal to the GroupExpiryTime (currently called RemoveAfter).
Bob’s proposal trades off bandwidth and an an extra check that the removeAfter
has not changed, with the requirement that the first message in a non singleton
group always be acknowledged.
Sunil pointed out that the status attribute is defaulted to
continue.
Iwasa stated that one
interpretation is the status attribute must be present if the message is not of
status continue.
This would imply that the first message in the group MUST
have the status=start.
The group does not exist unless a message is received with
status=start.
Sunil stated that putting ackRequested
on the first message does not guarantee that the first message will ever be
received.
Jacques stated that the removeAfter
attribute could always be required for orderedGroups.
Sunil suggested that if we always required the removeAfter attribute, and have the effective removeAfter for the group always be set at the receiver to
the value of the removeAfter attribute of the highest
sequenceNO receiver.
Iwasa scenario:
- first message has removeAfter
of Oct29.
- Later
message has removeAfter of Dec1.
- The
later message reaches the receiver on Oct30.
Iwasa stated the group will be
removed before the later message arrives.
The latter will be taken as establishing a new group.
The Iwasa scenario is a problem if
the removeAfter is allowed to change.
Tom suggested alternative:
The sender sends each message in group with ack
requested and removeAfter present, until it gets is
first ack message.
After that it does not need to send removeAfter. In all cased removeAfter
value is always the same for every message in the group (if present).
Jacques states this forces use of of
guaranteed delivery even if they do not want it. He expressed opposition to this proposal.
Proposal:
- RemoveAfter MUST be present for non-singleton groups
- RemoveAfter MUST always have the same value for all
messages in non-singleton group.
- If
receiver detects different value in sequence, it MUST return a specified
RM fault (InvalidRemoveAfter)
- RemoveAfter MUST not be
present for a singleton group. If
received, the sender MUST return the (invalidRemoveAfter)
rm fault.
This has the advantage that any single message in the group
will serve to establish the group.
An ordered sequence will not deliver messages if the first
message in the sequence is not received.
Nothing can fix this, it is a property of
guaranteed order.
Change the name of removeAfter
attribute to GroupExpiryTime Attribute.
Enforce rule that expiry time for every message in group
MUST be less than or equal to GroupExpiryTime.
Bob F asked if we could have two alternatives for groups:
- Finite
Group Expiry time
- Specific
maximum IdleTime for group.
This would result in a choice element called “RemoveAfter” with two possible arms in the choice:
- GroupExpiryTime
- GroupMaxIdleTime. (seconds).
This will not work for attributes since they cannot be
complex types.
Sunil asked why we could not have both allowed, with the
first one firing taking precedence?
If we made them both allowed, then non-presence of GroupExpiryTime would indicate arbitray
length group
Question: if GroupExpiryTime not present, does maxIdleTime
have to be present. Answer is yes
This would simplify the protocol.
New proposal:
·
Two optional attributes, GroupExpiryTime
and GroupMaxIdleDuration,
·
Neither allowed to be present in singleton
groups
·
For non singleton groups, at least one must be
present
·
Non presense of GroupExpiryTime indicates arbitrary length group.
·
The presence and values of both attributes must
be identical for every message in the group.
·
If both are present, the first criteria that fires terminates the group.
·
Presence of status=end always takes precedence
to terminate the group.
·
If groupExpiryTime is
present, its value must be greater than or equal to the message expiry time for
each message in the group.
·
When a group is terminated for any reason above,
all messages and group state information are removed from receiving rmp persistence.
·
Processing order constraints must be clarified.
The first message received in group is the one whose
parameters are used. If values are are not same a fault could be sent.
Doug B suggested we simplify the protocol by not requiring
constraint checking at the recipient side.
Sunil stated we could senf fault
on message, but continue the group processing.
Timestamp: must the
resend have the same timestamp value as the original.
Question:
What does receiver do if message in group has different GroupExpiry or GroupMax Idle - InvalidGroupTerminationCritera
What does receiver do if a message in group has expiry time
later than the group expiry Time – InvalidExpiryTime
Assume that protocol has validity restrictions on the three
parameters, expiryTime, GroupExpiryTime,
and GroupMaxIdleDuration.
Strongest possible enforcement – receiver must check the
validity of timing parameters on every message received, and if it detects an
invalid paramer, it must send a fault and MUST not
process message further
Jacques – this is a tradeoff of verbosity with
complexity.
Weaker alternative:
If receiver checks and detects invalid parameter condition, is must send
fault and not process message further.
However, checking is not required.
Straw poll:
Strongest alternative: 7
Weaker alternative: 2
Jeff Moved to accept strongest alternative, Dock seconded.
Doug B opposed 1
In Favor 9
2 obstain.
Motion passes.
Sunil stated that with this proposal, we would not need
knowledge of additional config parametes
for global limits and defaults.
We need to go thru each of the issues in the block to see if
the proposal closes them.
Marc: we need an exception if the value of the groupExpiryTime is greater than what the receiver is
willing to accept.
Timing issue checks:
8.2
REL-38: Timestamp
Bob F – the protocol does not use timestamp anywhere. Thus there is no need for this parameter, If the application
needs a timestamp, it should be put in the payload.
We used to have timeToLive which
was added to the timestamp.
Leave issue open, try to resolve on
Thurs meeting.
Jacques – the decision to keep it or not may be impacted on
whether the next version needs it or not.
6.1
REL-45: Handling message delivery failure cases
Leave open as low priority issue
6.2
REL-50: Semantics of message ExpiryTime
Jacques stated this is not yet resolved, and that the new
timing parameter proposal above, needs to be further clarified.
Potential refinement of Processing order constraints:
- Receiver
RMP must check for message expiration
- if
expired , receiver sends a fault with refToGroupID
present, and does not process message further
- If
not expired,
- If
duplicateElimination or messageOrder
is present in message, persist state information for group, and then
return ack
- Receiver
RMP executes duplicate ID check if duplicateElimination
element is present.
- If
duplicate detected discard duplicate message
- If
duplicate not detected
- If
ordered delivery not in use, make available to receiver app
- If
ordered delivery is in use, retain for proper order of making available
to user.
- For
a singleton message with duplicate elimination present, when expiry time
is reached, all information about that singleton group is removed from
receiver rmp state
- For
non singleton groups,
- when
the group terminates due to groupExpiryTime
criteria, all information about
that group is removed from receiver rmp
persistence, including the stored messages in the orderedDelivery
case
- When
the group terminates due to status=end condition, stop adding new message
sequence numbers larger than the sequeneNumber
of the end message into the receiver rmp
persistence for that group (and return fault), but keep all existing
persistence information for that terminated group
- When
the group terminates due to GroupMaxIdleDuration
condition, stop adding new messages with sequence numbers larger than the
highest sequenceNumber received into the
receiver rmp persistence for that group (and
return fault), but keep all existing persistence information for that
terminated group
- any information persisted in receiver RMP for a
message in the group is removed from persistent store when the message
expires.
- When
last message in terminated group expires, all state information about
that group is removed from receiver rmp
persistent store.
Tom: Alternative way to state the last major bullet:
- For
non singleton group termination (for any of the three reasons) stops a
group from accepting messages with higher sequence numbers than the
largest sequene number received before
termination of that group. For all
non accepted messages a “TerminatedGroup” fault
is returned. However, the persistence for a particular message already
accepted into that group at the receiver rmp is
saved until that message is expired.
Sunil alternative:
- when group expires, receiver rmp
eliminate all state information, which means ordered delivery and
duplicate elimination stops working for that group.
Bob alternative:
- For
a non-singleton group, when a group terminates, a largest sequenceNo received mark is placed in the group state
information, such that when the message with that sequence number is
delivered to the user and all the messages received for that group expire,
the group state is removed.
Jacques: If we change
the scope of the duplicateID check to be tied to the groupExpiry rather than the message expiry, it simplifies
the processing.
Bob: If we go back to
requiring a group expiry time it simplifies.
If you get a status=End before the group expiry time, the sequence
number of that end message terminates the ordered Delivery processing when that
message is delivered to the application.
Bob F – it would be very good to have the same behaviour for each way to terminate a group.
Doug: if sender does not tell receiver to stop with explicit
status=end, how does receiver let the sender know that the group is terminated.
Sunil it is simplified if we only start an ordered group
after the start message is received.
Other issues left to resolve on this topic.
REL-52: New rules
for persistence
REL-57: Ordering and
Missing Message Behavior
REL-97: GroupID lifetime (RemoveAfter)
7
Assess impact of Request/Response on Basic WS-R
Schema elements
Jacques sent the following summary on 9/30:
General recommendation on what WS-R
should cover regarding Guaranteed delivery (GD)
of
messages involved in a WSDL request-response :
1- Only the following GD cases
should be supported by this version of WS-R:
- GD of request + GD of response
(Variant 1)
- GD of request + no GD of response
(Variant 2)
The following case should be
excluded (not covered by this specification) (see Option 3.1.1):
- no GD of
request + GD of response (Variant 3)
2- The recommendation for GD of
request-response, is that its use of Ack and resend
procedures
will
differ from one-way ops in the following way:
- request-response
is treated as a single transaction (will be entirely replayed, if either leg
failed)
- in case
of Variant 1, in case the response is not acknowledged, the request-response
should not be replayed.
Instead, the Ack
should be resent (see Proposal 1.2) (depending on firewall restrictions on
either side,
either
using RMP-level polling to get the Ack, or a
resending mechanism for Acks.)(to
resolve!)
3- Given the impact of supporting
GD request-response on SOAP implementations (seee
Appendix A),
recommendation
is that it should belong to a higher conformance profile for WS-R.
i.e. some
implementations that cover only the reliability of one-way operations
should
still be considered as conforming at some level to WS-R.
More detail for variant 1:
Proposal
1:
We
address here the case where the response message (1.b) failed. The solution is
to resend the response over an HTTP response, itself part of a new HTTP
transaction that involves resending the request. In other words, we consider
that the entire HTTP transaction (1) has failed, and redo it. A successful
recovery will look like this:
(1.a)
Aà requestà B
(1.b) response + Ack1 ß
B need to distinguish this from a
normal piggyback of new rmRequest
(2.a)
Aà requestà B cannot avoid invoking
operation twice without dupElim
(2.b)
A ß response of 1.a + Ack1 ß B will send previous response
(3.a)
A à Ack2 à B
We could call this “transactional
reliability”, as it involves replaying the entire transaction. The transaction
(2) is carried over an HTTP request –response. Note that this is a pattern
different from the usual resending pattern as currently specified in WS-R.
Sub-Issue 1.1 to proposal
1: Note that the repeated request in
(2.a) will not be passed to the application in case duplicate elimination is
required, but otherwise will be. In case it is, which response should be sent
back (response to 1.a or to 2.a), as App(B) will have
answered twice?
In the above case the receiver rmp
must know that reliable requestResponse is in use (to
be able to resend buffered response for 2.b above). (another alternative
would be for the second response to be sent if dup elim
is not in use)
When receiver rmp receives request
and gets response from app, how does it distinguish this from another oneway rm Request?
The most difficult scenario for variant 1 is:
(1.a)
Aà requestà B
(1.b) A ß response + ack
ß B
(2.a) A à Ack
(lost) (like a
callback)
(3.b) A ß (Nack-Ack
error) ß B (like a poll)
(4.a)
A à Ack à B
3b could be accomplished with the existing poll message, but
perhaps we could also have a specific header for the nack-ack
error.
At lease one rmp needs to be aware
that erliable request-response wsdl
operation is being supported.
Variant 2 is simpler, and
introduces no new problems.
Jacques expressed an opinion that to make the above
scenarios work, we would have to extend the existing schema. (add new header
elements, or change existing header elements).
How does rmp know whether variant
1 or variant 2 is in use?
Could have an additional element in existing request header
(or a new header for this purpose) to indicate that reliable request/reply is
desired.
A new set of headers for the additional info would be
preferable for extending the existing protocol.
Possibly put the request response wsdl
operation type in an informative annex.
Meeting resessed at 5:15 PM.