[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Prelim minutes of 4/6/ teleconf
/The preliminary minutes are attached. Please post any corrections to the list before friday. Tom Rutt WSRM Chair -- ---------------------------------------------------- Tom Rutt email: firstname.lastname@example.org; email@example.com 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 took place by teleconference
<![if !supportLists]>0 <![endif]>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 Discussions of Issues and editorial comments
4 Discussion of FAQ for WS-Reliability
<![if !supportLists]>1 <![endif]>Roll Call
Meeting was quorate.
<![if !supportLists]>2 <![endif]>Minutes Discussion
<![if !supportLists]>2.1 <![endif]>Appointment of Minute Taker
Tom Rutt will take minutes.
Minutes will serve to record issue resolutions.
<![if !supportLists]>2.1 <![endif]>Approval of previous meeting minutes
Jacques moved to approve 3/30 minutes. Jeff T seconded.
No Opposition, Minutes are approved
<![if !supportLists]>3 <![endif]>Discussion of Issues and editorial Comments
<![if !supportLists]>3.1 <![endif]>Group Start Clarification
· Group start issue
Proposal from Sunil & Jacques on an issue assigned to us at last call:
Group "start" status is redundant with sequence number = 0 used for the
first message of a group. Having two starting group markers is redundant and
may lead to inconsistencies.
(a)- we keep seq num = 0 as a MUST for the first message of a group. @status="start" is no longer used, or relied upon.
(b)- we state more explicitly that the absolute max value for sequence number (in 184.108.40.206) is 18446744073709551615 (XMLschema unsignedlong)
(c)- we state more explicitly that a group must NOT wrap-around seq numbers,
i.e. when the max integer limit is reached, the group automatically closes.
We add this closing case in 5.1 (T6).
(d)- we remove the @status attribute from the schema, and use instead an attribute named "last", with values = "false" or "true". Value "false" is the default. When @last="true", it is the same as previous @status="end". But it is now OK to have the first message of a group be also the last one, even when using seq numbers.
NOTE 1: removing @status and using @last instead, is less ambiguous now that
there is no reason to use "start" and "continue". In addition, we keep using "status"
with a different meaning: the spec says frequently that a PollRequest is used to get
the "status" of messages, which is a different thing. This is confusing.
NOTE 2: a conservative alternative to (d) is to keep @status, but allow only two values: "end", "continue" ("continue" meaning "not end").
NOTE 3: Places affected by the change from @status to @last:
simpe edits (in many cases, just remove status="start")
except for subsection (4) in 220.127.116.11 (replace 10 lines). Spec areas affected are:
-sec 18.104.22.168: Line 617, Example 6, Table 3, Subsection (4) on Status attribute (line752-762)
-Table 16 (InvalidMessageParameter entry)
-sec 5.1.1, line 1118.
-sec 5.1.2, line 1127.
-Sec 5.1.3, Termination T3, T4.
NOTE 4: (suggested by Jacques) We also state that it is recommended that the
sender application only uses a "group handle" - and not directly the GroupId - when
submitting a message for a particular group.
*In case* group handles are supported, then in case a Sender submits a message that exhausts the last sequence number in a group, then the Sender must be able to keep submitting messages for the same group handle, without having to worry about the group it used being closed:
The RMP MUST automatically start a new group with same RM profile as the exhausted one, and transparently associate the group handle with the new group.
Jacques summarized the proposal above. All are basically minor changes. One aspect would impact the schema.
That is: Getting rid of status attribute, since it is only useful for end of sequence. Have an attribute to sequence number called last instead, with default False. This would allow the first message of the sequence to be the last.
Jacques stated they prefer the schema change.
No concerns about taking away start value.
Agreed to Turning it to Boolean with name Last, Nobody was opposed.
Action: Sunil and Jacques will propose the detailed changes required.
<![if !supportLists]>3.2 <![endif]>New proposal on Group Termination text
Jacques presented an introduction to his new proposal.
There is a change in terminology.
<![if !supportLists]>· <![endif]>A group is considered closed in the Sender RMP, when all its messages have been sent and the last sent message has an ending marker (SequenceNum/@last="true"). Note that closure occurs even if not all messages have been either acknowledged or faulted (in case GuaranteedDelivery is enabled.)
<![if !supportLists]>· <![endif]>A group is considered closed in the Receiver RMP, when a last message with an ending marker has been received, and all previous messages for this group have also been received, (no number missing in the sequence) although not necessarily delivered.
<![if !supportLists]>· <![endif]>When a group is disabled in the Sender RMP, no new message is expected to be sent by the RMP for this group. However, messages MAY still be resent in case GuaranteedDelivery is enabled. If a new message is submitted for a disabled group, the Sender RMP MUST notify the submitting application that the group is disabled and MUST NOT send the message.
<![if !supportLists]>· <![endif]>When a group is disabled in the receiver RMP, no new message is expected to be received for this group anymore. After a group is disabled, and before the group is "removed" (see definition), a Receiver RMP MUST NOT deliver messages received with this group ID, whether they are duplicates or not of previous messages, and regardless whether they result from a resending of previously failed messages initiated before closing on the Sender side (in case GuaranteedDelivery is enabled).
Note: A group may be disabled without being closed, due to timeout
Group removal occurs at the time the group is disabled, or after. Intuitively, a group is removed once all its messages have expired.
<![if !supportLists]>· <![endif]>When a group is removed in the Sender RMP, the RMP is not required to verify that future messages that are submitted are not associated with the removed group, and MAY treat these as belonging to a new group. However, in case the Sender RMP is in charge of generating group IDs, it MUST NOT reuse the group ID of a removed group, when initiating a new group.
<![if !supportLists]>· <![endif]>When a group is removed in the Receiver RMP, the RMP is no longer supposed to remember anything about this group. In particular, the group ID is discarded from the RMP state. When receiving a message with same group ID as a removed group, a Receiver RMP is not required to verify if this group ID value has already been used. Such a message MAY be treated as belonging to a new group.
For a disabled group the receiver must keep the group ID. This clarifies the previous text.
People should provide their comments on the details to the list.
<![if !supportLists]>3.3 <![endif]>Comments from Jun and its discussion thread
Re: [wsrm] Comments on CD 0.992
Jun Tatemura wrote:
> My question was how we can compose a Response element that include
> First, let me make sure the following understandings on sending
> InvalidPollRequest are correct:
> - InvalidPollRequest is included in Invalid Message Format fault set.
> - It is sent by the receiver RMP within the response header element.
> - In a Response element, fault code can appear only as attributes of
> a NonSequenceReply element or a (SequenceReplies/)ReplyRange element.
> Then, suppose, in Example 7 (PollRequest), the groupIds in
> RefToMessageIds elements are invalid. How can we compose a Response
> element with InvalidPollRequest fault included?
> The only way I can come up with is following structure (i.e., using
> inquired groupIds)
> since the PollRequest message itself has no messageId (as in Figure 6):
> <Response ...>
> <NonSequenceReply groupId="mid://firstname.lastname@example.org";
> fault="InvalidPollRequest" />
> <NonSequenceReply groupId="mid://email@example.com";
> fault="InvalidPollRequest" />
> <NonSequenceReply groupId="mid://firstname.lastname@example.org";
> fault="InvalidPollRequest" />
> Is this correct (even though the groupIds used are invalid)?
Correct in SequenceReplies/ReplyRange if the Poll request has a range.
> If the above Response element is correct, then I don't know how I can
> send a fault on the following PollRequest:
> <PollRequest ...>
> This is from examples in Table 16, i.e., "When the required RefToMessageId
> element is missing."
> Note that we don't have any groupId.
> How can we compose a Response element with fault?
Good observation, I think we need to remove that line. But again we have the same issue
for a regular RM request also. What if there is a Request with no MessageId element or
a MessageId element with no groupId attribute... same issue.
Jun: poll response refers to group id. What if there is no group ID.
Sunil: If the request header has no message id element, how do you send a fault if there is no group ID. Group ID is mandatory in the reply.
Tom: what about using GroupID value of “” in the fault case.
The may not be able to do anything in this case.
Sunil and Jun took action item to come up with detailed replacement text for this concern. They will describe the various edge cases.
· Re: [wsrm] Comments on CD 0.992
Jun Tatemura wrote:
> I have one clarification question and some editorial comments.
> Jun Tatemura
> NEC Laboratories
> A clarification question:
> How the receiver RMP can return InvalidPollRequest fault in a Response
> element whereas a PollRequest message does not have MessageId?
I'm not sure I understand your qn. clearly. Are you asking when do we send
InvalidPollRequest fault or are you asking why doesn't PollRequest contain
If it is the former, InvalidPollRequest fault is sent when the RefToMessageId
element is missing or doesn't contain soap:MustUnderstand attribute...
It doesn't contain MessageId because we are not doing RM features per say
on the Poll request itself. Most Poll requests will be sync. request-response
type and hence doesn't need any correlation mechanism and even it is an
async request, we are treating it as a 'stateless' call.
Let me know if I haven't clarified your question or if your concern is altogether
· Re: [wsrm] Comments on CD 0.992
My responses on your <JD> are inline:
Jacques Durand wrote:
> The receiver can forget previous group IDs after group state removal
> but the sender MUST NOT reuse group IDs. The spec shuold explicitly note
> about the sender side here. One engineer thought the sender could
> re-open a group.
> <JD> Section 2.1, as well as 4.2.1, clearly state that the GroupID is
> unique, and two groups must use two distinct GUIDs.
> Now we could stress the consequence of this, which is that a Sender
> must never reuse
> previous groupIDs.
Yes, I am aware of that. That's why I think the logic is complete. It is
clear to me, but
maybe because I am an insider of spec discussion. The user feedback
implies we should
stress this point in the Group Closing explanation (ll.1100-1102) for
> It should be explicitly noted that receiving "status=end" does not mean
> "Group Closing." In (t3)(t4), the spec uses another terminology
> "complete," which also confuses readers.
> <JD> Line 1118-1119 (section 5.1.1) defines "complete". Now we could
> add that more explicitly to the group terminology definitions in
> 5.1.1. Will propose rewording.
> For the receiver side group closing, we can define two categories:
> (a) group completion: the receiver RMP received all messages from start
> to end.
> (b) group timeout: (b1) the receiver RMP observes that groupExpiryTime
> specified is over
> or (b2) the receiver RMP observes that groupMaxDuration specified is
> Once we define these at the first time, termination rules would be
> much simpler and easier to understand.
> <JD> Fair enough. I will propose some edits for this section with your
> intro summary.
> One engineer was worried about the fact that the sender's
> groupExpiryTime and
> the receiver's groupExpiryTime are not in sync. It is in fact okay
> that the
> sender does not know the current groupExpiryTime in the receiver side.
> It is better to clearly state this.
> <JD> I thought Lines 1086 to 1090 in 5.1.1 stated that clearly enough.
> If you have a more explicit wording to propose, let me or Iwasa know.
Again, I think the logic is complete.
But the fact that group termination is asynchronous does not
necessarily mean that group termination parameters are also
asynchronous. At this point of reading, the reader can expect
the spec were somehow trying to synchronize the group termination
parameters based on some asynchronous protocol. (Actually, the term
"RM Agreement items" in 5.1.2 implies they are synchronized) A careful
reader can realize that this expectation was wrong after reading termination
My proposal of wording is replacing ll.1140-1143 with:
c) The sender MAY modify the value by sending a subsequent message
with a new value.
The sender MUST use the value from the message with the highest sequence
sent for the group. The receiver MUST use the value from the message
with the highest sequence
number received for the group.
d) A new value for groupMaxIdleDuration can either be increased ....
> It is not clear that when the spec states "groupExpryTime is over" in
> the sender
> side, which groupExpiryTime is observed by the sender. Is it based on
> the last message the sender sent? Or the last message for which the
> received ack? In fact, either cases are okay for reliable messaging. But
> this ambiguity confuses readers.
> <JD> You mean groupMaxIdleDuration? on sender side, it should be
> counted from
> the last sending (see Termination T2). We don't always assume Acks.
> Now, groupExpiryTime is a date, so no dependency on previous events...
The point was about semantics of groupExpiryTime for the sender
when the sender wants to modify the value of groupExpiryTime.
If the spec says GroupExpiryTime is one of Agreement items,
the reader may think the sender should use the value on which
the receiver has agreed. Since the only agreement the sender can
observe here is ack messages from the receiver, the reader may
think the sender should use groupExpiryTime for which the sender
received an ack from the receiver.
This point is actually included in the previous point , and the wording
proposed has resolved this.
· RE: [wsrm] Comments on CD 0.992
· Comments on CD 0.992
I have one clarification question and some editorial comments.
A clarification question:
How the receiver RMP can return InvalidPollRequest fault in a Response
element whereas a PollRequest message does not have MessageId?
(Maybe I missed some discussion done)
Sunil took action item to resolve this. Giving example will be include.
Overall editorial comments:
This comment does not affect the nature of the specification
but points out readability issues.
I have some feedback from engineers inside NEC, who were confused
in interpreting the spec, especially on the group termination (5.1).
The group termination rules are introduced in order to minimize
the receiver RMP implementation's cost on data persistence.
I think the logic is correct and complete but the writing is
not user friendly. Readers are required to read the spec very
much carefully to avoid misinterpretation.
Here are some implications from the feedback
The receiver can forget previous group IDs after group state removal
but the sender MUST NOT reuse group IDs. The spec shuold explicitly note
about the sender side here. One engineer thought the sender could
re-open a group.
Addressed by Jacques propoposal
It should be explicitly noted that receiving "status=end" does not mean
"Group Closing." In (t3)(t4), the spec uses another terminology
"complete," which also confuses readers.
For the receiver side group closing, we can define two categories:
(a) group completion: the receiver RMP received all messages from start
(b) group timeout: (b1) the receiver RMP observes that groupExpiryTime
specified is over
or (b2) the receiver RMP observes that groupMaxDuration specified is over.
Once we define these at the first time, termination rules would be
much simpler and easier to understand.
This is addressed by Jacques proposal
One engineer was worried about the fact that the sender's
the receiver's groupExpiryTime are not in sync. It is in fact okay that the
sender does not know the current groupExpiryTime in the receiver side.
It is better to clearly state this.
Addressed by Jacques proposal.
It is not clear that when the spec states "groupExpryTime is over" in
the sender side, which groupExpiryTime is observed by the sender. Is it based on
the last message the sender sent? Or the last message for which the sender
received ack? In fact, either cases are okay for reliable messaging. But
this ambiguity confuses readers.
Addressed by Jacques proposal
> the receiver's RMP
> the receiver RMP
> the receiver of the message MUST make messages available to the
> only after all messages with the same groupId value and a lower
number value have
> been made available to the application.
> the receiver RMP MUST NOT deliver the message until all messages with
> same groupId value and a lower number value have been delivered.
22.214.171.124 Table 3
> See 3.1.2 for details
There is no section such as 3.1.2
> When an application is ....
This discussion should not be done in 126.96.36.199(4). This part should be
moved to somewhere in 3.3 or totally removed.
Jacques has proposed to remove.
Agreed to remove
> notSupportedFeaturemust be
4.5.2 (l.1052 and Table 17)
Faults are somtimes "thrown" and sometimes "sent."
For consistent use of terminology, a fault should be "sent."
Agreed to use sent throughout.
> termination rules t1, t2 or t3 described below should be
> termination rules t1, t2, t3, or t5 described below
since t5 is applied even when a group persistence parameter is present.
5.1.3 (3) (ll.1021-1202)
Even in case of subcase 3.2, the state can become subcase 3.1 by receiving missing message before reaching states t1 or t2. The sentence could be something like
"Then the Receiver RMP MUST apply termination rules of (t1) or (t2)
or apply termination rule of (t3.1) after all message have been delivered"
reflected by Jacques new proposal.
<![if !supportLists]>3.4 <![endif]>Comments from Alan
· Re: [wsrm] Comments on CD 0.992
Sorry these are late, but there were a few internal issues that needed to be settled before I could send them out.
The comments below are my own, and have not been reviewed yet. Hopefully, we can address them on tomorrow's telecon
1. Section 1.4 Relation to Other Specs
In my opinion, we should create a TC document on this topic. The competition calls it "composability" and insists that there WSRM spec is NOT finished until all aspects of composability have been considered.
On line 144 it says that WS Reliability can be used with WS Security-WSS (which I think has now been completed in OASIS and a BSP working draft is available from WS-I). How? What reply patterns, configuration parameters, protocol capabilities are needed for each WSS message type? I think this is one of the most important applications of WS Reliability, but no one is looking at it (vs competition looking at composing WSS with WSRM)
WS-Security is now an OASIS approved standard.
Take out reference to security since it does not explicitly state how to do it.
Jacques text could go In a companion architecture type document.
Alan stated we should not hold up the spec for this document.
Defer resolution until after faq discussions
2. Section 1.7.2 RM Agreement Items: Setting, conveying, or changing the Agreement items listed here, is beyond the scope of this specification.
Line 408-406: If a reply pattern is sent that had not been previously agreed upon, it will be rejected, with a Fault message: Non Supported Feature returned to the sender
Alan suggested: MUST BE
Doug B: we tend to not use word reject, for this is to the sender end. This needs to use the deliver operation terminlogy.
Agreed in principle. Leave wordsmithing for later.
3. Section 1.7.3 Messaging Scope of Agreement items: For all scopes: Setting, conveying, or changing the Agreement items listed here, is beyond the scope of this specification.
Need clarification: Are the values for parameters in message scope (s3) and/or Group scope (s2) related to a particular Reply pattern or are the values the same for ALL Reply patterns over the same binding/ transport connection between sender and receiver????????
Does sender maintain parameters separately for each reply pattern.
Jacques: This work is still in progress on the retry interval relaxation interpretation. This parameter is a seed value. The Max retries are not necessary with expiry time.
It was a possibility to get rid of these two parameters. We were leaning to relaxing the interpretation.
Jacques; What is scope of these parameters. This section was reflecting what is in the spec. We may decide that these timing parameters should remain the same in the same group.
Tom: the receiver does not need to know these agreement items to work.
Jacques: these parameters are only used by the sending rmp side. The receiver does whatever is required by the parameters in the messages.
Alan: this is moving away from my specific issue here, on the scope of the parameters with reply patterns.
Tom: This is part of a more general discussion.
Jacques: the receiver does not need to be given these agreement items, other than what is communicated thru the message itself. The retry interval, and max no of retries are of issue here. What is the meaning of this for polling.
Keep discussing this open issue.
Tom: Take this to the list.
Take to Email discussion
4. Section 3.3. Guaranteed Message Ordering Failure Case
Line 563-565: Is the decision to abort ordered delivery totally implementation dependent? Can we specify a Maximum Persistance time parameter for a received out of order message, so that after that time receiver aborts ordered delivery. Otherwise, a skimpy implementation could give up almost immediately vs a robust implementation trying to recover for a much longer time after receiving multiple out of order messages without receiving any retransmitted sequential messages
Jacques: we remained away from these type of configuration parameters on the receiver side.
Alan: I am concerned about a skimpy implementation.
Need to quantify the meaning of “too much effort” and also if you do give up what fault code do you send back after aborting ordered delivery.
What Fault code is sent back to sender after aborting ordered delivery? Is it Permanent Processing Failure?
Doug: a receiving rmp can drop an out of order message on the floor, waiting for it to be retried in order. You can drop them whenever you want.
Alan: regarding Decision to abort ordered delivery. How does the sender know. Must a fault be returned.
Tom: Needs to be clarified that abort ordered delivery does not give any response.
Alan: Could add some clarification here that the decision to abort ordered delivery is implementation dependent.
Doug: we have another issue, in that we have no definition of abort ordered delivery.
Check if this is made explicit in the new text from Jacques.
The way this is defined no message is delivered for this group anymore.
Take this to the list to come up with appropriate text.
THIS BRINGS UP ANOTHER HUGE PROBLEM WITH THIS SPEC: THERE IS LITTLE OR NO MENTION IN THE TEXT OF WHICH FAULT CODES TO SEND FOR A GIVEN PROBLEM. ALSO, IT WOULD BE NICE TO HAVE A CAUSE CODE/ FIELD TO PROVIDE FURTHER GRANULARITY AS TO THE PRECISE CAUSE OF THE FAULT.
5. Line 726: groupExpiry Time attribute:
Clarification: No mention whether this parameter can be changed. Suggest forward reference to line 1148- 1149. 6. Line 1148- 1149
Suggest reference to appropriate section.
6. Line 1148- 1149 d) changing Group Expiry time
It would be most helpful to provide 2 examples illustrating the change of Group Expiry time when sending sequential messages:
-one correct/ permitted change; the other incorrect (decremented below Max Value of Expiry time)
Clarification: What is the relationship between Expity time (section 4.2.2) and Group Expiry time (line 726), i.e. why are they dependent here? While Group Expiry time can be modified, Expiry time (only sent in Request messages) can not be modified. I always thought that Expiry time was sent in a single Request message while Group Expiry time was sent in each sequential Reply message of a Group. In other words, they would never be sent in same direction
Check Accommodated by Jacques new text.
7. Suggestion: WSRM TC should consider producing a new document: An Implementors/ Users Guide to WS Reliability.
This would better explain how to use the protocol features, tips on setting and conveying configuration parameters, and how WS Reliability would communicate with WS Applications via platform neutral APIs (primitives and parameters in OSI sense). This document could also be referenced by the proposed Relation of WS Reliability to other WS Specifications (e.g. Security, Distributed Management, etc)- see 1. above
Alan: Two documents:
Second document is relationship of ws-reliability to other ws standards.
Suggest we work on this while maintaing the ws-reliabilty spec.
Jacques: Not clear to me that we need these to be two separate specs.
Tom: we can defer discussion of this until after we have resolved the FAQ question /answer about relationships with other ws standards.
<![if !supportLists]>4 <![endif]>Frequently Asked Questions:
Action Items From Last Week’s Minutes: In Italics to differentiate from today’s entries.
list of WSRM FAQs
What are the reliability features supported by the WS-Reliability specification?
A] Guaranteed delivery to the user or Application entity (the message MUST be persisted (i.e. stored in non volatile memory) in the sender Reliable Messaging Processor (RMP), until delivery to the ultimate receiver has been acknowledged.
B] Duplicate elimination - Delivery at most once -with duplicates detected and eliminated by the RMP receiver,
C] Guaranteed message ordering - when delivered by the RMP receiver to the user, the messages are properly sequenced. The problem arises when messages are received out of sequence or acknowledgements are lost. The solution is for the RMP transmitter to retransmit unacknowledged messages (after a time-out), and for the RMP receiver to re-order received out of sequence messages so that they are properly delivered to the user (e.g. Application entity)
Jacques took action item to propose new text for this question above..
Action item progress: pending
What is the difference between the WSRM TC’s WS-Reliability specification and the ws-reliable Messaging specification.
WS-Reliability is being developed within the OASIS open process, and our working draft, related documents and TC archives are all accessible to the public. We invite public review and comment on this work.
WS-Reliable Messaging is a proprietary specification being developed privately at this time by a group of vendors. As the status of the current version of WS-Reliable Messaging is not publicly known, we advise those with specific questions on WS-Reliable Messaging to contact its developers.
Jacques stated the word “difference” is too vague.
Tom: it is unclear why the name of the TC and the spec are different.
Jacques: WS- reliability seems to suggest we go beyond the messaging part.
Bob: I recommend we be silent about the other spec.
Change question to why does the spec have a different name than the TC.
Marc G agreed to propose a new question with new answer to clarify the matter.
Action item progress: pending
1. We did get a question at the Dec 03 XML COnference on relationship of WS Reliability to ebXML. I do not think they are related or that our spec will work in an ebXML environment.
2. I am not familiar with ebMS 2.0 and have never heard anyone ask about it
3. It would be a very bad idea to include a comparison of our spec to WSRM spec. That would open a can of worms and a lot of rock throwing. This is something that the industry/ market will have to decide on its own. Obviously all the vendors in a given camp will be biased in favor of their spec.
Jacques: The answer to this question could be formulated in a proper way. It is a legitimate question to ask and we should have an answer to it.
Jacques took action to clearly state what the case is. He agreed to draft a question with an answer.
Action item Progress: pending
Tom: Need a general question on how can ws reliability be used with other ws reliability protocols. Answer : we design it as orthogonal, to work with any other ws- reliability protocol. An example on why we have a reply to element of our own would help.
Tom Rutt agreed to send a suggested question and proposal out.
Action Progress: Pending. Following email discussons have occurred (no time at meeting to discuss)
Tom: take this discussion to the list.
A way to approach the composability with other WS-* specs is that they
are likely to fall under these (fuzzy) categories :
(a)- "Under WS-R": Add-ons to SOAP transport like routing, addressing,
that WS-R may need to accommodate or profile.
Status: nothing in the open space yet...
(b)- "Supporting WS-R" specifications (policies, WSDL annotation), that support some function
assumed by WS-R but not central to its deployment:
Status: not finalized or not open.
(c)- "Complementary to WS-R" specifications (Security, transactions, Context...)
that support other business requirements requirements likely to be used in conjunction with reliability, and share message footprint.
Soap headers composability and processing model make this possible. Apparent redundancy (message ID, reply address..) should not be an issue.
Appropriate profiling and guidelines may apply.
(d)- "Over WS-R", Higher level specifications (BPEL, Choreography, CAF, ASAP...)
would use/profile reliability, not the reverse.
That may help a bit I hope. Our focus would be on (c) this time.
From: Tom Rutt [mailto:email@example.com]
To: Tom Rutt
Subject: Re: [wsrm] Input for FAQ question
Tom Rutt wrote:
> How can ws reliability be used with other ws reliability protocols.
This is a mistake it should read "How can ws-reliability be used with
other web service protocols.? "
> Answer :
> An important consideration in design of the WS-Reliability protocol
> was to have it be orthogonal to any other web services protocols which
> define the use of soap header elements.
> WS-Reliability defines elements to be sent in Soap headers . Our
> header elements only contain parameters essential for the operation
> of the WS-reliability protocol. For example, WS-reliability defines
> a reply to element for the sending Reliable Message Processor to
> convey a call back address for the Reliable messaging reply. This
> address is independent of any other reply mechanisms used for other
> protocols (e.g., WSDL response is not influenced by the WS-Reliability
> reply To parameter).
Alan moved Jishnu seconded to adjourn at .
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]