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 6/22 Teleconference

Prelim minutes are attached.

Please provide corrections to list by Friday.

Tom Rutt
WSRM Chair

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 of WSRM TC Conference Call June 22, 2004


The meeting of the WSRM TC will take place by teleconference 

Tuesday, June 22, 2004, from 5:30 to 7:30 PM Eastern Standard Time



1         Draft Agenda:

Draft Agenda to WSRM TC Conference Call

1 Roll Call

2 Minutes Discussion

2.1 Appointment of Minute Taker

2.2 Approval of previous meeting minutes

3 Action Item Status Review

4 Discussions of unresolved comments

5 Discussion of Document progression

6 Discussion of FAQ for WS-Reliability


2         Roll Call


First Name

Last Name




Voting Level





Booz Allen Hamilton






Cyclone Commerce

















TC Chair































NEC Corporation






Nortel Networks




































Sun Microsystems






Sun Microsystems






University of Hong Kong





Meeting was 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 June 14 teleconf are posted at:


Abbie moved, Jeff Turpin seconded


NO opposition minutes approved.

4         Status of Action Items


4.1      Action 052503-1 (Tom Rutt) pending

Tom took an action item to complete the status column of 
pre public review issues list, with correct URLs.


4.2      Action 060104-5 (Jacques) Pending


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


Still open



4.3      Action 061404-1 (Iwasa) Pending


Action: Iwasa will produce new version 1.03 as the new editors draft as baseline.




5         Discussion of Issues and editorial Comments

The following issues list includes items which need further discussion:



5.1      PC24






Doug Bunting


Title: Payload inclusion and MEPs other than request/response

Description: Re: more on payload(s) inclusion and MEPs than our Request-ResponseMEP discussion covers

Proposal: under discussion



Summary of WS-Reliability 1.01* issues discussed over past week
From Doug Bunting <Doug.Bunting@Sun.COM> on
13 Jun 2004 22:10:30 -0000


The following is intended to help get everyone caught up.


Most of this derives from the abstract model in our specification,

resulting in a number of contradictions between it and the rest of the

document, underscoring a few over-general restrictions or indicating some

under-specified concerns. While some of the issues below could be

considered editorial, the bulk are at least minor technical concerns.


When reading the following, it is very important to remember the

distinction between the capabilities the WS-Reliability protocol provides

to the producer and consumer and how that protocol maps to use of an

underlying protocol. Producer / consumer interactions occur using

WS-Reliability and WS-Reliability uses SOAP messaging (our underlying

protocol). The RMP always has complete control over the bits on the wire

though the producer and consumer may provide the bulk of the message

content in a "pass through" fashion.


The example "solutions" are provided primarily to make the issues clear.

While some of these approaches may resolve the issues, we must come to a

common understanding of the problems before working on solving them.


1) The existing descriptions of the callback and poll RM-Reply patterns

assume the underlying protocol supports request-response SOAP

interactions but do not explain what goes into the underlying response

of the separate message exchanges. In detail, the response and

synchronous RM-Reply patterns may be used only with an underlying

protocol that supports request-response (a less general restriction than

currently specified). For the callback and asynchronous poll RM-Reply

patterns, we are using only one-way messaging; though the underlying

protocol might support request-response, we should rely on the SOAP

binding to describe or profile how the underlying response is used (or

ignored). For example, we might clarify that these RM-Reply patterns

involve two separate one-way SOAP message exchanges (callback), three

separate one-way message exchanges (asynchronous poll) or a one-way

followed by a request-response exchange (synchronous poll). Such a

clarification might also address part of (2) below -- though at the cost

of some generality.


1a) The "non-essential assumption" that the underlying protocol supports

request-response SOAP interactions, stated in section 2.1, should be

removed. This is no longer a general assumption but something specific

to two of our four RM-Reply pattern options.


1b) The HTTP Binding should be an instance of the general semantics

described in the main body of the specification and not extend those

semantics. The current section provides examples of semantics not

described elsewhere. After resolving the areas left under-specified or

over-generalized in the rest of the document, we must recheck section 6

for conflicts with these semantics. In addition, any transfer protocol

