Preliminary Minutes of WSRM TC Conference Call – May 06 2003

1 Roll Call

David	Ingham	Arjuna	dave.ingham@arjuna.com	Member	1
Joseph	Chiusano	BoozAllenHamilton	chiusano_joseph@bah.com	Member	1
Nazrul	Islam	CommerceOne	nazrul.islam@commerceone.com	Member	1
Jeff	Turpin	Cyclone Commerce	jturpin@cyclonecommerce.com	Member	1
K	Iwasa	Fujitsu	kiwasa@jp.fujitsu.com	Member	1
Tom	Rutt	Fujitsu	tom@coastin.com	TC Chair	1
Jishnu	Mukerji	Hewlett-Packard	jishnu@hp.com	Member	1
Eisaku	Nishiyama	Hitachi	nishiy_e@itg.hitachi.co.jp	Member	1
Nobuyuki	Yamamoto	Hitachi	no_yama@bisd.hitachi.co.jp	Member	1
Marc	Hansen	Individual	khookguy@yahoo.com	Member	1
paolo	romano	Individual	romanop@dis.uniroma1.it	Member	1
Venkat	Danda	IONA	venkat.danda@iona.com	Member	1
Sanjay	Patil	IONA	sanjay.patil@iona.com	Member	1
Dock	Allen	Mitre Corporation	Dock@mitre.org	Member	1
Junichi	Tatemura	NEC Corporation	tatemura@ccrl.sj.nec.com	Pros Member
Alan	Weissberger	NEC Corporation	ajwdct@technologist.com	Member	1
Magdolna	Gerendai	Nokia	magdolna.gerendai@nokia.com	Member	1
Szabolcs	Payrits	Nokia	Szabolcs.Payrits@nokia.com	Member	1
Sunil	Kunisetty	Oracle	Sunil.Kunisetty@oracle.com	Member	1
jeff	mischkinsky	Oracle	jeff.mischkinsky@oracle.com	Member	1
marc	goodner	SAP	marc.andrue.goodner@sap.com	Member	1
Pete	Wenzel	SeeBeyond	pete@seebeyond.com	Member	1
Colleen	Evans	Sonic Software	cevans@sonicsoftware.com	Pros Member
Doug	Bunting	Sun	doug.bunting@Sun.com	Member	1
Prasad	Yendluri	webMethods	pyendluri@webmethods.com	Member	Inc."
Scott	Werden	WRQ	scottw@wrq.com	Member	1

2 Minutes Discussion

2.1 Appointment of Minute Taker

Marc Goodner agreed to take minutes. Tom Rutt, added some items from his own notes.

2.2 Approval of prior minutes

http://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.
None opposed, passes

3 Progress report from Editors

Issue list posted last week still current, no further updates
Additional work on requirements doc pending approval of REL-1 issue

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 requirements

Dock 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 Protocol

Tom 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 clarification

AW: 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/SequenceNo

Deferred from last meeting
Doug outlined details on using messasgeID for sequencing

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 control

See 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 definitions

Marc 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 MEPs

Whether 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 meetings

Editors 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.
        (if you have not done so, send your UTC offset to Chair)
    - Face to Face meeting May 28 thru 30 in Redwood Shores CA (Oracle Hosting)

wsrm message