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: some editorial clean-up to prepare issues #1, #1a, #1b, #5,


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


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.

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.



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.
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.





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