[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: MSG and CPPA modularity and the SyncReply issue
David Fischer says: "How can SyncReply be used without a CPA?" Dale Moberg replies: Using CPPs and CPAs pertains to a way of publishing, discovering, negotiating and exchanging information for setting up BP collaborations. The contents of these infosets are determined by what parameters should be publicized, and what parameters need values settled, in order to implement a given BP among the participants. The MSG spec contains assumptions about what a MSH needs to have in the way of configuration information for its interface with the other participants for given BPs. These include security parameters, URLs, and so on. These assumptions are part of the MSG spec, not the CPPA spec. (Of course, the CPPA spec pays special attention to assumptions about these elements so that it will at least be able to facilitate exchange of values agreed upon for these for given participants in a given BP.) Now just as you don't have headers about what signature algorithm (RSA-SHA1 for example) is to be used by 2 participants for a PO PO-ACK conversation, you don't necessarily need to have a header saying that the participants conduct this BP using SOAP with attachments over HTTP, and the response comes back on the same connection as the request is sent. Just because a MSG implementation may not export, import, or negotiate CPPs and CPAs, does not mean that the information that would have been in the CPA has to be in the header! We need to understand why it needs to be in the header, when it suffices that the MSH track, for a given receiver, sender, and BP, what transport and security and packaging options are to be applied. I think that you must concede that there will be such information the MSH "knows" and makes use of, so the issue is why the SyncReply info cannot be part of this configuration knowledge and instead needs to be repeated over and over in each header of messages exchanged between receiver and sender... David continues: "I know of several in-work implementations and I don't know of any which are implementing CPPA (I'm sure someone out there must be). This does not mean they won't. CPPA is generally seen as a second level of implementation over Messaging. Messaging is the base. Once Messaging is in place, then we add CPPA, Registries, etc. We have to support non-CPA implementations -- at least for now. (One vendor actually suggested leaving CPAid blank for now since it is not needed -- except that the Schema specifies non-empty-string ;-)" Fine, just make certain that when they build a MSH that they have a place to "look up" the transport and security details for their response that is needed to service the request part of the received BP. They can look this up using any index/key they wish to use, and are not required to use CPAId as either index or primary key. And while they are looking up those details, please ask them to check whether a synchronous mode of reply is there in the details or whether a URI for asynch is there instead!! That is how SyncReply can be done without a CPA!
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC