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

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

Stefano,

I'm sorry that I have to disagree.  Yes, for simple applications, a
WSDL-like description might be all that is needed.  The service-interface
section of tpaML might be another example.

However, the CPA-less configuration might have the same level of
functionality that might be needed for B2B with ebXML.  Take a look at
IBM's Websphere Business Integrator product.

People should understand that without a CPA, for a given application, each
party still has to provide the same configuration about the other party to
its system.  If there is no CPA, the two parties have to use phone and fax
to understand each other's requirements and then manually populate the same
runtime database as with a CPA.

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
*************************************************************************************



"Stefano POGLIANI" <stefano.pogliani@sun.com> on 11/05/2001 08:29:23 AM

To:    Martin W Sachs/Watson/IBM@IBMUS, "David Fischer"
       <david@drummondgroup.com>
cc:    "Dan Weinreb" <dlw@exceloncorp.com>,
       <ebxml-msg@lists.oasis-open.org>, <ebxml-cppa@lists.oasis-open.org>
Subject:    RE: [ebxml-cppa] RE: [ebxml-msg] Attributes specified in both
       the message and the CPA



Sorry to jump in late.

I think that when the Messaging is used "without CPA", then the
configuration is
given by something similar to the WSDL file; I mean, when I am not working
with
a CPA, I am probably exposing a Web Service with ebXML-TRP bindings. This
W/s
may not be choregraphed or it may be choreographed by something different
than
the ebXML BPSS.
But, I agree with Marty, the two parties wanting to talk need to agree on
the
way they can understand each other. This may be done via "dynamic
negotiation"
or via "the CPA" or via something else. I am not sure that the message
should
carry all the information required to properly catch it and react to it
(but
perhaps I do not see the whole scenario)

Best regards

/stefano

> -----Original Message-----
> From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
> Sent: 01 November 2001 22:48
> To: David Fischer
> Cc: Dan Weinreb; ebxml-msg@lists.oasis-open.org;
> ebxml-cppa@lists.oasis-open.org
> Subject: [ebxml-cppa] RE: [ebxml-msg] Attributes specified in both the
> message and the CPA
>
>
>
> 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/@delivery
> Semantics
> 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>
>
>
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>