Here is a comparison I already attempted. It
aims to measure fit with various qualities of the factory "cloning"
operation(s):
export/import
copyPortlets
Privacy/security
-
+ (no data export possible, not modifiable externally)
Reliability -
+ (an atomic operation, no hidden state)
Bounded size
-
+
Lifetime scoped
- (could be fixed)
+
Multiple imports
+
? (extra 1.0 registrations or clones required.)
Cross-producer
? (same vendor?)
- (far-fetched but possible)
Then we have modularity, re-use and clarity
and encapsulation to consider. The danger I see is that we have no clear direct
use case for "exporting portlet data/state", as it seems we only really
seem to need multiple clones, but could end up with a consumer facing API that allows
and suggests it.
Regards,
Andre
From: Rich Thompson
[mailto:richt2@us.ibm.com]
Sent: 26 July 2004 15:53
To: interfaces
Subject: RE: [wsrp-interfaces] New
Import Export document
Regardless of the syntax, we are designing an
additional Factory for cloning portlets. By definition, this will always
produce new clones, even if the operation (either import or copyPortlet) is
being run a second time. By definition these are all single Producer focused.
Both proposals give the Consumer the control to decide which portlets are being
cloned when invoking the Factory. Both proposals allow the Producer/Portlet to
push opaque data to the Consumer and the Consumer is unable to manipulate this
data in either case.
I'm
not willing to throw out a use case the TC has accepted simply because doing so
allows a single operation solution over a dual operation solution. With both
use cases in front of us, I also would not want to design separate solutions
unless it introduced significant complexity to cover them both in a single
solution.
I'm
thinking what would be beneficial is a tabular review of the two proposals that
captures pros and cons on various points as this allows a side by side
comparison. Mike, are you willing to add Andre's proposal and such a table to
the Feature Proposal? The SC/TC can then be the debating/resolving point for
the table's contents. Initial rows should include:
-
Can capture a snapshot of a portlet's state
-
Other Consumers able to access snapshot
-
Able to create multiple equivalent portlets from a snapshot
-
Both Consumer and Producer able to clean-up any stored data
-
Able to support Portlet hierarchy proposal
-
???
Rich
|
Andre Kramer
<andre.kramer@eu.citrix.com>
07/26/2004 10:02 AM
|
|
To
|
interfaces
<wsrp-interfaces@lists.oasis-open.org>
|
|
cc
|
|
|
Subject
|
RE: [wsrp-interfaces] New Import Export
document
|
|
In the end, I suppose I don't see any real need
to export portlet data to a consumer in an inter-operable manner. It always
seems to throw back to some limitations on what one can do with the
"data". Can one import it into another producer? Is importing it
multiple times possible? Does a second import overwrite changes? Can one
(re)import individual portlets? At any future time?
I still think an explicit copyPortlet by reference model is
cleaner for the straight forward use cases (i.e. the first of our two use
cases) and new registrations and cloning portlets (all WSRP 1.0) could be used
to model more complex consumer/producer relationships.
Regards,
Andre
From: Rich Thompson
[mailto:richt2@us.ibm.com]
Sent: 26 July 2004 13:46
To: interfaces
Subject: RE: [wsrp-interfaces] New Import Export document
I guess I am fundamentally missing something. As I understand things, the
copyPortlets idea appears to encourage this factory sequence to occur by
producing a reference, but does support actually exporting the state (i.e. push
it to the Consumer) while the export/import idea, which appears to encourage
the sequence to occur by exporting state, also supports just producing a
reference. I don't see any validity to an argument about which of these two is
better in this area.
What I do see is other pros/cons to the two proposals regarding breadth of use
cases addressed. Why would we choose addressing a very limited set of use cases
when we also have a proposal that addresses a broader set of use cases without
a significant step up in complexity?
As to whether either of the proposals is complete as now stated ... I am pretty
sure that once we settle on a direction we will find various tweaks to finish
filling out the details of the chosen solution.
Rich
|
Andre Kramer
<andre.kramer@eu.citrix.com>
07/26/2004 07:46 AM
|
|
To
|
interfaces
<wsrp-interfaces@lists.oasis-open.org>
|
|
cc
|
|
|
Subject
|
RE: [wsrp-interfaces] New Import Export
document
|
|
Right, the use case explicitly does not require passing data through the
consumer. In fact, I'm arguing that it must not require data to be passed
through the consumer. This allows a real-world "no data will be exported
in any form" requirement to be asserted. This rules out the technical
option of encrypting the data.
The technical option of passing "by reference" is currently ruled out
by the lack of lifetime scoping on the export/import. Data can not be
held indefinitely by the producer (the Union)
just so that it can be imported or re-imported at some arbitrary later time. A
releaseExportedState(), called by the consumer, would address this (as would a
one-time only import / possibly with use-by data).
But copyPortlets() solves the use case much more simply (for me) as it is easy
to show that no data has passed through the consumer (only handles). How does
the producer know when to export encrypted state and when to export by
reference? Seems we are tying to address two use cases with one mechanism.
Regards,
Andre
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: 26 July 2004 12:13
To: interfaces
Subject: RE: [wsrp-interfaces] New Import Export document
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
<andre.kramer@eu.citrix.com>
07/26/2004 05:35 AM
|
|
To
|
interfaces <wsrp-interfaces@lists.oasis-open.org>
|
|
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: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-
> >
> >
>