I forgot about Rel 97 AI I had. I'll send one before the
As per the Poll thing, +1 to BobF's suggestion. I'd like to see
a complete proposal with all specifics for who ever is proposing
differently. I appreciate if the person can address the problems
I mentioned in one of my mails.
"Bob F stated we need to get all the proposals down to specifics, to
get the flames out of the discussion. If someone came out with proposal
for the body it would help."
While I've comments to MarkG's comments on this, I'll reserve
for the F2F.
We should close this issue at the F2F, so that I can work on the
Tom Rutt wrote:
the prelim minutes are attached.
Please post any requested corrections before Thurday PM.
Tom Rutt email: firstname.lastname@example.org; email@example.com
Tel: +1 732 801 5744 Fax: +1 732 774 5133
WSRM TC Conference Call – October
The meeting of the WSRM TC took place by teleconference
Tuesday October, 2003, from to 7:30 PM Eastern Daylight Time
items from previous meeting:
agreed to get a proposal for the semantics of RemoveAfter
had a proposal to change the syntax of the ack
response, for multiple acks. Payrits
agreed to participate in the proposal.They
should send a proposal to the group.Still
Open, not yet discussed Rel 75
Discussion of Reliable Request/Response Wsdl
operation support – Still Open, their proposal is complete, no discussion
has requested me to re-list the requirements for Poll RM Reply pattern
 and also list the concerns I’ve mentioned in the con. call.