responses that may be unclear because we are using a request-response

underlying protocol in a one-way fashion should be described by

reference to the appropriate SOAP over HTTP binding.


2) Section 5.2 is completely about the producer / consumer interactions

though some of its text has been applied to the RMP use of an underlying

protocol. The matrix in section 5.2 states that all RM-Reply patterns

may be used with consumer-generated payload(s) or application responses

on the receiving RMP side. However, the callback and poll RM-Reply

patterns provide multiple opportunities to return payload information

(as they are currently described, see (1) above) and the specification

does not describe which option is recommended. Our new Respond

operation (possibly restricted to specific RM-Reply pattern choices)

must be mapped to the underlying protocol at least as far as timing is

concerned. We may also decide to further restrict when the consumer may

invoke the Respond operation.


2a) The sentence "However, an RMP is not requried to disinguish WSDL

operation types." [please note new spelling errors] was introduced in

a recent edit to section 5.2, enshrining an assumption a few of the TC

had previously made. This assumption contradicts the complete control

an RMP has over the bits on the wire. The consumer may or may not

provide payload information (the consumer interface may be described

using either a request-response or a one-way operation type). Even if

the receiving RMP is only passing the information through, it must be

aware of when to wait for the consumer to invoke the Respond operation.

This sentence should be removed.


2b) The one-way consumer interface and Response RM-Reply pattern is the

most direct combination to reliably deliver one-way messages from a

producer "hidden" behind a firewall. The matrix in section 5.2 should

not disallow this combination. While synchronous polling at least

works, it always requires an additional round trip.


2c) The matrix in section 5.2 also was the first to introduce the idea that

the consumer could provide information intended for the producer. We

needed to extend the abstract model to introduce this earlier and avoid

a contradiction between the matrix and the model. I believe this issue

has become editorial as we discuss the details of the edits necessary.


2d) When using the Response RM-Reply pattern, the immediate underlying

response may be lost and the sending RMP may query using a Poll

request. Should the response to such a "spontaneous" Poll indicate

which referenced messages included consumer payloads in the earlier

response? The sending RMP might "just know" a consumer payload may be

available from information the consumer provides (WSDL, say) or some

other means; an indication of a consumer payload in the Poll response

informs the sending RMP directly. The sending RMP can already decide

when a resend might be necessary and any indications the receiving RMP

provides would be a new extension to the WS-Reliability protocol. Such

an extension would, primarily, reduce the size of the known subset

requiring resends since any a priori information would indicate only

that a consumer payload had been possible.


3) The description of duplicate elimination in section 3.2.2 does not

describe the content of either the immediate underlying protocol

response nor an RM-Reply that may be sent later (in the callback or poll

RM-Reply cases). In particular, whether or not consumer payloads from

the response sent the first time (in the case when the earlier response

had been lost) may be returned during this iteration is left

unspecified. As Sunil has stated, some have implementation issues with

caching payloads in the receiving RMP though this is the most

appropriate way to handle the duplicate message. We might thus avoid a

new requirement but concentrate on ensuring caching is allowed.


3a) Sunil mentioned in a private email that no RM-Reply pattern at all is

used unless an acknowledgement was requested. I have not searched but

am pretty sure we have not described RM fault semantics, duplicate

elimination nor consumer payloads in this situation. For example, will

the callback be invoked or the poll include any information about

successfully delivered messages when AckRequested did not appear in the

original message? I suspect we moved the ReplyPattern element out from

under the AckRequested to allow more generality here but the existing

text implies an RM-Reply is always publicized.


4) The RM Fault processing model described in section 4.5 previously

attempted to cover responses to duplicate messages though the reader was

not directed here from 3.2.2 "Duplicate Elimination". I believe we have

agreed not to lump faulting and responding to a duplicate message

together in the document and have addressed the editorial issues in

section 4.5.


4a) Sunil has outlined a few issues with including a SOAP fault when

returning an RM fault. If I remember correctly, the original reason

for this addition was avoiding an empty SOAP Body when the sending RMP

expected a consumer payload. If we accept all of the restrictions and

clarifications mentioned above (in (1) especially), the problem will be

