Re: [wsrp] Rationale for encouraging POP handles be UIDs

[Rich Thompson <richt2@us.ibm.com>]

It would be good to reunify the two
branches of this email thread ....

I can see the value of having a means
by which a Consumer can tell what would be the equivalent Portlet when
it begins using a different Producer. The problem is that the Consumer
only has the PortletDescription (i.e. metadata) to attempt such a determination
and all of the metadata fields are subject to change by the Producer. Recommending
the portletHandle be a UID or even GUID might help for crossing registration
boundaries within a Producer (normally the portletHandle will be invariant
anyway, so this would be a marginal improvement), but would not likely
help when switching Producers. To truly assist the Consumer, invariant
information from the packaging of the Portlet would be required and it
would help if this separately identified the Portlet's version. We could
define such fields in the metadata, but where would the data come from?

Rich

Michael Freedman <michael.freedman@oracle.com>

04/06/05 05:31 PM

To	wsrp <wsrp@lists.oasis-open.org>
cc
Subject	Re: [wsrp] Rationale for encouraging POP handles be UIDs

I don't think its strictly/technically true that the
Consumer see two 
different portlets.  The point of the issue I raised [as Rich has
clarified] is that mapping between two installations of a producer is 
not defined.  Technically speaking the consumer can only approximate
equivalence by comparing values in the meta data including the POP 
handle.  I am suggesting we move towards a more definitive method.
    -Mike-

Subbu Allamaraju wrote:

> Since the Producer chose to return different portletHandles for POPs,
> as far as the Consumer is concerned, there are two different sets
of 
> portlets.
>
> If you are talking about different *versions* of the same portlet,
> unfortunately we don't have any semantics to denote versioning, and
> compatibility guidelines. But it way be worthwhile to pursue that.
>
> But without such facilities, I'm not sure if the Consumer can safely
> assume that the new set of portlets are the same as the old set of
> portlets. That may be a risky thing to do.
>
> Subbu
>
> Michael Freedman wrote:
>
>> Resending to whole list with edited first sentence [so its actually
a
>> sentence]
>>
>> Yes,  that is one manifestation of the scenario.  The
type of situation
>> this may commonly occur in is when the two installations of the
Producer
>> are different versions [of the same producer].  If one version
has
>> removed a portlet from a prior version its conceivable/allowable
for the
>> removed POP handle to be resused.
>>
>> Basically, I am asking us to codify the rules for how a consumer
>> establishes the relationship between the POPs in these two 
>> registrations.
>>      -Mike-
>>
>> Michael Freedman wrote:
>>
>>  > As that is one manifestation of the scenario.  The
type of situation
>>  > this may commonly occur in is when the two installations
of the
>>  > Producer are different versions [of the same producer].
 If one
>>  > version has removed a portlet from a prior version
its
>>  > conceivable/allowable for the removed POP handle to
be resused.  > 
>> Basically, I am asking us to codify the rules for how a consumer
>>  > establishes the relationship between the POPs in these
two 
>> registrations.
>>  >      -Mike-
>>  >
>>  > Subbu Allamaraju wrote:
>>  >
>>  >> Mike,
>>  >>
>>  >> If I understand your use case correctly, the Producer
is offering a
>>  >> new set of POP handles in its service description
upon new
>>  >> registration. I'm not sure why the Producer would
want to assign a
>>  >> new set of portlet handles for each registration
for the *same* set
>>  >> of portlets. But I agree that it is free to do
so.
>>  >>
>>  >> Let's say, originally, the Producer offered portletA.
>>  >>
>>  >> The Consumer stored the metadata of the portlet
some place, and
>>  >> possibly also created CCPs.
>>  >>
>>  >> When the deployed Consumer tries to establish the
registration, 
>> let's
>>  >> say, the Producer offers portletA1 and portletB1.
>>  >>
>>  >> The problem is, how should Consumer guess that
portletA1 and 
>> portletA
>>  >> are the same, and some new portletB1 is not the
same as portletA?
>>  >>
>>  >> Is this the use case?
>>  >>
>>  >> Subbu
>>  >>
>>  >> Michael Freedman wrote:
>>  >>
>>  >>>
>>  >>> So why the need for unique POP handles?  The
answer lies in that 
>> its
>>  >>> reasonable to expect such consumer applications
to manage [its 
>> cache
>>  >>> of]
>>  >>> portlet meta data in an efficient manner by
relying on a single 
>> record
>>  >>> for all the portlets derived from a common
POP.  In such an
>>  >>> implementation, the consumer needs a mechanism
for rewiring these
>>  >>> references when a producer connection is retargeted.
 I.e. at
>>  >>> deployment
>>  >>> a new registration happens resulting in a new
set of POPs and
>>  >>> associated
>>  >>> portlet meta data being read into the application
cache.  The
>>  >>> application now wants to ensure that all its
portlets from that
>>  >>> producer
>>  >>> are properly rewired to point to this new meta
data. Somewhere 
>> along
>>  >>> the
>>  >>> line the consumer is going to need to figure
out how POPs in the
>>  >>> packaged application relate to the POPs in
the actual 
>> deployment. [i.e.
>>  >>> either from the POP point of view to figure
out which meta data 
>> record
>>  >>> this portlet description shoudl overwrite or
from the cloned 
>> portlet
>>  >>> point of view if the cloned portlet indirectly
references its
>>  >>> description via a POP reference/key].  Being
able to rely on the 
>> strong
>>  >>> suggestion/requirement that POeP handles are
unique minimizes th 
>> guess
>>  >>> work involved.  I.e. trying to implement
a heuristic that 
>> matches meta
>>  >>> data values to identify the relationship.
>>  >>>    -Mike-
>>  >>>
>>  >>>
>>  >>>
>>  >>>
>>  >>> 
>> ---------------------------------------------------------------------
>>  >>> To unsubscribe from this mail list, you must
leave the OASIS TC 
>> that
>>  >>> generates this mail.  You may a link to
this group and all your TCs
>>  >>> in OASIS
>>  >>> at:
>>  >>> 
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>  >>>
>>  >>
>>  >>
>>  >> 
>> ---------------------------------------------------------------------
>>  >> To unsubscribe from this mail list, you must leave
the OASIS TC that
>>  >> generates this mail.  You may a link to this
group and all your TCs
>>  >> in OASIS
>>  >> at:
>>  >> 
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>  >
>>  >
>>  >
>>  >
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC
that
>> generates this mail.  You may a link to this group and all
your TCs 
>> in OASIS
>> at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your
TCs in 
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php




---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs
in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php