OASIS ebXML Messaging Services TC

Back to discussions
Expand all | Collapse all

Re: [ebxml-msg] Proposed CPP/A schema changes to deal with ebMSperMessage parameters

  • 1.  Re: [ebxml-msg] Proposed CPP/A schema changes to deal with ebMSperMessage parameters

    Posted 11-27-2001 13:25 
    
Arvola,

I completely agree with your last paragraph.

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



"Arvola Chan" <arvola@tibco.com> on 11/27/2001 12:49:09 PM

To:    "PEDRETTIBRUCE (HP-NewJerseyex2)" <bruce_pedretti@hp.com>, Martin W
       Sachs/Watson/IBM@IBMUS
cc:    <ebxml-msg@lists.oasis-open.org>, <ebxml-cppa@lists.oasis-open.org>
Subject:    Re: [ebxml-msg] Proposed CPP/A schema changes to deal with ebMS
       perMessage parameters



Marty:

Please see Bruce's explanation why it may still be useful to have
negotiated
defaults for the AckRequested and DuplicateElimination parameters even when
the two parties have agreed that these be variable on a per message basis.
In my comments on the 1.09 draft, I am also questioning whether the
MessageOrder module needs to be treated similar to the AckRequested module
with "perMessage" semantics.

My assumption has been that Reliable Messaging (ack/timeout/retry) behavior
must be triggered by the presence of an Acknowledgment element in the
message. Either the application has to explicitly direct its local MSH to
construct an appropriate Acknowledgment element or the MSH must look up in
the CPA to determine if an Acknowledgment is to be created.

Similarly, whether duplicates are to be eliminated is controlled by the
duplicateElimination attribute within the QualityOfServiceInfo element.
Either the application has to explictly direct its local MSH to set this
attribute to the desired value or the MSH must consult the CPA for the
default value.

I am agreeable to simplifying the design to omit the recording of any
negotiated default from the CPA. In this case, whenever the CPA indicates a
parameter is "perMessage", the application must explicitly provide a value
for it so that the MSH can populatate the SOAP Header properly.

Regards,
-Arvola


Related Content