OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-pfb message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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 03:06:32 PM:

> 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.

Well what do you mean by fill out? We also have to "fill out" a
businessService structure...
I don't see any additional effort wheter you fill out things here or there.

> 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 don't understand the reasoning here. Even then it would be a Producer or
Portlet.
Aren't that the players we define in a WSRP world?

> 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.

Well, in the real world admins will look for "Portlets" to be integrated
into their portals.
And they might want to search for producers they can browse directly, too.
So I don't see what's artificial there - it's our spec that defined these
players.

Concerning the UIs:
I still don't see why we should base our model on the existing web UIs and
therefor limit ourselver or even contradict UDDI best practices.
*None* of the web UIs out there implements the whole UDDI API spec as of
today!
I'm still convinced that there will be tooling.
Publishing a Portlet will be a one-click-action from an admin. No one will
really want to fiddle around with UIs entering tModel keys...

> If we moved to categories, I would make the "WSRP category" optional
> and still guide binding details solely through binding tModel
> information.

But didn't you propose to have a binding- and version-agnostic means to
find Producers or Portlets.
I think this is one of our use cases: "Find all Producers - no matter what
bindings they implement, no matter what version, etc.".
We'll loose that if we make the tagging optional.

> 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?

No that's correct. I think it's more a conceptual level here.
The question here is: Is a Producer/Portlet a service categorization or
binding information?
For me it's a categorization.
In principle I could live with what we have currently (we took approach 2
of the straw man after first discussions).
But we have also to think of the UDDI principles and best practices, too.
And since we want to have also an approval of the UDDI TC, I would
recommend us to use their expertise.

cheers
Richard



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]