limited to use of the Response RM-Reply pattern (request-response

underlying protocol utilization) with a consumer response expected.

The SOAP Fault would cause the underlying protocol response to match

the signature expected in that case but may cause interoperability

problems in other cases. Sunil would like to avoid the inherent

redundancy of a message containing both SOAP and RM faults. He also

points out that "send a SOAP fault" is not specific enough.


5) The specification is generally vague about the meaning of

"application-level" and talks about WSDL primarily as describing the

producer / consumer interaction without making this distinction clear.

In some cases, WSDL operation or MEP types are applied at all levels.

As a relatively editorial matter, we must clarify distinctions between

exchanges controlled by the RMP processing ("underlying protocol" or

SOAP message exchanges) and how the RM-Reply patterns map to those

exchanges and the producer / consumer interface (sometimes described

using consumer-provided WSDL). In effect, the producer and consumer sit

on top of an RMP that is (abstractly) implemented using an underlying

SOAP processor. That SOAP processor provides the one-way or

request-response message deliveries used for the RM-Reply patterns. The

RMPs effectively provide another, higher quality of service, WSDL

binding that the producer and consumer use to interact. We probably do

not need to include the SOAP processor explicitly in our model but we do

need to be clear throughout or document what level is discussed.

Primarily, section 5.2 will be the main place in which the producer /

consumer interface come to the fore. And, no, this is not as large a

change as it seems.


RE: [wsrm] Problems in Section 5.2
From Jacques Durand <JDurand@us.fujitsu.com> on
19 Jun 2004 00:20:32 -0000


Title: RE: [wsrm] Problems in Section 5.2




I'll try to address some of these points by Monday,

but so far I believe that WSDL descriptions should not be concerned with RM headers...


See inline,




-----Original Message-----

From: Tom Rutt [mailto:tom@coastin.com]

Sent: Thursday, June 17, 2004 1:04 PM

To: wsrm

Subject: [wsrm] Problems in Section 5.2


Overview of problems needed to be Fixed in Section 5.2


Section 5.2 is called reliability of WSDL operations.


We need to clarify what this means.


We agreed a long time ago that we would not require wsdl for all

implementations of this spec. At least we agreed that WS reliability

features should be able to be added to existing WSDL descriptions of web

services without changing the WSDL.


Well, this is what causes the seeming Conendrum. If we really want to

talk WSDL speak, then we should describe the entire soap body, including

our reliability header Elements. If we did this, the use case Doug wants in 2b would be readily admitted.


<JD> If you mean by "describe", some typing in WSDL,

I believe we should not need that. Shouldn't the SOAP model precisely render

these headers transparent to the service description?


Sunil: does not want to suggest putting reliability headers in the WSDL. While the user can do this, this takes away flexibility. We need to make the protocol simple, talking about bindings complicates things. We should not prohibit this, but I do not want to.


We want our protocol to work with the headers transparent to the WSDL. We should be able to work with whatever wsdl is out there, without modification.


One could take an existing wsdl, and transform it into a WSRM capable

wsdl by adding the soap header elements as input and output parts of the

wsdl operation, and wsdl binding them to the soap header. This should be

clarified/ discussed in this section. When the user is not using the wsdl, it causes problems in trying to explain how the spec Works in a BP 1.0 compliant manner (remember bp 1.0 requires wsdl). We have been thining of our header elements only as extension elements unaware to the user. Well this is what is causing some of our conceptual problems.


<JD> I think we can describe what are the right combinations of (SOAP binding, underlying MEPs, reply patterns) that are *required* by BP compliance (not necesarily *sufficient*) When and if WSDL is used, it would have to follow additional requirements that are more service-dependent


Jacques: This is in the later mail. With the introduction of respond primitive gives us operations that cover any higher level wsdl operation type, and that can bind to any underlying protocol type. Looking above the rmp and below the user layer of the rmp, when using it with wsdl, we should define how wsdl operation types map to these rmp primitives. This avoids one more confusion. Focus on the RMP operations, and stop talking about wsdl operation types. We want this spec to be useful without wsdl. The WSDL constraints are only on the way we use rmp operations. The underlying protocol, has been talking about request response, and has been assuming too much. The definition of request response protocol is overconstrained. We need to be more abstract in the view of the underlying protocol using soap level MEPs. The underlying protocol is a SOAP binding. For two way operation on http soap binding we have soap envelope in the request, and we also want soap envelope in the response. Using the HTTP for one way mep, means the soap envelope will not be in the soap response.


