Minutes of OASIS WS-RX Teleconference

April 6, 2006

 

Start Time:4:00 PM Eastern Daylight Time

 

Paul Freemantle acted as chair.

 

Textual Conventions

 

Ø  Action Item

Motion

§    Resolution

 

1         Roll Call

From Kavi:

Name

Company

Status

Alexander Leyfer

Actional Corporation*

Group Member

Charlton Barreto

Adobe Systems*

Group Member

Lei Jin

BEA Systems, Inc.*

Group Member

Gilbert Pilz

BEA Systems, Inc.*

Group Member

Ian Jones

BTplc*

Group Member

Hamid Ben Malek

Fujitsu Limited*

Group Member

Jacques Durand

Fujitsu Limited*

Group Member

Kazunori Iwasa

Fujitsu Limited*

Group Member

Tom Rutt

Fujitsu Limited*

Group Member

Robert Freund

Hitachi, Ltd.*

Group Member

Eisaku Nishiyama

Hitachi, Ltd.*

Group Member

Nobuyuki Yamamoto

Hitachi, Ltd.*

Group Member

Doug Davis

IBM*

Group Member

Christopher Ferris

IBM*

Group Member

Matt Lovett

IBM*

Group Member

Peter Niblett

IBM*

Group Member

Mark Little

JBoss Inc.*

Group Member

Stefan Batres

Microsoft Corporation*

Group Member

Colleen Evans

Microsoft Corporation*

Group Member

Marc Goodner

Microsoft Corporation*

Group Member

Ondrej Hrebicek

Microsoft Corporation*

Group Member

Jonathan Marsh

Microsoft Corporation*

Group Member

Chouthri Palanisamy

NEC Corporation*

Group Member

Paul Knight

Nortel Networks Limited*

Group Member

Lloyd Burch

Novell*

Group Member

Steve Carter

Novell*

Group Member

Martin Chapman

Oracle Corporation*

Group Member

Sumit Gupta

Oracle Corporation*

Group Member

Anish Karmarkar

Oracle Corporation*

Group Member

Ashok Malhotra

Oracle Corporation*

Group Member

Eric Rajkovic

Oracle Corporation*

Group Member

Martijn de Boer

SAP AG*

Group Member

Sanjay Patil

SAP AG*

Group Member

Stefan Rossmanith

SAP AG*

Group Member

Steve Winkler

SAP AG*

Group Member

Glen Daniels

Sonic Software Corp.*

Group Member

Vikas Deolaliker

Sonoa Systems, Inc.*

Group Member

Doug Bunting

Sun Microsystems*

Group Member

Mike Grogan

Sun Microsystems*

Group Member

Pete Wenzel

Sun Microsystems*

Group Member

Dan Leshchiner

Tibco Software Inc.*

Group Member

Shivajee Samdarshi

Tibco Software Inc.*

Group Member

Paul Fremantle

WSO2*

Group Member

 

 

37 of 47 voting members, meeting quorate

 

Tom Rutt agreed to take minutes.

2         Agenda Approval

Agenda    

1) Roll Call

 

2) Review and approval of the agenda

 

3) Approval of the F2F meeting minutes

http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/17492/MinutesWSRX-f2f-032306.html

 

4) AI Review

http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php

 

5) Administrative issues

a) Editors update

b) telecon sponsorship for next meetings

 

6) New issues since last meeting

Watch for Marc’s email

 

7) Issue Discussion:

 

i108 misplaced guidance on fault handling

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i108

 

i106 SequenceAcknowledgement:Final assumption of deliverability

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i106

 

i089 Suggest the restricted use of anonymous URI

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i089

 

i096 Complete the state tables

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i096

 

8) Any other business

 

Chris F stated he would like to defer Issue 89.

 

No objection to defer Issue 89.

 

1         Approval of the 3/23 F2F minutes;

   http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/17492/MinutesWSRX-f2f-032306.html

 

Tom R moved  Doug D seconded to approve F2F minutes

 

§    No objection minutes for F2F meeting approved..

2         AI Review

   http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php

 

#0093: Paul F will produce a detailed proposal for i089 with usage of Get Message

Owner: Paul Fremantle

Status: Closed

Assigned: 2006-04-03

Due: ---

 

#0094: Marc G will produce a detailed proposal for i089 by fixing normal replay mechanism.

Owner: Marc Goodner

Status: Open – still Pending

Assigned: 2006-04-03

Due: ---

 

#0095: Matt, Bob, and Tom will provide an amended state table before the April 6 teleconference

Owner: Matt Lovett

Status: Closed

Assigned: 2006-04-03

Due: ---

 

#0096: Paul F will post a version of interop Scenario document on Kavi for access by entire TC

Owner: Paul Fremantle

Status: Closed

Assigned: 2006-04-03

Due: ---

 

#0097: have editors get a new namespace for next CD, given the use of ws addressing PR

Owner: Doug Davis

Status: Open – still pending

Assigned: 2006-04-03

Due: ---

 

#0098: Chris F and Anish will propose appropriate text for resolution of I108

Owner: Christopher Ferris

Status: Closed

