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

[Michael Freedman <michael.freedman@oracle.com>]

On your concerns:

   1. I guess I disagree.  Import/Export is the solution designed for
      managing the recreation of portlets across registrations within
      the same producer or like producer installations.  It is not
      designed as a solution for consumers to equate the relationship
      between of the common meta data of portlets that have a common
      ancestor.  I.e. Import/Export allows me to end up with a
      reconstituted portlets that have the same state as those from a
      prior export; it does nothing that allows me to understand what
      this portlets meta data is.  Short of having to call
      getPortletDescription for every imported portlet and then matching
      the results against the cache/POP meta data, the consumer is
      stuck.  And that of course assume one style of implementation.  I
      would prefer we separate the discussion of how do consumers
      reconstitute portlets in new deployments from how do consumers
      reassociate its portlets with managed/cached information.  I.e.
      maybe a better/another way to state my use case is that many
      consumers cache portlet meta data.  Commonly this cached data is
      shared by all instances of a portlet with a common POP ancestor. 
      How does the consumer re-establish the relationship to this cache
      when its moving from one registration to another?
   2. Though its unlikely, isn't it valid for a producer to return a
      distinct POP handle for the same POP for each registration?  I am
      merely trying to extend this unlikelyness to use cases that cross
      producer installations.  If its too troublesome for this to be the
      POP handle then we can consider a separate, independent uid field
      in the meta data.  I choose the POP handle because I figured many
      implementations may already not be dynamically generating these.

    -Mike-

Rich Thompson wrote:

>
> I have a couple of concerns with where this seems to be heading:
>
> 1. Import/Export is currently the solution designed for handling such 
> use cases. Introducing a second optional feature to provide 
> work-arounds for when import/export isn't supported seems a bit 
> broken. Even if we do introduce the second approach, this won't 
> address how Consumers might achieve the desired functionality with v1 
> Producers.
>
> 2. Your use case starts out with "By unique I mean that a consumer can 
> use the value of a POP handle to match POPs across registrations", but 
> then you go on to describe a use that crosses Producer boundaries as 
> well as registration boundaries. Wouldn't the cross-Producer usage 
> effectively require the POP handle be assigned by the Portlet when it 
> was packaged for deployment on Producers? If so, I would be concerned 
> about issues with Producer customizations and a lack of tools to bind 
> such an identifier to Portlet packages.
>
> Rich
>
>
> *Michael Freedman <michael.freedman@oracle.com>*
>
> 04/06/05 11:55 AM
>
> 	
> To
> 	wsrp <wsrp@lists.oasis-open.org>
> cc
> 	
> Subject
> 	Re: [wsrp] Rationale for encouraging POP handles be UIDs
>
>
>
> 	
>
>
>
>
>
> Import/Export isn't a required supported feature in WSRP 2.0.  Nor does
> it apply in 1.0.  In its absence consumers will still want to recreate
> the set of portlets that existed in the packaged application; they we
> merely lose the customizations of those portlets.  I.e. they will
> recreate the original portlet on the page from the POP but none of the
> derived portlets that represent further customizations.  In such a
> scenario, the consumer needs a way to reassociate the relationships
> between the portlet, POP and portlet meta data.
>    -Mike-
>
> Rich Thompson wrote:
>
> >
> > This scenario sounds like the reason we introduced a Consumer managed
> > ID in the ImportPortlet data structure. This allows the Consumer to
> > define the key its needs in order to be able to do the disambiguation
> > you outline without relying on Producers to supply portletHandles that
> > can meet all possible Consumer needs.
> >
> > Is there a reason this ID, in a combination with an export/import
> > solution, doesn't meet the need you outline?
> >
> > Rich
> >
> >
> > *Michael Freedman <michael.freedman@oracle.com>*
> >
> > 04/05/05 06:44 PM
> >
> >                  
> > To
> >                  wsrp <wsrp@lists.oasis-open.org>
> > cc
> >                  
> > Subject
> >                  [wsrp] Rationale for encouraging POP handles be UIDs
> >
> >
> >
> >                  
> >
> >
> >
> >
> >
> > I have asked us to strongly suggest/require POP handles be unique.  By
> > unique I mean that a consumer can use the value of a POP handle to match
> > POPs across registrations.  I.e. if two registrations that a consumer
> > thinks are related [i.e. the same type of producer] offers the same POP
> > handle, then the consumer can equate the POP in one registration to the
> > other.
> >
> > Here is the use case/reason why consumers need this 
> support/clarification:
> > Portlets are beginning to move beyond typical usage where they are
> > integrated into a Portal application to being viewed more generally as
> > UI components that can be integrated into any ole web application.  This
> > transformation changes the deployment model considerably.
> >
> > Today many portal style deployments follow a model where the portal
> > product is by and large deployed as a tool.  Developers then use the
> > Portal [tool] to register their content producers, construct their
> > portal application and then publish their portal application to
> > appropriate sites.
> >
> > When portlets are used as UI components in web applications, however,
> > the web application is packaged and deployed not as a tool but a
> > running/working application.  During the development process [of the web
> > application] content producers are registered, portlets included and
> > likely customized.  This application is then packaged into a
> > distributable entity, sometimes with and sometimes without packages
> > representing the producers.  At deployment, the intent is to recreate
> > the application including its connections with its producers/portlets.  
> > Often this later requires some deployment intervention, specifically in
> > the case that the referenced producers are to be migrated to new
> > installations [of that producer].  For example, a packaged application
> > may have a reference to the many portlets its has created from using
> > Producer XXX at location http://yyy [this reference was established in
> > the development environment].  The application is being deployed by a
> > customer who independently installs Producer XXX at location
> > http://zzz.  During the deployment process the deployer is asked if they
> > want to modify the connection information for Producer XXX --  and as a
> > local installation is being used the deployer says yes and changes the
> > URL reference from http://yyy to http://zzz.  Following this, the
> > deployment process auto-egisters the producer [at location http://zzz]
> > using registration information captured when the application was
> > developed, communicates to the new producer to import its portlets and
> > finishes up.
> >
> > 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
>
>