RE: [wsrp-pfb] [UDDI #4] WSRP_v1_Bindings tModel equals WSRP_Produc ertModel?

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

Title: RE: [wsrp-pfb] [UDDI #4] WSRP_v1_Bindings tModel equals WSRP_Produc ertModel?

As we already have to fill out a binding template to publish our services, I would just use these extra tModel (Producer or Portlet) as a tag to help locate bindings for WSRP services.

I view the producer / portlet as a somewhat artificial implementation distinction (WSRP could have gone for more independent Web Services or even Grid Services), but one that is version independent, and do not think it makes a particular good candidate for categorization. I may be unduly influenced by my experience of categories as being something defined through real world (non-software) bodies and maintained by registry admins and by their lack of good UI support.

If we moved to categories, I would make the "WSRP category" optional and still guide binding details solely through binding tModel information. One (or two for Portlets ;-( binding infos details should be all that is needed to publish/bind to a portlet.

So I would prefer :

1) extra tModel on binding details (what we have now: WSRP_PRODUCER and WSRP_V1_BINDINGS tModels)
2) just one tModel (the WSRP_V1_(WSDL_)Bindings) we discussed yesterday
3) the previous with WSRP as a Producer/Portlet category (optional)

but that's just my preference,

UDDI seems to have good support for multiple (implementation detail) level tModels on a single binding or am I missing some other things categories would allow us to do?

regards,
Andre

-----Original Message-----
From: Richard Jacob [mailto:richard.jacob@de.ibm.com]
Sent: 22 January 2004 13:28
To: Andre Kramer
Cc: wsrp-pfb@lists.oasis-open.org
Subject: RE: [wsrp-pfb] [UDDI #4] WSRP_v1_Bindings tModel equals
WSRP_Produc ertModel?

Andre Kramer <andre.kramer@eu.citrix.com> wrote on 01/22/2004 09:56:46 AM:

> -----Original Message-----
> From: Richard Jacob [mailto:richard.jacob@de.ibm.com]
> Sent: 21 January 2004 17:57

> > Also requiring the more abstract WSRP_Producer implies that we will
> > have other specification versions and other ways to select protocol
> > bindings in future (new best practice).
> right, but this would be the same without the Producer tModel.
> However I see (and that's why it already in the tech note) that by having

> th WSRP_Producer tModel we have a version and description method agnostic

> means to find Producers (search for WSRP_Producer tModels). Otherwise we
> would require an explicit "OR" when searching (once we have multiple
> versions).

And again I was thinking over what has been said about the version- and
binding-agnostic search of Producer and Portlets.
Basically by talking about binding-agnostic ways in essence we talk about
categorization of a service!
We don't provide any binding information by saying: "this is a WSRP
Producer" or "this is a WSRP Portlet".
Rather than this we catgegorize the service as being a WSRP
Producer/Portlet.

I had a talk today with Klaus von Riegen (UDDI TC, SAP).
His comment about that was indeed the same (even when he was not following
this thread but reviewing our tech note).
Klaus stated (please correct me if I'm wrong, Klaus), that the UDDI
TC/experts would only see that Producer/Portlet tagging as a categorization
scheme rather than a binding.
He suggested to use a taxonomy model where keyValues hold the type of
service like Producer or Portlet.

This brings me back to my first technote from april (
http://www.oasis-open.org/apps/org/workgroup/wsrp/wsrp-pfb/download.php/1595/wsrp-jacob-uddi-proposal-draft-03.pdf)

and our stawman, approach 1.
Here we define a "WSRP Service Type" tModel, which is a categorization
tModel (name to be discussed).
This tModel would be referenced in the service's categoryBag, and the
keyValue would be allowed to contain the values "Producer" or "Portlet".
By doing this we have an easy, version- and binding-agnostic means to
search for Producers/Portlets.
For todays Portlet binding information, we provide the Handle(+Producer
Reference, still argueing how to do that best).
This means that out current "WSRP_Portlet" tModel would mutate to
"WSRP_Portlet_Handle" (or whatever) tModel.
It would be referenced by the bindingTemplate. The indication here is: "The
bindingTemplate provides a Portlet Handle in the accessPoint".

This would also allow us to introduce different binding information by the
time.
For example, we have been thinking loud in the last F2F that later on, we
might want to express Portlets in WSDL.
Then we could easily add a new bindingTemplate indicating such a use.

Any opinions?

cheers
Richard