We need to discuss the simplifying limitation of the Respond primitive

only being used to convey the immediate consumer initiated payload (not

including the wsrm: response element of the soap header) to be conveyed

in a wsdl operation output message. This will take it out of the one-way



<JD> Before bringing in additional restrictions, I think a clearer

mapping of (1) how the WSDL op types map to RMP operations, (2) how these

RMP operations (and their usage patterns) map to underlying protocol,

would help clarify the discussion. This was not so critical before we introduced

the Respond/Notify channel, but now it is.


Jacques: No need to have this restriction of wsdl level on the RMP level. We have to define this in a way to keep these layers independent.


Sunil: could you explain the Response primitive. Who invokes it on what


Jacques: The consumer invokes the respond on the receiving RMP. This is needed to model the payload which is delivered to the receiving rmp by the consumer, in response to a payload it receives in a payload it receives from a deliver operation.


Jacques: a wsdl resquest response must map onto an underlying http request/response. The problem we had was, taking rmp as black box, it had only submit on one side and deliver on other side. How do you express that the response payload has to be correlated with the receiving rmp header response.


Doug: the way we have defined an RMP it is above or inclusive or a soap processor.


Jeff M: Do you mean intermediary.


Doug B: our diagrams to not separate an rmp from a soap processor, but it implicitly includes a soap processor in its implementation


Sunil: my concern is that this abstract talk is confusing, and is not solving the problem.


Jacques: we can try to solve problems we could not before, once we have this respond operation. We say RMP correlates respond operation with its own header response.


Jacques: In our implementation the correlation comes for free. In all implementations it has to be able to correlate a payload with a previous request. As an example, using the java handler approach for a web service stack design can make this easy.


I'll draft something on that.




  Re: [wsrm] Strawman Proposal for New wording of Section 5.2
From Tom Rutt <tom@coastin.com> on
18 Jun 2004 19:21:28 -0000

 Note 1) was cut off in the last message.


It should read:


1) The Response rm-Reply pattern MAY be used for a wsdl request response

operation which has the ws-reliability response element as its only

output message part.



Re: [wsrm] ws processing layers with successive wsdl descriptions
From Sunil Kunisetty <sunil.kunisetty@oracle.com> on
21 Jun 2004 05:45:05 -0000


Tom Rutt wrote:


> Lets look at a typical 2005 scenario.


> There is a user wsdl for operation foo with one message part fooInput,

> which is specified as an operation input message, and another message

> Part fooOutput specified as the operation output message.


> The producer invokes the wsdl operation with fooInput on the sending

> RMP. Now this user level wsdl is protected by wsrm features,

> thus the sending RMP adds the wsrm:request element to the soap header

> on the input message, and it is stripped by the receiving rmp before

> delivering the fooInput part to the producer.


> The consumer does a respond invoke on the receiving rmp with the

> fooOutput element, and the receving RMP adds the wsrm:response

> element to the soap header of the response The sending RMP receives

> the aggregate output message, and strips off the wsrm:response, and

> returns the fooOutput part to the producer.


> Now lets put ws security into the picture.


> The ws security processor adds the ws security element to the header

> of the request, and the receiving ws security processor strips

> Off the ws security header and delivers the fooInput and the

> wsrm:request header element to the receiving rmp.


> On response, the ws security processor adds a ws security header

> element to the receiving RMP provided wsrm:Response plus fooOutput

> element. The sending ws security processor strips off the ws security

> response header, to give the sending rmp the wsrm:response with the

> fooOutput element.


> This could all be described with effective wsdl descriptions for

> each level/Order of the ws header processing


> The ws reliability wsdl would have fooRel as the operation with input

> message parts fooInput plus wsrm:Request, and with output message

> parts fooOutput plus wsrm:response.


