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

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

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