[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ebxml-cppa] RE: [ebxml-msg] Attributes specified in both themessage and the CPA
I completely agree with your description.
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/06/2001 05:52:55 AM
To: Martin W Sachs/Watson/IBM@IBMUS
cc: "David Fischer" <david@drummondgroup.com>, "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
Marty,
I apologize for having been not precise in my wording.
The idea that I was trying to expose has been that some
"information about the other" is always required.
This may be in the form of the CPA, of tpaML, of WSDL, of
phone/fax or whatever thing makes it convenient to the
environment where the solution is deployed.
"logically" a CPA is always needed, even if it may not
be the ebXML-CPA.
Thanks a lot.
/stefano
> -----Original Message-----
> From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
> Sent: 05 November 2001 14:37
> To: Stefano POGLIANI
> Cc: David Fischer; Dan Weinreb; 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
>
>
>
> 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>
> >
>
>
>
>
>
> ----------------------------------------------------------------
> 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