[no subject]

I used this scheme because it gives us the "back reference", i.e. the
possibility to search for Portlets published by a given Producer, which we
would loose using a bindingTemplate.

>
> But we (seem to) have ruled out using extra "uddi:instanceDetails"
> in tModelInstanceDetails as its not well supported.
correct, the intent was: make it simple.
However if we find a better way by using them and can convice people, I'd
say: why not?
But you are correct: they are not well supported, especially in the web UIs
to make the loop again...

> Instead, a full
> (additional) bindingTemplate can be used to hold the service key for
> the producer Web service as a binding access point.
Agree, but this is also a "free interpretation" of concepts.
Idealy we would have only one bindingTemplate, simple because a
bindingTemplate is defining "a particular binding to a service".
However we enforce by our convention that both bindingTemplates must be
processed to obtain *one* required information: the PortletAddress.
One could see the "PortletAddress" as the combination of: Producer+Handle.

Thinking loud: Onother option could be to artificialy build an portlet
accessPoint as:
<PortletAccessPoint>
  <ProducerRef>
    producer's service key comes in here
  </ProducerRef>
  <PortletHandle>
    and this is the handle
  </PortletHandle>
</PortletAccessPoint>

One could then use this XML to be put in the accessPoint element of the
bindingTemplate.
Sounds funny but seems to be possible, too. And we would only require one
bindingTemplate, i.e. one tModel less.
But we would loose the "Portlets of an given Producer" search capability.

> That the best I was able to come up with :-(
me, too :-((

cheers,
Richard