[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; [email protected] Tel: +1 732 801 5744 Fax: +1 732 774 5133Title: Draft Agenda to WSRM TC Conference Call � May 06, 2003
|
Preliminary Minutes of WSRM TC
Conference Call � The meeting of the WSRM TC� will take place by teleconference 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
Attendance:
�Meeting� was� quorate. 3
Minutes
Discussion
3.1 Appointment of Minute TakerTom Rutt will take minutes. Minutes will serve to record issue resolutions. 3.1 Approval of previous meeting minutesThe minutes of the June 14 teleconf are posted at: http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/7335/MinutesWSRMTC061404.htm � Abbie moved, Jeff Turpin seconded NO opposition minutes approved. 4 Status of Action Items4.1 Action 052503-1 (Tom Rutt) pendingTom took an action item to complete the status column of pre public review issues list, with correct URLs.
4.2 Action 060104-5 (Jacques) PendingAction: Jacques, will propose further edits, on the FAQ for composability. Still open 4.3 Action 061404-1 (Iwasa) PendingAction: Iwasa will produce new version 1.03 as the new editors draft as baseline. Completed. 5
Discussion
of Issues and editorial Comments
The following issues list includes items which need further discussion: 5.1 PC24
�� Summary of WS-Reliability 1.01* issues
discussed over past week 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 Title:
RE: [wsrm] Problems in Section 5.2 Tom: 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, Jacques -----Original
Message----- From:
Tom Rutt [mailto:tom@coastin.com] Sent:
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 discussions. <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 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 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? �-Sunil �� 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 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
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. Jacques --------------------------------------------------------------- 1. Add definition
(Terminology section): Respond: "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
�� RE: [wsrm] clarification on Respond primitive 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. Iwasa: 7 Frequently Asked QuestionsNo time to discuss. Tom posted the following: �� Approved
FAQ set for WSRM TC Alan moved to adjourn Bob seconded. Meeting
adjourned at | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]