Minutes of WSRM TC Teleconference
Tuesday April 22, 2003
The call in details were as follows:
Host: Fujitsu
> Toll free: 1-877-801-2058
> Intl Number:1-712-257-6652
> Passcode: 309951
2:30 TO 4:30 pm Pacific Daylight Time (UTC - 7)
1
Introduction and Roll Call
1.1
Draft Agenda
The draft agenda was sent out by the chair:
1 Roll Call
2 Appointment of Editor (please be prepared to volunteer)
XML Schema for Web Services Reliable Messaging
3 Progress report from Editors of Requirements Document
4 Discussion of Requirements
- Orthogonality of Message ID and GroupID/SequenceNo
- Assumed Capabilities of Transport Protocol
- Usage of Transport Protocol(persistence, intermedieries etc)
- Other Points
6 Charter Finalization Discussion (if any required)
7 Planning for future F2F meetings
Timing for conference Calls (send your UTC offset to Chair)
Oracle offer to host meeting May 28 thru 30
1.2
Roll Call
|
Status
|
Company Name
|
Contact Last Name
|
Contact First Name
|
Email Address
|
|
pm
|
Arjuna Technologies
|
Ingham
|
Dave
|
dave.ingham@arjuna.com
|
|
vm
|
Commerce One
|
Burdett
|
Dave
|
david.burdett@comerceone.com
|
|
pm
|
Commerce one
|
Islam
|
Nazrul
|
nazrul.islam@commerceone.com
|
|
vm
|
Cyclone Commerce
|
Turpin
|
Jeff
|
jturpin@cyclonecommerce.com
|
|
x
|
Fujitsu
|
Durand
|
Jacques
|
jdurand@fsw.fujitsu.com
|
|
vm
|
Fujitsu
|
Iwasa
|
Kazunori
|
kiwasa@jp.fujitsu.com
|
|
vmChair
|
Fujitsu
|
Rutt
|
Tom
|
tom@coastin.com
|
|
vm
|
Hitachi
|
Yamamoto
|
Nobuyuki
|
no_yama@bisd.hitachi.co.jp
|
|
vm
|
Hitachi,Ltd.
|
Nishiyama
|
Eisaku
|
nishiy_e@itg.hitachi.co.jp
|
|
pm
|
HP
|
Mukerji
|
Jishnu
|
jishnu@hp.com
|
|
vm
|
individual
|
Hansen
|
Mark
|
khookguy@yahoo.com
|
|
vm
|
Infosys
|
Mishra
|
Neelkanth
|
neelkanth_mishra@infosys.com
|
|
vm
|
Infosys
|
Subramanian
|
Raghavan
|
sraghav@infosys.com
|
|
vm
|
IONA
|
Danda
|
Venkat
|
venkat.danda@iona.com
|
|
vm
|
IONA
|
Patil
|
Sanjay
|
sanjay.patil@iona.com
|
|
vm
|
MITRE
|
Allen
|
Dock
|
dock@mitre.org
|
|
vm
|
NEC
|
Cronin
|
Kevin
|
k.cronin@niteo.com
|
|
vm
|
NEC
|
Weissberger
|
Alan J.
|
alan@ccrl.sj.nec.com
|
|
vm
|
Nokia
|
Gerendai
|
Magdolna
|
magdolna.gerendai@nokia.com
|
|
vm
|
Nokia
|
Payrits
|
Szabolcs
|
Szabolcs.Payrits@nokia.com
|
|
vm
|
Oracle
|
Kunisetty
|
Sunil
|
sunil.kunisetty@oracle.com
|
|
vm
|
Oracle
|
Srivastava
|
Alok
|
Alok.Z.Srivastava@oracle.com
|
|
vm
|
SAP
|
Goodner
|
Marc
|
marc.andrue.goodner@sap.com
|
|
vm
|
See Beyond
|
Wenzel
|
Pete
|
pete@seebeyond.com
|
|
pm
|
Sonic software
|
Evans
|
Colleen
|
cevans@sonicsoftware.com
|
|
vm
|
WRQ
|
Werden
|
Scott
|
scottw@wrq.com
|
Mark Goodner took the minutes. The chair also added discussion items from his notes.
2
Appointment of Editor
XML Schema for Web Services Reliable Messaging
Scott Werden volunteered to be editor.
3
Progress report from Editors of Requirements Document
Not much
progress so far.
New document
requirements draft submitted by Payrits
- contains
requirements inferred from the original submitted specification
- issue list for new requirements from email discussion will
be made available soon
- issue resolutions can be incorporated as requirements by
making a motion
Payrits distributed a new version
of the requirements document. People
have not have had a chance to read it.
Alan Weissberger suggested that we
have a lot more email discussion. He
also stated it is premature to finalize any requirements document.
Magdolna asked about the separate
issues list.
The document will include requirements agreed. The issues need to be extracted from
discussion.
Every requirement will be voted individually.
Requirements reflect accepted requirements,
all ongoing discussion will be on an issues list.
Editors maintain issues list and requirements document.
Issues with a voted resolution get into the requirements.
How do we consider other specifications.
Important issue, two last requirements
from ISSUE.
WS-attachments, ws-security, which
should we be compatible with.
Requirements question.
Requirements Issue to be added .
4
Discussion of Requirements
4.1
NEC Comments on Requirements
Alan Weisberger summarized his
comments.
- Req/Resp message exch patterns
good idea, make them broader in next req
- Proposed
WS-RM API document
-
Higher layer communications (application level)
-
Lower layer communications (SOAP level)
- Jeff
Mischkinsky What language?
- AW
As an abstract on adjacent layer communications
-
Colleen Evans Would this be normative
- AW
No
- Tom
Rutt Should be covered by the English text
accompanying schema. Provide an example to illustrate where it is not. Term API
is problematic
- AW
Work needs to be partitioned
- TR
Service layer faults need to be better defined
-
Semantics need to be defined in a way independent of the programming language
- HTTP binding
OK, is there such a thing as a non HTTP binding?
- Sync/Async needs to be unambiguously defined
- ? At
what layer is sync/async being defined
- discussion needed, proposals should be made at face to face
- Crash
tolerance and persistent storage need to be better defined
- Backwards
compatibility with non WSRM nodes, fallback to standard SOAP
- How
to identify these nodes
-
Implications on WSDL definitions
-
Intermediaries need to be clarified
-
Implications on WS-RM messages
Discussion points:
If not an API, a separate document for abstract primitives
and parameters.
Colleen stated how could it be
normative to be abstract API.
MEPs from applications view, what
primitives and parameters are passed.
HowFault messages are conveyed.
How do you convey failure to the layer.
Nailing down semantics, is what Alan
wants out of this.
Alan recommends to partition the
work to get semantics in abstract way independent of binding.
Bindings should be specified. Not Http bindings?
Doc stated some issues are architectural issues. We should decide on the priority of the
issues.
Szabolcs has high level use
case. Intermediary may charge money, may
be able to know that one message is replayed, due to loss. Should not be charged
twice. May be
partially WS-RM aware.
Need to define all intermediary types we need to work with.
Soap intermediaries can do actual processing.
Cannot prevent useful processing of
messages.
Need Separate discussion on transport protocol
requirements. When you have
intermediaries you have concatenated transports.
4.2
Fujitsu Comments on Requirements
- Synchronous request/response messaging
- it is important to support this model
- Sunil (Oracle) Sync mentioned, what about async?
- K Yes
- Firewall considerations
- We want to realize the asynchronous messaging through
firewall
- Pull model, when PC inside firewall receives a message, it
initiates a connection to sender when ready to pull a message in sender's
storage which was prepared for the receiver. Thus connection is always
initiated from the receiver
- Dave Ingham - Is this more of a transport issue (HTTP)
than a firewall issue?
- TR - Could be discussed as a requirement in terms of when
a user can only initiate an HTTP connection
- Client/Limited resource device consideration
- Devices that can only initiate requests, no static IP etc.
- TR Is this just more pull model justification? More
clarification between these two issues is needed. Pull model seems to be
resolution for two issues.
- Attachment support
- Must be usable with attachments, MIME or WS-Attachment
- Consideration for other WS-XX spec
- Discussion of politics around other WS-* specs that have
not been submitted to standards organization
- TR Those specs are not available
to us officially. Keep them in mind and use them as a source of ideas for
requirements.
- JM – this area of alignment is on Thin
ice...
- Need to determine all frameworks and specs we want to be
compliant with
- TR Add to issue list
4.3
Orthogonality of Message ID and GroupID/SequenceNo
- Option 1 Use GroupID/SeqNo for
all message ids
- Option 2 Use MessageID for
everything and use pointers for ordering (Doug B. proposal)
AW What is pointer?
TR Pointer would be a new element indicating prior message
(linked list) Details need to be worked out
- Option 3 Keep it as it is with messageID
for reliability functions, groupID/sequenceNo for
ordered delivery
-
- TR Message ID is
mandatory, removing it is problematic
- TR Some people don't want to
maintain both types of IDs, seems redundant. SequenceNo
Discussion points:
TC should use email discussion for clarification on these
three options.
Iwasa is not sure why option 2 is
useful.
Sparing bytes, alonw, is not worth
it.
A statement was made that use of sequence number can enable
sliding window etc.
4.4
Assumed Capabilities of Transport Protocol
What are assumptions of transport protocol.
- Currently HTTP binding, assumed
use on top TCP/IP
- What are assumptions on transport layer?
- HTTP can either be persistent or new connection for each
request
- SP Should eb a seperate section in requirements document
If HTTP proxies are involved , do
not know how it will route TCP connections.
Magdolna suggested define
transport requirements, then define different
bindings.
TCP is the only protocol for HTTP.
Soap over HTTP is a requirement, but the architecture should
work with other bindings.
Discussion on Soap over SMTP, and Soap
With attachments.
Transport at soap level is not at TCP level.
Define requirements for underlying layer of SOAP. What is the concrete protocol.
Soap layer should work with other bindings.
Requirements Issue: how to use wsdl
to define services with WS RM.
4.5
Usage of Transport Protocol(persistence,
intermediaries etc)
- TR example:
1. A persistent connection guarantees ordered delivery
2. A nonpersistent
implementation does not guarantee ordered delivery
Other Points
SP Don't assume anything with HTTP, firewalls etc.
Doc Must be capable of working with all valid HTTP
implementations
Magda? HTTP only one
possible binding, better to define transport requirements then define bindings
TR Is TCP the only binding
for HTTP? (General agreement that yes)
TR Architecture should work with other bindings than
SOAP/HTTP? That is all in charter
AW What about SOAP/SMTP?
Magdolna: When talking about transport I do
not mean TCP, usually talking about SOAP over HTTP or SMTP etc. Defining
requirements for layer underlying SOAP facilitate adding new underlying
transports in the future.
TR SOAP w Attachments introduces new binding details
Scott Werden Transports should be
discussed in the abstract
TR We need a concrete binding into SOAP/HTTP, should not
preclude other bindings
TR How do we get WSDL into this? Add as a requirements
issue.
SW Would be another deliverable, not a requirement
TR Need to work with the lowest level denominator, every
SOAP request may initiate a new transport req
No ordering guaranteed by transport because we cannot assume
persistent connections
Discussion points:
Have to be capable of working with all valid HTTP
implementations.
Lowest common denominator has each http request starting its
own transport connection.
The protocol should function properly if connections are not
persistent. Do not make any assumptions
on persistence of connections.
Http persistent connections would simplify ws-rm. We cannot
make that assumption.
Magdolna suggested there is only
one requirement for underlying transport: that message corruption must be
signaled.
Need to discuss this requirement on mail list. Need to move from requirements issue to requirement.
Make this an issue, with a proposed response.
4.6
Other Points
AW Can we assume TCP bringing flow control
TR We can't assume persistent connections so TCP flow
control would not be very useful
AW Then flow control may be in scope then. Flow control
prevents loss of messages when a reciever is blocked
from responding due to congestion.
TR Congestion could be excaserbated
by retransmit if flow control not addressed
AW would then be an issue at the TCP level again without
persistent connections
TR Add to requirements issue list
Discussion:
Messages may be going no where because the far end is
congested. Congestion control is a
reliability issue. Transmitter throttles
back, from back pressure.
TCP can do retransmissions, and HTTP can do retransmissions.
This can exacerbate heavy load situations.
Requirements issue: Is there a need for flow control in our
soap level protocol.
Several people stated that it seems out of scope. Propoents need to bring
into discussion use cases which are vulnerable to uncontrolled congestion.
5
Charter Finalization Discussion
Tom will send draft changes, as agreed from previous minutes, to list for validation.
He will send these changes to Karl Best after validation by the TC.
6
Planning for future F2F meetings
Timing for conference Calls (send your UTC offset to Chair)
There was agreement to continue with current schedule.
Oracle offer to host meeting May 28 thru 30
Start Wed , breakfast at 8: meeting starts at 8:30.
Oracle conference center, Redwood Shores.
List of hotels suggestions might be sent out.
Want to be south of 92, Foster City, Redwood City, etc.
Meeting will Adjourn at 1:00 May 30.
Vote: Yes unopposed for F2F meeting
OASIS TC for BPEL are proposing face to face on the same few days. However, Jeff stated that this is not yet been scheduled officially.
Jeff will try to influence them to change their date.
Finalized with the dates May 28 thru 30, 2003.
- AW Will meeting be discussion or
contribution driven?
- TR More contributions the better
- AW Is there an official OASIS format for contributions?
- TR No
Meeting was adjourned at 4:20 PM PDT.