W3C home > Mailing lists > Public > www-ws-arch@w3.org > May 2003

RE: Web Service Description and stateful services

From: Savas Parastatidis <Savas.Parastatidis@newcastle.ac.uk>
Date: Tue, 20 May 2003 19:56:59 +0100
Message-ID: <BC28A9E979C56C44BCBC2DED313A447001C0C108@bond.ncl.ac.uk>
To: <www-ws-arch@w3.org>

> 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
> 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

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,
Received on Tuesday, 20 May 2003 14:57:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:05:51 UTC