WSRM Face To Face Proposed Agenda:
Wednesday Jan 14 –
16, 2004
Oracle
Conference
Center
350 Oracle Parkway
Redwood Shores CA 94065
Conference Bridge
Call in Info: Each day
(9:00 AM to 11:00
AM
Pacific Standard Time, with possible extension to 12:00 Noon if required each
day)
Host: Fujitsu
Toll only : 1-512-225-3050
Participant code:
89772
(NOT toll-free !)
Wed Jan 14: AM: Note: Roll call is on Wednesday
Morning you must be present or on bridge to have attendance count for voting
rights.
0
Draft Agenda
Wed Jan 14: AM: Note: Roll call is on Wednesday
Morning you must be present or on bridge to have attendance count for voting
rights.
8:30 Coffee
and Continental Breakfast
9:00 Start
Roll Call, Review of Agenda and Identification of input contributions
9:15 Approval
of 1/06 minutes
9:30 Walk
thru of WS draft/ Schema to confirm reflection of accepted resolutions
10:15 Triage of Open
Issues (arrange in priority)
10:30
Break
10:45
Resolution of Config Parameter Issues Rel(56,
83 84, 85, 86)
12:00 Lunch
begins
PM
1:00 PM
- Detailed WS-Reliability Editor’s Draft Walk thru
a)
Check for usage of Optionality “SHOULD, MUST,
MAY, etc” (Rel 22)
b)
Determine candidates for Optional Implementation (Rel 29)
2:30 Break
3:00 Discussion of
Rel 49 Non normative wsdl
annotation Specification
3:30 Discussion of
UML
State Charts
5:00 Homework
assignments and meeting recess
Thursday Jan 15
AM:
8:30
Coffee
9:00
Review of Homework Assignments and Continued Issue
Resolution
10:30
Break
10:45 Resolution of
“Requirements” Issues (Rel 59-79)
PM
12:00
Lunch
1:00
Continue Resolution of Requirements issues
2:30
Break
3:00
Resume Discussion of Issue resolutions
3:30
Discussion on Conformance issues (Rel 29) for
Sender and Receiver RMPs
5:00
Discussion of Homework Assignments, and meeting recess
Friday Jan 16:
AM:
8:30 Coffee
9:00
Review of Homework Assignments/proposals
9:30
Continuation of Conformance Discussion
10:30
Break
10:45
Review WS-Reliability Spec / Schema and assign subteams to clean up descriptions and
examples.
12:00
Lunch
PM
1:00
Discussion of Timing for Deliverables and Future Interop Demo plans
2:30
Break
3:00
Concluding discussions
4:00
Future Meeting Planning and Wrapup
5:00
Meeting Adjourns
1
Introduction
1.1
Earliest Possible timeline
Tom Rutt displayed the following
possible timeline
Jan 27 – CD 1 7 day Ballot issued
Feb 3 – CD 1 ballot closes
Feb 4 – 30 day Review initiated
March 5 – 30 Day public Review ends
March 15, submit to oasis staff for member vote
April 1 – Membership two week review
April 15 – start member two week vote
April 30 – member vote concludes. Earliest Oasis
Standard.
1.2
Roll Call
|
First
Name |
Last
Name |
Email |
Role |
Company |
|
Robert |
Freund |
bob.freund@hitachisoftware.com |
Member |
Hitachi |
|
Peter |
Furniss |
peter.furniss@choreology.com |
Member |
Choreology
Ltd |
|
J |
Durand |
jdurand@fsw.fujitsu.com |
Member |
Fujitsu |
|
Kazunori |
Iwasa |
kiwasa@jp.fujitsu.com |
Secretary |
Fujitsu |
|
Tom |
Rutt |
tom@coastin.com |
TC
Chair |
Fujitsu |
|
Eisaku |
Nishiyama |
nishiy_e@itg.hitachi.co.jp |
Member |
Hitachi |
|
Nobuyuki |
Yamamoto |
no_yama@bisd.hitachi.co.jp |
Member |
Hitachi |
|
Junichi |
Tatemura |
tatemura@ccrl.sj.nec.com |
Member |
NEC
Corporation |
|
Sunil |
Kunisetty |
Sunil.Kunisetty@oracle.com |
Secretary |
Oracle |
|
jeff |
mischkinsky |
jeff.mischkinsky@oracle.com |
Member |
Oracle |
|
Pete |
Wenzel |
pete@seebeyond.com |
Member |
SeeBeyond
|
|
Doug |
Bunting |
doug.bunting@Sun.com |
Secretary |
Sun
Microsystems |
|
Tony |
Graham |
Tony.Graham@Sun.com |
Member |
Sun
Microsystems |
|
Chi-Yuen |
Ng |
cyng@csis.hku.hk |
Member |
University of
Hong
Kong |
|
Goodner |
Mark |
|
ProsMem |
SAP |
1.3
Identification of input contributions
Iwasa prepared a new spec Version
updated with Sunil’s comments and some technical fixes to meet resolved
comments.
Doug asked that we use the 1-06 document, because his annotation were against that
version.
Doug uploaded a new version of the issues list, dated
1/14/2004.
2
Approval of 1/06 minutes
Sunil moved to approve the 1/6 minutes. Bob seconded.
No opposition , minutes
approved.
3
Discussion of Active Issues
3.1
Rel 56, and 83 thru
86
Jacques email sent on 1/6/2004
Here is a proposal for Rel 56, attached, for further review.
It already reflects some earlier
comments from some of you (most from Doug).
As for the former list of REL
83-84-85-86:
REL 83: current proposed
resolution for R83 is assumed by R56, although parameter is renamed in
R56.
REL 84: current proposed
resolution for R84
is assumed by R56, although parameter is renamed in
R56.
REL 85: propose to close without
action: not relevant anymore since we can guarantee to NOT deliver
duplicate
regardless of scope (i.e. "forever", thanks to the
semantics of ExpiryTime)
REL 86: propose to
close without action: REL 57 is handling the termination of pending out-of-order
sequences.
Any other reason to cancel an out-of-order sequences hinges on storage capacity, which
should be
handled
separately (and in a consistent way across several other RM features. E.g. with appropriate Faults.)
Jacques
<<RM-agreement.txt>>
REL 56: Proposal
================
Summary:
- the
proposal is independent from resolution for REL 83-84-85-86,
although
we
assume here that REL 85-86 are dropped. (rationale to
be sent separately)
- Instead of talking of
"configuration parameters", this proposal will talk
more
abstractly (and more generally) of "reliability agreement items", or
RM-agreement items.
- "RM-agreement items" describe
the reliability contract between parties.
They cover both the RM
parameters that show up in the protocol, and those which do not
(like
"retry interval", "number of retries"). This distinction is not essential at
this level.
Some items may, at
implementation level, translate into configuration parameters for RMPs.
- the
proposal is that the spec identifies and describes the RM-agreement items, so
they
have a
formal existence independent from their protocol representation (as some do
not
appear
in protocol). This allows for treating all of them in a uniform way in the
spec.
The proposal does not mandate a
concrete representation.
Later on, a formal
representation could be recommended (e.g. a policy language,
an
agreement representation...)
Detailed
proposal:
Reliability Agreement (or RM
Agreement):
-----------------------------------------
An RM Agreement describes the
set of agreed contracts between:
- a
Sending "application layer" and the associated RMP.
- a
Sending RMP and a Receiving RMP.
- a
Receiving "application layer" and the associated RMP.
The way these contracts are
established or communicated to each party is out of scope,
although for the contract RMP-RMP, the assumption is that
all the needed synchronization
is
achieved through the message protocol, i.e. the Receiver RMP does not need
other
input
than the message headers.
The highest-level items of the
RM Agreement are the main RM features themselves:
- Guaranteed delivery (or
at-least-once delivery):
When a Sender application
submits a well-formed business payload to the RMP,
the
agreement requires that either:
(1) the
payload is delivered to the Receiver application, or
(2) the
Sender application is notified in case of failure.
- Duplicate elimination (or
at-most-once delivery):
When an RMP delivers a business
payload to a Receiver application, the agreement requires
that no
future business payload from a message with same identity as the message
containing
the
first payload (GroupId and SequenceNumber if any) will ever be delivered
to the
Receiver application.
- Guaranteed ordered delivery:
When a Sender application
submits an ordered sequence of business payloads to an RMP,
the
agreement requires that when delivering a business payload to the Receiver
application,
all
previous payloads in the sequence have already been delivered.
RM Agreement
Items:
-------------------
An RM Agreement is a list of
Agreement Items.
An RMP implementation MUST be
capable of:
(1) taking knowledge (e.g. either via configuration, or via an
API call, or via a message,
or via
the result of an algorithm) of a set of values that represent the RM Agreement
Items
described in this specification,
(2) processing them according to the semantics described in
this specification.
Some of these items will map to
some message header field, some will not.
They are:
- GuaranteedDelivery (enabled/disabled): for setting guaranteed
delivery.
- GuaranteedOrdering (enabled/disabled): for setting guaranteed message
ordering.
- AtMostOnceDelivery (enabled/disabled): for setting message
delivery without duplicates.
- GroupMaxIdleDuration (number of seconds):
For setting the elapsed time
limit from the last message sent or received in a group,
after
which the group can be terminated.
- GroupExpiryTime (number of seconds):
For setting
the date and time after which the group can be
terminated.
- ExpiryTime (number of seconds):
For setting the date and time
after which a message must not be delivered
to the
receiving application.
- RetryMaxTimes (integer number):
For setting how many times a
message must be resent if not acknowledged.
- RetryTimeInterval (number of seconds):
For setting
the minimal elapsed time between two re-sending of the same message.
- ReplyPattern ("response", "callback",
"poll")
For setting
the mode of response for Acks or
Faults.
Messaging Scope of Agreement
Items:
-----------------------------------
The messaging scope of these
agreement items may be:
(s1) All messages sent over a
connection between a Sender RMP and a Receiver RMP (default).
(s2) All messages sent within a
Group.
(s3) a single message, within a
group of several messages (non-singleton group).
Some agreement items obviously
relate to a particular scope, e.g. ExpiryTime
is
affecting each message separately, while GroupExpiryTime is an agreement about groups.
Such scopes are "required"
scopes that must be supported.
The smallest required scope for
each RM agreement item is:
Message scope
(s3):
- ExpiryTime
- RetryMaxTimes
- RetryTimeInterval
- ReplyPattern
- GuaranteedDelivery
- AtMostOnceDelivery
Group scope (s2):
- GuaranteedOrdering
- GroupExpiryTime
- GroupMaxIdleDuration
NOTE: although an RMP must
support each agreement item at the scope level above,
the RMP
implementation may also provide a way to specify these values for a broader
scope.
Example: an RMP implementation
may decide to provide a way to specify the ExpiryTime
value
for all messages of a group.
Rules about Agreement Items,
when used in an RM Agreement:
---------------------------------------------------------
- If GuaranteedOrdering is enabled for a messaging scope, then
GuaranteedDelivery and
AtMostOnceDelivery MUST also be
enabled for that messaging scope.
- If GuaranteedDelivery is enabled for a messaging scope, then
the items
(RetryMaxTimes, RetryTimeInterval) MUST also be defined
for that scope.
- If GroupExpiryTime is enabled for a messaging scope, then the
item GroupMaxIdleTime
must
not be enabled, and vice versa.
Jacques summarized that the notion of RM-agreement, without
explicit representation in protocol, allows these terms to be used in the
specification.
Jacques moved to adopt his proposal. Bob seconded.
If motion passes, this text will be put into the spec. Editoral
changes could be incorporated later.
No opposition. Motion passes. Close 56, 83 to 86.
3.2
Rel 49 WSDL
annotation
Sunil Email:
This proposal not only addresses
the main issue as mentioned in REL 49,
but it also
touches upon the client side config that was
mentioned in other
issues. I'd like to discuss this more at the
F2F
Salient points are:
* This should either be
normative and optional (wrt to compliance) or should
be made non-normative. Oracle prefers former.
* Has 2 different schema
elements. <service-config> is defined for
service side WSRM config to be used in the Service
WSDL. <client-config> element is used for
client side config to be used in vendor specific
client property/config file.
* <service-config>
o Based
wsdl
extensibility elements concept.
o Per operation or per binding. Note that
while wsdl 1.1 is ambiguous about extensible
elements under portType/operation, BP does allow
it.
o This extensible element can be either used
in portType/operation or binding/operation. If it
has to be shared by all bindings, then it could be used in the portType/operation [abstract part]. If this (wsrm usage) is per binding, then it can be defined only in
the binding operation It can also be used at the
binding level directly, if it is common for all the binding operations (note
that extensibility elements are prohibited at the portType level though).
o This service element could be used inside
any vendor specific policy elements or directly. If used directly, one could
use the wsdl:required (set to true) attribute, to enforce
the config element..
Once we finalize the schema, we could
define them in the same schema we are
defining for
the WSRM SOAP Headers and use the same namespace.
Example of a
<service-config> usage inside the operation
'foorBar'.
<portType name="fooPortType">
<operation name="fooBar">
<wsrm:service-config xmlns:wsrm="some URI" wsdl:required="true">
<!-- Spec. version>
<wsrm:version>1.0</wsrm:version>
<!-- We can also have some kind of
capability parameters
<wsrm:batching-support>
{true|false}
</wsrm:batching-support>
<wsrm:piggyback-support>
{true|false}
</wsrm:piggyback-support>
-->
<wsrm:guaranteed-delivery>
<!-- List the reply patterns supported by
this service.
Can have one or more such patterns -->
<wsrm:reply-pattern>
Callback
<!—possible values are Response/Callback/Polling
->
</wsrm:reply-pattern>
</wsrm:guaranteed-delivery>
<wsrm:duplicate-elimination>
true
</wsrm:duplicate-elimination>
<wsrm:message-ordering>
true
</wsrm:message-ordering>
</wsrm:service-config>
<input
message="fooMessageIn" />
<input
message="fooMessageOut>
</operation>
</portType>
Client side config sample:
<wsrm:client-config xmlns:wsrm="some URI">
<!-- No. of retries to send for non ack. messages
and return interval -->
<wsrm:retry-config>
<wsrm:retry-count>5</wsrm:retry-count>
<wsrm:retry-interval>10</wsrm:retry-interval> <!-- 10 secs
</wsrm:retry-config>
<!-- Can have only one such pattern. If the pattern is
'Callback',
the reply-to attribute can also be used
-->
<wsrm:reply-pattern wsrm:reply-to="SomeURIToSendAcksAndFaults">
Callback
<!—possible values are Response/Callback/Polling
->
</wsrm:reply-pattern>
<wsrm:group-config>
<wsrm:group-expiry-time>dateTime</wsrm:group-expiry-time>
<wsrm:group-max-idle-duration>dateTime</wsrm:group-max-idle-duration>
</wsrm:group-config>
</wsrm:client-config>
-Sunil
Sunil summarized some issues:
- Client side config
- Optionality/conformance
- WSDL extensibility
element usage (on which wsdl 1.1 elements.
If we decide on the general approach, we can refine the
schema.
Jacques: at high level this is to specify capability of a
service with respect to Reliable message capabilities
Sunil: others have used ws-policy
for such things.
Jacques – is someday a standard policy language is adopted
we will have collistion.
Sunil – this would be replaced by the WSDL 2 features and
properties (F&P).
Jacques: Some of thes
capabilities may not depend on the web service itself
, but on the deployment.
Sunil: at abstract level it is less useful. It would be more useful at the port
level (or perhaps binding).
Sunil : it definitely would be
optional.
Tom: what requirement are we trying to solve here.
Bob: I have a concern about finishing this in the 1.0
timeframe. I suggest postponing
this beyond ws-reliability 1.0 as a future
feature.
We only have a few weeks to reach or committee draft
status.
Sunil: This thing is high level concept, once we decide the
specifics are not that difficult.
Bob: we should focus on fundamentals required to get us to
1.0.
Bob: we should focus on getting a tightly specified
document in the limited time we have.
There are activites being
started, WS-PL as part of WS-XACML
Bob F suggestd to close the issue
49 be closed, and that the annotation be put on the “wish list” for future
protocol versions.
Doug: is the problem that this solution appears large at
this late date, or whether it is addressing something separate from the raised
issue.
Bob: both. I
would like to be able to use features which have not yet been adequately baked
in standards committees.
Doug: there is that and the WSDL 2.0 approach of
F&P.
Doug: how about a simple annotation: this endpoint requires
the use of WS-Reliablity (or a list of the three
Reliability features).
Tom: thus the main requirement in R49 is to allow a WSDL
service definer to specify which of the three QOS features are required to be
used with a service instance.
Sunil we would not put wsdlrequired true on these extensibility elements.
The group decided to keep issue open for now, perhaps
decide later in the week.
Bob: we are on the fence about an optional feature, I would like to close now.
Leave it open for now.
4
Walk thru of WS draft/ Schema to confirm
reflection of completed resolutions
Doug: there are 6 accepted issues to check if they have
been applied to the document.
Iwasa and I can do this online.
There are 20 completed issues to confirm that they are
reflected in the document. We need to decide on moving from completed to closed.
All in order:
4.1
Rel 14
– in appendix c line 997 this is
done
4.2
Rel 16
- Issue resolution for (a) carried, will maintain MUST link
between message ordering and use of the AckRequested
element. Issue resolution for (b) carried, will maintain MUST link between
message ordering and use of the DuplicateElimination
element.
Done in 3.2.3 – line 715
4.3
Rel 31
– Meaning of
Guarantee – done in 2.7.
4.4
Rel 32
– editorial definition of reply
patterns, done in section1.8
4.5
Rel 33
– meaning of acknowledgement –
done in definition of Acknowledgement message. However, the first paragraph
now needs to be removed (lines 177 to 180) since the third paragraph is
better. It was agreed to remove
the first paragraph.
This was reopened below.
4.6
Rel 36
- Eliminate message id from WSRM headers, and use the groupID/sequence number as a concatenated unique ID for
WSRM identity purposes. Note: The
sequence number defaults to zero for senders that choose not to implement
order delivery (though that does not help recipients). - Search for message ID Line 251 on page 9 , section 2.4 needs to have messageID fully spelled out. This needs another check by the
editor.
Question for group: is it worth linking, at least
informally, from occurrences of message Identifier back to definition in 2.2.
Leave this as requiring further
checks.
4.7
Rel 37
– Use of MessageID – agreed to
make URI with rec for MID scheme. Done in Section
3.1.1, however rfcn 2392 does not appear in refs
The sentence” It
is RECOMMENDED to use a syntax of Message-ID, as
defined in [RFC2392].”
Agreed
to editorial change from “a syntax of Message-ID” to “the Message-ID
scheme”
4.8
Rel 38
– remove timestamp.
There were some changes made in latest document. These will be closed
later. Need to remove the timestamp fault
4.9
General Fault Cleanup
ACTION: Need to endure faults in general being Cleaned
up Sunil
will try to get a proposal to clean up fault text before the end of the
F2f..
4.10Rel 40
– time to live is change to expiry
time, and made mandatory. There
is a comment on 3.1.3, which it was agreed can be removed.
The text states “delivery to the application”, where the
definition of delivery uses “next processing entity”.
In 3.1.3 we agreed to
Change “MUST
NOT deliver a received message to the application.” To “ MUST NOT
invoke the deliver operation for the received message.”
Agreed to change “modified
in any case by Sender,” to “modified in any manner by
the Sending RMP”
Sunil : the pictures show the
rmp communicating with the receiving
application.
It was agreed to reopen Rel 33 to
refine the definition of Message Delivery.
4.11Rel 33 reopened
Propsed to Change resolution to Rel 33: Doug: suggested: add “(application layer)”
immediately after the term “next processing entity” in the definition of
Message Delivery. Agreed as important editorial.
Doug: either define application layer as next application
entity, or redefine ack in terms which are visible
on the wire.
Eg: “message in ordered sequence is not
acknowledge until all previous messages are acknowledged.”
Doug: we could eliminate the need for formal definition of
delivery.
Tom: Maybe use the term delivery, informally, in the def of
ack.
But the formal semantics required for acks,
should be defined directly.
Doug: there is no way to test delivery.
Doug: Two approaches
1)
Define application layer, and use as we do in
this spec. This is a little bit
messy for a protocol spec.
2)
Do our best to avoid discussion of Application
layer matters entirely within a single system.
Jacques: define a delivery operation that every Receiving
RMP must support in some application manner. Then define, send ack after invoking this abstract operation.
Tom: eg: Delivery – an abstract operation invoked by the
Receiving RMP to transfer responsibility for Reliable message.
Doug: delivery can be defined as some operation that
transfers responsibility for message shifting from RMP to application
layer.
Doug: I agree that for ordered delivery, non ordered
delivery of acks is not quite sufficient to cover
the semantics we want.
Doug: I like leaving the application layer in the spec, so
that ordered delivery has a useful meaning.
Jacques: we should define two abstract operations: Submit from application to sending
rmp, and deliver from Receiving RMP to
application.
Tom: Delivery: an abstract operation (implementation
specific realization) which is used by the Receiving RMP to transfer
responsibility of the Reliable message to the application layer.
Jacques: Require that the RMP invokes an operation called
deliver. Then have examples
(e.g, RMP transfers responsibility for the message
to the application layer through an implementation specific mechanism, such as
putting the message into persistent storage.)
Proposal: add new definitions.
Deliver: an abstract operation
the Receiving RMP may invoke per Reliable Message (e.g, a request to the application layer to.take responsibility for the Reliable message).
Submit: an abstract operation
the Sending RMP supports, invoked per Reliable message (e.g., a request to the
sending RMP to take responsibility for the reliable message.
Notify: an abstract operation
the Sending RMP may invoke per Reliable Message (e.g, a notification that the Sending RMP cannot insure
that the Requested Reliability feature were realized)
Everywhere else use words “deliver
operation invoked” to describe the action of delivery.
Change first sentence of
definition of Message Delivery to
“Message Delivery:
Message
delivery is the action of invoking the deliver operation for a Reliable
Message.
“
This is a new resolution to Rel
33.
The group also agreed to add labels of these
operations to the arrows in Figures 1, 2, 3. 7. 8. and 9. Remove the arrow showing a receiving
app invoking an operation on the Receiving RMP.
4.12Rel 44
Senders must not reuse message IDs
Doug: We need to add statement in definition of group id
that states it must not be reused.
Change second sentence of 3.1.1 from:
“This
element MUST have a globally unique identifier as its
value.”
To
“The sending RMP MUST use a
distinct globally unique Group ID for any distinct Group of messages. Any group of messages will have a
common Group ID value”
Action: Iwasa to apply changes,
then we will change status after done.
4.13Rel 50 Semantics of Expiry Time
Iwasa incorporated the email from
Tom, verbatim into the document.
Agreed to close this issue
4.14Rel 51 Message Piggybacking
Proposal:
Enable acknowledgement piggybacking by removing the distinction between
Reliable Message and Acknowledgement Message. Specifically:
1)
Remove the MessageType element. – This was done
2)
Any RMResponse
element could coexist with other elements."
Change “is containing” to “contains” in definition of
message Acknowledgment.
There are problems in English phrasing in four lines:
“
This
Response element can co-exist with Request element, and it enables to send
back
Acknowledgment
message with the business response to the original message.
It also enables
the
receiver sending an another independent message to the sender with an
Acknowledgment
message
to reduce network traffic.
“
to
“A
Response element can coexist with a Request element, enabling the combination
of an Acknowledgment message with the business response to the original
message. This coexistence also enables a receiver sending another independent
message to the sender with an Acknowledgment message (e.g., to reduce network
traffic).”
Doug: we need to globally change (as part of rel 22) the tables “ required –
no” to “cardinality – 0 or 1”, and “required – yes” to “cardinality – 1”.
4.15Rel 52 New rules for persistence
Message 70 in December had the agreed resolution.
This added all the new timing rules, and termination
stuff.
Section 2.5. and parameters are defined in section 3.
Doug: it would be better to move abstract definitions for
the group termination parameters to section 2. Section 3 should simply state that the
“xxx” attribute”corresponds to the abstract
definition in section 2.
Move everything after table in 3.1.1 (lines 546 thru 571)
into a new section 2.5.1, after the lead in text, pushing the rest of 2.5
down.
Change:
“
A
request message MAY contain one of the following
group
termination parameters:
–
a
groupExpiryTime
attribute
–
a
groupMaxIdleDuration
attribute
“
To:
“
A
request message MAY contain one of the following
Attributes
corresponding to the group termination parameters specified in section
2.5.1:
–a
groupExpiryTime
attribute
–a
groupMaxIdleDuration
attribute
“
Agreed to add new issue to update Section
2.6 “message persistence”, now that we have resolved the timing parameter
issues.
Mark Rel 57 as closed.
Leave Rel 53 open until we verify
that the changes are complete.
Action: Iwasa is to produce a
change barred version of all the changes made from the 1-06 document.
Use compare documents under Edit to do it.
4.16Rel 58 Namespace Identifier update
Done in 3.0 an also in the schema.
Agreed to close this issue.
4.17Rel 82
Agreed to close as resolved by resolution to timing
parameters.
4.18Rel 87
Fixes to resolve Rel 87 are in
Sunil’s comments in his email from 1/06:
Technical
Change second 3.3.1 to 3.4.1 and
fix is sub-clause numbers as well.
Delete “(to be added)” from 3.3
and 3.3.1
- Section 3 (Message
Format).
- replyTo is not an element rather an attribute of
ReplyPattern (pgs. 15 & 16) -
AGREED
- For PollRequest, GroupId is a
required element (minOccurs = 1) (pg. 16) -
AGREED
- Section 3.1/Table1 (pg.
17)
- Timestamp should be
removed from the child elements. It was removed when - AGREED
- Many more Faults to be
added - SUNIL Took Action item to
complete this.
- Section 3.1.1/Table 2 (pg.
18)
- Add InvalidGroupParameter fault to the table (also change
INVALID_GROUP_PARAMETER to InvalidGroupParameter on
line 555) - AGREED, but this will be in the
new section 2.5.1
- Section 3.3.1/Pg. 24
- GroupId under PollRequest is
different from GroupId in MessageHeader in 2 ways.
i) It has zero or more SequenceNumberRange elements - AGREED
ii) It also
has an attribute called 'value'. it's type is the
same as the type of GroupId in MessageHeader - AGREED
(because of REL-94)
- Section
3.3.1.1/SequenceNumberRange
- It has 2 attributes
called 'from' and 'to', both of type unsignedLong
(pg. 24-25) (because of REL-94) - AGREED to ADD two new attrbutes
- Section 3.4/ResponseElement (pg.
25).
- Response Element has
only one child element called RefToGroupId. – AGREED
to delete ref to seq no range in table and delete
line 747
- Section (now 3.4.1/Table 14 (RefToGroupId/pg. 26)
- Should have a new
attribute called 'value' - AGREED
- RefToGroupId has an attribute called 'value' of type MIDType and can have zero or more RefToSequenceNumber elements. - AGREED
- Section now 3.4.1.1/Table 15 (RefToSequenceNumber/pg. 26)
- Should have 2 new
attributes called 'from' and 'to', and no value - AGREED
These agreed changes resolve Rel
87.
Delete (needs updating ) from the
new section 3.4.1 section and subsection headers.
4.19Rel 88
Agree it has be implemented in the
spec.
Agreed to Close it.
4.20Rel 94 – Polling support
Tom: does it clearly state that the poll can only be done
for messages which were originally send with this pattern set.
Sunil: it does state this.
Need to add a section about polling in section 2, with the
model.
Sunil: there is no general section on the model for
polling.
The header elements are properly defined in sections 3.3
and 3.4.
ACTION: Sunil took action to come up with additions to the
model text for section 2.1 by Friday.
Left open until modeling text is complete.
4.21Rel 98 – sequence number usage
The informative note in second para of 2.4 was questioned by the meeting.
“
Informative
NOTE: It is recommended that an RMP removes the ID of a singleton
message
(message with GroupId but no SequenceNumber) from its persistent store after it
expires.
However,
unlike for singletons, it is recommended to not remove the ID of a message
that
belongs
to a non-singleton group, when the message expires. The reason is that message
IDs
for
groups can be stored efficiently as intervals of integers. When doing
duplicate checks for
messages
of a group, there is no loss of performance in checking over all past message
IDs of
the
group, whether expired or not. The check will in fact be faster, because not
discarding
expired
IDs means fewer intervals to look up.
”
Jacques agreed that the informative not is not needed with
normative text. It could go in
implementation guidelines, but we do not have them.
AGREED to remove the informative
NOTE.
Doug:: a message that does not contain
a sequence number is semantically identical to a message containing the
explicit sequence number zero.
Tom: need to update section 2.10 to correspond to
3.1.2.
Sunil: everything is based on existence of sequence no.
Doug: my real concern is that you are allowed to leave
sequence number out, but the conditions are not clear.
Tom:
- Sequence no is
required to be used for Ordered delivery.
- Sequnece no is not required to be used for Guaranteed delivery, however it may be present.
- Sequnece no is not required to be used for Duplicate
elimination, however it may be present.
Tom: For interoperability, all receivers MUST be able to
handle sequence numbers for non-ordered messages.
Doug: I agree with this statement of Tom.
Tom: For interoperability, all receivers MUST be able to
handle non-ordered messages which do not use sequence numbers.
Doug: the sender is deciding whether this “optimization” is
used, even though the receiver benefits.
Doug: eg. Sun version only uses
sequence number for Ordered delivery. Fujitsu Receiver RMP works much more
efficiently when ordering is used.
In this case the sun sending implementation would make the Fujitsu
receiver work very inefficiently.
Doug: we are describing an allowed optimization. Some senders may choose to generate a
new group ID for each un-ordered message, and they would conformant. The simplest sender may not want to
maintain the state of the last sequence number used in each group. This could be a significant cost for
some minimal sending implementations.
It is easier to generate global unique ids, not being concerned with
separate integer sequences per group.
Tom: A receiver implementation must be able to deal with
singleton groups for non-ordered messages.
Doug: Any receiver implementation of an optimization for
un ordered groups is not likely to be exercised,
given that may senders will not implement sequence numbers with un-ordered
group.
Jacques: Agree that there is no way to enforce the sender
to use sequence numbers for non-ordered delivery. However, if the sender and receiver
agree together to use the feature, it would be realized in practice.
The last sentence in 2.2 is incorrect:
“
Presence
of SequenceNumber indicates the Group has more than
one message.
”
Replace with “SequenceNumbers are
required only for groups that have more than one message.
Doug: what is def of group.
Bob: a group is a collection of one or more messages with
the same group ID.
Doug: then there can be groups of one.
Doug, there are semantics we do not capture in the
text. The sequence numbers when
used must be unique within the group, and monotonic. We do not say that no two messages in
a group can leave out the sequence number.
It needs to be stated
“
Groups with more than one message must have the sequence
number included for all messages in that group.
“
One logical place for this text to go is 2.10. This needs to be consolidated with
3.1.2 text on sequence number.
Bob: some of this belongs in 3.1.2, other stuff is in 3.1
The section about groupID needs
to be enhanced to discuss the definition of group and its use of sequence
numbers.
Jacques- we could have a section to define groups in
section 2.
ACTION: Jacques will make a proposal to fix these group
semantic concerns.
Doug has another schema issue with the messageID structure being a sequence with two elements,
while the ref to group ID is different.
Have sequence number be a child of group ID would allow
more expressive schema.
Currently:
“
<xsd:element name="GroupId"
type="wsrm:GroupIdType" />
<xsd:element name="SequenceNumber" type="wsrm:SequenceNumberType" minOccurs="0" />
“
Doug proposed to unify the schema for the message Id with
the schema for the refs.
Agreed to change “SequenceNumber”
to “SequenceNum”
Agreed to keep name of the attribute of
a new messageId element “groupId”
Change name “RefToMessageID”
to
- RefToMessageIDs
- RefToGroupedMessages
- Ref toMessages
- RefToMessageIdSet
- RefToGroupSubset
- RefToSubGroup
The winner was RefToMessageID.
Action: Jacques is to
5
Editorial Cleanup
Sunil sent the following email against the 1/04 draft:
Hi Iwasa,
Editorial:
- The Termination conditions (in pg.
11) uses GroupExpiryTime
and GroupMaxIdleDuration.
It should be consistent with the
actual attribute names (starting with lower cases).
- When attributes are mentioned in the
Table, please list their types. Ex. status (string)
- ReplyTo
attribute (in Section 3.1.4/pg. 21) should be replyTo (all attributes start with lower
case).
- Please add the schema as an
appendix
- Section 2.4/Line no.
259.
It should read "after the
message has been processed and delivered to the "next processing
layer".
- Figures
1-2-3 on pgs. 8-9 may
need to be updated to show the "next processor entity" as per
our
new
definitions.
- All the new terms such as Group
Termination, Removal, Complete etc... should be
defined
in the
terminology section
Thanks,
-Sunil
AGREED to accept these editorial comments
5.1
General Parameter Name Cleanup
e.g. ID, Identifier, Number,
etc.
Agreed to add a new issue
6
Discussion of
UML
State Charts
Tom showed two simplifications to the state diagram he sent
out in early Jan:
1)
The sending of an expiry fault was removed from
the state machine.
2)
the ack of duplicate delivered messages was removed. It is proposed to simplify by not
acking duplicates.
There was a large number of
concerns about the second change.
Doug stated it is not good to have the sender keep
resending in a lost ack case and never get an ack.
Jacques stated his major concern is the ability for the
sending rmp to be sure that the earlier receipt of
the duplicate message was actually delivered.
Tom stated: if the messages was received, and it is not in
the held queue waiting for prior, then you know it is delivered.
Doug: there are other ways to know the message was
delivered.
Tom: the key point is whether the protocol requires the
Receiving RMP to know what messages were received as well as what messages
were delivered.
Agree do not ack a resend on a
held message, also do not ack an expired message.
Tom will prepare a new receiver state diagram reflecting
these simplifications to send out for review.
Agreed that duplicate of held message will not have to be
acked.
7
Homework assignments and meeting recess
Iwasa will come up with a new
doc, change marked against 1/6
Doug will send out a new issues list.
Tom Will send out new receiver
stae
Jacques will send new proposal for group and sequence.
Sunil will send email about schema changes for group
ID.