[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 themessageand 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?
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC