I don't see how the use case requires
passing of data through the Consumer. The portlet gets to decide what is
bundled into the "exportedState" with the inherent flip side
of being required to process that data when instantiated as a new portlet
later. Whether this is a reference or some opaque (possibly encrypted)
data becomes a portlet decision. Why is this flexibility a bad thing?
Rich
Andre Kramer <>
07/26/2004 05:35 AM
To
interfaces <>
cc
Subject
RE: [wsrp-interfaces] New
Import Export document
I'm asserting that such use
cases exist in the real world. Passing any data, even if encrypted, through
the consumer should not be required for "install" of a portlet
application.
Regards,
Andre
From: Tamari, Yossi [mailto:]
Sent: 26 July 2004 09:36
To: interfaces
Subject: RE: [wsrp-interfaces] New Import Export document
Hi Andre,
I still don't understand what
is the issue with passing the data through the consumer, if it is encrypted
(note that what I mean by encrypted is so that only the producer can decrypt
it, so it is really opaque to the consumer).
Yossi.
From: Andre Kramer [mailto:]
Sent: Monday, July 26, 2004 10:58 AM
To: Tamari, Yossi
Subject: RE: [wsrp-interfaces] New Import Export document
The use case involves a (new)
union member installing the Union's application into her company portal
as a wsrp portlet. My claim was simply that no data should be "imported"
(and exported) through the company portal in the install process even if
encrypted. The details of how the union portlet ended up with state in
the first place was just to prevent any claim of the portlet being a "stateless"
UI tier.
Regards,
Andre
From: Tamari, Yossi [mailto:]
Sent: 25 July 2004 10:29
To: 'interfaces'
Subject: RE: [wsrp-interfaces] New Import Export document
Hi Andre,
I do not understand your final
comment (the Trade Union example). Are you suggesting that the portlet
uses the customization as cache? If this is the case, it should either
encrypt it or make sure it is not exported. Since it is a cache it will
just "refill".
It is true that a portlet can
put anything in the customization information, even an encryption key,
but I think this is misuse.
Anyway, this is a moot point,
since encryption solves the problem.
Yossi.
From: Andre Kramer [mailto:]
Sent: Friday, July 23, 2004 1:19 PM
To: 'interfaces'
Subject: FW: [wsrp-interfaces] New Import Export document
Ooops - I failed to reply to the
list. See comments below.
Regards,
Andre
-----Original Message-----
From: Tamari, Yossi [mailto:]
Sent: 23 July 2004 11:03
To: 'Andre Kramer '
Subject: RE: [wsrp-interfaces] New Import Export document
Hi Andre,
Did you exclude the rest of the
group from your answer intentionally?
<ak>sorry</ak>
The problem with the first solution
you suggest (the consumer releases...) is that in the second use case the
consumer does not necessarilly know when this is the situation, at least
not for a very long time.
By the way, two dangling references
are created here: portlet and registration.
The leasing solution could work
here, but it could also work with Mike's approach. Exported portlets just
become one more leased resource.
I still have some conceptual problems
with leasing in general, though, because it basically says: "things
will stop working, but at least you know when".
I would not be opposed to adding
an optional releaseExportedState, with metadata whether this is really
needed.
in the second use case copyPortlets
is not really atomic, since it needs to be called twice - once on export
to create a snapshot, and once on import to create a new clone. Since the
second could fail (the lease expired?), the probelms are all still there.
<ak> Agree, but the first
use case is covered in one operation. </ak>
The copyPortlets also requires more
from the producer: It can't differntiate between a "frozen" copy
and a "live" one, which prevents it from some serious optimizations
that can be done if you know a portlet is never going to be executed.
In the end, I think the second use
case requires an export/import mechanism. It can be "emulated"
using the copyPortlets operation, but that has no advantage. The advantage
of the export/import operations is that at least in some cases the producer
will want to export the state to the consumer (exportData), and other then
network traffic I see no problem with doing this. The security/privacy
concerns people have been voicing are unbased in my opinion for a number
of reasons:
1. Any user specific info that the
portlet had has first gone, in plain text, through the consumer (this is
how WSRP works), so the user must trust the portal he is using.
2. Usualy exported portlets are
not including personalization, just configuration (the use case document
says so), and this is normally not private info.
3. The producer can very easily
encrypt the data before sending it, at least in the case of one physical
producer, which is the only case copyPortlets works for.
4. The consumer can set up a mechanism
of private/public key encryption to insure only "safe" consumers
will be able to import the package.
<ak> A portlet can compute
and store data based on consumer mediated user info that the consumer should
not see, as it communicates with back-end services. E.g. A worker uses
the company portal to drive a Trade Union Portlet that has a back-channel
to the union database but caches affiliation data in the customization.
One can program portlets to be stateless so that export presents no problems
but do we want to mandate this? Some portlets are just not going to be
exportable. </ak>
Yossi.
-----Original Message-----
From: Andre Kramer
To: Tamari, Yossi
Sent: 7/23/2004 9:43 AM
Subject: RE: [wsrp-interfaces] New Import Export document
The dangling copy you identify should
be deleted by the consumer when
the imports are over.
In the export/import scheme there
is no way to signal to the producer
that no further imports are going to occur. This makes it problematic
for the producer to export state "by reference" (e.g. storing
handles or
a filename in the export blob) as the producer has no way to clean up.
Mike's proposal would be an extension
of copyPortlets if it added a
"releaseExportedState()" operation. But then we still have reliability
problems of potentially failing operations that copyPortlets() does not
have as it is an atomic operation (rather an a separate export and
import operation). Of course, I'm assuming that deleting portlets
reliably will be addressed by Leasing so there are no dangling (portlet)
copies!
Regards,
Andre
_____
From: Tamari, Yossi [mailto:]
Sent: 22 July 2004 18:13
To: interfaces
Subject: RE: [wsrp-interfaces] New Import Export document
The problem you seem to be ignoring
is the second use case, of exporting
once and importing multiple times. The way to solve this with
copyPortlets is:
The exporting consumer clones the
portlet on export, and then the
importing consumer clones again on import. But then we have the
"dangling" copy, which we can't delete, since it may be imported
again,
and the leak is the same as in Mike's proposal if exportData is used to
store the handle.
The point I am trying to make is
that Mike's proposal is an extension of
copyPortlets, with no extra cost, but with more flexibility.
Yossi.
_____
From: Andre Kramer [mailto:]
Sent: Thursday, July 22, 2004 8:05 PM
To: interfaces
Subject: RE: [wsrp-interfaces] New Import Export document
A clone of the portlets to "freeze"
them perhaps? (either within a
registration or to a new registration).
Regards,
Andre
-----Original Message-----
From: Tamari, Yossi [ mailto:
<mailto:>
]
Sent: 22 July 2004 17:02
To: interfaces
Subject: RE: [wsrp-interfaces] New Import Export document
But is the state still the same
as it was when copyPortlets first
called? How do you do this?
Yossi.
-----Original Message-----
From: Subbu Allamaraju [ mailto:
<mailto:>
]
Sent: Thursday, July 22, 2004 6:42 PM
To: interfaces
Subject: Re: [wsrp-interfaces] New Import Export document
I think copyPortlets() is replayable
as long as the source registration
is still valid and the source portlets are valid in that registration.
Subbu
Tamari, Yossi wrote:
> Hi Subbu,
>
> I think the use case document talks only about b. (quote: "the
above
> scenario assumes that each consumer environment [development, stage,
> production] is talking to the same physical producer").
>
> However, the second use case is not supported by the copyPortlets
> operation, if I understand the operation correctly, since the import
> operation should be "replayable", so one export should create
a
> "package" that can be imported many times at other consumers.
>
> Yossi.
>
>
> -----Original Message-----
> From: Subbu Allamaraju [ mailto:
<mailto:>
]
> Sent: Thursday, July 22, 2004
5:57 PM
> To: interfaces
> Subject: Re: [wsrp-interfaces] New Import Export document
>
> In the use cases document, I think we need to clearly distinguish
> between consumer-side migration issues from producer-side migration
issues.
>
> a. A Consumer customized some portlets of Producer. Producer is going
> from staging to production, while Consumer remains the same. There
is
a
> need to move portlet customizations across the Producers.
>
> b. The Consumer is moving from staging to production, while the
Producer
> remains the same. In this case, the new Consumer wants to retain the
> same portlet customizations in a new registration context.
>
> If we are talking about (b), it is still not clear why a
copyPortlets()
> like operation would not address it.
>
> Subbu
>
>
> Rich Thompson wrote:
>
> >
> > I agree that the burden of transferring portlets from one
registration
> > to another belongs at the Producer. I'm not sure what about
the
> > export/import proposal changes that. If it relates to the
use of a
POP
> > handle on the import, I actually disagree that the Consumer
should
need
> > to do that dereference ... it ought to be the portletHandle
> > corresponding to the exportedState.
> >
> > As to the use cases (see
> >
>
http://www.oasis-open.org/apps/org/workgroup/wsrp-interfaces/download.ph
p/5614/Portlet%20Transport.htm
<http://www.oasis-open.org/apps/org/workgroup/wsrp-interfaces/download.p
hp/5614/Portlet%20Transport.htm> )
>
> > that seem to favor an approach that captures a snapshot
of a
portlet's
> > state:
> > - Use case #1 refers to capturing a snapshot of a development
system
> > that is then pushed to the production system while development
> > continues. I think it unreasonable to require the development
system to
> > remain static for whatever duration is involved in deploying
the
> > snapshot on however many production systems it impacts.
> > - Use case #2 makes snapshots even more important as the
timing for
> > deployment of the
new Consumer in unknown. Certainly development
wants
> > to continue on these systems as well.
> >
> > That said, import/export is not the only way to capture
a snapshot.
> > However, it is important
that the solution we develop support the
> > underlying use cases.
> >
> > Rich
> >
> >
> > *Subbu Allamaraju <>*
> >
> > 07/22/2004 09:41 AM
> >
> >
> > To
> > Rich Thompson/Watson/IBM@IBMUS
> > cc
> > interfaces <>
> > Subject
> > Re: [wsrp-interfaces] New Import Export
document
> >
> >
> >
> >
> >
> >
> >
> >
> > I agree with Andre's suggestions, as it correctly puts
the burden
on the
> > producer to transfer portlets from one registration context
another
> > another without
exposing any state.
> >
> > > The main difference I see between such an operation
and the
proposed
> > > export/import is that the operation references
the current state
of a
> > > portlet while export/import proposal captures
a snapshot and
then
> looks
> > > to recreate it. For some of the use cases, I
think this is an
> important
> > > difference.
> >
> > Could you elaborate this in the context of the use case?
The use
case is
> > about letting certain customized portlets be used from
another
consumer.
> > Import/export may be one particular way of solving it,
but not the
only
> > option, I think.
> >
> > > I would suggest we not get involved in scenarios
involving a
> migration
> > > of the Producer as well. How would a Consumer,
in general, learn
the
> > > following scenario relative to Portlets exported
from Producer1:
> > > - PortletA
may be imported to Producer 2, but not Producer3
> > > - PortletB may be imported to Producer3, but
not Producer2
> > > - None of the exported portlets may be imported
to ProducerN
> >
> > Have we captured these with our use cases for this problem?
> > Cross-producer import/export seems to be a new use case
not
discussed so
> > far.
> >
> > > With the opaque nature of exportedState, Producers
can easily
store
> > > enough information to allow automation of such
cross-Producer
(same
> > > vendor implementation) imports. Out-of-band
communication to the
> > > Consumer
of which portlets a different Producer is able to
import
> seems
> > > appropriate for our protocol (at least until
other deployment
> protocols
> > > get defined that we could leverage).
> > >
> > > Rich
> > >
> > >
> > > *Andre Kramer <>*
> > >
> > > 07/22/2004 06:45 AM
> > >
> > >
> > > To
> > >
"'Michael Freedman'"
<>,
> > interfaces
> > > <>
> > > cc
> > >
> > > Subject
> > >
RE: [wsrp-interfaces] New Import Export
document
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > As Exporting / Importing state has privacy and
reliability
issues,
> how
> > > far would the following operation go in covering
the use cases?
> > >
> > > PortletHandle newHandle = copyPortlet(PortletHandle
thePortlet,
> > > RegistrationHandle fromRegistration, RegistrationHandle
> toRegistration);
> > >
> > > This would normally be called by a wsrp consumer
(e.g. when a
staged
> > > deployment goes live). I've purposely not included
our
> portletState to
> > > show that no data need be passed outside of
the producer(s). Two
> > > producers
could pass portlet data between themselves (using a
> > > proprietary API or the proposed Export/Import
mechanism) if the
> > > registrations are on different producers.
> > >
> > > Regards,
> > > Andre
> > >
> > >
> > >
>
------------------------------------------------------------------------
> > >
> > > *From:* Michael Freedman [ mailto:
<mailto:>
] *
> > > Sent:* 22 July 2004 01:46*
> > > To:* interfaces*
> > > Subject:* [wsrp-interfaces] New Import Export
document
> > >
> > > I have rewritten the original strawman to define
specific
> import/export
> > > methods. It has been _uploaded to the
Interfaces documents_
> > >
> >
> <
http://www.oasis-open.org/apps/org/workgroup/wsrp-interfaces/download.ph
p/7861/Import_Export2.html
<http://www.oasis-open.org/apps/org/workgroup/wsrp-interfaces/download.p
hp/7861/Import_Export2.html> >.
>
> >
> > > If you want to refer to the old version
click on "Manage" to
the far
> > > right of the document entry. This takes
you to a page where you
> can see
> > > the previous revision(s).
> > > -Mike-
> >
> >
>
