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: [wsrp] [wsia] [wsrp-wsia joint interfaces] Search results pag e,map services, transient entities.


You're on the spot, for the OO "camp" thinking.

In the non-OO "camp" way of thinking, the transient entity is not per-user
and thus cannot store the (hotel=DownTownHilton...) information, and this
must be stored in the session. But the session is shared (per-user) for all
those hotel services, and so the information there must be "partitioned" by
the transient entity handle, e.g. the session will be
"#1(hotel=hilton...),#2(hotel=wyndham...),#3...", where #n is the transient
entity handle.


Note:
1. Usually, the information itself will not be stored in the session handle,
but rather a handle will be stored which points to the information, but it
still will be partitioned, e.g "#1(#123), #2(#456),..."

2. It is the producer/entity that must do the partitioning, and given that
an entity can never know whether it can be added multiple times to the same
page, it must always do so, or never support the ability to add itself
multiple times to the same page. This makes it very unnatural for a
"web-oriented" developer to develop a service (they _never_ dealt with this
concept before WSIA/WSRP service development), and so I question the phrase
"web-architecture group" for the non-OO camp. For them, paradoxically, the
OO camp concepts would be more natural, as it would enable them to map
_their_ concept of session to the WSIA/WSRP concept of transient entity
handle.

3. This email is _not_ an endorsement of any "camp". I see the two sides as
"simplicity of model/concept" (the OO camp) vs. "scalability" (the non-OO
camp, although a previous email of mine questioned that).

Gil


-----Original Message-----
From: Alan Kropp [mailto:akropp@epicentric.com]
Sent: Wednesday, June 12, 2002 21:17
To: wsia@lists.oasis-open.org; wsrp@lists.oasis-open.org
Subject: RE: [wsrp] [wsia] [wsrp-wsia joint interfaces] Search results
pag e, map services, transient entities.


I'm coming around to this idea.  I guess that coming from the web app
background, it's difficult to conceive of OO concepts overlaying neatly on
top of the stateless, loosely-coupled world of HTTP.  I tend to think of
Ravi's approach as somehow more "natural" for this sort of application, but
completely see Rich's point.  

