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: Prelim Minutes of WSRM TC teleconf Nov 30

Prelim minutes are attached.

Post any required corrections before the end of this week.

tom Rutt

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

Title: Draft Agenda to WSRM TC Conference Call – May 06, 2003

Preliminary Minutes WSRM TC Conference Call –November 30, 2004


The meeting of the WSRM TC took  place by teleconference 

Tuesday, November 30 , 2004, from 5:30 to 6:45 PM Eastern Standard Time


1         Draft Agenda:


    1 Draft Agenda to WSRM TC Conference Call

    2 Roll Call

    3 Minutes Discussion

    3.1 Appointment of Minute Taker

    3.2 Approval of previous meeting minutes –

    4 Action Item Status Review

    5 Status of WS-Reliability Specification

    6 Status of Interop SC activities

    7 Next Step Documentation

    7.1 Editorial Clarifications and Errata

    7.2 Implementation Guidelines

    7.2 Future Enhancement Requests

    7.2 Composability with other WS-Specs

    8 Discussion of Future Meetings


2         Roll Call


First Name

Last Name






Cyclone Commerce











TC Chair

















Nortel Networks












Sun Microsystems




Univ of Hong Kong



 Meeting is quorate.


3         Minutes Discussion

3.1      Appointment of Minute Taker

Tom Rutt will take minutes.


Minutes will serve to record issue resolutions.

3.1      Approval of previous meeting minutes

The minutes of the Sunnyvale F2F meeting are posted at:



Bob F moved to approve, Abbie seconded.


No opposition, minutes are approved.


4         Status of Action Items

4.1      Action 060104-5 (Jacques) Closed


Action: Jacques, will propose further edits, on the FAQ for composability.


Jacques proposed input for discussion at:




Come back to FAQ after we agree on the comments.


Jacques will give an overall overview.

4.2      Action 090704-1 (Tom) Pending


Action: Tom will try to find, from previous minutes, a list of features we have put off for future versions and will post it to the list for discussion.


5         Status of WS-Reliability Specification

Now a full OASIS Standard.


Doug has seen a number of articles on the web.


Jacques stated Fujitsu has published on Wired information list.


Tom: we have to get it into our products.


Bob: there is a Korean BLOG.webservices.orkr on this.


Action: Tom to deal with OASIS staff to get schema posted at the proper location on the OASIS web site.


Sunil: the web site needs to be updated.


6         Status of Interop SC activities

Demo at XML 2004.


Bob F presented a summary.  Good news: it worked.  Bad news: almost no attendance.  We had more traffic last year when in the exhibit area.  The team worked late every night until the actual demo.  It came together at the last minute.


There were some interpretation differences to work thru.


Next time they should stick with a more simplistic demo scenario, or have it in the can much earlier than the time of the demo.


Jacques will send an email to OASIS staff on the problems with the demo arrangements.  Jacques was involved in another demo (ebMS ) which had better attendance, because they were not competing with main sessions.  The publicity needs to be improved at the future.  How can we do better next time.


Bob F stated that an open source implementation (RM4GS) of the ws-reliability stack has been released, and downloaded.


This is the Hitachi, Fujitsu and NEC implementation.


Tom asked Bob to distribute the URL of the web page which makes this implementation available.


Jacques stated he has contacted the OASIS staff to make this known publicly.

7         Next Step Documentation

A few pages were reviewed from the SC at the Face to Face.


Action: Bob will work with the Interop SC to have them recast a next version of their feedback document using the following three categories (and taking into account the discussion at the F2F).

7.1      Editorial Clarifications and Errata 

Clarifications , editorial nits, interpretations of the actual specification,

which should be posted for others to see

7.2      Implementation Guidelines / Application Notes

Things to help implementers, which, would typically be specific to application environments.

7.3      Future Enhancement Requests

Proposed changes for future versions which would ease implementation or enhance protocol capabilities.

8         Composability with other WS-Specs

Jacques posted a contribution for discussion at:


Composablity of WS-Reliability: what can we say about it



NOTE: this is not intended to be FAQ material as is, but intended to be input material for a FAQ, an implementor guideline, or both.



1- General Composability of WS-R, its model and the processing of its SOAP headers:


- Composition with other WS specifications that also have header footprint, follows the SOAP processing model. Except in the case where there is processing of the WS-R headers themselves by another function such as Security, the order of processing of WS-R headers vs other headers, is open. We normally would expect that Reliability be one of the first functions to be processed on Receiver side, so that the processing of other headers benefits from reliability (meaning will not be done uselessly for duplicate messages, or for out-of-sequence messages that may never be delivered, or for expired messages.) Symmetrically on the Sender side, WS-R headers would be added last (except for security) and reliability mechanism should be processed last, so that a resending mechanism will not entail duplicating the processing (e.g. addition) of other headers in the message.


- The "reliability" Message ID (group ID and sequence number) is specific to reliability functions, and not supposed to be reused by other functions, or to be replaceable by an other message ID from other headers, because sequence numbers have a special reliability semantics, and depend on the scope of reliability QoS.


Tom: perhaps our wsrm:replyTo is another element which is only pertinent to WS-reliability, and should be kept separate from any other ws-addressing related replyTo.


Jacques: we need to get an email thread going on this topic of composition.


Doug: this says too much:  I agree that our message id is not replaceable by another one, however the “not to be reused” by other specs is too strong a statement.  


