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:yossi.tamari@sap.com]
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:andre.kramer@eu.citrix.com]
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:yossi.tamari@sap.com]
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:andre.kramer@eu.citrix.com]
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:yossi.tamari@sap.com]
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:yossi.tamari@sap.com]
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:andre.kramer@eu.citrix.com]
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:yossi.tamari@sap.com
<mailto:yossi.tamari@sap.com> ]
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:subbu@bea.com <mailto:subbu@bea.com> ]
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:subbu@bea.com <mailto:subbu@bea.com> ]
> 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
<subbu@bea.com>*
> >
> > 07/22/2004 09:41 AM
> >
> >
> > To
>
> Rich Thompson/Watson/IBM@IBMUS
> > cc
>
> interfaces
<wsrp-interfaces@lists.oasis-open.org>
> > 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 <andre.kramer@eu.citrix.com>*
> > >
> > >
07/22/2004 06:45 AM
> > >
> >
>
> > > To
> >
>
"'Michael Freedman'"
<Michael.Freedman@oracle.com>,
> > interfaces
> > >
<wsrp-interfaces@lists.oasis-open.org>
> > > 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:Michael.Freedman@oracle.com
<mailto:Michael.Freedman@oracle.com>
] *
> > > 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-
> >
> >
>