RE: Other message patterns

I agree that we need a well-architected notion of request-response, but I 
think the reason goes somewhat beyond helping applications to "correlate" 
messages.  As we've seen from the HTTP binding in SOAP, it is important to 
certain bindings to know when a message is sent outbound whether a 
response is expected. If you send a one-way message, you essentially drop 
the connection as soon as transmission is complete.  When there is a two 
way message, you sometimes want to keep a connection open, allowing the 
binding to help you with the correlation.  Indeed, you may send the 
outbound message differently if you know that a response is expected.

So, I think we need architected models of one-way and request-response. 
I'd like to think, but am not 100% sure that we want to go somewhat beyond 
that:  an architected notion of message patterns in general, that would 
eventually support notions of multicast (with a variety of response 
models---all members acknowlege, a majority acknowledge, whatever) , 
pub/sub, etc.)  I do not want to do all the patterns for V1, but it would 
be nice to have a good idea of whether they'd fit neatly later.

------------------------------------------------------------------------
Noah Mendelsohn                                    Voice: 1-617-693-4036
Lotus Development Corp.                            Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------------

Received on Wednesday, 14 March 2001 23:01:48 UTC