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] Re: RE: [wsrp] Sessions and Transient Entities


I am a picture type of guy.  I've often found discussions over the last
several months confusing because there has been no neat little picture to
which I can attach terms.  The column format is similar to a standard way of
illustrating the sequential flow of actions in a communications protocol,
but more graphics are also needed so people can point and say "this is the
piece I am talking about".  It may also be useful to include some state
transition diagrams.  Almost any device to supplement the words will enhance
clarity of the final product.  Remember, people will eventually have to
implement the specification.  As with any standards effort, an important
objective is eliminating the ambiguity that arises from varying
interpretations.  Well constructed graphics are a great help.

Brian R. Young
SSG & WHQ IS / Companywide Architecture and Standards
(425) 865-5834
brian.r.young@boeing.com


> -----Original Message-----
> From: Rich Thompson [mailto:richt2@us.ibm.com] 
> Sent: Thursday, June 13, 2002 11:55 AM
> To: wsia@lists.oasis-open.org; wsrp@lists.oasis-open.org
> Subject: RE: [wsia] Re: RE: [wsrp] Sessions and Transient Entities
> 
> 
> 
> You are the second person who commented on the order of the 
> columns ... is the consensus that should they be inverted?
> 
> In looking at your gif, I would say you captured the essense 
> of things reasonably. Changes I would suggest include:
> 
>  - The WSIA/WSRP interface/protocol do not participate in the 
> Web Browser to Web Server connection. Maybe someday we will 
> have browsers that can act as Consumers, but since todays 
> browsers are not aware of our protocol it will confuse 
> readers to imply the protocol applies.
> 
>  - While it may be a common occurence that a Consumer chooses 
> to initiate a Session as a result of the browser connection, 
> that is an implementation choice of the Consumer rather than 
> a protocol specified aspect.
> 
>  - As was mentioned relative to the glossary today, the 
> generalized term for what was a portlet is an entity. It 
> would be good to eliminate the redundant terms everywhere.
> 
>  - I would suggest that the last paragraph above the Consumer read:
>       Consumer may choose to partition entities into sessions 
> however it sees fit,
>       subject to the Producer enforcing any policies it has 
> regarding session sharing.
> 
>  - Not sure exactly what the last paragraph above Producer 
> means ... may just need clarification.
> 
> Do others find this gif useful ... should it be included in 
> the followon to the 0.1.2 document?
> 
> 
> 
>                                                               
>                                                       
>                       Rex Brooks                              
>                                                       
>                       <rexb@starbourne.        To:       
> Eilon Reshef <eilon.reshef@webcollage.com>, "'Rex Brooks'" 
>                       com>                      
> <rexb@starbourne.com>, wsia@lists.oasis-open.org,                   
>                                                 
> wsrp@lists.oasis-open.org                                           
>                       06/13/2002 01:50         cc:            
>                                                       
>                       PM                       Subject:  RE: 
> [wsia] Re: RE: [wsrp] Sessions and Transient Entities  
>                                                               
>                                                       
>                                                               
>                                                       
>                                                               
>                                                       
> 
> 
> 
> 
> 
> As I was trying to get this process down to the most basic 
> and simple, I diagrammed it using a component diagram. The 
> problem I had with the chart in the 0.1.2 version of the spec 
> is that it read right to left in terms of the flow from the 
> origination of the process with an end user request. I know 
> that this was done because the end point of the process is 
> the end-user but I wasn't able to keep the flow straight in 
> my mind as I read down over the four pages it spans. Also, it 
> covers just about all the variations of flow and types of 
> properties, entities and calls. I found I was better able to 
> use that chart with this diagram in hand. However, I still 
> have problems following Sophisticated to Simple and Simple to 
> Sophisticated within the chart context.
> 
> Also, it would be helpful to know if what I diagrammed is 
> essentially correct or not, so I attached it. it is a .gif 
> file so you can view it in a web browser or insert it into 
> another program to view it.
> 
> Thanks,
> Rex
> 
> At 9:09 PM -0400 6/12/02, Eilon Reshef wrote:
> Rex, We are all trying to simplify the interface. If we can 
> achieve the same results (namely, Portlet Grouping/Scoping) 
> without the need to have an explicit interface for creating 
> sessions, we are all better off. Eilon -----Original Message-----
> From: Rex Brooks [mailto:rexb@starbourne.com]
> Sent: Wednesday, June 12, 2002 8:39 PM
> To: Eilon Reshef; wsia@lists.oasis-open.org; wsrp@lists.oasis-open.org
> Subject: RE: [wsia] Re: RE: [wsrp] Sessions and Transient 
> Entities I think we are already getting down to too much 
> micromanaging. Why should I care how a producer manages their 
> portlets, transient entities or any combinations thereof in 
> one of my sessions? As long as I get back what I ask for, I 
> don't see what difference it makes. Ciao,Rex
> 
> At 6:53 PM -0400 6/12/02, Eilon Reshef wrote:
> Wouldn't it be easier to just pass a key (say: 
> portlet-group-id), that allows the Producer to manage this 
> more carefully than providing access to a low-level mechanism 
> such a session? -----Original Message-----
> From: Rich Thompson [mailto:richt2@us.ibm.com]
> Sent: Wednesday, June 12, 2002 12:27 PM
> To: wsia@lists.oasis-open.org; wsrp@lists.oasis-open.org
> Subject: [wsia] Re: RE: [wsrp] Sessions and Transient Entities
> 
> I would agree that supporting explicit creation of sessions 
> is easy means for a Consumer to indicate an arbitrary 
> grouping that it would like to establish. As the Producer is 
> ultimately managing the sessions, it can always enforce 
> whatever policies it would like on these groupings. I would 
> recommend that this version of the spec not try and define 
> how a Producer could expose such policies to the Consumer, 
> though we may want to revisit this question for future 
> versions of the spec if scenarios are defined that 
> demonstrate value to the Consumer in knowing the Producer's policies.
> 
> 
>                       "MICHAEL.FREEDMAN"
>                       <MICHAEL.FREEDMAN@        To: 
> wsia@lists.oasis-open.org, wsrp@lists.oasis-open.org
>                       oracle.com>               cc:
>                                                 Subject:  Re: 
> RE: [wsrp] Sessions and Transient Entities
>                       06/12/2002 10:58
>                       AM
> 
> 
> Irs not so much a bother to allow rather its a no reason to 
> prevent.  If a consumer wants to support such a thing they 
> should be free to do so as this would allow arbitrary 
> groupings (from the perspective of the producer).
> 
>       -Mike-
> 
> 
> 
> 
> 
> 
> 
> 
> 
>       face="Trebuchet MS" color=#0000ff>If a simple group-id 
> within the
>       portlet UI
>       takes care of the issue (which I agree with), why 
> bother to allow the
>       Consumer
>       to create and manage sessions explicitly (versus 
> implicit creation by
>       the
>       Producer)?
>       class=122592900-12062002>
>       class=122592900-12062002> -----Original Message-----
>       From:
>       Michael Freedman mailto:Michael.Freedman@oracle.com]
>       Sent: Tuesday,
>       June 11, 2002 7:43 PM
>       To: wsia@lists.oasis-open.org;
>       wsrp@lists.oasis-open.org
>       Subject: Re: [wsrp] Sessions and Transient
>       Entities
> 
>             Eilon,
>               I think your
>             suggestion intermixes 2 different concepts -- 
> that of session
>             identity and
>             that of instance/entity identity.  My scenario 1 concerns
>             itself with how
>             an instance/entity id can be used to segment data within a
>             session.  My
>             scenario 2 concerns itself with how distinct 
> sessions can be
>             established/maintained.  I suggested we don't 
> define a way for
>             the
>             producer to describe its grouping rules.  Rather 
> a consumer can
>             choose to
>             support grouping (via a mechanism its free to 
> define) or leave
>             it up to the
>             consumer to handle internally (via 
> perference/configuration
>             data).  So in
>             my scenario 2, a consumer isn't responsible for 
> separating the
>             portlets into
>             different sessions.  It merely is allowed to do 
> so.  Portlets
>             must
>             assume they aren't running in such environments 
> -- rather they
>             must assume
>             they run in a shared session world -- hence they 
> need an ID to
>             do the proper
>             namespacing.  As the consumer doesn't know this grouping
>             (because it
>             doesn't implement grouping) the producer must 
> provide its own
>             UI for getting
>             these keys -- i.e. the producer must provide a
>             configuration/personalization
>             UI that allows a group key to be specified for each of its
>             portlets -- it can
>             then use this "internal" group id to key/separate 
> data in the
>             shared session.
> 
>             Just a long way of saying -- I don't buy your 
> scenario 2.  If
>             the
>             consumer knows the grouping, I would rather the consumer
>             maintain 2 discrete
>             sessions as this allows it to continue to pass 
> the entity id so
>             each entity
>             can maintain entity specific data if necessary 
> (i.e. portlet A,
>             B, B' in the
>             same session/group -- B and B' can keep their 
> data separate).
>             If the
>             consumer doesn't know the grouping then it 
> controls things just
>             like scenario
>             1.  The producer is free to define/manage finer 
> granularity as
>             described
>             above.
>                  -Mike-
> 
>             Eilon Reshef wrote:
>                     face="Trebuchet MS">Mike, 
> class=731155222-11062002>
>                   face="Trebuchet MS">Per your recent 
> e-mails, I think that
>                   the
>                   approach makes sense. class=731155222-11062002> face
>                   ="Trebuchet MS">The only thing that 
> concerns me is that
>                   we
>                   have two different mechanisms to handle 
> what would seem
>                   to be a very similar
>                   scenario. class=731155222-11062002>Scenario 1:
>                   If there are two occurrences of a single 
> portlet on a
>                   page, then as
>                   you described it the portlet is responsible for
>                   segregating the
>                   occurrence-specific information, using an 
> additional key provided by the
>                   portal. class=731155222-11062002>Scenario 2:
>                   If there are two occurrences of a pair of 
> portlets, then
>                   suddenly the
>                   portal is responsible for segregating the 
> two pairs by
>                   placing them in two
>                   separate sessions. class=731155222-11062002> face
>                   ="Trebuchet MS">(All, of course, assuming that the
>                   portlets use sessions) 
> class=731155222-11062002> face
>                   ="Trebuchet MS">The idea of the Consumer 
> creating and
>                   managing the segregation keys has the
>                   scalability advantage that you mentioned.
>                   class=731155222-11062002> 
> class=731155222-11062002> face
>                   ="Trebuchet MS">Can't we use it to handle both
>                   scenarios? class=731155222-11062002>
>                   class=731155222-11062002> size=-1>Namely:
>                   class=731155222-11062002> 
> class=731155222-11062002> face
>                   ="Trebuchet MS">In scenario 1, where 
> there's portlets A1
>                   and A2, then the portal sends a key "1" 
> when displaying
>                   A1 and a key "2"
>                   when displaying A2.  class=731155222-11062002> face
>                   ="Trebuchet MS">In scenario 2, when there's 
> portlet pairs
>                   <A1, B1> and <A2, B2>, then the portal 
> sends a key "1"
>                   when
>                   displaying A1 and B1 and the key "2" when 
> displaying A2
>                   and
>                   B2. class=731155222-11062002> 
> class=731155222-11062002>
>                   This would
>                   allow the Producer to create and manage the 
> session id
>                   (and maybe even
>                   create them only when needed, instead of explicitly
>                   creating them up-front
>                   as the current draft suggests). The 
> Consumer only has to
>                   take into account
>                   that it may receive (and needs to re-send) 
> a separate
>                   session id for each
>                   one of the keys. class=731155222-11062002>
>                   class=731155222-11062002> face="Trebuchet MS">Eilon
>                   class=731155222-11062002> class=731155222-11062002>
> 
> 
> 
> 
> 
> 
> 
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
> 
> 
> --
> 
> 
> --
> 
> 
> 
> 
> #### WSIA-WSRP_Joint_Interface.gif has been removed from this 
> note on June 13 2002 by Rich Thompson
> 
> 
> 
> 
> 
> ----------------------------------------------------------------
> 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