Comments on Chris's proposed flow and id chasing (was Re: Sanity checkneeded for struggling TPA participant)

["Moberg, Dale" <Dale_Moberg@stercomm.com>]

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.