Jacques; I stated it too strongly above, I agree our headers, if visible, should be able to be reused.


Tom: We need to separate composition of this spec now, with future enhancements to ws reliability for better composition.


Jacques: I am assuming in the analysis composition with the current spec.


- The reliability contract is defined relative to abstract operations on the RMP: Submit, Deliver, Respond, Notify. When composing with other SOAP processing functions - e.g. as supported by other SOAP nodes - the reliability contract starts at the time of submission to the RMP ("Submit"), meaning that reliability (e.g. guaranteed delivery) will not concern messages faulted by SOAP processors that operate upstream to a sending RMP, and therefore which never reach the sending RMP. However, once a message has been submitted to a sending RMP, the reliability contract will apply regardless of what subsequent processing occurs, in addition to WS-Reliability.


- Deciding how to handle SOAP faults that are generated by additional SOAP processors between a sending RMP and a receiving RMP (e.g. deciding to not resend such messages, in case of guaranteed delivery, and instead notify the message producer of delivery failure) is an implementation choice: an RMP may decide to adjust its resending behavior based on faults other than reliability faults.


- An important aspect of composability concerns the meaning of "Delivery". The reliability model in WS-Reliability is open to two interpretations (implementation choices) when composing with the processing of other SOAP headers:


- Case (1) : reliability QoS is expected to apply all the way until the delivery of the message body to its consumer (e.g. handling of the business payload to an application or to a queue). In that case, a message should not be acknowledged until delivery to the final consumer.


- Case (2): the reliability contract stops as soon as the processing of the reliability headers is complete.

Successful delivery occurs as soon as the message is passed to the next processor.


In case 1, the Deliver operation can be interpreted by implementers as including subsequent processing of other headers. A failure of any of these would entail a delivery failure for the RMP and the generation of a MessageProcessingFailure fault, which would prevent the acknowledgement of messages that have not been delivered to the final consumer. Thus no message would ever be acknowledged until final delivery to this consumer.


In case 2, an acknowledgement would be generated as soon as the message is passed to the next processor. Failures that occur in processing other headers would not affect the reliability mechanism. SOAP faults generated would simply be passed to the sender side, as they would without reliability, and no  "delivery failure" would be notified to the producer.


Tom: is it feasible to implement either case above.


Jacques: I think that can be the case.


Doug: Soap node, vs. soap processor is a terminology problem.


Jacques; I will check out to use the proper terminology for this.  I will check what we put in the spec.  There is a defn for soap Node.  What I am pointing at is that our model allows an implementation to control what is going beyond the RMP as being part of a big delivery operation. (case 1).


Jacques: Faults are another aspect of composability.  There could be soap nodes before the receiving rmp.  At this point it will not make it , and some sending retry will take place.


Tom: how would you distinguish such a fault from a transport fault.  The protocol will still work.


Jacques:  as stated in the bullet above the prior, third party faults are another aspect of composability.


2- Composition with Security:


Reliability headers may be signed or encrypted according to WSS. It is strongly recommended that the integrity of the WS-R headers be guaranteed, as this is a pre-requisite an RMP to be able to enforce the reliability contracts. This generally requires that the reliability headers be signed.


Confidentiality may be achieved in the same way, although integrity of headers is more critical for effective deployment of WS-Reliability implementation.


Because WS-Reliability does not rely critically on "signal" messages (e.g. no specific messages to initiate or terminate a sequence of messages), the effects of tampering with a message are limited in scope.

Tom: was there any demo of composition with ws security


Bob: we did demonstrate some of that at the xml 2004 demo.


3- Composability with supporting specifications:


We define a supporting specification as a specification that may compose with WS-Reliability to better support some of its features.


Besides Security which is essential in guaranteeing the integrity of reliability headers, we see two areas where supporting specifications can improve on implementations:

- the representation of the address where a CallBack response should be sent to. Because such specifications as WS-Addressing or WS-MessageDelivery are not finalized yet, WS-Reliability keeps open the representation of new reply address formats, via extensibility points in the schema.

- the representation of an RM agreement.  Because no open specification is available yet to support this,  an abstract representation of the RM agreement is provided in WS_Reliability. 


This structure can be related to a future specification via a binding.


Jacques provided an overview of the material.  Comments on specific text is recorded in line, in the text above.


Tom: how would a system use a different reference scheme for our reply to syntax type.


Doug: they could use a private agreement.


Tom: how would we standardize the use of ws addressing for our reply To syntax.


Doug: Someone in the future could do this if they needed it.  If w3c wanted to do it they could do that.  If that does not happen, we could do it ourselves.


Tom we need further discussion before updating the FAQ.


Tom: we should work on this via email discussion before we come back to the FAQ.


Jacques: we cannot continue to remain silent, we have to go public in some way.  We should not wait for an implementers guide.  We could issue an application note about composibility.

9         Discussion of Future Meetings


Potentially, what is the next Face to face.


Tom: do we need a meeting before April.


Doug: we should first demonstrate we have made progress on the post standard work, if we show progress we would need sooner that 4 months from now.  Unless the way the april meeting is structured differently than last year I suggest we do not take advantage of that venue.


General concensus on a face to face sometime in February, early march time frame.  April is crowded.  


Agreed to continue schedule of 90 minute teleconferences every two weeks starting Jan 11.. thru February.


Dec 14, Jan 11, Jan 25, Feb 8, Feb 22


The latter Feb Date could be changed to an F2F, if necessary.

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