- From: <paul.downey@bt.com>
- Date: Thu, 15 Jul 2004 11:52:24 +0100
- To: <Jim.Webber@newcastle.ac.uk>, <www-ws-desc@w3.org>
Jim: > The fact that two operations accept the same input messages and > return different output messages is only a problem if one insists > on conceptualising them as RPC, thus: i'm citing an operation which has a "request response MEP". how i 'conceptualise' that is my business, thanks! > OutMessage operation(InMessage in); > OtherOutMessage operation(InMessage in); > > If this is broken down into its constituent parts it's much more > easily digested: > > InMessage -> Service > OutMessage <- Service > OtherOutMessage <- Service > Now all the service has to do is process InMessage messages. One of the > outcomes of that processing will be to create and send an OutMessage or > OtherOutMessage. AIUI an agent now has to examine all of the operations in an interface, divine which of them accept the same input message, and anticipate any one of a series of actions occurring and output messages in response. Hmmm. So if it were possible to describe an operation as accepting InMessage and returning either OutMessage or OtherOutMessage, wouldn't that be good enough? > On the consumer side, the consumer must be able to create and send an > InMessage message, and be able to process OutMessage and OtherOutMessage > messages. What happens if OtherOutMessage is from the second operation that has a different MEP? The sender may be expected to process and send additional messages, but as the operation, and therefore the MEP is unclear. It doesn't know if it's dancing to "Strauss" or "The Pogues". Paul
Received on Thursday, 15 July 2004 06:52:44 UTC