[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Preliminary minutes of WSRM TC Conf call -050603
Here are the prelim minutes. Please post any corrections before this Friday PM. Tom Rutt WSRM chair Fujitsu -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@fsw.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133Title: Such as they are
Preliminary Minutes of WSRM
TC Conference Call – 1 Roll Call
2 Minutes Discussion2.1 Appointment of Minute TakerMarc Goodner agreed to take minutes. Tom Rutt, added some items from his own notes. 2.2 Approval of prior minuteshttp://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/1407/MinutesWSRMTCFormation.htm http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/1582/WSRMMinutes-040803.htm http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/1789/MinutesWSRM-042203.htm Block motion to approve by
Colleen Evans, second by Jeff M. 3 Progress report from EditorsIssue list posted last week
still current, no further updates 4 Discussion of Requirements Issues:- Requirements Issues List: (From Marc Goodner): http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/1812/wsrm-reqm-issues.html 4.1 REL-1 Acceptance of initial requirementsDock moves to accept Payrits contribution (with 8 requirements) as a starting
point for requirements document. Jishnu seconds. None opposed, motion passes 4.2 REL-12 Usage/Capabilities of Transport ProtocolTom Rutt - Agreed in principal at last meeting to
only require that transport will not let corrupted messages thru (i.e. Filter corrupted messages). Dock - Guarantee wsrm
layer will not receive a corrupted message.
Motion to
accept the proposal from Magdolna Second Alan W. “All we are expecting of the transport layer is that it will not deliver
a corrupted message to the reliability layer.” None opposed, motion passes 4.3 REL-8 Intermediaries clarificationAW: Is it a passive monitoring
device we do not have to worry about it.
MAG – not
necessary to have technical details. May not change anything in
the message. Jeff M – do we want to explicitly
model soap intermediaries, or just give an assertion that they are
passive. Given how murky soap
intermediaries are it will be hard to describe them. Active mediary
has to be aware of our protocol. The
actor being specified as end to end will be enough. Doug expressed concern, that we
have at least 3 or 4 options. Explicitly
state WSRM must be used with particular actor value, vs
Describe it as being between two reliable messaging
end points, and leave it up to end points to decide what actor values are
necessary. Third option - intermediate
reliable messaging and end to end reliable messageing
and how they can be used together. Do we
rule things out of scope or not. Jeff M ,
could define URI as actor value. This
is a soap element This
is a wsrm specific value in a soap defined
attribute. It has a name “role” in soap
1.2. We would define a URI and any intermiediary acting in that role has to obey this
spec. Or we could use one already
defined. Leave as optional requirement. Doug B – alternatives (end to end
model and protocol, or role based endpoint to endpoint model, or two layer
protocol for parallel end to end. Alan W – need to clarify now vs future enhancements.
If we take the third scenario of intermediaries, there is difference in
end to end reliability. Payrits stated there are two approaches, Passive or active
intermediary. Alan clarified that it is active
when it changes MEP (e.g., sends acks on its
own). Payrits stated that passive would make this simpler. Doug B – passive but aware
intermediary is invisible from any other proxy.
Payrits if limit actor value for ultimate receiver, intermediary
may not change it. Chair proposed contributions on
the email list on this topic. Issue left
open 4.4 REL-11 Message ID and GroupID/SequenceNoDeferred from last meeting
Doug B – consecutive sequenceID in group is semantically equivalent to sending
message that depends on a previous message id.
This is a particular refTo relationship. This allows things like branches in
dependencies graph, and gets rid of confusion in mixing id types in a message
exchange. He stated he does not like to
have split primary key, and sees no need to optimise for
sequencing. Dock asked for an example of a
message technology using this approach.
She expressed a concern about dropping a few contiguous messages in a
sequence. Doug B stated it could work in
this case. Doug stated TCP uses sequence
numbers, ebms uses sequence numbers for order, while
another message ID for message identity. Doug tried to phrase a requirement, solution must use at most one unique id per
message. Doug’s concern is parallel storage for two mechanisms to do one
holistic set of features. One or the other could get lost. One thing is easier to track than two. Doug
B does not want two primary keys. Payrits asked what is the problem with two ids. Paulo stated that having two
identifiers (such as groupID, sequenceNO)
is needed for several groups of messages with
dependencies. Messages
ordered by groups is a use case we have often. He also would prefer one id mechanism, but it
could be a struct with groupID
and sequenceNO.. Collen: We need (at least one) unique
message id to use. The ws-reliability
spec has Message ordering of a sequence within a group Doug B ,
The requirement is that the RM solution supports ordered delivery of a set of
messages. Jishnu stated that sequencing of messages is requirement Tom Rutt proposed: Multiple concurrent sequences of
messages between same two endpoints must be supported by protocol. Jeff M stated this is a real requirement Jeff
moved, Doug B seconded. No opposition, passéd Doug had requirement level
statement about two identifiers. Dock stated deciding how many IDs
as a spec issue, not a requirements issue. Decided that
this is not a high level requirement, leave number of identifiers for spec
work. Number of identifiers deferred as a spec issue Close this issue 4.5 REL-24 Flow controlSee AW email (in issue
proposal), not practical Jeff M moved to close with no action.l
Collen seconded.
No opposition,
Issue closed 4.6 REL-4 Sync/Async definitionsMarc asked for a volunteer to resolve Issues 4 thru 6 Issue 4 defn of synch asynch Colleen - w3c has been working on this point. Payrits asked if we should have section in requirements document for definitions. He would like to put in other terms as glossary. Action ITEM: Payrits will propose list of definitions. Action Tom Rutt, provide a New folder, for Editor’s drafts. 4.7 New issue on Multiple Ack Message:Paulo – advantages to allowing multiple messages acknowledged by the single Ack. Is this requirements issue? Joe Chiasano – we had a thread on this. Paulo stated there is a large amount of overhead on sending one ack per message. This is not hard to do as an optimization. Doug – could also have an ack to one message also acking all earlier messages in the sequence. Requirement is whether a single ack can ack one or more reliable messages. Jeff M stated – minimize overhead in acks. Doug asked: bandwidth or number of bytes? Tom Rutt stated that, to avoid excessive latency in overload or failure recovery conditions, this could be a requirement. Perhaps the requirement is to minimize acknowledgement overhead, or to minimize work in doing acknowledgements. Issue agreed to be added and left open. We need email discussion on proposed text. 4.8 REL-2 Req/Resp MEPsWhether this gets into the spec
1.0 is the requirement issue. Payrits: Current soap applications use Request Response MEP. If we only have one way mep,
we put the soap world into a deficiency.
Oneway only will impact acceptance of this specifation. Can extend easy. Jeff M – if you can get response
back quickly you would want to piggyback a response with ack,
Joe Chiusano
asked about overlap with WSCI – section 3 message correlation. Doug B stated this would not
overlap. We are providing a run time
correlation of a basic element. Jeff M stated WSCI is not adopted
standard. Soap does not define correlation
in requiest response. Doug B – do we want to support
reliability from endpoints you cannot receive message from. Doug B stated that this and the
polling issue are solutions to same requirement. Payrits disagreed that soap does not define correlation between
request and responses. Jeff M asked about sending message to someone
behind firewall. This is polling or an ack in immediate response. Cannot get direct connection is
separate requirement. Tom Rutt stated reliable request
having its own ack and a response with its own ack , and
the response is correlated to request. Payrits has explained another implementation: HTTP request, with
response in http response, We would have to add the ack to the response. Reliable soap layer offer service
to app above for application to transfer request reliable with reliable
response. This is how to state this. Doug B – need to separate API
requirement from protocol requirement.
How is this manifest in protocol? Colleen: we need to support two
one way exchanges with correlation. Tom Rutt expressed confusion about
whether the response itself must have an ack sent by
the request originator. Sunil stated
that there is no requirement for ack of response
(timeout mechanism will cover this). Payrits – Not sure responder needs to be sure that response is
arrived at requester. Requester could
send back an ack for the request/response pair is one
way, with two http two way exchanges.
Another way is to rely on time outs.
The advantage of thes two approach needs to be
discussed in the solutions phase to this requirement. Coleen moved to have requirement for support of Request/Reponse MEP. Sunil seconded. NO opposition. Motion passes Issue closed. 5 Planning for future F2F meetingsEditors agreed to have updated issues list and new editor’s
draft requirements ready before next conf call in two weeks. Tom Rutt expressed goal to have the requirements
document agreed as an output of the Face to Face meeting. - Dates
and timing for conference Calls posted on calendar. Will have teleconf
in two weeks, the week before the F2f. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]