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?