> The ws security level wsdl would have fooSec as the operation with

> input message parts fooInput, wsrm:request, and wss:requestHeader, and

> output message parts fooOutput plus wsrm:response plus

> wss:respnseHeader elements.


> I just want to point out that we could describe the boundaries of wss

> processing )i.e. succesive layers)

> each having their own effective abstract. wsdl spec.


> This might help to explain what is going on, even if the effective

> WSDL is never actually formally registered. It is useful for

> conceptually explaining what is going on.



While I understand your good intentions here, I think we should not do this as it complicates the specification by being too verbose and deviating form the fundamental and core reliability stuff.


I strongly advocate that our spec. should be very simple and just concentrate our own protocol. I for one still not totally convinced that we should dwell too much into the abstract stuff. For that matter, I'm still not convinced that we need the 'Respond' abstract operation.


The underlying problem (the 'Ordering' problem) you mentioned is indeed a genuine problem, but beyond the scope of our chapter and should be dealt by a SOAP processors/engine.


2 specific problems with your reasoning:

i) I for one will desist to include WSRM Headers or for that matter any QoS Headers in the WSDL definition. While it is indeed legal, I believe part to Header mapping is more meant for application Headers and not QoS. So I don't like to talk about wsdl mappings/bindings in our specification at all.


ii) while your solution to have different level wsdls for security and reliability may work, what if I want both security and reliability at the same time?






some editorial clean-up to prepare issues #1, #1a, #1b, #5,
From Jacques Durand <JDurand@us.fujitsu.com> on 21 Jun 2004 13:36:08 -0000


Title: some editorial clean-up to prepare issues #1, #1a, #1b, #5,


As a preamble to resolve issues #1, #1a, #1b, #5, here is a proposal

to straighten up our terminology about:

- MEPs (application-level / WSDL)

- underlying protocol




Jacques: The original proposal in contribution 1.01J is still basically ok, but there is a tight association with the respond and the underlying protocols. We should not assume the underlying protocol is request response. The reason to add respond is to allow allow mappings to underlying protocol. We do not want to hard code individual binding constraints (such as BP 1.0) into our soap level model.


Two editorial proposals:



1. Describe user-level message exchanges (e.g. WSDL) in terms of RMP usage

(Submit/Deliver/Respond/Notify). Then we can make abstraction of any user-level choreography, and express everything in relation to RMP.


That means:

- In the case of WSDL, explicitly define - meaning decide of - the mapping of WSDL MEPs (or operation types) to RMP invocations.


Tom: we need to be clear when we use MEP at wsdl level what does it mean.


Ageed to use MEP for soap level and operation type for WSDL level.


That is simply done as follows:

Given a payload (p) to transfer from RMP1 to RMP2,


- a WSDL operation of type One-Way maps to an RMP invocation sequence of the form: { RMP1.Submit(p) + RMP2.Deliver(p)}

We will refer to this as the "One-way RMP invocation pattern".


- a WSDL operation of type Request-Response maps to an RMP invocation sequence of the form:

{ RMP1.Submit(p) + RMP2.Deliver(p) + RMP2.Respond(p2) + RMP1.Notify(p2) }

We will refer to this as the "Two-way RMP invocation pattern", where the payload p2 is the response to p.


Once this mapping is defined (inside WS-Reliability specification for WSDL, or outside spec for other choreography dialects), we don't need to talk further about application-level MEP or WSDL MEP.

we only talk of RMP invocation patterns, which relates better to WS-R works.


Impact on spec: everywhere we talk of "One-way application level MEP" or "WSDL One-way MEP", we replace by: One-way RMP invocation pattern.

Same for Request-Response application level MEP...--> Two-way RMP invocation pattern.


Jacques: I would rather not have the protocol talk about WSDL in its abstract model. When you use wsdl operation type one way, that will be transferred into a submit operation onto the sending rmp, and will subsequently result in a deliver payload on the receiving side RMP. Once we have said this, we do not have to talk about WSDL any more. We just talk about RMP invocation patterns. BP 1.0 requirements would be left to constraints on binding to soap protocol. The rmp should know if there will be a corresponding respond primitive to a given deliver.


