OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-caf message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [ws-caf] Meeting notes 3-22-2004


It is critical for the WS-CTX model that we precisely define activities
as groups of service operation invocations. With Peter and Mark, at
bottom, I don't care about the words (but see nothing very wrong with
the current ones in use). I do care about the concept (which is why I've
raised the point at the last two TC meetings).

A service does indeed send and receive messages. When a message is
received it either has no effect (in which case, why send it?), or it
has an effect on the recipient. (And in fact a "no effect" message
requires processing to be discarded: listening is not a no-op.) 

The effect may be wholly hidden (for example, if an acknowledgement
message allows some internal housekeeping to proceed), or it may produce
state changes, and/or it may copy state information into an outbound
message. The effect of the message is produced (has to be produced) by
the execution of a program. In other words: meaningful message reception
instigates the execution of a program; that program is the service's
reaction to message reception. 

The program has to be identified, parameterized etc. Its execution
environment, means of parameterization, etc are unknown to service
interlocutors. 

Conventionally such programs are called operations. When they are
executed, dispatched, invoked, run, in reaction to a particular message
reception, we have an instance, a run, whatever you want to call it.

My point is twofold: 

1) to deny that services execute programs in reaction to messages (to
say that we cannot mention this behaviour) is akin to forgetting to
mention the brain in describing a human being's sensory capacities. At a
certain level of abstraction human beings could be viewed as
listening/speaking/seeing/feeling machines. How they move from listening
to speaking, and why they bother to do either, would not be captured
well by such an exclusive concentration on interface.

2) Activities are not made up simply of messages, they are made up of
effects (which may include sending of messages). It is the effects
(changes to the environment of the services) that are important in this
context.

Alastair

-----Original Message-----
From: Furniss, Peter 
Sent: 24 March 2004 09:40
To: Mark Little; Savas Parastatidis; ws-caf
Subject: RE: [ws-caf] Meeting notes 3-22-2004

I strongly agree with Mark, and would quote the same authorities.

The main point at issue is part of caf-63 (aka
http://www.choreology.com/external/ws-ctx.prf_comments.revised.htm#PRF-1
). An activity comprises a set of instances of use of a web service -
particular transmissions of messages - and not a set of statically
available services or facilities within those services. Actually, what
one presumably wants to encompass is the processing related to the
messages, but that gets rather hard to specify in a service world (just
as it was hard to specify in open systems interconnection, where the
same kind of communication-centred, implementation-agnostic approach was
used. 

(come to think of it, OSI would call an "operation" a "service
primitive", but that is still the static type, not the instance that
travels on the wire. I think we used to say "invoke a service
primitive", but I'm not sure. There was certainly no feeling in my mind
that "invoke" implied methods on objects back then)

Peter

> -----Original Message-----
> From: Mark Little [mailto:mark.little@arjuna.com] 
> Sent: 24 March 2004 08:45
> To: Savas Parastatidis; ws-caf
> Subject: Re: [ws-caf] Meeting notes 3-22-2004
> 
> 
> I think it's true that Web services receive documents and 
> those documents are used to determine work that has to be 
> "done". But conceptually the are being invoked and they do 
> offer services/operations/types of work. WSDL even goes as 
> far as providing the <operation></operation> name, so it's 
> not like we're not following the standard as far as the work 
> "operation" goes. And as for "invoked", once again other 
> specs. (e.g., BPEL) use the same term in the same way (and in 
> the same sentence as "operation").
> 
> I think this isn't the time or place to start a holy war 
> about syntax. The worst thing we could do is start to use 
> completely different terminology from what our readers will 
> be used to. Now that's not to say that the discussion is 
> irrelevant, only that this isn't the venue for it.
> 
> Mark.
> 
> ----
> Mark Little,
> Chief Architect, Transactions,
> Arjuna Technologies Ltd.
> 
> 
> ----- Original Message ----- 
> From: "Savas Parastatidis" <Savas.Parastatidis@newcastle.ac.uk>
> To: "ws-caf" <ws-caf@lists.oasis-open.org>
> Sent: Wednesday, March 24, 2004 12:10 AM
> Subject: RE: [ws-caf] Meeting notes 3-22-2004
> 
> 
> > All,
> >
> > I am sorry for this intervention in your technical 
> discussions. I know 
> > I haven't been active in following the excellent work you've been 
> > doing here but I just couldn't resist in sending this comment...
> >
> > >
> > > 3)  Should "web service operations performed" be changed to "web 
> > > services operation invocations" in the first sentence.
> > >
> >
> > I think that the choice of the term "operation" in WSDL is not 
> > representative of what actually takes place. I believe that Web 
> > Services shouldn't be seen as having operations that can be 
> > "performed" or "invoked". Instead, Web Services just send 
> and receive 
> > messages. The terms "perform" and "invoke" may give the wrong 
> > impression and may lead us to think in terms (ooops... 
> overloading of 
> > the term "term" here :-) of other architectural models 
> (e.g., RPC or 
> > object-orientation).
> >
> > I do hope that this make sense even though I am not 
> expecting everyone 
> > to agree, even those from just few buildings away from where I am 
> > based
> > :-))
> >
> > Just my 2p.
> >
> > Regards,
> > --
> > Savas Parastatidis
> > http://savas.parastatidis.name
> >
> >
> 
> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]