[UDDI#1] How to represent Producer Service Reference

["Richard Jacob" <richard.jacob@de.ibm.com>]

We discussed different methods on how to represent a reference from the
Portlet to its hosting Producer.
Following has been put on the table yet.

1. use a categorization scheme
The Portlets businessService refers to a "Producer Service Reference"
tModel in its categoryBag, the keyValue holds the UUID of the Producer's
businessService in the registry.
See technote 5.3.1

2. use a binding template
The Portlet businessService contains an additional bindingTemplate with a
reference to the "Producer Service Reference" tModel, the access point
value holds the Producer's businessService UUID in the registry
See technote 5.3.3

3. Portlet businessService provides directly the Producer WSDL
Not discussed yet the details, but basicly would end up in an addition
bindingTemplate, with access point holding the WSDL location.

Additional discussion is centered around whether we want to allow for
multiple methods or concentrate on one.

First I would like to start by repeating my argument from the other
threads.
In general my opinion is that we should to establish only one way for the
representation of the reference.
I see the following reasons here:
Firstly by makeing things more complicated we raise the barrier for
implementors of the search funcionality.
Basicly when having Portlets published in different allowed ways we would
end up in the need for products which want to support their users with UDDI
search functionality to to a programmatical maintainance of result sets,
i.e.
the set of Portlets found by using method 1 needs to be merged with the set
found using method 2 (or 3,4...). It should remain the repositories domain
to deliver only one set so applications can pass it directly to the
enduser, i.e. we need to make sure that we disconnect data management and
programm logic.
Furthermore having multiple methods means also to have multiple queries
against the directory while in essence searching for one result set.
Secondly even if this can be done programmatically we also want to think of
users using the standard UDDI UIs (not using product's search facilities).
Here the users would have to manually merge the results sets which seem
cumbersome to me. Remember that we discuss the introduction of additional
methods because option 1. does not allow UI usage in some cases (some UIs
do not allow to enter the data needed to implement scheme 1). I was able to
use the SAP UDDI test registry UI to implement the scheme, while I was not
able to enter the data necessary in IBM's and Microsoft's UDDI UIs.
I would also question whether it makes sense to limit ourselves because of
UI limitations.
Thirdly making things more complicated might reduce acceptance of both
programmers and end users.

Let's look at two relevant use cases and the methods we have currently:
1. search for portlet(s), find producer hosting it/them, bind...
This is possible with approach 1. and 2. because a search for Portlets
would be basically a search for businessServices referring to the
WSRP_PORTLET tModel.
The question how best to obtain the reference to the Producer's
businessService can be left out here. It is clear that 1. and 2. both allow
it in a quite easy way.

2. search for Portlets that are hosted by a specific Producer
This is possible with scheme 1., here categorization can be utilized and
the Producer's businessService key can be set to limit the search result to
those Portlets which reference that particular Producer.
I was able to test this scenario with the SAP UDDI test registry UI, while
I was not for the IBM and MS registry for the given reasons.
With scheme 2. it is not possible to discover this relation since the
inquiry API does not allow to search for businessServices whose
bindingTemplate contains a particular value in its access point element.

In principle I could happily go either for scheme 1. or 2. depending on the
use cases we consider important. However use case 2. seems to me to be a
valid question and worth targeting a solution which answers that question.
For reasons of referencial integrity I would also discourage us to refer to
the Producer by holding the WSDL of the Producer in each Portlet's
datastructures.

Mit freundlichen Gruessen / best regards,

        Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
Phone: ++49 7031 16-3469  -  Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com