Tom: do we need to say how this is done, or is it enough to make that statement.


Jacques: when talking about correlating deliver with a respond this is behaviour of the receiving role of the RMP. An RMP can have both roles.


Sunil: the actions pertain to particular roles of the RMP. If respond operation is only on the consumer and receiving rmp this is fine.


Tom: we are trying to get BP 1.0 constraints to the particular binding of RMP invocation patterns and the SOAP layer.


2. The "underlying protocol" (defined also as SOAP binding protocol, in SOAP 1.2) is still something too vague, on which we have little grasp when it comes to defining how we can use it (how to bind our RM headers to it) At the same time we don't want to get too transport-specific.


I propose to only define the SOAP protocol (including its binding) used by the RMP in terms of what type of MEP it supports for SOAP messages, which is what

really matters to us.


Jacques: Use SOAP MEPs rather than underlying protocol concept for the standardized behaviour of the rmp processing. If a soap envelope is not required for the return MEP, then it does not matter if the underlying protocol has a response capability.


Jeff M: but the sender rmp has to know to at least ignore the response it happens.


Tom: while the underlying protocol mapping may affect the rmp behaviour, we do not need to expose this at the abstract level. We need an abstract protocol behaviour that can work with alternative protocol bindings.


Jacques: with bp 1.0 a wsdl request response will be bound to underlying http request response, but this should not be explicit in our processing model.


Jacues: Sending rmp may need to be able to correlate a response with a previous submit.



I call these "SOAP MEPs" (again, although SOAP is essentially one-way, SOAP MEP refers to properties of its binding). So we would say that a SOAP protocol binding is:


- Supporting a Request-response SOAP MEP if:

(a) a node that received a message with a SOAP envelope (called a request)

can send back a message with a SOAP envelope (called a response).

(b) the request-originating SOAP node can correlate the received response

with the request it sent.


- Used by a Request-response SOAP MEP if:

a response message is sent back, which contains a SOAP envelope.


- Supporting a one-way SOAP MEP if:

the SOAP node is simply able to initiate the sending of a SOAP envelope over

the underlying protocol (so not as resulting from a previous protocol action,

such as an HTTP POST or even GET).


- Used by a one-way SOAP MEP if:

In case a response message is sent, it does not contain a SOAP envelope.


So according to these defs, the SOAP HTTP binding (defined in SOAP) is supporting both Request-response SOAP MEP and one-way SOAP MEP.


