[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: POC question for CPP-CPA possibly for Vienna agenda
Dale, 1. Service element I agree that we have a mismatch with TRP. We will need to discuss this in Vienna (and we will need Chris for this one). I don't think the answer is that the value of the CPA's name attribute should be the value of the TRP's type attribute because that still leaves the question of what to do with the value of the TRP service element. I think that we have two choices: 1. Specify that the value of the Name attribute SHALL be a URI. 2. Add an additional IMPLIED attribute for service type and repeat the TRP rules about when the type attribute is needed. We could go a step further and make it exactly like TRP (Service element as child of ServiceBinding and type attribute of Service). This is probably preferred since it is in the spirit of using the same XML grammar in both specs. I suggest that the POC assume choice (1) and implement accordingly. This should work regardless of our final decision. 2. Action element We resolved the Action element definition in ver. 0.96 after Chris and Karsten finally intersected last week and resolved some of the open questions in TP-BP synchronization. In short, Override identifies a delivery channel to be used for messages received from the business transaction identified by the Action element. Note that this is a TP-BP question, not a TP-TRP question. You will see the fix in the version I distributed yesterday afternoon but here it is. 7.5.7 Override element The Override element provides a Party with the ability to map, or bind, a different DeliveryChannel to Messages of a selected Business Transaction that are to be received by the Party within the context of the parent ServiceBinding element. ...(stuff ommitted here) 22.214.171.124 action attribute The REQUIRED action attribute is a string that identifies the Business Transaction that is to be associated with the DeliveryChannel that is identified by the channelId attribute. The value of the action attribute MUST match the value of the Name attribute of the desired BusinessTransaction element in the Process-Specification document that is referenced by the ProcessSpecification element. I don't believe that our definition is at odds with the definition of Action in TRP; both ours and TRP's are really the same animal. CPA optionally specifies a delivery channel to be used with a particular business transaction (Action). When the application sends a message, it supplies the name of what TRP calls the process within a Service. If the service is defined by the BP Specification Schema, then I think that Service is the name of the applicable Binary Collaboration and Action is the name of the Business Transaction within that Binary Collaboration. Regarding your final questions, I believe that both TP and TRP are OK though perhaps TRP should have some words pinning down service and action to BPSS constructs. However TRP has been even harder-nosed than our team about avoiding any appearance of dependencies between TRP and TP/BP. In any case, I believe that the semantics are simply that a message is from a process within a service and is routed to a process within a service. We (TP) might want to add a statement that when the BPSS provides the Process Specification document, the Service is the Binary Collaboration. Then again may be it's better to leave it loose. As to the agreement being or not being reflected in the CPA, the agreement IS reflected in the CPA, indirectly, by the agreement to use the same Process Specification document. The contents of that document are as much a part of the agreement as the base CPA is. I suspect that most of your problem here is caused by our taking until ver. 0.96 to finally resolve the semantics of Action. Look over the material in 0.96 and see if you agree. I will add this topic to our agenda. Regards, Marty ************************************************************************************* Martin W. Sachs IBM T. J. Watson Research Center P. O. B. 704 Yorktown Hts, NY 10598 914-784-7287; IBM tie line 863-7287 Notes address: Martin W Sachs/Watson/IBM Internet address: mwsachs @ us.ibm.com ************************************************************************************* "Dale Moberg" <firstname.lastname@example.org> on 05/03/2001 08:55:15 AM To: Martin W Sachs/Watson/IBM@IBMUS cc: Subject: POC question for CPP-CPA possibly for Vienna agenda Hi Marty, I have been wearing my developer hat the last 1.5 weeks for the Vienna POC. While most issues pertain to TRP, one or two pertain to CPA 0.95. While writing xslt code for CPA to ebXML header population, (or equivalently, for MSH DB configuration), I discovered possible issues. Maybe I have missed something but here they are: 1. The TRP group says that its Service element is a URI when the type attribute is missing, but is some string when the type attribute is used that reflects a bilateral agreement (section 8.4.4 and 126.96.36.199). TPA says (188.8.131.52) that the value is a string. If the string is not syntactically well-formed as a URI, a type value must be used. What would be useful is a convention for indicating that the CPA-specified service string is an agreed upon value for the ebXML header Service element's type attribute. In other words, something like: uri:www.ebxml.org/CPP-CPA could be the value for the type attribute when the service string is not syntactically a URI. While the missing convention may not strictly be a defect, it does make interoperability dicier partly because TRP asserts: If it is not a URI and no type attribute is present, the MSH has to emit an error response. Implementationally, one needs a basis for deciding whether to add a type value or not-- and a URI syntax check can do that. Then if not a URI, add a type specifier. While there is no way to anticipate all possible extensions here, we can at least specify how the one established extension mechanism (CPA) is indicated. Comments? 2. I have lost track of where the value for the TRP Action element comes from. There is no place in the CPA where we connect the Action value of TRP with anything in the CPA. (unlike the Service element) Nor have I found anything in the BPSS that is referenced by the CPA that clearly provides this value. Like the previous issue, this is a system coherence issue that stradles TRP,TPA and BP. Could you update me on what has happened to the Action value? TRP is pretty vague about it in 98b and 99. We seem to omit saying where it can be specified. Have we decided that CPAs pertain to _any_ action within the same service? (Nothing necessarily wrong with that but it might help MSH implementers if that were stated explicitly.) What is the action value doing? Will all actions within a service be routed to/from its "consuming/generating application" the same way? I believe we are not providing a clear semantics for the action value within the overall ebXML architecture at present. If we can't say how it is used and what difference it makes, maybe it should go? If we say that it is bilaterally agreed upon, then that agreement is not reflected within the CPA except possibly through some pointer off to BPSS. Are we confident that TRP,TPA,and BP have congruent and compatible presumptions about the Action element's semantics?
Powered by eList eXpress LLC