> It's my understanding of SOA that the "service" should not deal with state
at all.
Forgive the lack of eloquence in my reply.
A service that is thread local *is* dealing with state for the period that
it is attached to a particular thread. For example, a service that provides
database transactions must manage the state of the transactions it provides
while its attached to a thread, but all bets are off at some point when its
necessary to disassociate the the service from the thread (like at the end
of a web request). I don't see the great difference here between a service
that has an activate/passivate lifecycle with regards to threads and a
service with the same lifecycle with regards to a web session.
Making a service session local follows the same ideal, activation is a bit
more work (restore/save some state from/to the session) . I'll stay with the
transaction metaphor, but I assume that a "transaction" is something other
than a database transaction. My hypothesis is that a wizard in a web
application is a "transaction", but it spans more than one web request.
> 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.
A very minimal implementation that ignores configuration points (because I'm
still learning about those).
Create a service called HttpSessionService that is "pooled" and has two
methods
setSession(HttpSession)
HttpSession getSession()
implements PoolManageable and overrides passivateService() to null out its
session field on cleanup. Its job is make the session available to other
services and that's it.
Use a new servlet filter (or extend the hive one) to call setSession on a
thread local HttpSessionService instance when a request starts.
Another service, MyWizardService implements PoolManageable, uses the
HttpSessionService to obtain the session.On activateService() is restores
any session dependant state. When passivateService() is called, any session
dependant state is stored in the session.
Now, having ignored the interface for MyWizardService completely, clients
can get a session local reference to MyWizardService with one simple call to
the Registry, and the client is not responsible for keeping track of session
dependant state somewhere (like the Visit).
To me having a service to obtain a wizard but then making the client
responsible for managing the wizard state would be like making Tapestry
programmers responsible for maitaining the persistent properties of thier
pages/components manually in the Visit. yuk.
Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
