RE: [ebxml-cppa] Re: [ebxml-msg] Attributes specified in boththemessageand the CPA

[David Fischer <david@drummondgroup.com>]

Colleen, you are absolutely correct.

Regards,

David.

-----Original Message-----
From: Colleen Evans [mailto:cevans@sonicsoftware.com]
Sent: Monday, November 05, 2001 11:27 AM
To: David Fischer
Cc: Dale Moberg; Dan Weinreb; ebxml-msg@lists.oasis-open.org
Subject: Re: [ebxml-cppa] Re: [ebxml-msg] Attributes specified in both
themessageand the CPA


David,
A clarification - do you really mean to say that existence of a config file vs.
a
CPA always = "lack of pre-agreement on some parameters"?  If so, I don't agree.
Ebusiness can be accomplished with config files that are created as the result
of
pre-agreement on some or all of the necessary  parameters between trading
partners
(just like it is for the most part today).  For whatever reason, businesses,
private
exchanges, etc. may in the future continue to operate this way, even when
implmenting the ebXML message service.

Granted, a config file can also be used as a default bootstrap mechanism where
no
pre-agreement exists, but I don't believe we can exclude the other case.

Regards,
Colleen

David Fischer wrote:

> Dale,
>
> I agree with you but I also must point out that configuration does not
> necessarily mean mutual agreement.  What if I set retries to 3 and you set to
5.
> Does this really make any difference?  I don't think so.  However, if you make
a
> configuration decision like syncReply=true, then I need to know and, if we
have
> not previously agreed, you need to indicate this in the headers.
>
> TRP agreed not to require a CPA.  I have never taken that to mean a lack of a
> configuration file (although nothing says the structure of the configuration
> file has to match the CPA spec).  I have always taken that to mean a lack of
> pre-agreement on some parameters.  This might mean I download your
> url/service/action from a registry and send you an unsolicited business
> document.  This is what I mean by bootstrap.
>
> Regards,
>
> David Fischer
> Drummond Group.
>
> -----Original Message-----
> From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com]
> Sent: Friday, November 02, 2001 10:30 AM
> To: Dan Weinreb; david@drummondgroup.com
> Cc: ebxml-msg@lists.oasis-open.org; ebxml-cppa@lists.oasis-open.org
> Subject: RE: [ebxml-cppa] Re: [ebxml-msg] Attributes specified in both
> the messageand the CPA
>
>    Date: Thu, 1 Nov 2001 09:21:37 -0600
>    From: "David Fischer" <david@drummondgroup.com>
>
>    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.
>
> From: Dan Weinreb [mailto:dlw@exceloncorp.com]
> Sent: Thursday, November 01, 2001 8:53 PM
>
> "I see.  I'm surprised to hear you say this.  I came away from the Palo
> Alto meeting with a strong sense that everybody understood that there
> was always a pre-agreement, a CPA or a "virtual CPA" of some sort.  I
> thought that was a fundamental architectural decision that had been
> made before I joined the TC."
>
> <DaleMoberg>
>
> I think that the "pre-agreement" is simply
> another way of describing
> the need for MSH configuration. I believe
> there has always been in ebXML an
> operative contrast between what is done
> at design time, at configuration/deployment time,
> and at run time.
>
> If there are people who do not
> share this contrast, I think they are
> definitely a very small group, and
> the current specs (BPSS, RegRep,
> CPPA, Messaging) really presume that you
> make this contrast.
>
> Filling out the ebXML Messaging
> header is a run-time matter. But
> some values used in headers are retrieved from
> configurations of service bindings,
> or in the future, possibly also from specific
> BSI interface "signatures".
> Several of the values in the header are
> relevant to the operation of the MSHes.
> But some values relevant to the operation
> of the MSHes, do not occur in
> the ebXML header. I don't think
> anyone thinks that all information
> that MSHes might use in implementing
> a collaboration session is or should be
> recorded and transmitted in the ebXML header.
> There is information that collaboration
> participants simply do not need
> to change or mention message by message.
>
> I guess I would like to understand
> what the "problem" is that has a
> core assumption that there is
> "pre-runtime configuration".
>
> </DaleMoberg>
>
> Dan also says:
>
> "...
> but I do think we had better all agree about this, and if there are
> going to be "bootstrap default" values, we should make it clear in the
> relevant specs."
>
> I agree with this. But, why is there a need for bootstrap
> default values in the Messaging spec? I can understand RegRep
> worrying about this, but I am puzzled why Messaging would.
>
> My diagnosis of the problem is that
> I think that David F. may be trying to make ebXML
> collaborations too much like light weight
> web services.
>
> In general, aren't ebXML collaborations
> really distinguished from web-services
> on the basis of web-services
> being "lighter weight" business
> interactions that have minimalistic setup burdens,
> simpler to nonexistent security,
> no range of agreement on packaging,
> nor agreements on optional protocols (like RM),
> nor agreements on transports (HTTP, love it or leave it),
> nor agreement on various business signals
> (nonrepudiation of receipt, etc etc) ?
>
> While ebXML collaborations could be a way to get stock
> quotes, I think a SOAP service advertized in UDDI
> and characterized by WSDL might
> be an easier way to quickly implement that interaction.
> The fact that some business interactions
> might be better/easier/faster implemented as web services
> rather than as collaborations is not one
> ebXML has to worry about, however. We should
> rather make certain that the more demanding
> requirements encountered for business collaborations
> are correctly captured, IMO. I do not see it as
> a current goal that ebXML support these ad-hoc,
> so-called "dynamic" business interactions.
> Maybe disagreement about this goal is instead the core
> problem?
>
> ----------------------------------------------------------------
> 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>