Prelim Minutes WSRM TC Conference Call –
Feb
24, 2004
The meeting of the WSRM TC took place by teleconference
Tuesday Feb 24 2004, from 5:30 to 6:45 PM Eastern Standard Time
(UTC - 5)
0
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 Discussion of New Orleans Meeting and
Conference papers
4 Discussions of Issues
5 Discussion of
Editorial Comments
6 Discussion of Document Progression
Agenda approved
1
Roll
Call
Attendance:
|
First
Name
|
Last
Name
|
Email
|
Role
|
Company
|
|
Chris
|
Hipson
|
chris.hipson@bt.com
|
Member
|
BTplc
|
|
Jeff
|
Turpin
|
jturpin@cyclonecommerce.com
|
Member
|
Cyclone
Commerce
|
|
Jacques
|
Durand
|
jdurand@us.fujitsu.com
|
Member
|
Fujitsu
|
|
Kazunori
|
Iwasa
|
kiwasa@jp.fujitsu.com
|
Secretary
|
Fujitsu
|
|
Tom
|
Rutt
|
tom@coastin.com
|
TC
Chair
|
Fujitsu
|
|
Jishnu
|
Mukerji
|
jishnu@hp.com
|
Member
|
Hewlett-Packard
|
|
Eisaku
|
Nishiyama
|
nishiy_e@itg.hitachi.co.jp
|
Member
|
Hitachi
|
|
Nobuyuki
|
Yamamoto
|
no_yama@bisd.hitachi.co.jp
|
Member
|
Hitachi
|
|
John
|
Fuller
|
jfuller@wernervas.com
|
Observer
|
Individual
|
|
Junichi
|
Tatemura
|
tatemura@ccrl.sj.nec.com
|
Member
|
NEC
Corporation
|
|
Mark
|
Peel
|
mpeel@novell.com
|
ProspMember
|
Novell
|
|
Anish
|
Karmarkar
|
Anish.Karmarkar@oracle.com
|
ProspMember
|
Oracle
|
|
Sunil
|
Kunisetty
|
Sunil.Kunisetty@oracle.com
|
Secretary
|
Oracle
|
|
marc
|
goodner
|
marc.andrue.goodner@sap.com
|
Secretary
|
SAP
|
|
Pete
|
Wenzel
|
pete@seebeyond.com
|
Member
|
SeeBeyond
|
|
Tony
|
Graham
|
Tony.Graham@Sun.com
|
Member
|
Sun
Microsystems
|
Meeting
is quorate.
2
Minutes
Discussion
2.1 Appointment
of Minute Taker
Tom Rutt will take minutes.
Marc will serve to record issue resolutions.
2.2 Approval
of previous meeting minutes
http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/5630/MinutesWSRMTC021704.htm
Jeff moved to accept the Feb 17 minutes. Jishnu seconded.
No opposition, 2/17 minutes approved.
3
Discussion of New Orleans Meeting and Conference
Tom stated he told the OASIS staff that we
wanted to meet all day Wednesday, and Thursday morning for our F2F. This has been verified.
Jacques:
The panel discussion was not accepted, since
only our TC members were on the panel.
We cannot determine who will be in the panel.
It is up to the TAB to decide who the
participants are. Jacques is lobbying to
allow our original participants on the extended panel.
Jacques is continuing to lobby
Pete stated he sent an update to Jacques.
4
Discussion
of Issues
4.1 Rel 108/115 Semantics of Polling and Fault Returns
New Proposal to Resolve Rel
108/115 thru unified Response Element
This proposes to make RM-fault reporting
mechanism orthogonal to Soap Fault
model.
The soap fault model will remain in place for
faults associated with the soap
body of the request.
I propose that we not not map RM-fault to soap fault for any of our
response
reply patterns.
Conceptually, it works to keep the rm fault model and the soap fault model
separate and distinct
If we take this principal, there is no
Fundamental problem having a rm-response
indicate both
acknowledgements and RM faults.
So given the above rational I propose the
following detailed changes to resolve
R108/115:
Rewrite the Response Element section, 3.4 and
schema to allow to have one
element returned per
group being reported.
That element has a groupID
attribute, and zero or more lists.
a) a list of sequence
numbers to report messages in that group which have been
delivered. (for a singleton group ack this
sequence number list is empty)
b) for each fault code
which has been encountered for messages in that group, an
element which has the
fault code and a list of sequence numbers which faulted
due to that code (for a
singleton group ack this sequence number list is
empty).
This proposed response mechanism does not include fault
detail info, however
that could go into
extensions to the reply elements if so warranted.
The detailed proposed changes to the schema and
the response element text are
posted at:
http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/5628/ws-
reliability-SchemaProposal-2-23.zip
Other changes are proposed as follows:
---------
Remove the Fault element section, 3.5.
In Section 4, on Faults:
Lines 1243-1261 need to be replaced with the
following:
“
4 Fault
Processing
This section describes the protocol specific
fault codes that are needed to
better describe the
reason for ws reliability protocol processing
failures .
We categorize the faults into 2 categories based
on whether the fault was
generated because
Reliable Messaging Headers are malformed or invalid or because
of the some runtime
processing errors encountered by the RMP.
The former category is called Invalid Message
Format fault set and the latter is
called Request
Processing fault set. They are explained
in detail in the
following sections.
These protocol specific fault codes are returned
by the receiving RMP within the
response header element.
The WS reliability protocol does not directly
map our rm faults to the soap
fault model.
The soap fault model is used for reporting
faults due to the request payload,
which fits the soap
fault model better.
Thus an rm-fault could
come in a soap fault message, but the reason for the soap
fault would be due to
problems caused by the message payoad
Example case 1:
For wsdl
request/response operation types, a soap fault can occur for a reliable
request which was
delivered , but then encountered an application level fault
due to something wrong
in the payload (soap body of request
which is not under
control of Sending RMP)
or application processing space outside the realm of the
Receiving rmp.
That means a reliable messsage
acknolwedgement can be delivered on a soap fault.
Example case 2:
For the response reply pattern, used with wsdl two way operation type, the
return message could
conceivably carry an indication of an RM fault, which is
not itself carried on a
soap fault. The exact behaviour in such a case might be
an implementation matter.
A message with an RM fault indication MUST not
be delivered by the Receiving RMP.
If the message cannot be delivered due, say an request
fault, then there
would be no meaningful
data for the responder to put into the
soap body for the
WSDL response.
In some implementations, the responding
application may not be available to
participate in a
decision to issue a Soap fault for this non delivered request.
With such an implementation, the RM fault
indication could be carried on an http
response, which only
includes the RM response header and an empty soap body.
Other implementations which are more aware of
the wsdl operation definition,
might be able to also
realize that a soap fault has occurred for that messageID.
With such an implementation for the response
reply pattern case, the RM reply
could be carried on a
soap fault message associated with the wsdl operation
itself.
4.1 Fault Codes For
Reliable Messaging Failures
The following fault codes may be caried in an RM response element associated
with a meesage ID.
“
Excerpt of new text:
“
2.x Response
element
A receiver MUST include the Response
element to indicate Acknowledgments for reliable messages and indications of
reliable message Faults . This element includes the
following attributes:
o
SOAP mustUnderstand
attribute with a value of “1”
o
a ReplyPattern
attribute, which defaults to the value “Response”
At least on of the following child
elements MUST be present in the Response element:
o
NonSequenceReply element, which can have zero or more occurances
o
SequenceReplies element, which can have zero or more occurances
When the response is using the callback
reply pattern, if the reply and the new request share a common destination URI,
a Response element can coexist with a Request element, enabling the combination
of an Acknowledgment message with the business response to the original
message. This coexistence also enables a receiver sending another independent
message to the sender with an Acknowledgment message (e.g., to reduce network
traffic).
Table
14 Response Element
|
Cardinality
|
0 or 1
|
|
Value
|
None
|
|
Attributes
|
MustUnderstand
replyPattern
|
|
Child elements
|
NonSequenceReply
SequenceReplies
|
|
Fault
|
None
|
xample
7 shows an example of the Response element.
Example
9 Response Element
<Response
xmlns="http://www.oasis-open.org/committees/wsrm/schema/1.1/SOAP1.1"
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
soap:mustUnderstand="1">
<NonSequenceReply
groupId="mid://20040202.103832@oasis-open.org/">
<NonSequenceReply
groupId="mid://20040202.103811@oasis-open.org/"
fault="wsrm:PermanantProcessingFaulure"/>
<SequenceReplies
groupId="mid://20040202.103807@oasis-open.org/">
<RangeReply from="1" to="4"/>
<RangeReply from="5" to="5" fault="wsrm:InvalidMessageHeader"/>
<RangeReply from="6" to="42"/>
</SequenceReplies>
</Response>
(1) replyPattern attribute
If the response Element is being
returned as a result of a poll request, this attribute must have the value
“Poll”.
If the response is being returned as a
reliable message callback, to return replies sent using the Callback reply
pattern, this attribute must have the value “Callback”.
If the response is being returned using
the Response reply pattern, this attribute indicate the “Response” value, which
is the default for this attribute. In the case of a response returned using the
Respose reply pattern, the following restrictions
apply:
·
If the group does not use sequence numbers, the
first element of the response must be a NonSequenceReply
element containing the groupID which is the message
ID for the reliable messaging Request.
·
If the group uses sequence numbering, the first
element of the response must be a SequenceReplies
element, with its groupID equal to that of the
request, and with its first Range element having its
from and to attributes both equal to the sequence number in the request.
“
Sunil pointed out we are missing the soap client
fault, server fault categorization.
Someone could send fault detail strings as an extension.
Attributes lower case.
Propose to remove the default on
Change range reply to replyRange.
Tom Rutt wrote:
> Lines 1019 thru 1024 currently state the
following:
>
> “
> - *Response *: An Acknowledgment message
(or Fault message) MUST be
> sent back
> directly in the
response to the Reliable Message. This pattern is not
> applicable for
one-way application level MEP. The acknowledgment
> message that can
be sent back in the response is for the message in the
> request only.
Acknowledgment message for the former request
> MUST NOT be sent back.
> “
>
> To allow the receiving RMP to return acks or falts for former
> requests, the last
two sentences are too strong:
Discussions have led to a concensus
that the spec should be silent on
sending extra
information in the response for the response reply pattern.
The proposal to resolve rel
108 and rel 115 includes restrictions on a
response element
pertaining to response reply
pattern. These are
the more approprate way to state the requirment,
without disallowing
extensions to provide
more information.
Delete the last two sentences:
"
The acknowledgment message that can be sent back
in the response is for
the message in the
request only.
Acknowledgment message for the former request MUST NOT be
sent back.
"
Sunil moved to accept the proposal with the
editorials from Sunil. Jeff seconded.
No opposition, close rel
108/115.
4.2
Rel 113 Message Delivery processing after Fault.
Detailed proposal to Resolve Issue Rel 113
Lines 526 thru 532 currently state:
“
If the RMP sending a Reliable
Message does not receive an Acknowledgment
for a sent message that has not yet
expired, it MUST resend the same
message with same Message Identifier to
the receiver RMP until the
sender gets an Acknowledgment message
from the receiver, or until the
number of resend attempts specified by
the RetryMaxTimes agreement item
is exhausted, whichever occurs first.
The time interval between two
retries is specified by the RetryTimeInterval agreement item. If the
sender RMP fails to send the message
(i.e., no Acknowledgment is
received), the sender RMP MUST notify a
delivery error.
“
This does not talk about fault
conditions.
Proposed Change:
Change “Acknowledgement” to “Acknolwedgement or Fault” in the first
sentence of the text quoted above.
Add the following paragraphs
immediately after the exsting line 532:
"
The sending RMP MUST NOT send
retries with a message ID, for which it
received an rm-response
with one of the following fault types:
* an
invalid message format fault code (table 18)
* an
unsupported feature fault code
* a
permanent processing faulure fault code
The RMP MUST NOT return
an RM fault for a delivered messageID.
The RMP MUST NOT deliver a message
which encounters an RM fault.
“
Add the following paragraph
immediately after exsiting line 660:
“
The receiving RMP MUST NOT update
its Group Termination Criterea using
parameter values from a rm-request
which encounters an RM fault.
“
Sunil suggested the fist list be
any fault except the messaging processing fault.
Chris suggested to
exclude the transient fault in the group termination criteria.
Jacques re-itereated that the retry is exactly the same message with
exactly the same header values.
Tom suggested to Change
the last requirement to
The receiving RMP MUST update its
Group Termination Criterea using
parameter values from a rm-request,
even if that request encounters an RM fault.
Jacques moved to accept amended, Jishnu seconded.
No opposition, rel
113 resolved.
4.3
New issue on elimination of Message Header on
Request
Proposal
to resolve New issue on need for MessageHeader
in Poll Request:
If
a poll request is not piggybacked on a reliable message request.,
it
does not need a message header. There is no meaning to
expiry time for
the poll request, and there is no need for a message id for
the poll
request itself.
It
would simplify the protocol if the poll request message, which is not
itself piggybacked on a new reliable message request, does
not include
the request header.
In
addition, this change would allow the Request header to be merged
with the MessageHeader, so further
simplify the protocol processing.
Detailed
Changes Required:
Lines
873 and 874 have the following Sentence:
“
A
RMP MUST include a MessageHeader element in a
Reliable Message, a
PollRequest
message, an Acknowledgment message, or a Fault message.
“
Change
this to the following:
“
A
sending RMP must include a MessageHeader element in a
Reliable message.
“
lines 900 and 901 state the following:
“
The
RMP MUST include the MessageId element for Reliable
Message,
Acknowledgment
message, Fault message and PollRequest
message.
“
This
needs to be changed to the following:
“
The
sending RMP must include the MessageID element for a
reliable message.
“
Merge
the existing section 3.2 into Section 3.1. add the
three child
elements “ack requested”, “DupicateElimination”: and “MessageOrder”
at
the end of the MessageHeader.
Rename
the new merged section 3.1 to be “Request Element”
Change
all occurences of “Message Header” to “Request
Element in the
entire document.
Remove
the “InvalidMessageHeader” fault from the tables in
section 3.1
before line 954
Merge
the explanatory text after line 1266 in table 18 from the
InvalidMessageHeader fault into the InvalidRequest
fault: as follows:
“
InvalidRequest -
This
fault is sent when the Request element is wrong or invalid.
Examples
are:
1.When any of the mandatory elements such as MessageId, ExpiryTime,
ReplyPattern are missing
2.SOAP:mustUnderstand attribute is missing
3.When AckRequested, DuplicateElimination or MessageOrder
elements
appear twice
4.SOAP:mustUnderstand attribute is missing
“
.Change
the message format pictures in Section 3 to take MessageHeader
out of the poll response message.
Change
the message format pictures in Section 3 to merge MessageHeader
and Request element into a new Request element.
Lines
1099 thru 1101 , in the existing section 3.3 state the
following:
“
A
sender MUST include the PollRequest element only in
the PollRequest
message as shown in
the Figure6. The PollRequest
message contains two direct child elements
for SOAP Header
element. The one is MessageHeader
element, and the other is the
PollRequest
element.
“
change this to the following:
“
A
sender MUST include the PollRequest element only in
the PollRequest
message as shown in
the Figure6. The PollRequest
message contains the PollRequest element.
“
Nobody
has a concern about the merger.
Jacques
stated the the reason we had a separate header was
that the elements in the header could be replaced by other web service
standards. However, the request header
now only has only ws reliability specific elements.
Jacques
did not like the word request, because it is overloaded. This could be confused with a wsdl response sent as an rm.
John
Fuller stated we should change it from the name header. It is not common.
Sunil:
I like RM Request as the title. Also RM response.
Sunil
Proposal:
RMRequest, RMResponse,
RMPollRequest:
Sunil
can propose name changes later.
Ok
with using Request for merged element.
Jeff
moved, Jishnu seconded to
accept proposal.
No
opposition, motion passes.
4.4
Issue 49 WSDL Annotation
.
Anish stated this proposal is to resolve
Rel 49 on how to annotate. He gave an overview of the proposal, which he
characterized as a backport of the work in wsdl 2.0.
The following email was discussed:
Jacques Durand wrote:
> Anish:
>
> that
looks clean, not overloaded, and I believe can be introduced
> as
naturally as any previous annotation mechanism.
>
> See inline comments tagged
<JD> in attached doc.
>
> - I think the proposal needs
be more explicit on how
> to express “required-to-use”
features vs. “”supported” features.
> I gave it a try in my
comments.
>
Thanks for the comments.
The idea of the compositors is
that, the compositor semantics specify whether something is required or just
supported. Perhaps the examples need an explanation which might make things
clearer.
Of the four compositors:
“all” :
Every element (feature/property/extensibility-element) that is composed is ‘required’.
“choice” :
Exactly one element is required but all are supported
“one-or-more” :
at least one is required but all are supported
“zero-or-more” :
none is required but all are supported.
Jacques, we need to make this clear
in the spec.
Comments and example in your
<JD> annotation under section VI.A :
>Let me know if I got these right:
>- I guess we can use a
"zero-or-more" composer to mean that the
>composed
>features are all supported but
optional for client.
>- to say that a feature below
is NOT supported, would require a "false"
>value
>under an
"all" composer (e.g. for message-ordering).
>- to say that you must use
either poll or callback but NOT response
>reply,
>would require:
><compositor
"all">
><compositor
"one-or-more">
><..callback-reply-pattern..>true<>
><..poll-reply-pattern..>true<>
></compositor>
><..response-reply-pattern..>false<>
></compositor>
></JD>
You got it exactly right!
> - these annotations map
clearly to the notions of RM Agreement and RM Capability,
> of
which they are a concrete representation.
> I think it is the proof that
WS-Reliability is open to externally defined
> ways
to express WS policies, and proposes the right abstract notions to help this.
>
> Jacques
>
>
The first document is generic.
The second is specific to WS reliability. Features and properties are defined for wsdl services.
The client side deployment
descriptors are the configuration parameters, which do not go in the wsdl document.
Tom asked about the conformance.
The following is in the proposal:
Conformance
Implementations of WS-Reliability
are expected, though not required, to
understand the WSDL extensibility points
defined in this proposal.
Understanding of these
extensibility points promotes interoperability. When a
WSDL document contains these
extensibility points, it is through these
extensibility points that a service advertises
its supported and required
features. Therefore it is RECOMMENDED that
implementations recognize,
understand and support these extensibility
points.
It is also possible for services to
advertise features through other channels
(such as
UDDI) in addition to these extensibility point. Mandating that every
conformant implementation recognize,
understand and support these
extensibility points is considered to be too
high a bar for conformant
implementations. Therefore, it is not required
(though recommended) that every
conformant implementation support these
extensibility point.
Tom: who is responsible to do this. Could it be a
human programmer hand coding from the values in the extension.
Anish: it could be the wsdl processor to do it,
RMP is separate from wsdl.
Jacques: I agree that this notation
would not have to have meaning for the RMP.
It is a notation to allow a web service to indicate it capabilities.
Tom: every other feature of our
spec is optional for implementation.
Anish:
some wsdl processing will be able to automate
the tool chain to configure the rm properties from
the service description.
Jacques: It is a
good annotation syntax. The compositors does the job very well. There are good ways to use them, and bad
ways.
If we are explicit on their use, it
will help. The all features,
could each have several choices. That
means the user could have complicated nestings of
compositors.
This can be mapped to rm agreement and rm capability.
The syntax is not heavy.
In general:
Marc G: I have concerns. This proposal just came in. I am concerned about backporting
generic features. I have to have
discussions before I can agree to support this.
Is features and properties stable in wsdl 2.0.
Anish: I believe they are there to stay.
There is a face to face next week, this is
on the agenda.
Tom: we would be agreeing to our specific
way to do it for this version. We would have
to put it all in our document.
Chris: I have some slight reservations, this is a wsdl 2.0 draft.
2.0 might move. WSs is the fist to need this. Are they using it.
Tom: All of this would have to be in
our spec. We would be standardizing it.
Anish: Wsdl 2 probably
will change. However, this is based on wsdl 1.1, and is closely matched to the wsdl
2 proposal. It will not be a big deal to
do both ways in the future.
Briing to email list.
4.5
Soap
fault for missing reliability features in request
We need a Generic SOAP fault for
WS-reliabililty
What fault, if any, can a service
send back to a client, when the
service requires that all clients
communicating with it MUST use
WS-reliability (or specific
feature(s) of reliability), but the client
sends a message that does not contain
the (right) WS-reliability headers?
Interop requires not only defining what
header to use and when but also
what faults to generate when the right
headers/specs are not used. E.g,
consider a service that requires the use of
callback, but a client sends
a message which does not specify the
reply-to address.
It would be worthwhile to define a SOAP fault
for such purposes.
Jacques, I am not sure if that is a
problem A sender might send a non reliable
message, the receiving rmp has no way to know about the
contract. The contract is driven from the
sender side.
Log as new issue.
4.6
Clarification
Issue on Service enforcement of agreement
I just realized a new issue for
clarification:
What is the expected service
behavior when the client does not respect
the agreemen
(i.e, contract) specified for a web service (conveyed
through whatever means)?
In this case, is it required that
the service send a fault OR is it up
to the service implementation to
decide. This has conformance
implications for the service.
Example:
a service that requires the use of callback (as
specified in the
service contract) receives a message that
uses another mechanism for
reply,
can the service still process the message OR it it
required to
fault?
--
Log as new issue
4.7
Sunil
new Issue on Callback for Poll Request
- New
Issue
From Sunil Kunisetty
<Sunil.Kunisetty@oracle.com> on 24 Feb 2004 00:50:10 -0000
Sunil:
sent a proposal for a reply to on the poll request.
Tom:
you seem to be adding a new requirement. An asynch poll was not
in the requirements.
Sunil:
our requirement never said the response has to be synchronous.
Tom:in the definitioan
for poll, s the response is on the underlying response.
Sunil,
there is a need for a poll when only have oneway information.
flow
Tom:
take this to the list for discussion. Please express your opinion on the list.
Log
as new issue
5
Discussion of Editorial
Comments.
Editorial Comments for Discussion
No problems
with Jacques reshuffle.
Go ahead with
it for the next version.
6
Timing of WS-Reliability progression
Iwasa will have another editor’s
draft by the end of tomorrow.
Get in by Monday morning.
Sunil will give a new schema with the amendments form these
minutes..
Tom stated it is important to have a public review underway
before the next WS-I plenary, on March 16th.
Timeline
proposed at F2F meeting.
- Feb
10 – Tuesday
call, final editing instructions agreed.
- Feg 12 – Document posted for TC internal review.
- Feb
24 – TC review comments resolved, editing instructions produced.
- Feb 25 Frozen
document completed, TC review begins.
These dates will likely be delayed by one week.
- March
2 – CD 1 ballot closes
- March
5 – 30 day Review initiated
- April
5 – 30 Day public Review ends
- April
15, submit to oasis staff for member vote
- May
01– Membership two week review
- May
15 – start member two week vote
- May
30 - member vote concludes.
Earliest Oasis Standard.