I already listed few issues briefly before .
a client behind a firewall using one-way MEPs.
It can’t use the Response RM Reply pattern as the application is using
one-way MEPs. It also can’t use the Callback
RM Reply pattern as it is behind the firewall. So essentially there is
no easy way out. I believe this is very prominent use case and should have
an efficient solution. Poll RM Reply pattern solution would be solving
this problem efficiently.
is not always an alternate if the payload is huge. Retry-on-demand is an
alternative. And one way to achieve is to poll the message before retrying.
Client: Currently for applications using one-way MEPs
and Callback patterns, they need to have a listener on the client side.
This may be acceptable to fat/thick clients. This requirement may be too
heavy weight for (very) thin clients especially if not all messages have
to be reliable (say only 5 out 100 msgs.
sent are critical for an application). So instead of having a listener,
the Sender can only poll for acks.for
those critical messages).
the TC has unanimously accepted the requirement, and the syntax was agreed
in-principle, the main concern seems to be more conceptual. Whether this
request should besent
in the SOAP Body or SOAP Header? I foresee many issues with sending the
request in SOAP Body.
sending in SOAP Body:
this Poll request has to be sent in the SOAP Body, then it has to be defined
in the WSDL unlike in the Header case. In the latter case, it is not a
must rather could.If not, interoperability
is not guaranteed, schema/payload validation won’t happen etc.
if it has to be defined in WSDL, where?
as application’s WSDL: WSDL 2.0 (was WSDL 1.2) does have support for Interface
(was PortType) inheritance. Provided with
this, we could have required that all application interfaces that require
RM Poll could inherit the RM Poll Pattern PortType.
But WSDL 2.0 is not expected to be in community draft before we are. Even
if so, we still has to solve the WSDL 1.1 cases. So for WSDL 1.1, this
would require mucking around the Application’s WSDL – which is not acceptable.
Mucking around problem will exist whether we are changing the same PortType/Port
or whether adding new PortType/Port to the
element or adding a new <wsdl:service> to
the same WSDL. Mucking around has lot of problems:
How is the updated WSDL available to the user?
It is no longer application’s WSDL, rather a combo version.
If QoS module has to update the application’s
WSDL, who does when & how?
endpoint same URI as application endpoint URI in a different WSDL: Other
option is to create another WSDL with one operation (Poll RM Reply Pattern)
and endpoint address will be the same as the application endpoint address.
However, the concern/issues here are:
How does the platform (RMP) get hold of this WSDL?
If the platform (RMP) hosts 1000 applications, do we have to create 1000 WSDLs
with the same portType/Port with different URIs
(basically one each for each application service endpoint)?
WS-I BP 1.0 discourages URI overloading though doesn’t prohibit it.
If the name of the operation is “poll”, then we will have a restriction
that user shouldn’t have any operation with the same name. [This is not
an issue if it is a DOC service as it would be namespace qualified. This
will be an issue if it is a RPC service].
endpoint different URI: The other option is to treat a RMP as a Serviceand
hosted on a different endpoint/WSDL. Issues in this case:
How does the client get hold of the WSDL?
How is the Service implemented? Rpc/doc,
If a RMP implementation uses different (persistence) cache for different
endpoints (for different applications), how does this centralized RMP endpoint
get hold of all these caches?
If every QoS is treated as a different Service
and has a different endpoint, how can we achieve Secure, Transactional
and Reliable stuff on the SAME endpoint?
No mechanisms to prohibit other (non RM) Headers on this request to this
issues with Body:
odd. All other RM operations are expressed in Headers.
Generally speaking Body contents are meant for end applications. Headers
are the extensibility mechanism for Web Services and are a double edge
sword. If required, they can be defined statically in the WSDL or can be
added dynamically on wire without being defined in the WSDL.
Most of us (at least all the Interop participants
used some sort of Handlers) will be using Handlers for the RMP implementation.
JAX-RPC Handlers are meant to be triggered based on certain Headers, i.e.,
a Handler definition has aset
of Headers (QNames) that are mapped to it and
it is meant to be invoked only when those Headers appear on wire. So if
we send this RM operation as a SOAP Body without any Headers, how will
the Handler be invoked? We end up peeking into every message if this new
implementation requirement is imposed.
Piggybacking will be prohibited.
sending in Body is still possible, but have
lot of issues as mentioned above. It should be the last resort. I don’t
see any problem using Headers for sending this Poll request except for
few conceptual worries, so I don’t see a need for a change. Here are the
advantages using the Header:
with other RM operations.
to define WSDL Bindings if required.
is nothing wrong in sending operations in SOAP Headers.
won’t be re-inventing a new MEP, as MEPs
deal with Senders & Receivers and not Body or Header. The current proposal
still constitutes the R-R MEP.
spec. doesn’t say that Headers shouldn’tbe
used for operations. Infact, it’s perfectly
valid to use Headers for Platform (non application) operations. Here are
some snippets from SOAP Specs.
provides a flexible mechanism for extending a message in a decentralized
and modular way without prior knowledge between the communicating parties.
Typical examples of extensions that can be implemented as header entries
are authentication, transaction management, payment etc.
SOAP header is an extension mechanism that provides a way to pass information
in SOAP messages that is not application payload. Such "control" information
includes, for example, passing directives or contextual information related
to the processing of the message. 
I also discussed this in length with our rep. on XMLP W3C WG
he echoed my thoughts that it is nothing wrong in sending in
don’t think this is anything different from the Callback thing we are doing.
specifications already send QoS-like operations
in Headers. The only difference is that they are sent with some associated
payload, where as in this case, there is no such payload.
multiple Poll requests
backing with other requests to the same endpoint.
new implementation restrictions. Consistent with
the current approach.
me also address Mark’s concerns raised in his mail :
Security is bit different when compared to Reliability, Transactions, Lifecycle
etc. The former has tight dependency with payload, while the latter ones
are loosely coupled and generally have a
XKMS didn’t define WSDL SOAP Bindings and hence they don’t have the problems
I mentioned above.
XKMS didn’t define any Header operations and ALL of them are in Body. So
at least it is consistent in that respect.
in short, there are no technical issues as far as I can see with sending
this request in SOAP Header except for conceptual concerns.
Mark G stated
that while the use cases are strong, the potential solutions could take
several months.He would not want
to waste the entire F2F on this issue, because there are a lot of other
issues that should be resolve.
stated we are going for a fist committee draft out of the meeting.
proposed to limit the time at the meeting, if we cannot get agreement we
would postpone to a future revision.
Mark G stated
that the application will likely to be aware that the polling is going
on.The intermediaries would not
do it, only the thin client would do it.The
app could be involved in this interaction.
Oracle – I guess
it is not seen as a system operation.
Mark G, the thin
client app probably would do the polling.
Jeff M agreed
that the intermediary would be acting as a client in this case.
Mark stated the
intermediary adds to the discussion, and it shows it is most useful for
Jeff M asked
if the RMP is an exposed service, or is it under the covers.
Mark G stated
that if it is under the covers, the polling is not seen by the client.He
stated that the client needs access to the polling operation to do the
Jeff M stated
that do we make rmp an application level
thing, or is it the qos mechanism.
Oracle 0 I want
it to be a qos mechanism.
Jeff M what is
the target of the service?.Is
it the RMP or the ultimate endpoint.
Oracle – all
the WS implementation are treated as QOS
mechanisms.We allow the end users
to add these qos to their end services. It
does not matter to them what these protocols are.
Oracle – keep
as system level op.
Mark G – the
application would participate in this.
that the Header poll allows thin client rmp
to add the poll on a new Reliable message delivery.
Mark G is not
convinced that this is an important feature.
Doug B stated
that this is not enough of a benefit to sway the solution.
The ability to
ask more that one question at same time is a good thing.
Marc G: Since
the poll message is so tiny, it might not be a major concern whether piggybacking
is not allowed.
is the address of the poll operation needs to be made known to the client.
Tom stated that
the easiest way to resolve the issue is to demand that the poll operation
is addressed to the same url
as the one the reliable message was sent to.
Jeff stated it
makes sense to demand that it be sent to the same URL.
Mark G stated
that it makes sense to have the poll go to the same url
whether or not it is in the body.
that they are using header handlers to ease the implementation of ws
They do not have
to look at the bodies if the protocol is in the headers.
how many endpoints are needed for the polling endpoint, is another issue.
Mark G stated
that requiring the same URL would allow turning on and off the poll for
Focus on a solution
by email before the meeting.Limit
the discussion, the first discussion at the meeting, and if we cannot agree,
put it off to the next release.
Bob F stated
we need to get all the proposals down to specifics, to get the flames out
of the discussion.
If someone came
out with proposal for the body it would help.
81 thru 86 on Parameters
a small group look into this issue before the F2F.
He has a basic
would propose we create a small task force to generate a group proposal
for Rel 81 - 86
Parameters), as it is an issue with several possible ramifications and
we need to sort out and decide on before shaping a coherent proposal.
what is the scope of these parameters?
connections sender-receiver an RMP is involved in?
One individual connection?
is a summary of my (revised) initial but partial proposal on these:
81: Maximum message lifetime/duration
(ExpiryTime is now mandatory)
82: Maximum message group (or message sequence) lifetime
propose to rename removeAfter attribute,
as GroupExpiryTime or ExpiryTime,
propose to add GroupMaxIdleTime parameter
as an option to terminate a group
on maximum idle time between two messages. But would only apply if
that the remove after time limit ends a group, or the end message for the
group.Either of these can end the
is an optional attribute currently.Another
way to estimate that the group is over is to put a time limit on the elapsed
time between two messages in the group.He
revised the initial proposal to state that this elapsed idle time is used
when remove after is not specified.
83: Resend interval (related REL 47)
proposed in issue list.
84: Retransmission count (related REL 47)
proposed in issue list.
85: Duplicate search scope (minimum number of past messages to look-up)
defer, as maybe more an implementation issue tied to overall available
86: Unordered messages window size (max number of messages to hold)
cancel, see proposal for Rel 57.
will have to detect their persistent store limits.
I see at least 3 parameters (Rels 82, 83, 84)
that represent some
of RM agreement that govern the behavior of a Sender, of a receiver or
that should not appear in message headers. The editorial treatment of these
be something like:
reliability feature XYZ is required, an RMP MUST represent and persist
parameters <...> [for each connection][for all conenctions,...]"
parameters can then be referred to by the spec to describe the behavior
of an RMP.
that issue 57 for window size might not be able to be specified for an rmp
to enforce.He stated this in his
proposal to resolve issue 57.Ordered
sequence missing message on receiver side.He
as covered this with Scott, and they have proposed a resolution.
The two parameters,
forRel 82 will affect our protocol.Group
Max Idle time could also be in the header.Three
parameters are proposed for being in the message.
that other parameters do not need to travel to the receiver.
Marc G stated
that if these parameters are part of the RMP, the receiver could use faults
to indicate this to the sender.
For example the
resend interval parameter is in the rmp
layer, but the sender does not need to tell the receiver what it is.If
the sender send messages too often, the receiver
can only send a fault.
are under sender control, and the receiver does not need to know them.
Marc G asked
why parameters should not go into the header.
for a small team to resolve these problems.
There was a Question
on retransmission count being sent from sender in the header.
Want to have
all header values determined by the end of F2F.
we need to determine which parameters appear in the message header soon.
to retire a group that is taking too long.
who could commit to help review any text he prepares on this topic.
Marc G agreed
to review Jacques text.Bob F agreed
to review the proposal from Jacques.
Tony Graham volunteered
to review the proposals.
They will post
the output before the meeting.
will have a proposal available at meeting.
an email on 9/30:
Ordering and Missing Message Behavior Description:
out from issue REL-16
is the behavior of a WSRM receiver that is ordering messages and one of
never received, or at least not within the MET (timeout) of a subsequent
is being used?
example: it receives msg #0, #1, #3. The
MET for message #3 is 5 minutes so the receiver
wait more that 5 minutes for #2 to arrive. What does it do when the 5 minutes
recommendation on what WS-R should cover regarding Guaranteed
messages involved in a WSDL request-response :
Only the following GD cases should be supported by this version of WS-R:
GD of request + GD of response (Variant 1)
GD of request + no GD of response (Variant 2)
following case should be excluded (not covered by this specification) (see
GD of request + GD of response (Variant 3)
The recommendation for GD of request-response,
is that its use of Ack and resend procedures
will differ from one-way ops in the following way:
is treated as a single transaction (will be entirely replayed, if either
case of Variant 1, in case the response is not acknowledged, the request-response
should not be replayed.
the Ack should be resent (see Proposal 1.2)
(depending on firewall restrictions on either side,
using RMP-level polling to get the Ack,
or a resending mechanism for Acks.)(to
Given the impact of supporting GD request-response on SOAP implementations
(see Appendix A), recommendation is that it should belong to a higher conformance
profile for WS-R. i.e. some implementations
that cover only the reliability of one-way operations
still be considered as conforming at some level to WS-R.
the proposal above.
this will not be easy to implement on a soap stack.This
should be optional feature.
Agreed that we
will have a agenda discussion on conformance
at the meeting.
to add this aspect to the conformance discussion for the meeting.
this at the meeting how to handle this.There
are still some minor issues to decide, the ack
from response is lost.How do we get
the other ack.Jacques
will lead this discussion at the f2f meeting.
Draft Spec for Meeting
Marc G asked
if we will have a New draft for face to face
meeting, with accepted issue being moved into the spec.
There are some
issues which are closed and that they could be put into the text.
agreed to check all closed issues to get them into the spec.
agreed to get document out by the end of the next week.
of F2F meeting document distribution policy and agenda(Oct
28 - 30) in CA
The chair asked if we can agree that the meeting will
be all electronic document access
It was agreed that we will not have paper distribution
at the next meeting.
Agreed starting time
Agreed call in periods
First morning for roll call. pacific coast time for roll call
And the last two days, time the call at the normal
call time Eastern Time.