RE: Web Service Description and stateful services

> 
> Absolutely right on the button I think. (Makes crash recovery a whole
> bunch
> easier too.)
> 
> The service should always be able to "reconstruct" its internal state
> machine that implements the business logic with the message that
causes
> the
> service invocation.

I would be tempted not to associate crash recovery with "reconstruction"
of internal state (I am not sure whether that was Jim's intention). The
ability to "reconstruct" state based on the message that causes a
service invocation shouldn't have to be specific to a particular
service.

In the ATM example, the state that is associated with your bank account
is reconstructed no matter which ATM you go to. It's the context (your
bank account number) that is used to reconstruct the state. Then again,
it depends on how you define the service in this case. Is the ATM a
service or is it just a different endpoint to the same banking service?

IMHO, the association of context and state is important, while the
management of the internal state of a service is container-specific.
Also, once state is created, the way that is exposed is also important
and should be discussed. I agree that there are situations were
specification requirements may require crash recovery semantics of a
service's internal state.

I believe that the context-state association and the related operations
(create, destroy, lifetime, etc.) needs to be standardised. Perhaps some
of the existing standards already provide ways of doing this.

Just my 2 cents,
.savas.

Received on Tuesday, 20 May 2003 14:57:33 UTC