Assigned: 2006-04-03

Due: ---

 

3         Administrative issues

3.1      Editors update

 

Doug D: no changes since Face To Face.

 

Paul F: what are plans for producing new draft incorporating F2F changes in.

 

Doug D: I would like to have it done before the next phone call.

3.2      b) telecon sponsorship for next meetings

 

Gil volunteered to get a bridge for the next call.

 

Paul Knight volunteered for the subsequent call.

4         New issues since last meeting

Watch for Marc’s email http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200604/msg00019.html

 

Proposed 01

Title: dangling reference to RMAssertion acknowledgement timing params

 

Description:

From cd03[1] lines 564-566:

 

The timing of acknowledgements can be advertised using policy and

acknowledgements can be explicitly requested using the <wsrm:AckRequested>

directive (see Section Request Acknowledgement).

 

Justification: dangling reference

 

Target: core

 

Proposal:

 

Suggest that the text be changed to read:

 

Acknowledgements can be explicitly requested using the <wsrm:AckRequested>

directive (see Section Request Acknowledgement).

 

[1] http://docs.oasis-open.org/ws-rx/wsrm/200602/wsrm-1.1-spec-cd-03.pdf

 

Cheers

 

Christopher Ferris

No objections to accepting proposed 01 as new issue.

 

Chris F moved, Doug D seconded to accept proposal for proposed 01.

 

§    No objections, proposed 01 to be resolved with proposal from Chris F.

Proposed 02

New Issue posted by Paul Freemante:

Title: Sequence state in event of MessageNumberRollover

 

Description:

 

The spec doesn't talk about what the continued state of a sequence is after MessageNumberRollover.

 

Justification:

The state tables have an entry that is not clear. We ought to define what the state is after a rollover.

 

Target: core design

 

Proposal:

 

At line 519 after the following sentence:

If the message number exceeds the internal limitations of an RM Source or RM Destination or reaches the maximum value of 9,223,372,036,854,775,807 the RM Source or Destination MUST issue a MessageNumberRollover fault.

 

Add one of:

 

(a) In this case the RM Destination should continue to accept undelivered messages until the Sequence is closed or terminated

 

(b) In this case the RM Destination should Close the Sequence.

 

 

Paul

Sanjay: would not the creater of messageID know when rollover happens.

 

Doug D: there is a third option, do nothing at all.  Anything else lower is bad.

 

Chris F: RMD can close sequence if it does not like multiple rollover messages.

 

Tom R: closing the sequence seems acceptable solution, should discuss on email.

 

 

No objection to accept proposed 2 as new issue.

 

 

 

5         Issue Discussion:

 

5.1      i108 misplaced guidance on fault handling

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i108

 

Chris F proposal posted as http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200604/msg00017.html

As per my AI, I have noodled on this with Anish, Gil and Doug and have come up with the following revised proposal for i108 [1]

 

 When the processing of an RM protocol header block (with the exception of Sequence) generates  a fault, and the purpose of the containing message is not exclusive to that RM protocol header  block, then the receiving  endpoint MUST continue normal processing of the message unless  the generated fault is a SOAP MustUnderstand fault.

 

Gil had suggested that we add to the glossary a set of terms that could help us in describing

certain types of messages. I agree. Here's a start:

 

Sequence lifecycle messages:

       A message that contains one of: CreateSequence, CreateSequenceResponse, CloseSequence, CloseSequenceResponse,

       TerminateSequence, TerminateSequenceResponse as the child element of the soap:Body element.

 

RM protocol header blocks:

       Sequence, SequenceAcknowledgement, AckRequested

 

Sequence messsage:

       A message that contains a Sequence RM prototcol header block.

 

Acknowledgement message:

       A message that contains a SequenceAcknowledgement RM protocol header block

 

[1] http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i108

 

Christopher Ferris

 

Anish: I am convinced now that MUST makes sense.  My concerns are all covered by the MUST statement.

 

Chris F moved, Anish seconded to resolve issue 108 by accepting proposal.

 

§    No objections, issue 108 closed by accepting proposal.

5.2      i106 SequenceAcknowledgement:Final assumption of deliverability

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i106

 

http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200604/msg00007.html

As an alternative to the proposal I made in http://lists.oasis-open.org/archives/ws-rx/200603/msg00185.html the following will also satisfy my concerns:

 

Since implementations may have various methods of delivering messages to the application and may or may not include some sort of persistence, it may be instructive to annotate the ack sequence with information indicating which messages were actually delivered or otherwise safely transferred to the RMD.

 

Sequence acknowledgements indicate simply that the RMD layer has received the message, and provides no information concerning their subsequent processing or delivery.  SequenceAcknowlwdgement/Final received upon sequence closure may therefore provide ambiguous information to the RMS concerning the potential deliverability or delivery status of received messages based in part on message ordering contracts that may exist between the RMD and the application which are invisible to the RMS.

 

What is proposed is the inclusion of two additional attributes to the SequenceAcknowledgement/AcknowledgementRange element that would define message upper and lower bound ranges that have been delivered by the RMD to the application

 

A partial proposal is contained in the attached pdf based on CD03.

 

