RE: Attributes, yes. Set/Get operations, no.

On 21/07/2003 13:11,  Savas Parastidis wrote:

> I get the feeling that in points 2 and 3 you make the assumption that
> the services are stateful. Unlike OGSI, Web services are not stateful.

Sometimes they are; it's just hard to tell :-)  If I do a SquareRoot(x)
operation I get the same answer each time: Not stateful. If I do a
getAttribute(x) twice, I expect the same answer: Stateful.

So, a service that has an 'attribute' has state. Why? it's a semantics
that's implied by the use of the term in other architectures. If I've
misunderstood the interpretation here, let me know.

> There are no concurrency related concerns there.
> Application domain specific infrastructures, like OGSI, can apply
> semantics like statefulness to Web services and then they will have to
> deal with concurrency issues. However, such issues do not exist in Web
> services where message exchange is the only thing that is defined.

My comments about semantics were not all concurrency-related; that's just
one possible cause of complexity that we need to be wary of when defining
what the messages mean. At the moment I am wondering what is meant by the
proposal to define get/set messages for attributes.  How do they behave?

> Attributes should just be convenient way to describe a message exchange
> pattern where a message is returned/sent from/to a service. Nothing
> more, nothing less.

Agreed!

> What extra semantics are applied to attributes or to
> the services that have attributes as part of their interfaces should be
> application domain specific.

Agreed! I am arguing that the application should be left to define the
operations and the semantics that go with them.

Regards, Tim Banks

Received on Monday, 21 July 2003 10:39:43 UTC