OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [ebxml-cppa] RE: [ebxml-msg] Arvola's SyncReply issues


Some discussion from the MSG listserver that relates to CPA.

Regards,
Marty

*************************************************************************************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************
---------------------- Forwarded by Martin W Sachs/Watson/IBM on 01/04/2002
09:08 AM ---------------------------

Doug Bunting <dougb62@yahoo.com> on 01/03/2002 08:07:30 PM

To:    ebXML Msg <ebxml-msg@lists.oasis-open.org>
cc:
Subject:    RE: [ebxml-msg] Arvola's SyncReply issues



David,

Instead, we should avoid re-defining SyncReply to mean "give me
specific information from the To Party in the synchronous reply".  The
problem is how narrowly the CPP/A specification has interpreted this
flag, not its existance.

I didn't say SyncReplyMode is still about bundling, just that it has
some of that legacy.  Deciding what comes back in a synchronous reply
remains interesting.  It's also interesting to describe what will come
back together in a later (asynchronous) response message since that
message may not contain everything not bundled into the first one.
Both bundles could occur for the same outgoing message.  The second
bundle should be considered later.

thanx,
    doug

--- David Fischer <david@drummondgroup.com> wrote:
> Yes, SyncReply and Multihop don't work well together.  As
> shown in Arvola's example, SyncReply and RM also do not work
> well together.
>
> The only place SyncReply might work well is for single-hop,
> but SyncReply is only for Synchronous-Transports, but with
> single-hop+Synchronous why would we ever send back
> Asynchronously, in which case SyncReply is not needed.  Why
> again do we have this element?
>
> IMO, this should be an implementation detail.  This is
> really not about SyncReplyMode.  As Doug pointed out,
> SyncReplyMode is really a bundling attribute and need not be
> about Synchronous Transport at all.
>
> Regards,
>
> David Fischer
> Drummond Group.
>
>
> -----Original Message-----
> From: Arvola Chan [mailto:arvola@tibco.com]
> Sent: Wednesday, January 02, 2002 8:43 PM
> To: Doug Bunting; ebXML Msg
> Subject: Re: [ebxml-msg] Arvola's SyncReply issues
>
>
>   Doug:
>
>   Please see my comments inline.
>
>   Regards,
>   -Arvola
>     ----- Original Message -----
>     From: Doug Bunting
>     To: ebXML Msg
>     Sent: Wednesday, January 02, 2002 1:48 PM
>     Subject: [ebxml-msg] Arvola's SyncReply issues
>
>
>     Arvola,
>
>     I've snipped out a few of your comments that centre on
> the SyncReply element and embedded a few comments below.
> Hopefully, this will move us quickly towards resolving your
> questions.
>
>     thanx,
>         doug
>
>     ----- Original Message -----
>     From: Arvola Chan
>     To: David Fischer ; ebXML Msg
>     Sent: Wednesday, 02 January 2002 12:33
>     Subject: Re: [ebxml-msg] Messaging Spec v1.092
>
>
>     ...
>
>     6. Line 1412: I like to point out that a SyncReply
> element is not compatible with an AckRequested element that
> is targeted at the next MSH.
>     I'm not sure why you're of this opinion.  Why couldn't
> the next MSH synchronously reply with an Acknowledgment
> element (after it's persisted the incoming message, of
> course)?
>
>     <ac>
>     The From Party MSH expects a synchronous response from
> the To Party MSH.  On the other hand, if the intermediary
> MSH returns the intermediate Acknowledgment synchronously
> after it has persisted the message, and then closes the HTTP
> connection (prior to forwarding the message), then how can
> the response from the To Party MSH be returned synchronously
> to the From Party MSH?
>     </ac>
>
>     12. Line 1591: I think it may be problematical for the
> recipient to do duplicate elimination when no
> DuplicateElimination element is present. What happens if
> SyncReply is present and AckRequested is not present. If the
> incoming message is not passed on to the application, should
> any reply be returned to the sender?
>     The DuplicateElimination semantics are described rather
> clearly in the specification.  The answer to your question
> is that the synchronous reply must contain the first
> response to the duplicate message.  The receiver application
> might not hear about the duplicate but the will get the same
> answer back as the first time.
>
>     <ac>
>     You are correct. I was confused by the statement on line
> 1788: "A Receiving MSH node is not participating in the
> reliable messaging protocol for a received message if the
> message either does not contain an AckRequested element, or
> ..." I think there are actually four aspects of reliable
> messaging behavior: (1) persisting the sent message and
> retry on the part of the sender when an Acknowledgment is
> not returned in time; (2) returning an Acknowledgment
> message by the receiver; (3) persisting the received message
> to allow duplicate elimination by the receiver; (4)
> automatic returning of the first response message without
> forwarding the message to the application when a duplicate
> message is received. (1) and (2) are triggered by the
> AckRequested element. (3) and (4) are triggered by the
> DuplicateElimination element, or if the receiver decides to
> do duplicate elimination in spite of the absence of a
> DuplicateElimination element in the incoming message. Line
> 1589 needs to clarify what adopting a reliable messaging
> behavior really means (really (3) and (4)). In the paragraph
> starting on line 1591, it will be helpful to qualify
> "although elimination of duplicates is still allowed" to
> mean that (3) and (4) are to be done.
>     </ac>
>
>     20. Line 1733 and line 1738: These two bullet points
> assume that syncReplyMode in the CPA is not used with an
> asynchronous communication channel. This is in conflict with
> the 1.0 CPP/A spec statement quoted in item 15 above. I
> think this is a minor technical issue that may require some
> discussion.
>     Would this be resolved by (more correctly) referencing
> the syncReplyMode semantics in the CPP/A 1.1 specification?
> If not, we still have a discrepancy between the two
> specifications and that should be resolved as soon as
> possible.  The CPP/A 1.0 specification may have some
> vestiges of the "bundling" semantics I've mentioned before
> (using syncReplyMode to describe which signals may be
> bundled with the application response).  Those semantics
> apply equally to synchronous and asynchronous channels.  The
> current SyncReply MSH semantics are all about what signals
> must appear in the synchronous response over a synchronous
> channel.
>     It's not up to the MSH to determine how later business
> responses might be bundled with business signals and
> asynchronous channels are therefore not relevant.  Of
> course, the current description of an MSH doesn't provide a
> way to describe expectations around bundling of business
> responses and signals with MSH signals like the
> Acknowledgment element over an asynchronous channel.  2.0
> issue?
>
>     <ac>
>     I think the simplest solution may be to request the
> CPP/A team to strike out from the 1.1 spec the following
> sentence: "If the delivery channel identifies a transport
> protocol that has no synchronous capabilities (such as SMTP)
> and the Characteristics element has a syncReplyMode
> attribute with a value other than "none", a response SHALL
> contain the same content as if the transport protocol did
> support synchronous responses." which contradicts the
> statement on line 1625: "The SyncReplyMode parameter from
> the CPA is used only if the data communications protocol is
> synchronous (e.g. HTTP)." We can defer the bundling issue
> for asynchronous communications protocols until the 2.0
> versions of the MSG and CPP/A specs.
>     </ac>
>
>     ...
>
>


__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC