[ebxml-cppa] RE: [ebxml-msg] Attributes specified in both the messageand the CPA

[Martin W Sachs <mwsachs@us.ibm.com>]

David,

Some comments below, as "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
*************************************************************************************



David Fischer <david@drummondgroup.com> on 11/01/2001 10:21:37 AM

To:    Dan Weinreb <dlw@exceloncorp.com>, ebxml-msg@lists.oasis-open.org
cc:    ebxml-cppa@lists.oasis-open.org
Subject:    RE: [ebxml-msg] Attributes specified in both the message and
       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?

MWS:  You still have to get both ends' middleware to agree on how to
exchange
the message.  What you need is to be able to negotiate and deploy the CPA
so rapidly that it can be thrown away after one use.  Some people call it
"dynamic eCommerce".  Automated negotiation is a step in that direction.

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?

MWS:  My comment above applies.  However let's face it.  B2C works quite
well
today using browsers.  What we are really after is dynamic B2B eCommerce.

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.

MWS:  Excuse me.  You may call it "negotiation" or not but the two parties
still have to understand each other's IT requirements or the message won't
flow.

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.

MWS:   Yes, you could throw the entire equivalent of the CPA into the
message
headers but you thus guarantee that two different implementations are
required,
one with and one without CPAs.

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).

MWS:  OK, I think we more or less agree in these last two paragraphs.
Someone
else can comment on whether it makes implementation
sense to dynamically change between sync and nonsync
(or ack requested and no ack requested) for the same action. It
makes perfect sense to define some actions as sync and others non-sync.
Different messaging characteristics can be accounted for by defining
different
actions (i.e. different business transaction activities) in the BPSS spec.
That's
why the CPA provides for specifying a different delivery channel for each
action.

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>


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>