[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: more on payload(s) inclusion and MEPs than our Request-Response MEPdiscussion covers
All, (Sorry again to be a squeaky wheel and the length of this email.) In thinking more about the various reply patterns, all could have a generic "getting any payload back" issue, specific "responding to duplicate messages" issue or both. I will be sending a separate email about the "responding to duplicate messages" problem. Here, I concentrate on the implications of implementing Jacques' suggestions for the rest of the document. Unfortunately, I have lifted a rock and do not like what I see beneath it. Section 4.2.3.1 completely contradicts table 26 in section 5.2, even with the recent updates to the table. The restrictions described in 4.2.3.1 are somewhat implied (reasoning by example, not a great idea) in the HTTP binding descriptions (near the top of sections 6.2 and 6.3) of fault situations. The problem we have here with the Callback and Poll RM-Reply patterns is a lack of clarity about the underlying protocol response to the original message, an outgoing callback or a Poll request. While fault situations are somewhat described, normal processing is not (except, occasionally, by example). We are also left with little or no description about a receiving RMP "bundling" payload(s) with the outgoing Callback request or Poll publication (underlying protocol response or request for the sync and async cases). Note that, while it would be a useful addition to our specification, I am not clamouring for text on the details of payload bundling. More, just when are payload(s) delivered for those reply patterns? Assuming relatively complete knowledge of the sections mentioned in the previous paragraphs (sorry), alternatives here include: A. Completely and consistently resolve the contradiction, likely in favour of section 4.2.3.1's restrictions. This basically means applying the same rules to all wire level exchanges as to the producer / consumer interaction (application level WSDL, whatever that means). The synchronous Poll case is probably an exception we would have to underscore because it requires a wire-level request-response exchange. The new Respond operation would be allowed only when the Response RM-Reply pattern is used. Section 5.2 would change substantially in this case and might become redundant. B. Clarify section 4.2.3.1 to link the existing "pattern is not applicable" sentences only to the initial sending RMP / receiving RMP wire-level interaction (the delivery of the reliable message). That is, the original message is sent using an RMP-to-RMP (remember this is not about the consumer's description of the service they provide, that comes in section 5.2 under this alternative) one-way operation unless the Response RM-Reply pattern is in use and a request-response operation for that pattern. The new Respond operation would provide consumer payload(s) to be carried with the RMP publication. How the published (receiving RMP provided) information must be delivered to the original sending RMP should probably be described in this section as well. The callback "request" is sent using a one-way operation and the Poll and Response "response" is returned using either a one-way operation (async poll case) or underlying protocol response (sync poll and Response pattern cases). For the asynchronous Poll reply pattern, the wire protocol requirements actually involve two one way operations. Again, all of these WSDL operation types and related MEPs[2] are separate from the application WSDL or "application level MEP" and are not written down anywhere as WSDL but are made explicit in this section. Section 5.2 would cover the overall producer / consumer interaction (again, sometimes called the "application level WSDL" in our specification) and what information a consumer may add to the Response pattern response, Callback request or Poll publication. Effectively, section 5.2 describes bundling payload(s) together with the RMP publication. The details of such bundling would not necessarily be explicitly described in our document but would be allowed. C. Clarify section 4.2.3.1 to link the "pattern is not applicable" text to the inclusion of consumer information with the published data. That is, these restrictions cover the addition of payload(s) to the underlying protocol response in the Response RM-Reply pattern and later publication in a Callback request or Poll response. Patterns other than the Response RM-Reply pattern would disallow any consumer information carried together with the RMP publication. Section 5.2 should be clarified to apply to the original message as well as the overall producer / consumer interaction, allowing payload(s) to be returned "immediately" though (in cases other than the Response RM-Reply pattern) the RMP information will travel separately and such payload(s) are not necessarily correlated with the original message(s) (and are certainly not sent reliably). The use cases for this option seem a bit far fetched since the RMP information would be expected to be available faster than any consumer Respond invocation; we would expect the RMP to be able to respond faster than the consuming system / user / application / ... The new Respond operation would provide consumer payload(s) returned as part of the initial message exchange. The return of published information must be described (using identical terminology to that recommended for section 4.2.3.1 in alternative B) in this section. This alternative is somewhat the opposite of B though the overall producer / consumer interactions are identical. In the B case, payloads are optionally carried along with the RMP publication. For C, payloads are optionally returned immediately as part of an initial request-response (wire level) MEP. Yes, B and C result in identical handling for the Response RM-Reply pattern. ---- I lean somewhat toward B since that would not require extensive changes to the HTTP binding and seems somewhat more useful. However, any of these alternatives would somewhat change the proposed definition of the Respond operation. If we choose A, the Respond operation has strict restrictions on when it may be invoked. In the B case, invoking this operation results in magic occurring for the Callback and Poll RM-Reply patterns but may be used for every pattern. If we chose C, the magic occurs in the initial underlying protocol response. Going a bit further down the rabbit hole, we also need to think more about the "spontaneous" use of the Poll request message when the original message was sent using the Response RM-Reply pattern (if we choose A above) and, generally, when the consumer provides payload(s) associated with an incoming message. The problem here arises primarily when the Poll request mentions (asks for information about) multiple earlier messages. The Response provides no mechanism to correlate individual payload(s) with individual NonSequenceReply or single messages within the SequenceReplies/ReplyRange. Alternatives here include: I. Additional words stating that any consumer-provided information (the results of an earlier Respond operation) are quietly lost in this situation. That is, the response to a Poll request never includes any payload(s) -- no matter what RM-Reply pattern was used originally. This would contradict the text in section 5.2 according to alternative B above. II. Add a new warning in the Message Processing Fault set named PayloadAvailable. This would inform the sending RMP of lost payload(s) associated with messages within the referenced range. III. Possibly along with (II), describe a special case in which the response to a Poll request asks for information about a single earlier message. Syntactically, such a Poll request would contain a single RefToMessageIds element. In turn, that RefToMessageIds element must contain 0 or 1 SequenceNumRange and, when SequenceNumRange is included, the @from and @to values must match. For this very special case, any information included in the SOAP Body would be automatically correlated with the earlier message. Information provided in a Respond operation would be published along with the acknowledgement indication in support of this case. Please note that saved information useful in responding to a Poll request would also support "caching" Response RM-Reply pattern responses in case a duplicate message comes later. IV. Ensure the existing text does not disallow option III as an implementation choice but otherwise remain silent on payload(s) included in the response to a Poll request. I suspect (but am not sure) we have nothing normative that would prevent use of III. However, the non-normative text (a new note in section 5.2 for example) should at least describe the correlation issue. ---- What do others prefer? thanx, doug [1] Specifically, the negative (why negative?) links between RM-Reply patterns and WSDL MEPs. The bullets in this section can be paraphrased as stating the Response RM-Reply pattern may only be associated with request-response MEPs and other RM-Reply patterns (Callback and Poll) may only be associated with one-way MEPs (and WSDL operations of those types). [2] Note that I am not particularly picky on terminology here and go back and forth between WSDL operation types and MEPs. I am not making a distinction. I also use the word "operation" to describe the abstract interface between consumer or producer and associated RMP, mostly with regard to the Respond operation.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]