Discovery MEP

Sitting in on a JMS-centric discussion, I was reminded of another thing
(besides two correlated one-ways) that looks like request-response but
isn't.  I say this based on the assertion that, in the absence of
failure, request-response consists of /exactly/ two messages (in the
broader definition, the return message may not be a SOAP envelope) and
it looks this way to /both /the client and the server.  The key
consequence of this is that the client knows when it's done; eventually
either it will get a response or a failure will occur.

What I'll call "the discovery MEP" for the purposes of this discussion
consists of these steps:

    * A requester broadcasts a request message, typically containing a
      correlation id of some sort.
    * /Zero or more/ responders respond with appropriate messages. 
      These messages should contain the correlation id of the request
      they apply to and will typically also contain some indication of
      the responder's identity.

I've called this the discovery MEP because it's useful in discovery
protocols.  I want to find someone, so I broadcast an appeal.  Various
interested parties respond and I pick some subset of those to correspond
with.

As with correlated one-ways, it's easy to /build/ request-response on
top of discovery.  You need a policy for picking a single respondent
among multiple respondents and for when to stop listening, bearing in
mind that the decision to stop listening, or not, may depend on what
you've heard so far.  As with correlated one-ways you also need a
timeout in case no one answers at all.

A protocol that provides for discovery does not necessarily provide for
request-response directly.  Before you can turn discovery into
request-response you have to lock down just what policy to use for
selecting the response (often but not necessarily first response wins)
and just what timeout you want to use.

It's an interesting question whether to model this by a separate
"discovery MEP" (as my subject line implies) or to model one-way
multicast and define discovery in terms of it.  I lean toward the
latter.  More accurately, discovery would be defined at the level of
WSDL and similar, while one-way multicast would be defined at the SOAP
or underlying protocol level, as opposed to defining discovery at the
SOAP/underlying level directly.

I believe that one-way multicast could best be modeled as FAF combined
with a "multicast enabled" property.  Such a property captures the
essential cardinality.  If I send to a single address, I know that at
most one receiver got the message.  If I multicast, any number of
receivers (including zero) could get the message.  If in addition the
receivers are following a request-response pattern locally -- that is,
each receiver receives a request and sends a response, then I can
further infer that a singlecast request will elicit zero or one
responses while a multicast request may elicit zero or more.

Note that request-response, correlated one-ways and discovery all look
the same to the receiver (except that a request-response protocol
provides a special facility for responses), while they look quite
different to the sender.  My position is that the SOAP 1.2
request-response MEP is the case that looks like request-response to
/both/ the sender and receiver.

Naturally, the inspiration for this was JMS topics, but the same
considerations apply whenever there is multicast available.