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



I see a number of cases for transitioning between Producers:
  1. Producer upgrades the vendor software version it has deployed: I would expect this to be invisible to the Consumer even though it likely means the interactions move to a machine at a different ip address (i.e. the Producer should fully manage the transition though it may inform its users).
  2. Staged environments: One example is the Consumer switching from using a "test" Producer to the "production" Producer. This switch may involve different vendor software versions and different Portlet versions. This case may have a good degree of sharing of metadata between the two Producers, but all the metadata items are subject to change.
  3. Different Partner: This case occurs in situations such as a competitor to the Producer offering better terms and the Consumer decides to switch. There are several subcases:
  1. New partner offers the same Producer vendor/version and Portlets as the original Producer
  2. New partner offers the same Producer vendor/version with an equivalent, but not identical, set of Portlets
  3. New partner uses a different Producer vendor/version with original set of Portlets deployed
  4. New partner uses a different Producer vendor/version with an equivalent, but not identical, set of Portlets

I think the export/import scenario is targeted at cases 2, 3.a and 3.c.

Cases 3.b and 3.d almost certainly will require quite a bit of work by the page designers at the Consumer to recover to its previous state.

It sounds like you are trying to enhance the ability of the Consumer software to reduce the effort for cases 2, 3.a and 3.c when at least one of the Producers has chosen to not support this instance of export/import. About all the Consumer software has to help reduce the effort is the Portlet metadata and all of it is subject to change, particularly if different versions of the Portlets are deployed.

Does this capture the cases you are thinking of? If so, how does encouraging portletHandles to be UIDs enhance the metadata matching?

Rich



Michael Freedman <michael.freedman@oracle.com>

04/07/05 12:26 PM

To
wsrp <wsrp@lists.oasis-open.org>
cc
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
>
>



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