Impact on spec: there are many places in the spec where an underlying "request-response" protocol is implicitly assumed (e.g. "...is sent over the request of the underlying p.." or " ... sent over the response of the underlying p..".


If we introduce the above definition of SOAP MEP, we can then rewrite the definition

- as an example - of Response reply pattern (terminology section) :

" When the Response RM-Reply pattern is in use, the request-response SOAP MEP must be supported. The outbound Reliable Message is sent in a request of a SOAP MEP instance and the RM-Reply is sent in the response message of the same SOAP MEP instance."


When describing an RM feature, we can first say which SOAP MEP is required or assumed, and then say how it is used.


That way we do not need make any reference to the nature of the underlying protocol, nor use unclear implicit assumption. Only its ability to support SOAP-level MEPs is described.


Jacques: I will try to show these changes in a new contribution.


Sunil I need to read it completely before I decide.


Bob F: I am concerned about the July 15 deadline, I would like to see if we can agree in time.


Bob: I just want to be sure it will not make the spec slip.


Jacques: these changes are to the model, and I do not think they will affect the implementations we have to the particular http soap binding. It is not my intent to bring runaway changes the spec, I just want to address these issues in the model of our spec to allow future bindings to underlying protocols.



editorial update for Respond / Notify RMP operations
From Jacques Durand <JDurand@us.fujitsu.com> on
21 Jun 2004 12:31:49 -0000


Title: editorial update for Respond / Notify RMP operations


Proposed (revised) updates for introducing the Respond operation, and Notify extension:

(As opposed to the one I proposed before, this new update does not preempt

the handling of some of Doug's summary items, e.g. does not assume an "underlying

request-response" protocol)


Reminder: The intent behind the recent proposal to add a "Respond" abstract operation

to the RMP, was to specify how the RMP must treat user-level MEPs that correlate responses and requests

such as (but not restricted to) WSDL request-response operation types.

"Notify" is also enhanced so that it may deliver a payload to a Producer

(not just failure notices).


Note: introducing Respond / Notify as a new RMP-to-RMP communication channel,

has more editorial implications on how the RMP uses the underlying protocol

and how the RMP maps to WSDL operation types.

This will be detailed separately.






1. Add definition (Terminology section):


"An abstract operation supported by the RMP. When invoked, the operation transfers payload data from the Consumer to a Receiving RMP, that is related to a previous payload received by the RMP and passed to the COnsumer via "Deliver". "


Notify: Add at the end:

"..., or passes to the Producer a payload sent back by the Consumer."


2. Add the following subsection in Messaging Model section (under 2.1):

Properties of Operations invocation:

"In order to act in both sending and receiving roles, an RMP MUST implement the four abstract operations Submit, Notify, Deliver and Respond. An RMP MUST be able to correlate a Respond invocation with a previous Deliver invocation. When the Deliver operation is invoked for a payload, a receiving RMP MUST know whether a related Respond invocation is expected."


3. Ignore the previous update proposed for 2.2.1. A more complete definition of the options for mapping the "Respond" invocation to the underlying protocol MEPs (and how that affects the bundling of RM Reply with business response) need be introduced.


4. In Section 3.2:

Unless we have time to address the reliability of payloads submitted via "Respond",

I suggest we add a scoping statement at the end of the QoS subsection of each reliability feature

(Sections 3.2.1, 3.2.2, 3.2.3) (because so far, we only describe relaibility of payloads submitted via "Submit"):

"In the current specification, the [ XYZ, e.g. Guaranteed Delivery] agreement is defined for payloads passed to the receiving RMP via the Submit operation. Although the [XYZ] agreement may etend to payloads submitted via Respond, some binding cases with the underlying protocol require a special handling not describes in this specification."


5. Latest updates proposed for Table 5.2 should not be done, until 5.2. fixed separately.


This will also be put into Jacques new contributin.

5.2      PC25






Doug Bunting


Title: Duplicate message responses

Description: http://www.oasis-open.org/archives/wsrm/200406/msg00078.html

Proposal: under discussion



RE: [wsrm] clarification on Respond primitive
From Jacques Durand <JDurand@us.fujitsu.com> on
14 Jun 2004 06:19:04 -0000


There was no subsequent email list discussion on this issue.


Tom lets get some email discussion on this issue before next week.


Tom: put minutes from last week on duplicate elimination discussion in separate email.

6         Discussion of Document Progression.


For discussion


Bob: We have June 29, July 6, and July 13 are the remaining dates.


July 13 Tuesday, approved CD and vote to submit on July 15.


Last possible clean text has to be ready July 6 meeting.


Bob we have two meetings between now and then.


Bob by next meeting on 29th we would have that Jacques text and the duplicate elimination text.


Jacques: I realize that has to be done this week.


Doug B: there is no difference in kavi vote and vote at quorate meeting. I do believe that these changes will help the spec considerably.


Doug B: I have two questions about this progression issue. We are creating a better spec, but it is a spec which is different that what we voted on. I would suggest we go thru a public review this time before we submit to oasis as a whole.


Doug B: Could have solid committee draft available for public review by the July WS-I meeting.


Tom: This could still allow a spec to be sent to OASIS membership by April 15th, if the public review had no substantial comments.


Doug B: the TC as a whole needs to decide whether a new public review is required.


Bob F: It is up for the TC to vote on whether the changes have been substantive.


Tom: After we have the next approved CD, we will have a vote on whether the changes are substantive. This vote will determine whether another public review is required.



7         Frequently Asked Questions

No time to discuss.


Tom posted the following:


Approved FAQ set for WSRM TC
From Tom Rutt <tom@coastin.com> on 3 Jun 2004 13:57:21 -0000


Alan moved to adjourn Bob seconded.


Meeting adjourned at 7:06 PM.


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