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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[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 ebMS permessage parameters


Chris:

Please see my response to Bruce Pedretti:

http://lists.oasis-open.org/archives/ebxml-msg/200111/msg00277.html

I was trying to let the CPA provide the guidance to the sending MSH whether
it should include an AckRequested element in the SOAP header, should the
application omit the specification of whether it wants an AckRequested
element to be constructed, and the two parties have agreed that this
property is "perMessage" rather than "fixed"

Similarly, I was trying to provide a default value for duplicateElimination
should the application not specify a value for this attribute, and the two
parties have agreed that this attribute is "perMessage".

Regards,
-Arvola

-----Original Message-----
From: Christopher Ferris <chris.ferris@sun.com>
To: Arvola Chan <arvola@tibco.com>
Cc: ebxml-cppa@lists.oasis-open.org <ebxml-cppa@lists.oasis-open.org>;
ebxml-msg@lists.oasis-open.org <ebxml-msg@lists.oasis-open.org>
Date: Monday, November 26, 2001 12:03 PM
Subject: Re: [ebxml-msg] Proposed CPP/A schema changes to deal with ebMS per
message parameters


>Arvola,
>
>I don't understand why you have included an 'includeInMessageHeader'
>attribute on AckRequested element in the CPA, especially with
>the default value of 'false'. IMO, the presence or absence of
>the SOAP extension should be the trigger by which an acknowledgment
>is returned. I would prefer that if this attribute is preserved,
>that the default value be made 'true' and would much prefer
>if this attribute were eliminated and the AckRequested element
>be REQUIRED to be present in the message.
>
>I would also prefer that the default value for duplicateElimination
>either be eliminated or be set to 'fixed', *not* 'perMessage'.
>
>My $0.02,
>
>Chris
>
>Arvola Chan wrote:
>
>> 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
>>
>>
>>
>
>



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


Powered by eList eXpress LLC