OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [wsia] [wsrp] [wsrp-wsia joint interfaces] Merged interfacesdocument


Rich,

Ultimately I believe the producer is in charge, as it needs to defend 
against consumers who hold many "temporary" objects over long periods. 
I've not caught up with all the email discussion on this topic but can 
see one possible use case for transients (a sort of stateless Portlet):

user logs into (WSRP consumer) portal
portal loads user prefs from local db
portal up-loads prefs to producer (WSRP portlet service)
	creating a "transient" entity
portal asks remote producer to render "transient"
user logs out & portal destroys remote "transient"
portal saves any user pref changes to local db

However, it seems much more natural to store the prefs at the producer
and uploading prefs each time may be costly in terms of nw bandwidth.

Instead, it may be useful to have an "instance" scope on sessions. 
This would allow for both shared (between portlets at a producer) 
and private session data (per protlet), under the control of the
consumer (per user or per consumer or consumer side group or role).
This would be similar to a "transient" with lifetime bounded by a 
session (I know this was objected to)? Sessions are preferable to 
me as they are available in all requests. i.e. it is unclear to me 
how a transient entity can be used in the rendering of another 
(aka persistent entity) portlet (here, the session is part of the 
request context).

Temporary result objects can be held in the consumer session. Again,
I would prefer all state to be kept in the producer (rather than
being uploaded with each request a la view state or managed by 
*remote reference* a la request-result transient entities). 

If the consumer considers one or more portlets to be part of one 
logical application and one or more other portlets (at the same 
producer) to be part of another application then I think it is 
natural for the consumer to create two sessions (a sort of 
application scope for remote portlet maintained by the consumer 
as distinct sessions).

	-- Andre

-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: 11 June 2002 15:50
To: wsia@lists.oasis-open.org; wsrp@lists.oasis-open.org
Subject: RE: [wsia] [wsrp] [wsrp-wsia joint interfaces] Merged
interfaces document



I started several replies and then realized I really needed to ask a
clarifying question first.

When you say
      "I view persistency as a continuous rather than an
      all or nothing property (degree determined by the producer)"
do you mean that the entity will continuously persist whatever portion of
its state is declared to be peristent OR do you mean that the producer
exerts control over what portion of its state is persisted?



 

                      Andre Kramer

                      <andre.kramer@eu.        To:       Rich
Thompson/Watson/IBM@IBMUS, wsia@lists.oasis-open.org, 
                      citrix.com>               wsrp@lists.oasis-open.org

                                               cc:

                      06/11/2002 04:00         Subject:  RE: [wsia] [wsrp]
[wsrp-wsia joint interfaces] Merged      
                      AM                        interfaces     document

 

 

 




Rich,

Thanks for your quick reply to my questions. On the need for "transients",
I still do not see why (or how) the *consumer* needs to decide to call
createTransientEntity or createPersistentEntity. If this is only
a hint that the lifetime is bounded by a session then why not just
include a sessionId as a create argument? Also, I view persistency as a
continuous rather than an all or nothing property (degree determined
by the producer).

             -- Andre

-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: 10 June 2002 18:21
To: wsia@lists.oasis-open.org; wsrp@lists.oasis-open.org
Subject: RE: [wsia] [wsrp] [wsrp-wsia joint interfaces] Merged
interfaces document



We have to work through the array idea as it as big performance
implications and I don't see any indications that call batching at the SOAP
stack level will be available in a relatively short timeframe.

My understanding from the WSRP interfaces discussions is that a template is
a portal concept. It is effectively a configured portlet that is used from
a toolbox to design pages. The concept of an instance is a configured
portlet that is linked to the layout of a portal page. This configuration
MAY have come from cloning a template. From the perspective of what the
Producer needs to support, both of these are particular configurations of
an entity the service exposes with the Consumer choosing to use them in
different ways. I have been searching for reasons why there would be a
difference for the entity, but haven't found one yet.

If I understand your question about transient entities correctly, you see
why sessions should be separated from entities so that they can be shared
but question whether services will ever expose entities that aren't
persistent. I can certainly imagine entities with no persistence (the
service that hosts them likely has some persistence of who may use them
along with some use log for audit & billing purposes). A simple entity that
puts a UI on a stock ticker feed may be a good example. It chooses to
delegate all the billing issues to the service where it is deployed and all
the configuration persistence to its Consumers. In this case,
createPersistentEntities() would always fail as only transient entities are
supported.





                      Andre Kramer

                      <andre.kramer@eu.        To:       Rich
Thompson/Watson/IBM@IBMUS, wsia@lists.oasis-open.org,
                      citrix.com>               wsrp@lists.oasis-open.org

                                               cc:

                      06/10/2002 10:37         Subject:  RE: [wsia] [wsrp]
[wsrp-wsia joint interfaces] Merged
                      AM                        interfaces     document










Supporting a batch operation mode through arrays does not seem very clean.
In the "getFragment"
case (getFragments?), the portal will most likely then have to wait until
the whole array is
returned (i.e. all remote portlets have rendered) before it can display the
resulting mark-up.
How many consumer to producer parallel calls do we expect typically? I
would
rather leave
call batching up to the (future) SOAP stack.

Always using "Entity" as the thing to create remotely seem to loose the
"class" versus "object"
semantics that the WSRP "template" and "instance" operation names used to
imply. Do we now see no
no difference between remote data storage - 'templates' (possibly with
inheritance) and
computational entities - 'instances', that WSRP seems to naturally call
for?
Or are these the
persistent v.s. transient entities of the document (for me, portlet
instances persist too)?

In trying to follow the discussion, I'm confused as to why we need both
sessions and transient
entities, both being under the control of the consumer. I do see a need for
common sessions
(same user/group or consumer portal) but do not see the need for other
transient entities,
expecting a consumer to have to pay for all entities, in some way, in the
real world. I know
the next call will discuss these but could someone give a brief rational
before then?

Thanks,
Andre

Andre Kramer, Citrix Systems, Inc.

-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: 07 June 2002 20:38
To: wsia@lists.oasis-open.org; wsrp@lists.oasis-open.org
Subject: [wsia] [wsrp] [wsrp-wsia joint interfaces] Merged interfaces
document



Here is a draft of the merged interfaces document that Carsten and I have
been working on this week. The largest conceptual change from the previous
0.44 Joint Spec Draft is the appearance of arrays in most of the
operations. This allows Consumers on the scale of portals to efficiently
interact with Producer services.

(See attached file: WSIA - WSRP Interface Specification.doc)






----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>






----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC