RE: What does WSDL describe?


> You claim there's no operation, but there really is one, because there
> remains a notion of "success" and "failure".  You just have to ask
> "success and failure of what?".  The answer to that question is your
> operation, whether or not you choose to include it in your message.

There doesn't necessarily have to be an answer. I can imagine situations
where there isn't a requirement for a response.
> So it's true that you can get a whole lot done with just the "process
> this state" implicit operation in your example - heck, EDI was built
> around that operation (AFAICT).  But at least one more would be nice;
> an operation for *retrieving* the state of things.

I don't use the terms "process" or "state". Sending a message is not an
instruction to an agent to do something. It's just a message. No other
semantics attached. Do you want to call that message "state"? That's up
to you.

> > All these within the concepts of WSA where
> > you have the additional protocols for adding extra functionality,
> > communication protocol independence, modularity, etc.
> Sorry, I don't understand what you mean there.

Apologies. That was not very clear. What I meant was that the WSA
document describes an architecture for building distributed applications
that may use a set of protocols for message correlation, transactions,
coordination, security, orchestration, etc. All that in a
transport-neutral way (no dependence on HTTP for example). Web Services
are these agents that can receive/send messages that carry information
necessary for those protocols. All that (and more) are part of the Web
Services Architecture. So, I am talking about message exchange within
this model and not the model described by REST.


Received on Sunday, 26 October 2003 21:53:47 UTC