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