commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Rubier <>
Subject Re: [Hivemind] Tapestry/HttpSession service
Date Sun, 07 Mar 2004 07:21:59 GMT
It's my understanding of SOA that the "service" should not deal with state at all. It's been
hard for me because I usually just like to jump in with the old procedural guns blazing ;)
but I think the ideas have merit. Hivemind is giving me the opportunity to explore this without
having to deal with SOAP and other distributed SOA hassles.

My thinking is that it could be modeled after the way Howard did the Symbol source stuff.
Have a factory service, say WizardManager. This service has a configuration point called WizardSource.
The interface for WizardSource has "createWizard()" and "getType()". Then you have NewCustomerWizard,
NewSupplierWizard etc. modules that contribute their own WizardSource implementations.
You would make a call to the WizardManager...newWizard("customer") which would iterate over
the various contributed WizardSource's and call createWizard() and return the appropriate
one which could then be stored in the visit. If the wizards have a standard interface, the
pages would only be coupled to the interface and nothing else.

Not sure if I'm on the right track here...

Take care,


On Saturday March 6th 2004, Geoff Longman wrote:

> The content of this message crosses boundaries so I'm cc'ing Tapestry dev
> too.
> I have a real problem in a Tapestry application and I'm wondering if another
> 'flavour' of Hivemind service approach would be applicable.
> We have a Tapestry app that has many hundreds of pages. Different groups of
> pages need to share different sets of information. We have tried using the
> Visit  to share data and have also tried explicity passing things between
> pages but both methods are less than ideal..
> The visit approach ends up being like a big hashtable. Explicity passing
> data via method calls leads to coupling between pages.
> What would be nice is a service that is not only pooled, but is peristent in
> the Tapestry way, i.e. the value of certain fields in the service are
> private to one user session.
> An example implementation could be a Wizard that uses 5 pages to build a new
> customer record in a database.
> If the service I described was doable, each page could access a
> NewCustomerWizard service, read data from it and set data in it. The
> NewCustomerWizardService could minimally reply to questions like:
> - Can the wizard finish?
> - What's the next page to show?
> - What's the previous page to show?
> Thus, the pages could interact individually with the service and not be
> coupled to one another.
> In fact, a menu component could interrogate the NewCustomerWizardService
> also to get the first page to show in order to start the Wizard. Plus, the
> service could keep track of all the pages used so far and if the user
> clicked 'Finish' or 'Cancel', the service could respond with the list of
> seen pages for cleanup purposes (forgetPage()).
> Is this wishful thinking?
> Cheers,
> Geoff
> Geoffrey Longman
> Intelligent Works Inc.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message