[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ebxml-cppa] RE: [ebxml-msg] Attributes specified in both the messageand the CPA
Hi Dan, I think you have made an assumption which is at the core of this problem. You have assumed that there is a pre-agreement. Many in this group agree with you but some don't. Take the case, for example, of someone requesting a stock quote. This may be a one-time transaction, and a rather simple one at that. Why go through all the trouble of negotiating a CPA? Take the case, for example, of someone purchasing a sweater from L.L.Bean. This is a B2C transaction and again, may be one time. Why bother with a CPA negotiation which takes longer than the transaction? When we agreed not to require a CPA, we agreed not to require it. When we ask the question, "how does this work without a CPA?" we have to assume there is no CPA and no "virtual" CPA. Does this mean we have no configuration? Of course not, it only means there is no negotiation between the parties. What then is required in the message headers to accomplish this task? Many things, like persistDruation, retries, retryInterval, etc. can be given default or "bootstrap" values. Even the CPAId can be given a default -- like a credit card number -- or the sender can pick one and the receiver continues to use it. So we come down to -- what can't be given defaults? These are going to be transmission parameters such as syncReply, and parameters which may change per-message, like AckRequested. These are the things we need to maintain in both the MessageHeader and the CPA (my personal opinion is that syncReplyMode should be removed from CPA). We also MUST allow ebXML-MS to work with a CPA -- which will probably be the most common case. To do this, we agreed NOT to override CPA values with values in the MessageHeader. Regards, David Fischer Drummond Group. -----Original Message----- From: Dan Weinreb [mailto:dlw@exceloncorp.com] Sent: Thursday, November 01, 2001 8:38 AM To: ebxml-msg@lists.oasis-open.org Cc: ebxml-cppa@lists.oasis-open.org Subject: [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 (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. 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. 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. (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. ---------------------------------------------------------------- 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