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