RE: [wsrp] [wsia] [wsrp-wsia joint interfaces] Search results page,map services, transient entities.

From
Qavi Lonuru
Date
2002-06-12T18:09:30+00:00
ID
Thread
RE: [wsrp] [wsia] [wsrp-wsia joint interfaces] Search results page,map services, transient entities.
I am not questioning whether the design makes sense. I was questioning the phrasing of the problem to demonstrate the

need for transient entities and I was looking for a convincing business scenario where the need  for transient entities

is clear. As long as there is an alternative, fairly clean solution to the problem, the rationale would not be clear.

Eilon and I talked about the scenario when the customization call ended early today. We agreed that

	-  my solution made sense for the particular phrasing problem

	- and refining the problem where the search results page 

		- actually is showing page fragments from each of the map services

		- and the number of results is unbounded (e.g all map services are not part of a single hotel chain).

makes a good case for transient entities.

	

Ravi Konuru

Rich Thompson/Watson/IBM@IBMUS

Rich Thompson/Watson/IBM@IBMUS

06/12/2002 01:22 PM

	

	To:	, 

	cc:	

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

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

 file:                          DE         cc: "'Alan Kropp'"

 pic116                                    <>,

 57.gif                                    ,

 )                              06/12/2002 

                                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鐽lingen , 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'" <>, ,

 |

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

Sent: Tuesday, June 11, 2002 2:18 PM

To: ''; ''

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

Sent: Tuesday, June 11, 2002 2:19 AM

To: Gil Tayar

Cc: thomas klein6; '';

''

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鐽lingen , 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: "''"

<>, "''"

<>, 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:]

Sent: Tuesday, June 11, 2002 08:45

To: Alan Kropp

Cc: ''; ''; 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鐽lingen , 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: "''"

<>, "''"

<> |

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

#### pic28419.gif has been removed from this note on June 12 2002 by Ravi Konuru

#### pic11657.gif has been removed from this note on June 12 2002 by Ravi Konuru

#### pic00419.gif has been removed from this note on June 12 2002 by Ravi Konuru

#### pic30879.gif has been removed from this note on June 12 2002 by Ravi Konuru