- From: Savas Parastatidis <Savas.Parastatidis@newcastle.ac.uk>
- Date: Tue, 9 Sep 2003 19:36:53 +0100
- To: "He, Hao" <Hao.He@thomson.com.au>
- Cc: <www-ws-arch@w3.org>, "Jim Webber" <jim.webber@arjuna.com>
Hao, Just a couple of thoughts on your message. Regarding the following... > An SOA is a style of software architecture, which centralises on the > concept > of service. A service is a unit of work done by a service provider to > achieve desired end results for a service consumer. Both provider and > consumer are roles played by software agents on behalf of their owners. > The > end results are usually the change of state for the consumer but can also > be > the change of state for the provider or for both. A service is considered > "safe" if agents do not incur obligations by invoking the service[1]. A > service is specified by a contract between a provider and a consumer. A > contract typically prescribes the means of service consumption and > expected > end results from a consumer's prospect. Additionally, quality of service > may > also be specified. Why try to define what a service does? Do we really know what a service does (e.g., whether "it's a unit of work", whether its state changes, or what its relationship with consumers). Wouldn't be simpler to define a service as an entity that can just send and receive messages? Or, an entity that can participate in message exchange patterns? Is a service anything more than this? [snip] Regarding statefulness/stateless... I personally see services as stateless entities. A service should be defined with stateleness as a default behaviour. By statelness I mean that there is nothing in the definition of a service that allows it to correlate messages it receives or sends. Statefulness is achieved through additional message correlation mechanisms. If a token was to be sent as part of the message, that doesn't mean that the service is stateful. Instead, an application-specific mechanism has been employed to build stateful interactions on top of a stateless architecture (SOA). There is something to be said about a community-agreed mechanism for achieving this but the fact still remains that the semantics of a service do not need to change. So, I agree with Bill's comment that this group should provide guidance on how stateful interactions should be achieved in the same manner that the group is talking about transactions, orchestration, etc. However, that does not mean that anything regarding stateful interactions should appear in the explanation of SOA and the definition of a service. Just my 2c. Regards, -- Savas Parastatidis http://savas.parastatidis.name
Received on Tuesday, 9 September 2003 14:37:42 UTC