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

[David Fischer <david@drummondgroup.com>]

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>