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
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrp <wsrp@lists.oasis-open.org>
- Date: Thu, 7 Apr 2005 13:43:03 -0400
I see a number of cases for transitioning
between Producers:
- 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).
- 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.
- 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:
- New partner offers the same
Producer vendor/version and Portlets as the original Producer
- New partner offers the same
Producer vendor/version with an equivalent, but not identical, set of Portlets
- New partner uses a different
Producer vendor/version with original set of Portlets deployed
- 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]