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.
Alan - my comments are embedded in [CL] tags.
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/12/2002 08:17 |
| | PM |
| | Please respond to|
| | Alan Kropp |
| | |
|---------+---------------------------->
>---------------------------------------------------------------------------------------------------------------------------------------------|
| |
| To: wsia@lists.oasis-open.org, wsrp@lists.oasis-open.org |
| cc: |
| 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.
[CL] agree [CL]
Each
transient entity represents a distinct state (hotel=Downtown Hilton,
city=Toronto).
[CL] agree [CL]
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.
[CL] the consumer would integrate the transient entities in its aggregation
procedure and call getFragments to get the markup. Such a markup could be a
GIF of the map but also any other (e.g. textual) information. [CL]
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.
[CL] It would be performAction, but the result would be the same. [CL]
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.
[CL] agree [CL]
Alan