So to make sure I've got this..The Consumer tells the Producer to construct
n transient entities, one for each hotel in the search results.  Each
transient entity represents a distinct state (hotel=Downtown Hilton,
city=Toronto).  The Consumer can then call performAction() (I don't think
it's getFragment?) on each transient entity, to get back an appropriate GIF
that it uses to render the results page.

When the user clicks the GIF, the Consumer transmits a getFragment() request
to the transient entity, which responds with the full-size map GIF, and
perhaps text driving directions.

On the Producer side of this, I can see a streamlined implementation where
there's an instance (in the OO sense) to represent the MapQuest entity, and
each transient entity is really an in-memory representation of the
appropriate transient state.  The transient entity handle in the request
(either performAction or getFragment) tells the Producer which transient
state to "connect" the MapQuest entity to for this request.


Alan

 

   





-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: Wednesday, June 12, 2002 10:23 AM
To: wsia@lists.oasis-open.org; wsrp@lists.oasis-open.org
Subject: RE: [wsrp] [wsia] [wsrp-wsia joint interfaces] Search results
page, map services, transient entities.




It sounds like you are questioning whether the design proposed for the
Consumer's search result page makes sense. I would respond that not only
does it make sense, I have seen the equivalent on the web already (don't
remember where, but it was the basic scenario Eilon laid out). You are
basically there when you state that the search page could present a set of
clickable GIFs ... the question is where do these come from. Two basic
choices are that the Consumer prefetches them into a local cache and just
makes a connection to the search result record OR that for each result
record, the Consumer creates a transient entity at a Producer, sets the
configuration such that an appropriate GIF is generated and the Producer
includes whatever logic is needed to deal with clicks on the GIF. I would
argue that the architecture should not exclude either approach (both have
their advantages) and that the second approach is a good case where the
context known only by the Consumer is what dictates whether a persistent or
transient entity is appropriate.



 

                      Ravi

                      Konuru/Watson/IBM        To:
wsia@lists.oasis-open.org, wsrp@lists.oasis-open.org       
                      @IBMUS                   cc:

                                               Subject:  RE: [wsrp] [wsia]
[wsrp-wsia joint interfaces] Search      
                      06/12/2002 10:53          results page, map services,
transient entities.                     
                      AM

 

 




I don't understand why transient entities are created in this scenario. Why
is the search results page creating the transient entities?
I can think of a case where the search results page provides a set of
clickable GIFs that correspond to the hotel services but NOT actually
create transient entities at the Producer. If the user actually clicks on
one of them, it is at that time the consumer requests the producer to
create an entity (transient or persistent) and then embeds the output of
the entity in its web page.

Am I missing something?

thanks,
Ravi Konuru

(Embedded image moved to file: pic28419.gif)Carsten Leue/Germany/IBM@IBMDE

                                                                          
 (Embed (Embedded image moved to file:     (Embedded image moved to file: 
 ded    pic00419.gif)                      pic30879.gif)                  
 image                          Carsten                                   
 moved                          Leue/Germa To: Eilon Reshef               
 to                             ny/IBM@IBM <eilon.reshef@webcollage.com>  
 file:                          DE         cc: "'Alan Kropp'"             
 pic116                                    <akropp@epicentric.com>,       
 57.gif                                    wsia@lists.oasis-open.org,     
 )                              06/12/2002 wsrp@lists.oasis-open.org      
                                06:57 AM   Subject: RE: [wsrp] [wsia]     
                                           [wsrp-wsia joint interfaces]   
                                           agenda for Tuesday 11 June     
                                                                          
                                                                          




I think that this is a very good scenario where transient entities make
sense.


Best regards
Carsten Leue

-------
Dr. Carsten Leue
Dept.8288, IBM Laboratory B÷blingen , Germany
Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401



|---------+----------------------------->
| | Eilon Reshef |
| | <eilon.reshef@webc|
| | ollage.com> |
| | |
| | 06/11/2002 08:35 |
| | PM |
| | Please respond to |
| | Eilon Reshef |
| | |
|---------+----------------------------->
>
----------------------------------------------------------------------------
-----------------------------------------------------------------|

| |
| To: "'Alan Kropp'" <akropp@epicentric.com>, wsia@lists.oasis-open.org,
wsrp@lists.oasis-open.org |
| cc: |
| Subject: RE: [wsrp] [wsia] [wsrp-wsia joint interfaces] agenda for
Tuesday 11 June |
| |
| |
>
----------------------------------------------------------------------------
-----------------------------------------------------------------|




Alan,

I think that one example scenario is a search results page, say for hotels,
that dynamically displays multiple maps - a map for each hotel found.

Assuming that maps are remote services, and assuming that the number of
results is dynamic, the Consumer needs to create multiple copies of the map
service. If we allow the Producer to determine the persistence state of
those maps, that would mean that someone will have to take care of the
lifetime of those maps. The Consumer can't, because the page may be gone
without the Consumer never knowing about it (the user closes the browser
window). The Producer can't, because it can't tell whether the Consumer has
stored a reference to those maps as part of a design-time description of a
user page.

Is that along the lines of what you were looking for?

Eilon
-----Original Message-----
From: Alan Kropp [mailto:akropp@epicentric.com]
Sent: Tuesday, June 11, 2002 2:18 PM
To: 'wsia@lists.oasis-open.org'; 'wsrp@lists.oasis-open.org'
Subject: RE: [wsrp] [wsia] [wsrp-wsia joint interfaces] agenda for
Tuesday 11 June



I find that the question of a Consumer creating a persistent vs. a
transient
entity to be a little troubling.


Isn't the Consumer primarily interested in getting a handle to an
_entity_
(be that transient or persistent), and then using that handle to
direct
subsequent requests to?


Could we not consider persistence and transience to be entirely
Producer
concerns? I understand from the sequence in the spec (pp. 6-8) that
the
only supporting scenario for the Consumer calling
"createTransientEntity" is
out of an effort to maximize the efficiency of the conversation with
the
Producer. This is a worthy goal, of course, but the Producer should
advertise its interaction behavior in the meta-data, right?
Presumably the
Producer uses the meta-data to hint to the Consumer the way(s) the
Consumer
SHOULD structure invocation requests efficiently.


I'd love to see some more convincing scenarios to support pushing the

persistent/transient aspect of the conversation out to the Consumer.
Otherwise, I'd love even more to limit our specification to a single
"createEntity" call.


Alan





-----Original Message-----
From: Carsten Leue [mailto:CLEUE@de.ibm.com]
Sent: Tuesday, June 11, 2002 2:19 AM
To: Gil Tayar
Cc: thomas klein6; 'wsia@lists.oasis-open.org';
'wsrp@lists.oasis-open.org'
Subject: RE: [wsrp] [wsia] [wsrp-wsia joint interfaces] agenda for
Tuesday 11 June






Gil -


1-3: the consumer MUST explicitly create entities (transient or
persistent). It can decide to create sessions explicitly if it wants
to
share them amongs entities, otherwise it can let the producer create
sessions on the fly.
4: the decision to have multiple entities per session is up to the
consumer
who make this choice based on the producer's metadata. e.g think of
portlets that form a shop together. These would want to share a
session
with each other. But the consumer could decide to have two shops of
the
same type on the same page. Then there would be two sessions and only
the
consumer could know what portlet shares what session.
5: The consumer should create a session before issuing a getFragment
call.
The entity is created whenever necessary.
6: A Session is a bucket that holds some data (physically on the
provider)
and times-out after a while. A transient entity is a remote portlet
that
does not store any data in a DB.


Hope that helped.


Best regards
Carsten Leue


-------
Dr. Carsten Leue
Dept.8288, IBM Laboratory B÷blingen , Germany
Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401






|---------+---------------------------->
| | Gil Tayar |
| | <Gil.Tayar@webcol|
| | lage.com> |
| | |
| | 06/11/2002 09:28 |
| | AM |
| | Please respond to|
| | Gil Tayar |
| | |
|---------+---------------------------->

>
---------------------------------------------------------------------------

------------------------------------------------------------------|
|
|
| To: Carsten Leue/Germany/IBM@IBMDE
|
| cc: "'wsia@lists.oasis-open.org'"
<wsia@lists.oasis-open.org>, "'wsrp@lists.oasis-open.org'"
<wsrp@lists.oasis-open.org>, Thomas|
| Klein6/Germany/IBM@IBMDE
|
| Subject: RE: [wsrp] [wsia] [wsrp-wsia joint interfaces]
agenda
for Tuesday 11 June
|
|
|
|
|

>
---------------------------------------------------------------------------

------------------------------------------------------------------|






Carsten, could you clarify some things for me?


1. If sessions and entities are orthogonal, what SHOULD the Consumer
do?
2. SHOULD it create a transient entity _and_ a session?
3. MUST it do so?
4. Who gets to decide whether there are multiple entities per session
or
multiple sessions per entities?
5. When SHOULD a Consumer create a session and when a transient
entity?
6. What _is_ a session, logically? What _is_ a transient entity?


Gil


-----Original Message-----
From: Carsten Leue [mailto:CLEUE@de.ibm.com]
Sent: Tuesday, June 11, 2002 08:45
To: Alan Kropp
Cc: 'wsia@lists.oasis-open.org'; 'wsrp@lists.oasis-open.org'; thomas
klein6
Subject: Re: [wsrp] [wsia] [wsrp-wsia joint interfaces] agenda for
Tuesday 11 June






Alan - some first thoughts


1. the general concept is that entities (transient or persistent) and

sessions are orthogonal. There might be mulitple entities per session
and
(at least for persistent entities) multiple sessions per entity. An
example
for the first case would be that entities share session data within
the
same user request. An example for the second case are portlets on a
common
page (group page) that are access simultaneously by multiple users.
A transient entity differs from a persistent entity in that its data
does
not persist and its lifecycle is coupled with the session life cycle.


2. Eilon pointed out in a comment to the interface proposal that
batch
processing is already part of SOAP. I was not aware of that and will
look
it up until the call.





Best regards
Carsten Leue


-------
Dr. Carsten Leue
Dept.8288, IBM Laboratory B÷blingen , Germany
Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401






|---------+---------------------------->
| | Alan Kropp |
| | <akropp@epicentri|
| | c.com> |
| | |
| | 06/11/2002 01:54 |
| | AM |
| | Please respond to|
| | Alan Kropp |
| | |
|---------+---------------------------->


>
---------------------------------------------------------------------------

------------------------------------------------------------------|
|
|
| To: "'wsrp@lists.oasis-open.org'"
<wsrp@lists.oasis-open.org>, "'wsia@lists.oasis-open.org'"
<wsia@lists.oasis-open.org> |
| cc:
|
| Subject: [wsrp] [wsia] [wsrp-wsia joint interfaces] agenda
for
Tuesday 11 June
|
|
|
|
|


>
---------------------------------------------------------------------------

------------------------------------------------------------------|






I think we'll have plenty of discussion around the merged document
Rich and
Carsten put together.


The two main issues I see that have arisen on the email lists are:


1. What is the difference between transient entities and sessions,
and is
there enough of a distinction to warrant including both in the
specification?


2. There are efficiency concerns around the use of arrays in the
method
signatures, basically to enable batched requests for network
efficiency.





Call-in numbers:
USA Toll Free Number: 877-718-0936
USA Toll Number: +1-712-923-6878
PARTICIPANT PASSCODE: 563151





Alan





----------------------------------------------------------------
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>








----------------------------------------------------------------
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>








----------------------------------------------------------------
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