RE: Proposed text on 'SOA' (resend)

hi, Savas,

Thanks for your comments. My replies are within.

[snip]
> 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?

<hh>I guess so. A service certainly implies doing something on behalf of its
client.  There is certain degree of commitment involved here.  Only sending
and receiving messages sound too much simpler than that. </hh>


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.

<hh>I think that I agree with you. The only dispute here is whether to call
an interaction involving tokens stateful or stateless. Personally, I don't
mind either way apart from the need of differentiating them. </hh>

Hao