Re: [OWL-S]: Proposal for 3 new control constructs

On Monday, October 6, 2003, at 07:34 PM, David Martin wrote:
> Following up on recent messages (in particular,
> http://lists.w3.org/Archives/Public/www-ws/2003Sep/0111.html
> ),
> here's a proposal for 3 new constructs for OWL-S - "invoke", "accept", 
> and "select".  These constructs are simple and non-novel.
[snip]

Upon reflection, I can map these to the send ("!") and "receive" 
operators in Erlang (and since receive can select from a message queue, 
I'll take that as mapping to "select"). However, it's not clear to me 
that they are non-novel. In Erlang, message sending occurs between 
"processes" (conceived as lightweight threads with identity), but 
whether the send occurs between or within a "node" (aka, execution 
engine) is entirely transparent to the send site. In other words, it 
depends on the identifier of the process receiving the message, not on 
the syntactic construct for sending the message.

	P1 !  someMessage.

Works "where ever" P1 is.

Erlang, of course, does have a distinction between message sending and 
function invocation, and thus, between intraprocess and interprocess 
calls (but, again, processes can be distributed over many 
nodes/execution engines). But, as I understand DAML-S, there currently 
is only message sending. I guess one could see it as only function 
invocation, but many of my WSDL colleagues, I'm sure, would emphasize 
that that is a mistake. WSDL only describes message exchange patterns.

Hmm. It seems to me that I'm (polemically) responding to the wrong 
message. I should be responding to your earlier one on Simple Process 
Coordination.

I don't have an objection to having (more) terms for these situtations, 
especially if we tend to leave them to be inferred. I'm not at all 
convinced that people will want to use them themselves, explicitly, 
though that's a purely empirical matter. I guess I don't *want* them to 
so want, but that's a different issue.

I am worried that we're going against current trends in Web Services. I 
also worry that this is sort of like SimpleProcess, in that we 
introduce an explicit language feature -- in effect, a kind of control 
construct that says "here is an abstraction point" -- but we have a 
number of other places where that abstraction could have been handled 
(e.g., multiple or no groundings for an AtomicProcess; grounding to 
AtomicProcess which may make available a richer process model; multiple 
bindings in a grounded to WSDL description). I think this complicates 
things unnecessarily, in particular, by forcing a choice of how to 
represent things for which little guidance is, or perhaps can be, given 
to a description author.

Cheers,
Bijan Parsia.

Received on Tuesday, 7 October 2003 05:04:31 UTC