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

Paul:

> So a WSDL interface describes two operations both with the 
> same input message but with different actions and output 
> messages. Would you expect something inside the message to 
> describe the operation to be invoked?

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:

OutMessage operation(InMessage in);
OtherOutMessage operation(InMessage in);

If this is broken down into its constituent parts it's much more easil
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.

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.

> Or could the dispatching be achieved from something out of 
> band - it's raining, i've sent twenty messages previously, 
> it's my birthday, the ISS is overhead, etc? 

The dispatch will generally be based on some business logic acting on
the content and structure of the messages. That business logic can use
whatever esoteric inputs you choose. "I've sent twenty messages already"
is a good one, it means that perhaps I can start dispatching your
messages to some "priority system" because you're clearly a high-volume,
high-value customer.

> If so, where would this policy based dispatching be described?

In my internal architecture documents. If you're outside my enterprise
you never see this document.

> i'm not totally against you all wanting to do such a thing, 
> just want to know how far down this rabbit hole we're all headed.

Glad to hear it - I think your questioning useful since it helps to
clarify and constrain the message-oriented approach.

Jim
--
http://jim.webber.name

Received on Thursday, 15 July 2004 04:58:58 UTC