Of course you object.
We already decided not to set syncReply based upon message size -- so why
bring it up. My point is there is never a reason to set syncReply to
*false* for synchronous transports so why have a flag /element at all.
Consider the options:
If SyncReplyMode equals:
1) responseOnly -- then syncReply MUST be set to *true* and the MSH
must wait for the business reply.
2) signalsOnly -- then syncReply MUST be set to *true* and the MSH
must wait for the business signals.
3) signalsAndResponse -- then syncReply MUST be set to *true* and
the MSH must wait for both the signals and response (presumably they would be
packaged together by the application).
4) none -- then syncReply MAY be either *true* or
*false*
4a) syncReply is *true* -- MSH
signals would be sent with the HTTP 200 OK.
4b) syncReply is *false* -- MSH
signals would be sent separately with a different
connection.
ONLY in the case of 4b would syncReply be *false* (1 case of 5, so why
isn't the default *true* as in 4 out of 5 cases?). IMO, there is
really no need for the 4b case since MSH signals SHOULD always be sent with the
200 OK (why would you ever NOT send them -- why wait?). The only case I
can think of where 4b is usable is for large files where signature validation
might take some time but we have decided NOT to consider this
case.
Doug, so far you have only expressed your opinion about what syncReply
should be but you haven't really given any reason why syncReply should
ever be *false*. I suspect your reason is because syncReply is default
*false* for RNet. That's not a reason.
Regards,
David Fischer Drummond Group.
David,
I object to being misread in this fashion. I said
nothing leading to any requirements for per-message SyncReply choices.
Nor do I agree this parameter should be true for all HTTP connections. I
suggested I'd turn on SyncReply if and only if I were behind a firewall and
unable to receive incoming messages (one-time configuration of the MSH) or
knew my trading partner could evaluate all MSH error cases within the
HTTP timeout (per-relationship). Message size may not be the primary
driver for slow processing at a recipient. (Besides, how would the
sender know what processing time the receiver will need for a particular
message size, payload split and overall complexity?) My default
suggestion would be to leave SyncReply false.
thanx,
doug
----- Original Message -----
Sent: Monday, 26 November 2001 08:04
Subject: RE: [ebxml-msg] Re: SyncReply Module
<<comments in-line>>
I am waiting on a ruling from the Chair about my objection, but I will
make a couple of comments anyway.
Regards,
David Fischer Drummond Group
David,
This has gone on too long. I'll bite one last time
but what exactly are we debating now the issue has been resolved?
<<Resolved? Not
really>>
The use case described has been in the document for quite
some time. I refer, for example, to lines 728-730 in section
2.2.10 of the 1.09 draft which explicitly describes the "next MSH"
actor as allowing SOAP extensions to skip intermediate SOAP processors
without full MSH capabilities. Otherwise, "next" would be
sufficient. Though it isn't as explicit, the same could be said for
the "To Party MSH" actor because it allows the default SOAP actor to be
placed before or after the To Party actor on a multi-hop route.
<<Doug, you make a good point. There
were so many changes in v1.05 that I just did whatever Chris said
and didn't think about it too much -- to get the restructured
document out the door. You are correct that this is a new requirement
and probably should not have been included. You are also right that
"next" and the default are probably sufficient for our current
needs.>>
I'd turn off sync reply whenever I know the receiving end
can't or won't reply synchronously. For example, signature validation
and other security checks may be time-consuming. I'd rather wait for a
single asynchronous reply (allow push) than retry (poll) for the transport
confirmations. It becomes much more efficient to operate in this way
once the chance of failure reaches measurable levels -- especially if the
recipient does security checks prior to duplicate detection. This is
exactly how the RosettaNet Integration Framework works today. In fact,
I might turn on sync reply if and only if I were behind a firewall and
unable to receive incoming messages. (We're only covering part of the
requirements for such a configuration because we don't cover polling for
business responses but it's a start.)
<<Thank you, Thank you, Thank you! Final someone agrees
with me. This is the Use Case I have been using all summer to justify
per-message syncReply (Large Messages). Dale had me convinced to drop
this use case since it is so rare it is not worth supporting!
In the case where I am behind a firewall and unable to receive
incoming, doesn't that mean that I MUST have syncReply set to "true"?
It seems like we are agreeing? I am suggesting that syncReply will
never be "false" for synchronous transports
(HTTP).>>
thanx,
doug
----- Original Message -----
Sent: Tuesday, 20 November 2001 10:48
Subject: RE: [ebxml-msg] Re: SyncReply Module
It appears that the answer to my first question is, this is a new use
case/new feature for a previously unmentioned/ unsupported set of
functionality.
OK, now my second question, why would syncReply ever be *false* for a
synchronous transport (for all scenarios pertinent to v1.0). For all
asynchronous transports, syncReply is ignored, so its value is irrelevant
(see section 7.4.7).
- David.
OK Chris, since you are just talking and not
answering the questions, I will KIS and ask one at a
time.
How can there be SOAP nodes in our path which do not
understand MessageHeader? How would it
route/forward?
- David.
BTW, I like the HTML ;-)
David,
Some comments
below.
Cheers,
Chris
David Fischer wrote:
NFBBIIHJNFIEBFENACIJKEFMCDAA.david@drummondgroup.com
type="cite">First, I agree there are still some difficulties with multihop and syncReply. This new element does not do anything to solve those difficulties. The only answer I can see is to do as Dale suggested and use a cascading Ack -- but that has difficulties too. This
doesn't address the problem, the issue isn't acknowledgments, it is all
about message exchange patterns.
NFBBIIHJNFIEBFENACIJKEFMCDAA.david@drummondgroup.com
type="cite">
Second, I still think there cannot be IM SOAP only nodes. This makes no sense at all since any SOAP IM MUST understand MessageHeader in order to route. This is the Store-and-Forward only IMs we have been discussing -- doesn't need to touch the Manifest. If it can look in MessageHeader to get the To then it can also look in MessageHeader/QualityOfServiceInfo to get syncReply. So I must ask again, why are we adding a new element.
There
is nothing, nor should there be nothing to preclude OTHER SOAP headers,
not just ebXML MessageHeader in a SOAP message that just happens to
also contain ebXML defined extensions. There is no need for a
non-ebXML MSH SOAP node to understand anything in the MessageHeader
as long as it understands whatever headers are targetted to it by
virtue of the actor of "next" or anything else for that matter. ebXML is
not, nor should it be, a closed protocol, especially given that it is
layered on top of SOAP.
NFBBIIHJNFIEBFENACIJKEFMCDAA.david@drummondgroup.com
type="cite">
Third, when I made the assertion that syncReply is for MSHsignals, I did not mean to imply that it did not match SyncReplyMode -- it does follow. If SyncReplyMode is not *none* then syncReply MUST be *true*. This does not imply that syncReply cannot still be *true* even if SyncReplyMode is *none* -- this would mean MSHsignals only.
However, when would the MSH syncReply ever be *false*?
I must reiterate, we don't need syncReply at all.
I
don't buy this unless we are going to completely abandon multi-hop and
intermediaries for v1.1. There needs to be some way of communicating
to a node whether the connection over which a message was received is
expecting a response so that it can be held open (as long as feasible
and practical). Whether the node is a MSH or a plain old SOAP node
serving some other purpose for which ebXML does not define itself is
irrelevant. The reason that the actor of "next" is used is just to
provide for the possibility, regardless of how remote that the node
at which a message is received can be asked, in a manner that
REQUIRES it to understand (mustUnderstand=1) at least the part about
the fact that the connection over which the message was received will
need to be kept open for a subsequent response.
We agreed to this
in the F2F by vote. I see no reason why it needs to be
continuously debated.
NFBBIIHJNFIEBFENACIJKEFMCDAA.david@drummondgroup.com
type="cite">
Doug, Chris?
Regards,
David Fischer Drummond Group.
-----Original Message----- From: Arvola Chan [mailto:arvola@tibco.com] Sent: Monday, November 19, 2001 1:16 AM To: David Fischer; ebxml-msg@lists.oasis-open.org Subject: Re: [ebxml-msg] Re: SyncReply Module
David:
Chris and Doug are the SOAP experts who have recommended the use of the SyncReply element. I would defer to them for an explanation on the necessity of this elemen (possibly for inclusion in the spec).
Doug stated in his last message:
http://lists.oasis-open.org/archives/ebxml-msg/200111/msg00223.html
"The previous synchronous mode would have sup
ported MSH -> HTTP proxy -> MSH because HTTP proxies operate in a synchronous mode by default. The new flag allows MSH -> SOAP -> MSH in spite of the asynchronous mode the SOAP node might prefer."
I suspect that is the main reason for the SyncReply element.
I don't quite agree with your statement "SyncReply in the MSH concerns sending back MSHsignals." Depending on the sync reply mode set in the CPA, SyncReply can mean returning the MSH signal synchronously, or returning the MSH signal along with business level message (signal and/or response) synchronously.
It also occurs to me that SyncReply may be incompatible with an AckRequested element that is only targeted to the nextMSH. If the nextMSH returns the intermediate Ack synchronously, how can it possibly return the application level response also synchronously? If this observation is correct, perhaps the incompatibility should be identified in appropriate pl
aces within the spec.
Regards, -Arvola
----- Original Message ----- From: "David Fischer" <david@drummondgroup.com> To: "Arvola Chan" <arvola@tibco.com>; <ebxml-msg@lists.oasis-open.org> Sent: Sunday, November 18, 2001 3:04 PM Subject: RE: [ebxml-msg] Re: SyncReply Module
If SyncReply is always included, then why is it needed in the CPA? If it
always
goes all the way through, why is there Actor=Next? What is the advantage
to
having this as a top level element instead of in QualityOfServiceInfo?
We are adding a new top-level element and gaining nothing. This is
definitely
not backward compatible, not a fix and not a clarification. If all we are
doing
is renaming Via, then we should leave Via alone since that would be
backward
compatible and this change gains nothing. If this is always present then
it
should be combined with MessageHeader since it adds no functionality to
have it
separate and adds 100+ characters to every single message.
As we discussed, the simple solution is ALWAYS assume syncReply=true for
HTTP
then we don't need this at all. Why would we ever need syncReply=false?
I can
only think of one use case (very large files), which we have decided to
ignore.
In the case where there is an async hop/IM in the middle, the
response/signals
will be sent back async anyway so the IM can just close the connection --
the IM
already knows what to do.
If you are concerned with the BPSS requirements, then you are talking
about
another layer (layering violation). SyncReply in the MSH concerns sending
back
MSHsignals. If BPSS needs for the MSH to wait and send back a combo
message,
then only the end/ToParty needs that info, not the IMs. IMs can ALWAYS
assume
syncReply=true (there is no syncReply flag for SMTP and if it appears it
is
ignored -- no error).
This is a bad/unnecessary idea that needs to go away.
Regards,
David.
-----Original Message----- From: Arvola Chan [mailto:arvola@tibco.com] Sent: Friday, November 16, 2001 8:35 PM To: David Fischer; Doug Bunting; ebxml-msg@lists.oasis-open.org Subject: Re: [ebxml-msg] Re: SyncReply Module
David:
We used to have a syncReply attribute under both QualityOfServiceInfo and Via. We determined that the one under QualityOfServiceInfo is not needed because it should be obtained from the CPA.
The Via element is essentially renamed as SyncReply because once we
removed
the TraceHeaderList, syncReply is the only attribute that is left in Via.
Because the sender may not be aware of the presence of SOAP or MSH intermediaries, it should always include a syncReply element in the
message
header if the CPA specifies any syncReplyMode other than 'none'.
Regards, -Arvola
-----Original Message----- From: David Fischer <david@drummondgroup.com> To: Arvola Chan <arvola@tibco.com>; Doug Bunting <dougb62@yahoo.com>; ebxml-msg@lists.oasis-open.org <ebxml-msg@lists.oasis-open.org> Date: Friday, November 16, 2001 6:18 PM Subject: RE: [ebxml-msg] Re: SyncReply Module
No, SyncReply is NOT perMessage. I added a paragraph in 6.1 to cover
this
issue.
My problem is that you never know if there is an intermediary so should
you
always include SyncReply if SyncReplyMode not equal *none*? If SyncReply
is
included, it will make it all the way to the end (one hop at a time),
isn't
there always a potential for mismatch? If it is always going to be pass
all the
way through, why put actor=next? If it is always included, then why
bother
with
it in the CPA?
What was the value of taking this out of QualityOfServiceInfo and making
it
an
element? IMO, we just added 100+ bytes for nothing.
Regards,
David.
-----Original Message----- From: Arvola Chan [mailto:arvola@tibco.com] Sent: Friday, November 16, 2001 7:37 PM To: Doug Bunting; ebxml-msg@lists.oasis-open.org Subject: Re: [ebxml-msg] Re: SyncReply Module
Doug:
Thanks for the clarification why SyncReply belongs in 'Core
Functionality'
rather than in 'Additional Features'.
I have two related questions:
1. Is syncReply assumed one of those parameters that are perMessage? I
don't
think that the CPP/A team is aware of such an assumption.
2. If not, is the element mandatory when it is already specified in the
CPA?
When no intermediaries are involved, I would have expected that a
syncReply
specification in the CPA would imply that sync reply is to be used regardless of the presence or absence of a SyncReply element in the
message
header. What triggers the sender to include a SyncReply element in the
first
place?
Thanks, -Arvola
-----Original Message----- From: Doug Bunting <dougb62@yahoo.com> To: ebxml-msg@lists.oasis-open.org <ebxml-msg@lists.oasis-open.org> Date: Friday, November 16, 2001 5:15 PM Subject: Re: [ebxml-msg] Re: SyncReply Module
Arvola,
My, you're a quick reader...
You're understanding covers the flag's semantics as it appeared in the
1.08
document. Maintaining the existing "keep channel open 'til a response is ready" semantics, we slightly expanded the feature to include making sure
an
intermediate SOAP processor doesn't close the connection. In essence, we recognised the possibility of "regular" SOAP nodes linking full-blown MSH nodes.
The previous synchronous mode would have supported MSH -> HTTP proxy ->
MSH
because HTTP proxies operate in a synchronous mode by default. The new
flag
allows MSH -> SOAP -> MSH in spite of the asynchronous mode the SOAP node might prefer.
You're correct that the previous flag in QoS is no longer necessary.
We discussed placement of this module's description in our document
during
the meeting and the consensus seemed to be putting this feature in the
base
section because it may apply even to a SOAP node with just a bit of ebXML smarts -- level 0 in ebXML conformance.
thanx, doug
----- Original Message ----- From: "Arvola Chan" <arvola@tibco.com> To: "David Fischer" <david@drummondgroup.com> Cc: <ebxml-msg@lists.oasis-open.org> Sent: Friday, 16 November 2001 16:47 Subject: [ebxml-msg] Re: SyncReply Module
David:
My understanding is that the SyncReply module is equivalent to the
renaming
of the former Via module, minus the TraceHeaderList. As such, shouldn't
it
stay in Part II (Additional Features) and under the Multi-hop chapter?
The syncReply attribute under QualityOfServiceInfo goes away because the
use
of syncReply between the From and To parties is governed by a static (not per pessage) parameter in the CPA.
In the single-hop case, it should be sufficient to indicate in the CPA
that
sync reply is to be used, without explicitly including a SyncReply
element
in the SOAP header.
Regards, -Arvola
-----Original Message----- From: David Fischer <david@drummondgroup.com> To: ebXML Msg <ebxml-msg@lists.oasis-open.org> Date: Friday, November 16, 2001 3:59 PM Subject: [ebxml-msg] v1.09
This includes all the edits I have received including those decided upon
at
the F2F this week.
I do not yet have a Conformance Clause or the new sub-section dealing
with
Signature Security (Galvin).
Regards,
David Fischer Drummond Group ebXML-MS Editor.
---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
|