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 WSRM TC meeting - April 8, 03


Attached are the preliminary minutes.

Please suggest any corrections before Thurday PM, I will post the final 
minutes on Friday Morning.

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

Title: The meeting of the WSRM TC will take place by teleconference this Tuesday April 8, 2003, from 5:30 to 7:30 PM Eastern Time

Preliminary Minutes of WSRM TC conference Call Meeting

April 8, 2003

The meeting of the WSRM TC took place by teleconference Tuesday April 8, 2003, from 5:30 to 7:30 PM Eastern Time.
The call in details were as follows:

Host: Fujitsu
 > Toll free: 1-877-801-2058
 > Intl Number:1-712-257-6652
 > Passcode: 309951

1 Roll Call

Status

Company Name

Contact Last Name

Contact First Name

Email Address

pm

Arjuna Technologies Ltd.

Ingham

Dave

dave.ingham@arjuna.com

vm

Booz | Allen | Hamilton

Chiusano

Joe

chiusano_joseph@bah.com

vm

Choreology

Furniss

Peter

Peter.Furniss@choreology.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

vm

Fujitsu

Iwasa

Kazunori

kiwasa@jp.fujitsu.com

vmChair

Fujitsu

Rutt

Tom

tom@coastin.com

pm

HP

Mukerji

Jishnu

jishnu@hp.com

vm

individual

Romano

Paulo

romanop@dis.uniroma1.it

pm

individual

Stojanovic

Nikola

nikola.stojanovic@acm.org

vm

Infosys

Mishra

Neelkanth

neelkanth_mishra@infosys.com

x

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

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

Mischkinsky

Jeff

jeff.mischkinsky@oracle.com

vm

SAP

Goodner

Marc

marc.andrue.goodner@sap.com

vm

See Beyond

Wenzel

Pete

pete@seebeyond.com

vm

Sonic Software

Chappell

Dave

chappell@sonicsoftware.com

pm

Sonic software

Evans

Colleen

cevans@sonicsoftware.com

vm

Sun

Bunting

Doug

Doug.Bunting@Sun.COM

vm

webMethods

Yendluri

Prasad

pyendluri@webmethods.com

vm

WRQ

Werden

Scott

scottw@wrq.com

x

Fujitsu

Durand

Jacques

jdurand@fsw.fujitsu.com

 

Tom Rutt agreed to take the minutes.


2 Appointment of Editors (please be prepared to volunteer)

  Requirements Doc

Doug Bunting SUN

Payrits Nokia

Mark Goodner SAP


  Web Services Reliable Messaging Specification

Iwasa Fujitsu

 


  XML Schema for Web Services Reliable Messaging

Leave as Part of spec for now

3 Introduction of Input contributions

3.1 WS-Reliability Specification

Fujitsu, Sun, Oracle, Hitachi, NEC, Sonic

 

3.2 WS-Reliability Schema

 

3.3 Royalty Free License Terms for WS-Reliability

 

3.4 Nokia Requirements input

They provided this as a starting point for the requirements document.

3.5 Nokia WS-Reliability Overview Presentation

The slides were introduced by Payrits. They summarize the WS reliability mechanisms and the basic requirements.

They want a general architecture for WS reliability, including a communication layer in the protocol stack. With a formal definition.

They manage it as an extension of the existin soap, on top of the soap exchange pattern. They include summary of the reliable messaging scope.

They would like to support reliability for one-way and for request response message exchange patterns.

Slide 15 requirements; maximum reuse of existing specs, and use of Soap. This should be an extension to the existing soap protocols. Another requirement is that persistent storage should not be mandated. Levels of reliability should be defined, especially for persistenct.

They want to work with soap intermediaries. They would like to be sure that architecturally that the spec will work with intermediaries.

Dave Bunting stated that this is a reasonable request. Faults and acks going to the original sender is both good and bad.

They have an illustration.


4 Continued discussion of charter (out of scope items)

the item was opened for discussion:

-         Synchronous RPC at the application level

 

Synchronous RPC at application level is included as out of scope. This was done originally to make the spec simpler to understand. It was put here for that reason originally. He now thinks the spec should be allowed to use in a Synchronous way.

We need to clarify the requirement.

Application level support for RPC we would have to do a lot more.

Dock asked if you could build an acceptable RPC on top of this that might be enough.

Payrits asked for clarification of terms:

-         Synchronous is blocking

-         Message exchange pattern

-         RPC is another term, independent from request response message exchange pattern.

Jacques asked if you can have Request response without rpc.

There was consensus that we should include Request response message exchange patterns in the scope of the spec. Sanjay.

A question of what the request/response message exchange pattern would allow a response to be sent correlated with the request, as well as sending the response reliability.

A question was asked on having to also correlate faults with the message.

Magdolna stated that Reliability already includes correlation, and it could be extended to include request response.

Colleen stated we were.

It should be in scope to allow request/response message exchange pattern.

Synchronous means sender blocks while waiting for the acknowledgement.

Alex Weinberger made a motion to delete item from scope. Seconded by Dave from sonice.

No opposition to deleting the item.

Paulo Romano stated the sentence is confusing because it has a different interpretation. One way to clarify is request response is allowed.

