RE: [wsrp-pfb] [UDDI#1] How to represent Producer Service Reference

[Andre Kramer <andre.kramer@eu.citrix.com>]

Title: RE: [wsrp-pfb] [UDDI#1] How to represent Producer Service Reference

Firstly, I would include the possibility of other (unspecified) kinds of producer reference in 3, and not restrict to only producer wsdl reference (which we would not specify after all). If we can name this bigger option "4", then I would go for that and drop 3 altogether.

As I already indicated, this (4) would strongly encourage a producer service key to be used, and the additional complexity would only need to be dealt with when a wsrp consumer goes to use a producer service. It's very much like how we allow a producer to support multiple Web service bindings (SOAP http and https; DIME, SwA etc) via our wsdl.

However, our main difference seems to be on what types of query to support (directly in UDDI, without client side result set filtering). I would say we only need to support "find wsrp portlets and wsrp producers" which one can do using the WSRP_PRODUCER and WSRP_PORTLET tModel keys. Producers are "businesses", as are *portlets*, at the logical level. The fact that portlets are hosted in a producer service may not reflect business level realities (e.g. a portlet hosted by an Application Service Provider (ASP)).

The "find all portlets in a producer service" is thus a second-level implementation question only. However, we may want to support this, and the (1) category based scheme can address this requirement when needed (as Richard & Alan point out). However, I would not mandate it, preferring 2 to 1.

This makes publishing portlets more flexible (and easy via UIs) but requires consumers to discover binding information in the following more complex way:

a) look for producer_service_reference binding template (scheme 2)
b) look for producer_service_reference category information (scheme 1)
c) look for other types of producer reference (4, possibly 3 as first)

For the above, we would not specify (c), only allowing it by use of MAY/SHOULDs and would re-order the document to favour (b/2) over (a/1), which I did not do as I was only enumerating options.

regards,
Andre

-----Original Message-----
From: Richard Jacob [mailto:richard.jacob@de.ibm.com]
Sent: 16 January 2004 17:42
To: wsrp-pfb@lists.oasis-open.org
Subject: [wsrp-pfb] [UDDI#1] How to represent Producer Service Reference

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

To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrp-pfb/members/leave_workgroup.php.