W3C home > Mailing lists > Public > www-ws-desc@w3.org > July 2004

RE: FW: Action Item 2004-07-01 Solution to 168/R114

From: <paul.downey@bt.com>
Date: Thu, 15 Jul 2004 11:52:24 +0100
Message-ID: <2B7789AAED12954AAD214AEAC13ACCEF2709DA5E@i2km02-ukbr.domain1.systemhost.net>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:32 GMT