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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

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


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


When you and Subbu talk about switching Producers aer you talking about 
the general problem where a customer switches between two independent 
producers that don't have a common origin?  Or are you talking about the 
more limited problem where the producers are related by a common 
origin?  I.e. Its the same producer implemented by the same company 
installed in two locations [the only difference being they may be 
different versions]?  To be clear I am not concerned about the first 
situation as I think is uncommon.  I agree with Subbu that in that 
situation you can be forced to rely on out-of-band means to establish 
the relationship.  I am concerned about the "versioning" case.  And 
maybe that is how we should focus on this problem:  "How does a consumer 
reestablish the relationship to its cached meta data/portlets when the 
producer version changes?"  I.e. this problem technically exists within 
a given consumer/producer registration across meta data changes.
     -Mike-

Rich Thompson wrote:

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




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