Please see the insertions in lines 560 and 603.

 

If this proposal is accepted, then the exemplar in lines 570-580 would need to be expanded as well as schema.

 

Bob F:  Taking responsibility means RMD can deliver the message.  Since then I proposed a definition of range attributes .

 

Matt: I think this goes beyond scope of spec.  If the sender knew ordered delivery is in place, it will know something might not be delivered, even after acknowledged.

 

Stefan: why do we need these new mechanisms.

 

Bob F: we have know way otherwise, what will be delivered.  It is possible to implement RMD that messages persist before being acked.  But I cannot deliver before delivering the prior. 

 

Tom R: The ack ranges give info to have the client to know that maybe it is not delivered.  Quality of implementation might buffer these “dangling’ out of order messages for the user application to retrieve them..

 

Bob: I would agreed if you could restart a sequence.

 

Chris F: all the info sender needs to know is in the Ack.

 

Jacques: It is valuable information to have rms side know what is going on in RMD side.  However, a special message fault could do job, say “message not delivered”.

 

Paul F: My concern is that we do not have a definition of delivery, which was a conscious decision.  Middleware layers deliver to the next layer, but there is no final definition of delivery.  The correct way to do this is to compose with some other spec (say transactions) to get the concept of completion.

 

Paul F: with the concept of service, you have given the message to be delivered, and that is enough.  I oppose adding new mechanisms to assert delivery.

 

Jacques: 2.1 glossary has some existing text about “delivery” which needs to be clarified.  I question the need for these definitions

 

Chris F: Using RM between enterprises, purpose of RMD is to pop on a MQ series queued.  I would like to consider it delivered from the point of view of RMD.

 

Glen: it is clear that you do not have to resend it.

 

Bob F: but if the RMD supports ordered delivery, there can be messages which are never delivered since they are waiting for a prior.

 

Tom: but the conservative RMS would have to assume that the later messages would not be delivered within the sequence.  The definition of the ordered sequence requires this.

 

Chris F: The spec enables what is needed for delivery in order.  All the destination the destination needs to know regarding order within the sequence is provided in the message.

 

Glen: Different mechanisms have options on what to do in particular situations.  For any real application of what are doing there is a notion of delivery.  JMS states on connection one can get ack of receipt, or ack that the application has taken off the queue.  I think Delivery assurances that are well defined would be useful.

 

Tom: The RMS knows that the RMD is waiting on a prior.  It can send the prior to get it delivered.  If it does not resent, then the contract of “ordered delivery” does not allow delivery to the sender.  Thus the RMS must assume it was not delivered.  I think that the only thing we need to do is to clarify that the sender knows that ordered delivery is in use.   

 

Dave O: the meaning of delivery of message is application specific.  Will the delivery mechanism recover from failure.  I would like to keep the protocol as to what you can test on the wire.

 

Glen: there is a fruitful middle ground, where the application can give meaning of how it can be interpreted.

 

Tom: Given the sender might not know whether ordered delivery is in use, I think a fault might be more appropriate, for the non delivered ordered delivery case, as Jacques pointed out earlier.  If RMD knows it is not delivered because it is out of order, then it has information to give to the sender.

 

Chris F: that fault would just state “it is not delivered now”.  It may not be delivered, or even deliverable.  We are getting back into delivery assurance discussion.  Application level acks can be added to the mechanisms we have here.

 

Bob F: another alternative is outage event is the ability to restart a sequence.  If a way existed to restart a sequence this could solve the problem.  It is the edge cases for terminations that I am concerned about.

 

Chris F moved to close I 106 with no action, Stefan seconded.

Bob Objected to motion.

 

Anish: would Bob’s proposal to clean up language to make it clear what ack means.

 

Bob F: a clarification that ack does not imply enablement.

 

Paul F: given Jacques point about glossary, we have to change that as well.

 

Tom Rutt moved to table, Jeff M seconded motion to table.

 

§    No objections to table motion.

 

5.3      i096 Complete the state tables

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i096

 

 

Matt posted a new PDF file.  http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200604/msg00011.html

 

The state table does not have empty boxes or question marks.

 

Bob F: I will be opening two issues against the table.  Sequence Ack Final on processing of ranges, and when elapseExpired event is triggered by time or by something else.

 

Bob F: the state tables are complete.  However there are still things we need to do to clean up.  Rollover operations changes could be made.

 

Jacques: in the event column it would be good to make it clearer that the “fault” related events, are we talking about generating this or receiving this.  Unknown sequence is an event generated by RMS.

 

Tom: this table is now cleaner, we can clean it up with other issues.

 

Matt: I would prefer we accept this table as is for now, using new issues to fix.

 

Bob F: I have questions about removal of the rollover state.

 

Paul F: If we accept now, can editors get into next WD.

 

Doug G: Yes.

 

Paul F: it might be best to raise new issues on inconsistencies.

 

Bob F moved to accept Matts proposal to close I096, Seconded by Tom R.

 

§    No objections, new state tables accepted, as closing issue i096.

6         Any other business

Meeting adjourned at 5:30 PM

_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.