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

RE: Proposed text on 'SOA' (resend)

From: Savas Parastatidis <Savas.Parastatidis@newcastle.ac.uk>
Date: Tue, 9 Sep 2003 19:36:53 +0100
Message-ID: <BC28A9E979C56C44BCBC2DED313A447002050ACD@bond.ncl.ac.uk>
To: "He, Hao" <Hao.He@thomson.com.au>
Cc: <www-ws-arch@w3.org>, "Jim Webber" <jim.webber@arjuna.com>


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
> The
> end results are usually the change of state for the consumer but can
> be
> the change of state for the provider or for both. A service is
> "safe" if agents do not incur obligations by invoking the service[1].
> service is specified by a contract between a provider and a consumer.
> contract typically prescribes the means of service consumption and
> expected
> end results from a consumer's prospect. Additionally, quality of
> 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?


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.

Savas Parastatidis
Received on Tuesday, 9 September 2003 14:37:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:41:08 UTC