MHonArc v2.5.2 -->
wsia 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.
This is a new twist on the concept of transient entities, at least as
far as I understood what we meant by the term. I see the utility of
this, but I'm not clear about why it is necessary. This is a way to
do this, but I guess I just don't see what the added value is for
doing it this way as opposed to other ways. In an aggregated service
for one-stop shopping so to speak, I guess maybe it would be somewhat
more convenient, but I would certainly want to test it or get some
information to that effect before I bought it, the service not the
specific hotel reservations. If I saw some figures that proved it was
quicker, or provided some other equally attractive value, I would buy
it.
This may be a case where transient entity is just a specific set of
information, two calls to a database, two images with hyperlinks
associated with them and a bit of processing during a discrete
session. That could be more efficient if the OO aspects mentioned can
be leveraged without transient entities proliferating beyond
expectations. I had thought of transient entities more as volatile
elements like stock quotes with changeable values rather than as
search selections gathered together temporarily.
It definitely gives me more to think about.
Ciao,
Rex
At 11:17 AM -0700 6/12/02, Alan Kropp wrote:
>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
>
>
>
>
>
>
>
>
>
>