David,
some comments below, labelled MWS:
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
*************************************************************************************
Dan Weinreb <dlw@exceloncorp.com> on 11/01/2001 09:37:42 AM
Please respond to Dan Weinreb <dlw@exceloncorp.com>
To: ebxml-msg@lists.oasis-open.org
cc: ebxml-cppa@lists.oasis-open.org
Subject: [ebxml-cppa] [ebxml-msg] Attributes specified in both the
message and the CPA
In a recent ebXML MS phone meeting, we talked about how to deal with
attributes and properties of messages that appear to be specified both
in the CPA and in the message itself. I said that I would try to put
together a list of these.
I assume that every ebXML MS conversation is governed by a
pre-agreement on parameters, whether specified in an actual CPA
document or by some other means ("virtual CPA").
If values are pre-agreed then why bother to reiterate them in the
message itself? We discussed two possible answers: (1) to let the
sender control the attribute on a per-message basis, and
MWS: Any parameter that can be varied on a message by message
basis doesn't belong in the CPA. The problem is if there are any
parameters that are USUALLY static but might occasionally want to be
varied per message. We would need to identify such parameters and
agree that they need to be able to be varied. Those parameters might
require indicators in the in the CPA. The cleanest way to do that would
be to add a Boolean "variable" attribute on those parameters in which if
set to "variable", the message would, for that CPA, always override what
might be in the CPA. At this point I don't know of any CPA fields that
might sometimes have to be varied per message.
(2) so that
intermediaries, who may not be privy to the pre-agreement, can see the
values. If, for some attribute, neither of these is a concern, then
there would not seem to be any reason for the attribute to be
reiterated in the message.
MWS: This is part of the whole issue of what functions intermediaries
perform.
One obvious exception: the message header should contain whatever
fields are necessary to identify the message, especially whatever is
necessary to establish which pre-agreeement applies to the message.
Thus there's nothing wrong with MessageHeader subelements From, To,
CPAId, ConversationId, Service, Action, and MessageId.
Here is a list of thing that *might* constitute attributes that are
specified in both the CPA and the message. In cases where I'm not
sure, I err on the side of inclusion.
Section 7.4 says "This parameter information can be specified in the
CPA or in the MessageHeader", but some of the parameters listed among
the subsections of 7.4 do not appear to be in the MessageHeader, or
indeed in the message at all: Retries, RetryInterval, PersistDuration.
Perhaps the wording in section 7.4 proper needs a small change.
MWS: The wording in section 7.4 needs a BIG change. I believe this is
already in the issues list. For each of the subsections of 7.4, it has
to state whether the parameter is in the CPA or in the message header.
In other words, this is not a designer's choice. Ver. 1.0 simply
inadvertently omitted this information.
Taking all this into account, there actually don't seem to be very
many conflicts. The ones I can see that deserve scrutiny are:
(1) syncReply
The message has MessageHeader/QualifyOfServiceInfo/@syncReply
(3.1.7.1) with values true and false. The CPA has
CPA/PartyInfo/DeliveryChannel/Characteristics/@syncReplyMode
(7.5.11.1) with values "signalsOnly", "resonseOnly",
"signalsAndResponse", and "none".
The CPA certainly appears to be talking about BPSS "signals" and BPSS
"Business-response Messages", whereas the message header seems to be
talking about MS-level acknowledgement. There has been a lot of
discussion of this one already and I won't attempt to recap it here.
(2) duplicateElimination / idempotency
The message has attribute
MessageHeader/QualifyOfServiceInfo/@duplicateElimination (3.1.7.2)
with values true or false, while the CPA has attribute
CPA/PartyInfo/DocExchange/ebXMLBinding/ReliableMessaging/@idempotency
(7.6.4.2) with values true or false. These really do seem to mean
the same thing.
MWS: For version 1.0 they do mean the same thing. For version 1.0,
it was asked why idempotency needs to be in the CPA at all since use
of reliable messaging includes idempotency test (duplicate elimination).
For version 1.1, the F2F ended up breaking out 6 or 8 separate Boolean
parameters that together define the delivery semantics. The CPA
will have to agre with however this redefinition comes out in the MS
spec. This point applies to all the following paragraphs.
(3) request for acknowledgement / deliverySemantics
The message has DeliveryReceiptRequested (6.1.1) with "signed"
attribute that can be either true or false, and AckRequested (7.3.1)
with the same "signed" attribute and an "actor" attribute. The CPA
has the attribute
CPA/PartyInfo/DocExchange/ebXMLBinding/ReliableMessaging/@deliverySemantics
with possible values "OnceAndOnlyOnce" and "BestEffort".
These do not mean exactly the same things, but they seem to at least
overlap.
The CPA "deliverySemantics" attribute has only two possible values,
rather than expressing all four possibilities the way the Message
Specification currently does. The four possibilities are:
Name Retry/ack? Dup elimination?
BestEffort No No
AtLeastOnce Yes No
AtMostOnce No Yes
OnceAndOnlyOnce Yes Yes
In fact, it seems to me that it's not altogether clear what would be
meant by setting deliverySemantics to OnceAndOnlyOnce and setting
idempotency to true. If you know that a message is idempotent then
"only once" is not important, and effort spent preventing duplicates
may not be worth the cost.
MWS: I think there is a problem with interpreting the word "idempotent".
Formally, idempotent means that repeating the function will produce the
same result and therefore it is not necessary to eliminate duplicates,
which I think is what you are saying here. The problem (which I think
we discussed at the F2F) is that "idempotency" in our context means
"test for duplicates" (a common misuse of the word "idempotency"). We
should say "eliminate duplicates", not "idempotency".
MWS: I agree: The problem with splitting delivery semantics into
a bunch of boolean parameters means that some combinations are meaningless
and in other cases, settings of two different parameters to "yes" is a
redundancy.
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>