ebxml-msg — archive

[System]

Jacques, Please see below. Jacques Durand wrote: > > I believe the notion of "independence" should remain "formal": means > an MSH instance is not required to imperatively access an ebXML CPA > server somewhere, > or is not forced to literally parse a CPA document. This is precisely the case presently. The ebXML Message Specification says nothing about required use of the CPA document at runtime nor has it ever done so to my knowledge. In addition, there isn't described anywhere a notion of a CPA server. How an implementation chooses to store/access the information that is defined in this specification as coming "from the CPA" is completely up to the whim of the implementor. > I think it satisfies the spirit of the charter, the ultimate purpose of > which is > I believe that any MS implementation should be able to work without a > (formally) > CPA-compliant implementation. And, as previously stated, that is just what we have been saying all along. There is nothing to my knowledge in the spec that states otherwise. > > That does not mean an MSH should not use any "CPA-data"... which should > be considered > as MSH configuration data, as Martin suggested. Being able to configure > MSH behavior > at conversation level, not just message level, makes it a much more > reliable/efficient > tool for business, and so it is worth the pain of sorting out the > semantic conflicts > between this configuration data and header data. agreed. > If we don't do it, then each message will have to always carry CPA-data, > and the burden will be on the app to provide it each time. > Plus, in future versions, the MSH will likely be the place where to > enforce CPA data > that is higher level than message: duration of a conversation, max > concurrent conversations... possibly, but again, I see this not as a function of the MSH but of some software that manages the conversation/process somewhere between the application and the msh, which again is just an abstraction that defines the behavior prescribed in this specification. > > Maybe the apparent dependency is mostly editorial. I don't believe so, I believe that this "dependency" is an artifact of myth and legend based upon either misinterpretation, misunderstanding or misrepresentation of document and/or discussion. > we could have abstracted more the notion of CPA in MS spec: We did, possibly not as effectively as we could have. > Just a (late) suggestion: we could have named it "Communication Protocol > COnfiguration" (CPC) What purpose would that have served other than to make things even less clear. > and assume it is no more than a set of attributes associated with each > communicating pair (from/to), and write CPC anywhere we use CPA today. > We could have then a RECOMMENDATION that the CPC content be derived from > a CPA... > So applying a CPA to an MSH is a matter of configuration, in the same > way as applying a > CPA to a lower transport layer is. Again, that is all that it has ever been. Even if a CPA document is used directly, it is likely to be transformed or translated into something that the implementation can use more effectively than if it were to parse the CPA each time a message is processed. See lines 350-356 of the spec. This has been present in the spec for quite some time now. It was first published in draft form back in August [1], and introduced into the spec in v1.02 [2]. I also firmly believe that we have expended WAY too many cycles on this issue. The fact is, and has been for quite some time now, that most electronic business is conducted in the presence of an agreement that is often a legally binding contract between the parties that carries legal remedies for non-compliance with that agreement/contract. The CPA (virtual or physical) is the machine readable representation of the technical terms of that agreement between the parties. The TC voted at the last f2f to agree that for purposes of this specification, that messages exchanged between parties by their respective MSHs were governed by a CPA which represents the technical terms of an agreement between the parties. How the information represented in a given CPA is made known to an MSH at runtime is, and has always been, unspecified by the ebXML Message Service specification. This is, and has always been, (intentionally!) completely up to the implementor to define for themselves. Even if an MSH implementation has hardcoded all of the CPA parameters that the MSH spec identifies as being relevant to its operation, as long as the parties *agree* to that (limited) set of terms, it could be a conformant implementation of this specification. It might not be very agreeable to many prospective partners, but that's a completely different issue. In conclusion, I will add this. The ebXML TR&P team began its work, early on, with a notion of something we were calling, at that time, the TSLA (technical service level agreement), which constituted a set of parameters that were necessary to the runtime execution of the MSH in the context of a given exchange of messages between two parties. This predated IBM's generous contribution of tpaML to the ebXML initiative. Had the IBM contribution not been made, and a separate project team established for the purpose of adapting tpaML to the needs of ebXML as a whole, it is highly likely that the equivalent of what is defined in the ebXML CPP/A spec with regards to the CPA would have been incorporated into the ebXML Message Service specification and this whole issue of "independence" would have been moot. Cheers, Chris [1] http://lists.oasis-open.org/archives/ebxml-msg/200108/msg00330.html [2] http://lists.oasis-open.org/archives/ebxml-msg/200110/msg00002.html > > Jacques > >