Re: [ebxml-msg] Re: SyncReply Module

[Arvola Chan <arvola@tibco.com>]

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 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."

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 places 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>