Subject: Comments on Chris's proposed flow and id chasing (was Re: Sanity checkneeded for struggling TPA participant)
I am focusing on the following excerpt from Chris Ferris where he is addressing how to chase ids and links to find what needs to be matched in CPPs when forming CPAs... I have edited and commented on the steps to indicate how I understand them. Please let me know if I have missed something crucial as you see it. (I see Marty also has some other proposals out in this area that are really interesting and I hope to get to them later today) <ChrisFerris> <someEdits> One side [party A] picks the CP and Role within that they want to use to create a CPA with another party. The rest is figured out as follows: 1.examine the BPM pointed to by CP 2.get list of Roles [from the BPM] 3.XOR selected Role [of party A] with list of Roles in BPM 4.identify Role(s) in CPP of Party B that match <alternativeToBeDiscussedStartsHere> 5.find CP in Party B's CPP that matches (so we have ID) 6.for each Role, select ServiceBinding that has IDREF matching ID above 7.find matching DeliveryChannel (default) for Party B's ServiceBinding </alternativeToBeDiscussedStartsHere> <assumedDoable> compare characteristics of Party B's DeliveryChannel with Characteristics of Party A's DeliveryChannel for a possible match </assumedDoable. </someEdits> </ChrisFerris> Chris, I am not certain that I find steps 5 through 7 satisfyingly simple (tm) I would like to proceed to step 4 and then proceed as follows: 5. Using roleIds found in step 4, go to new association elements <Implementation>, which contains attributes (serving as foreign keys) of roleids and channelids. Look for the roleid in the implemtations, and using the channelids get the delivery channels. From there we are off and running. 8 and 9 as before. Why do I like this better than what you have in 5 to 7? For starters, I am very wary of trusting too much in the ServiceBinding values. What really do those values tell us about the scope of the BP actions? If this were RosettaNet, and each PIP had a separate value referenced in the Servicebinding, I would then have one clear picture of the scope of my BP reference (really just a simple request-response action, usually). But if the binding points to the RegistryServices DTD for example, then a whole lot of request/response pairs (having different security requirements at least) are pointed to. It is outside of our scope to mandate what these items pointed at in the servicebindings really amount to in terms of messaging granularity at the implementation level. Because of this, I feel uncomfortable trusting that "the right thing" will happen with these pointers and their values. If I can use an analogy from what UDDI has done with their "green pages," they just check on some 'tmodel' element that apparently points to a protocol specification URI. Clearly the grainsize in that approach is not fine enough to support the granularity over BP technology details that we are trying to specify that support formation of interoperable agreements over implementation details.
eList eXpress LLC