OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Preliminary Minutes of 4/22 WSRM TC conf call


Attached are the prelim minutes.

Please post any proposed changes before Friday Noon EDT.  I will post 
the final minutes on friday.

Tom Rutt
wsrm chair
Fujitsu
-- 
----------------------------------------------------
Tom Rutt		email: tom@coastin.com; trutt@fsw.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133

Title: The next meeting of the WSRM TC will take place by teleconference this
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.

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]