[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-msg] Proposed CPP/A schema changes to deal with ebMSperMessage 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 -----Original Message----- From: PEDRETTI,BRUCE (HP-NewJersey,ex2) <bruce_pedretti@hp.com> To: 'Martin W Sachs' <mwsachs@us.ibm.com> Cc: 'ebxml-msg@lists.oasis-open.org' <ebxml-msg@lists.oasis-open.org> Date: Tuesday, November 27, 2001 8:28 AM Subject: RE: [ebxml-msg] Proposed CPP/A schema changes to deal with ebMS perMessage parameters Marty, I'm o.k. with requiring the attribute to be in the message header and also happy with throwing an error if it is not. However, I think it is also ok for the attribute to be absent *if* there is an *agreed on* default. Even if we require the attribute's presence, there is the case where the sending MSH has no indication from its app as to what value the attribute should have. In that case, what value should it use? I don't think we can assume that the business application will always know what value to use. Do you? (If we can assume the business app always knows, then yes -- there is no need for a default.) Setting up a default value in the CPA eliminates the need for the sending MSH to "second-guess" the two parties. Basically, the CPA is saying: "To the sender MSH: if you do not know what to set this perMessage attribute to, use 'x' because that is what we (the two parties) have agreed on as a default". This notion of a perMessage default is Arvola's embellishment on perMessage semantics. I think it is a good and necessary one (based on the assumption that the business app does not always know about this parameter or how to set it). Admittedly, allowing a default value is not something that we have formally agreed on as a group, that I know of. That said, I think it logically follows the decisions that we have made. Bruce ============================================ Bruce Pedretti Hewlett-Packard Company Software Developer 6000 Irwin Road (856) 638-6060 Mt. Laurel, NJ 08054 http://www.hp.com/ ============================================ -----Original Message----- From: Martin W Sachs [mailto:mwsachs@us.ibm.com] Sent: Tuesday, November 27, 2001 10:52 AM To: PEDRETTI,BRUCE (HP-NewJersey,ex2) Cc: 'ebxml-msg@lists.oasis-open.org' Subject: RE: [ebxml-msg] Proposed CPP/A schema changes to deal with ebMS p erMessage parameters Requiring that the attribute be in the message header simplifies things considerably. There are only two possible values, so why allow the attribute to be omitted from the message header? The attribute should be required and an error thrown if it is missing. Certainly, guessing by the MSH is totally off base. It can't be allowed to second-guess the two parties. 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 **************************************************************************** ********* "PEDRETTI,BRUCE (HP-NewJersey,ex2)" <bruce_pedretti@hp.com> on 11/27/2001 10:15:43 AM To: Martin W Sachs/Watson/IBM@IBMUS cc: "'ebxml-msg@lists.oasis-open.org'" <ebxml-msg@lists.oasis-open.org> Subject: RE: [ebxml-msg] Proposed CPP/A schema changes to deal with ebMS p erMessage parameters Marty, Arvola needed to make this clear to me, as well. The use case is that two partners agree to perMessage semantics. But in practice, what happens on the sending MSH side when the business app makes no perMessage indication? Should the sending MSH make a random choice? Or, what happens when the receiving app gets a message that has no perMessage indication? What should the senders and receivers do in these cases? Establishment of an agreed upon default value (other than the one in the cpa) would promote clear expectations and consistent results. Bruce ============================================ Bruce Pedretti Hewlett-Packard Company Software Developer 6000 Irwin Road (856) 638-6060 Mt. Laurel, NJ 08054 http://www.hp.com/ ============================================ -----Original Message----- From: Martin W Sachs [mailto:mwsachs@us.ibm.com] Sent: Tuesday, November 27, 2001 9:22 AM To: PEDRETTI,BRUCE (HP-NewJersey,ex2) Cc: 'Arvola Chan'; ebxml-msg@lists.oasis-open.org Subject: RE: [ebxml-msg] Proposed CPP/A schema changes to deal with ebMS p erMessage parameters Since there are really only 3 cases: yes in CPA, no in CPA, per message, I don't understand the need for a default in the message specification. Given that the only usable values in the message are yes and no, why should the attribute be permitted to be left out? 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 **************************************************************************** ********* "PEDRETTI,BRUCE (HP-NewJersey,ex2)" <bruce_pedretti@hp.com> on 11/26/2001 06:07:05 PM To: "'Arvola Chan'" <arvola@tibco.com>, ebxml-msg@lists.oasis-open.org cc: Subject: RE: [ebxml-msg] Proposed CPP/A schema changes to deal with ebMS p erMessage parameters Arvola, Thank you for helping me understand the issues. This design is elegant in that you nicely cover the gambit with two attributes, but perhaps it is difficult to understand because the "flag" attribute is dual-purpose. Sometimes "flag" provides a fixed value, sometimes it provides a default. This makes me a bit uneasy for two reasons: 1) if a value is a default, then for readability the attribute name ought to indicate such (for example, "perMessageDefault"); and 2) without annotated documentation, this "dual-purpose" concept can not be expressed in a schema. There are at least two other alternatives: 1) <DuplicateElimination inForce="perMessage" perMessageDefault="false"/> 2) Use element presence for boolean conditions. For example: a) if duplicate elimination false: <DuplicateElimination> absent b) if duplicate elimination true: <DuplicationElimination> present c) if duplicate elimination perMessage: <DuplicateElimination perMessageDefault="true"/> All 3 seem to me to have pros and cons. My preference is for alternative (1). My fellow hp developers prefer alternative (2). If you go with your original proposal, careful documentation may be important. Bruce ============================================ Bruce Pedretti Hewlett-Packard Company Software Developer 6000 Irwin Road (856) 638-6060 Mt. Laurel, NJ 08054 http://www.hp.com/ ============================================ -----Original Message----- From: Arvola Chan [mailto:arvola@tibco.com] Sent: Monday, November 26, 2001 4:24 PM To: PEDRETTIBRUCE (HP-NewJerseyex2); 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 Bruce: I was allowing for the fact that the two parties may have agreed that a property like AckRequested is "perMessage" and still specify in the CPA a bilaterally agreed default value (which can be different from the schema default) for the property should the sending application omit to specify a value for this property. If such negotiated defaults are unnecessary, then I agree that your suggested simplifications will be sufficient. Thanks, -Arvola -----Original Message----- From: PEDRETTI,BRUCE (HP-NewJersey,ex2) <bruce_pedretti@hp.com> To: 'Arvola Chan' <arvola@tibco.com>; ebxml-msg@lists.oasis-open.org < ebxml-msg@lists.oasis-open.org> Date: Monday, November 26, 2001 12:36 PM Subject: RE: [ebxml-msg] Proposed CPP/A schema changes to deal with ebMS permessage parameters <bp>Comments in-line...</bp> -----Original Message----- From: Arvola Chan [mailto:arvola@tibco.com] Sent: Monday, November 26, 2001 2:58 PM To: PEDRETTIBRUCE (HP-NewJerseyex2) 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 p ermessage parameters Bruce: Please see my embedded comments. Regards, -Arvola -----Original Message----- From: PEDRETTI,BRUCE (HP-NewJersey,ex2) <bruce_pedretti@hp.com> To: 'Arvola Chan' <arvola@tibco.com> Cc: ebxml-msg@lists.oasis-open.org <ebxml-msg@lists.oasis-open.org> Date: Monday, November 26, 2001 10:35 AM Subject: RE: [ebxml-msg] Proposed CPP/A schema changes to deal with ebMS p ermessage parameters Arvola, Thanks for taking the initiative to present these ideas to the cpa team. Comments: 1) Personally speaking, I had envisioned an attribute for DuplicateElimination that had the enumerated values: true, false, perMessage. For example, <DuplicateElimination inForce="true"/> or <DuplicateElimination inForce="perMessage"/>. <ac> Even when the two parties agree that duplicate elimination is to be specified per message, the sending MSH may still want to look to the CPA for guidance on how this attribute should be set. That is, the application may explicitly specify a value for the duplicateElimination attribute, or choose to omit it in which case the CPA should provide the default value. Therefore, just having "perMessage", "true", and "false" as the only possible values for the inForce attribute is not quite sufficient. <bp>I don't understand what you mean by "not sufficient". What other possible values might there be? Just to be explicit about the meaning of these values as I see them: 1) If "true", then both parties agree that duplicateElimination is inForce; 2) If "false", then both parties agree that duplicateElimination should not be performed. 3) If "perMessage", then the Receiving MSH will comply with message header (if possible). Are there other arrangements? I agree that the CPA schema should provide a default value, but that idea is not counter to an enumeration.</bp> </ac> 2) The AckRequested issues could also be simplified with the same enumeration. For example <Ack requested="true" signed="perMessage"/>. <ac> Similarly, the CPA should provide guidance to the sending MSH whether it should construct an AckRequested element, if the application chooses to omit such specification. <bp>Similar rebuttal as above</bp> </ac> 3) Also, am I understanding correctly that you are proposing defaults for AckRequested such that: <AckRequested perMessageCharacteristics="perMessage" includeInMessageHeader="false"/> ... are these default values at odds with each other? If AckRequested is supposed to be decided on a per message basis, mustn't the info be included in the message header -- or am I misunderstanding the includeInMessageHeader attribute? <ac> The intended meaning is that the application may specify on a per message basis, whether an AckRequested element should be constructed. However, if the application omits such a specification, the MSH should not construct an AckRequested element because includeInMessageHeader is set to false. At the same time, this default can be changed by setting includeInMessageHeader to true. <bp>Isn't an absence of AckRequested and an AckRequested="false" semantic the same? Seems to me that if the app says nothing about an MSH ack requested, then the MSH should not create the AckRequested element. Under what circumstances might it need to create an AckRequested="false"? </bp> </ac> -----Original Message----- From: Arvola Chan [mailto:arvola@tibco.com] Sent: Monday, November 19, 2001 7:16 PM To: Doug Bunting 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 per message parameters Doug: The first point in my original message was intended to differentiate message properties that originate from BPSS from those that are specific to the messaging specification. The DeliveryChannel element originally contains a Characteristics element that carries BPSS related parameters. I am recommending that Characteristics be renamed BusinessProcessCharacteristics before we add the new MessagingCharacteristics element. Here is another suggested set of schema changes to address your desire to allow "acknowledgments are required for this delivery channel and the message will indicate whether signing is required" or "any requested acknowledgement must be signed". <element name="MessagingCharacteristics"> <complexType> <sequence> <element ref="tns:AckRequested"/> <element ref="tns:AckSignatureRequested"/> <element ref="tns:DuplicateElimination"/> </sequence> </complexType> </element> <element name="AckRequested"> <complexType> <attribute name="perMessageCharacteristics" type ="tns:perMessageCharacteristics.type" default="perMessage"/> <attribute name="includeInMessageHeader" type="boolean" default ="false"/> <attribute name="actor" type="tns:actor.type" default="toPartyMSH"/> </complexType> </element> <element name="AckSignatureRequested"> <complexType> <attribute name="perMessageCharacteristics" type ="tns:perMessageCharacteristics.type" default="perMessage"/> <attribute name="flag" type="boolean" default="false"/> </complexType> </element> <element name="DuplicateElimination"> <complexType> <attribute name="perMessageCharacteristics" type ="tns:perMessageCharacteristics.type" default="perMessage"/> <attribute name="flag" type="boolean" default="false"/> </complexType> </element> <simpleType name="perMessageCharacteristics.type"> <restriction base="NMTOKEN"> <enumeration value="fixed"/> <enumeration value="perMessage"/> </restriction> </simpleType> <simpleType name="actor.type"> <restriction base="NMTOKEN"> <enumeration value="nextMSH"/> <enumeration value="toPartyMSH"/> </restriction> </simpleType> Regards, -Arvola -----Original Message----- From: Doug Bunting <dougb62@yahoo.com> To: Arvola Chan <arvola@tibco.com> Date: Monday, November 19, 2001 3:26 PM Subject: Re: [ebxml-msg] Proposed CPP/A schema changes to deal with ebMS per message parameters Arvola, I'm not on the CPPA list and I'm unsure about the history here. Feel free to forward your answers as appropriate. What will the effect of the first point be? More particularly, what does this have to do with the goals you've listed above? The line "<attribute name="actor" type="tns:actor.type"/ default ="toPartyMSH">" needs the slash moved to the end. I like what's been described as two separate Boolean values for AckRequested in the CPA -- one that controls whether acknowledgements are supported at all and another that controls whether any supported acknowledgments may be signed. This proposal seems to eliminate that separation. A CPA will not be able to say "acknowledgments are required for this delivery channel and the message will indicate whether signing is required" or "any requested acknowledgement must be signed". thanx, doug ----- Original Message ----- From: Arvola Chan To: ebxml-cppa@lists.oasis-open.org ; ebxml-msg@lists.oasis-open.org Sent: Monday, 19 November 2001 15:12 Subject: [ebxml-msg] Proposed CPP/A schema changes to deal with ebMS per message parameters At last week's ebxml-msg TC F2F meeting, it was agreed that the duplicateElimination attribute (under QualityOfServiceInfo) and the AckRequested element (under soap:Header)will in principle be treated as parameters that are adjustible on a message by message basis. Trading partners may specify in the CPA that they have agreed that these parameters are variable per message, or that these parameters are to be fixed at certain values, for a given delivery channel. Accordingly, I am proposing the following changes/additions to the CPP/A schema: - Rename the existing Characteristics element under DeliveryChannel as BusinessProcessCharacteristics. - Add a MessagingCharacteristics element under DeliveryChannel. - Add AckRequested and DuplicateElimination elements under the MessagingCharacteristics element, as follows: <element name="MessagingCharacteristics"> <complexType> <sequence> <element ref="tns:AckRequested"/> <element ref="tns:DuplicateElimination"/> </sequence> </complexType> </element> <element name="AckRequested"> <complexType> <attribute name="perMessageCharacteristics" type ="tns:perMessageCharacteristics.type" default="perMessage"/> <attribute name="includeInMessageHeader" type="boolean" default ="false"/> <attribute name="actor" type="tns:actor.type"/ default="toPartyMSH"> <attribute name="signed" type="boolean" default="false"/> </complexType> </element> <element name="DuplicateElimination"> <complexType> <attribute name="perMessageCharacteristics" type ="tns:perMessageCharacteristics.type" default="perMessage"/> <attribute name="value" type="boolean" default="false"/> </complexType> </element> <simpleType name="perMessageCharacteristics.type"> <restriction base="NMTOKEN"> <enumeration value="fixed"/> <enumeration value="perMessage"/> </restriction> </simpleType> <simpleType name="actor.type"> <restriction base="NMTOKEN"> <enumeration value="nextMSH"/> <enumeration value="toPartyMSH"/> </restriction> </simpleType> - If the perMessageCharacteristics attribute (under AckRequested and/or DuplicateElimination) is 'perMessage', then both parties have agreed that AckRequested and/or DuplicateElimination can be varied per message. Furthermore, the sender would by default make use of attributes under the AckRequested and DuplicateElimination elements within the CPA to populate the AckRequested element and duplicateElimination attribute in the ebXML message. For example, if the includeInMessageHeader attribute under AckRequested is true, then an AckRequested element will be constructed with its actor and signed attributes populated accordingly in the ebXML message. Of course, the sender is free to populate the AckRequested element in the ebXML message differently, based on other criteria (if the CPA stipulates that this is to be treated as perMessage). - Conversely, if the perMessageCharacteristics attribute is 'fixed', then both parties have agreed that AckRequested and/or DuplicateElimination) must always be set to the same values as indicated in the CPA under the AckRequested and DuplicateElimination elements for the corresponding DeliveryChannel. In this case, the sender is required to make use of attributes under the AckRequested and DuplicateElimination elements within the CPA to populate the AckRequested element and duplicateElimination attribute in the ebXML message. For example, if the value attribute under DuplicateElimination is true, then the duplicateElimination attribute under QualityOfServiceInfo will be set to true. Any deviation from the agreed upon fixed values would cause the receiver MSH to return an error. Please let me know if you see a problem in the suggested schema change, or if I have mis-represented the decision reached last Thursday. Thanks, -Arvola ---------------------------------------------------------------- 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