RPC is an api term. Ensuring both exchanges are delivered by. He would like to discuss the differences in exchange patterns in requirements. He agrees to remove the out of scope item from the charter.

Request response is a standard use case.

Payrits stated if basic correlation of request response is done by reliable soap layer vs. using HTTP is the major concern to be discussed.

NO opposition to deleting out of scope item.

Dock Allen asked about:

  • Message Integrity: However, WS-RM's work should be able to be used with Digital Signatures to provide some level of message integrity

Colleen stated we want this to not be specified by this protocol, but to work with other security protocols.

Dock Allen asked about corruption. She asked why we should not deal with corruption of messages.

The point is that the transport takes care of a lot of corruption avoidance.

Alan Weisberger stated that if we are relying on a Transport protocol for certain features, this has to be clarified in the requirements. E.g, transport flow control, etc.

Jeff M stated the authors were assuming TCP.

Jishu stated the Transport requirements have to be clarified.

Enterprise messaging may require flow control at the application layer.

Doug Bunting stated if we are starting to discuss the transport layers. If we want to layer ws-reliability on top of UDP we are starting to hit issues which are much greater.

Jeff M stated the charter writers intended the out of scope item was meant for security. The rest of this discussion is that we have to refine the requirements on the underlying transport.

Peter Furniss asked to clarify whether we are keeping the focus away from security hits, but including normal corruption hits.

Applying security where message is signed and hashed using normal security mechanisms, would cover all integrity concerns, from any corruption.

You could chose not to use security mechanism, because it is expensive.

TCP failure would leave the user unknown.

Jeff M summarized that the item is referring to security, if the group wants to raise other forms of message integrity, they should raise these concerns in the Requirements discussion.

Jeff M asked if there are any words here which will make a difference in the final document being produced.

Jishnu asked what the problem is to leave it as is.

Peter Furniss asked that we could take message integrity (including corruption of a single messae) out of the scope of our protocol, since we are using mechanisms in the lower layers to do this.

Motion to add new bullet to out of scope.

  • Mechanisms to protect against corruption of an individual message

Seconded by Jeff M.

No opposition to adding item.


5 Discussion of Requirements

Alen Weisberger suggested kicking discussion on the Email.

Payrits asked if we have a procedure for requirements.

Weisberger asked that the requirements doc is supposed to be out in two months.

The first requirements document should contain the functional aspects of what we have,

As we go over the future document issues, we could add to the requirements for a second spec. This would come much later.

Jeff M suggested to Reverse engineer the spec to produce the current requirements, then enhance the requirements.

Doug Bunting states the WS-reliability spec has a set of requirements already, to use as a starting point. He would not like to prevent resolution of issues we have time to resolve in the first two months.

Magdolna stated we have things done already for requirements, put these in the first document.

Clarify requirement for current doc scope first had consensus.

We could also have a living list of additional requirements not in the current specification. We could have general consensus on what items can go into the living list.

Doug stated something can be an issue if one person is annoyed.

Call it a requirements Issue list. Anybody can put something on the Requirements Issue list.

Finish the requirements list before working on modification of the spec.

Payrits stated it is ok for functional requirements to have the basis for the requirements. We should also proceed with high level use cases.

Nobody is opposed.to use cases.

Dock asked if end to end was intended to mean app to app.

Doug stated end to end was in a space sense, rather than a time sense.

We were not thinking about state management.

Doug Bunting suggested the editors have an off cycle exchange for the format of the original requirements document, extracting those requirements.

Starting point for the issues list will be provided by the Requirements editors, who will use the Nokia contribution and other items raised on the list.

Payrits stated that if there are any objections to requirements in the list.

There was a question as to the final document in 6 months. It does provide constraints on the extra work to get done.

Dock asked about the intent the first of series of specs vs the final spec at 6 months time frame.

Payrits asked whether there would be a future requirements document after the two month time frame.

He asked if we can agree on requirements closed in 2 months. This would be a first pass. How do we get the extended requirements into place.

The requirements for the original spec would not

Doug Bunting stated we don not know if there will be requirements on the requirements issues list after two months. We might meet all the requirements everyone cares about in the document ready at 6 months, in which case the TC could be closed down.

There could be more requirements in the two month document.

The two months time frame is giving the group a target to get something produced. We should continue to put new requirements issue on the issues list. We should not close our eyes.

Jishnu stated that we could change the charter to change the schedule.

Doug Bunting clarified that the co-sponsors are now just regular members.

Jishnu clarified that the team will vote at the end of the two months what the requirements are. The level of completeness will be subject to a vote.

Editors will track the issues being raised on the list.

6 Planning for future F2F meetings

Doug suggested that we attempt to use the survey thing. After discussion the group agreed that every member should send their time zone offset from GMT to the Chair at:

trutt@fsw.fujitsu.com

We can then use this as a discussion point for other possible times.

It was agreed to have the next two meetings be at the same time on Tuesday.

The time suggested for the first face to face meeting was :

9:00 am May 28 thru Noon May 30. Hosted by Oracle in SF Bay Area..

Oracle will determine if they can meet this meeting cycle.

Jeff M or Sunil will get back to us on next week call as to whether they can meet these dates.

The meeting was adjourned at 4:20 PM PDT.

 

 



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