RE: [R3xx] Requirements Section "4.2 Simplicity and Stability" -- com parison with SOAP1.1.

> > "Also note that "application" semantics are
> > clearly out of scope (as they are for SOAP1.1),
> > whereas "operational" semantics of a messaging
> > system are in scope."
> >
> >Certainly, from my point-of-view the abstract model is really
> >only trying to construct a framework that will ultimately help us go 
> >forward into the design process and hopefully will help us to 
> >articulate our design.
> 
> Sounds good to me. Btw, I would think message exchange patterns fit as
part of
> "application space" - it is hard to talk about clients and servers and
message
> flows without having a particular application in mind.
> 
> Henrik

I think that we can talk about message flows without having a particular
application in mind. TCP gives us bytestream pipes that we can shove data
through, it comes out in order and for the most part doesn't get lost -
barring the failure of a TCP connection (and abnormal closure is detectable
by both ends); HTTP gives us a number of request response operations that
themselves have semantics (which you know inside out) that many regard as
very important (I'm not saying I don't, just that I not as well grounded in
the fine details of HTTP semantics) - you don't have to know semantics of
the application level message exchanges (buying a book from amazon, a google
search or whatever) to want to have well defined semantics for the operation
of a protocol layer.

What I would like to get anchored is what we expect of XP, and it may be
*very* simple, and it may not...

	When we send a message using XP can it get lost? (yes probably)

	If it does get lost, do we expect to hear about it, or can the loss
be silent?

	Can a single message (or response) be delivered more than once?

	When a message is delivered to the intended recipients 'inbox' do we
want 
	to be able to inform the sender?

	When multiple messages are sent between the same two parties, do we
expect them to arrive in the 
	same order (and be seen by intermediaries in the same order)?

If XP is to be a solid foundation, I think we need to take a view on these
questions, and provide and abstraction that is as far as is possible
independent of particular underlying protocols. 

Clearly, the simplest messaging operation (or pattern) we might be trying to
offer is a bestEffort, one-way message with no ordering guarantees and the
possibility of silent failure (not that all failures are silent, just that
the possiblity of silent failure exists).

An intrinsic request/response pattern *might* also be useful from the point
of view that the implementation of that (common) pattern might keep a
channel open for the response (which enables implict correlation), or it
might include other means in the protocol header to do correlation... but
from the application POV it sees an explicit request/response style of
interaction.

It gets a bit heavier once we begin to think about more conversational
styles of interaction, and I'm not sure that we want to 'burden' the core of
XP with these. However, the notion of a conversation does give a context in
which ordering may or may not be important and which gives some temporal
scope to any state that may be neccessary to reorder messages, spot
duplicates and recover from loss. I'd expect these conversational patterns
to be part of the "application space" at least for now... it may be that
'popular' patterns arise and over time there is an interoperability benefit
in sharing mechanism for achieving the same effect across multiple
"application spaces".

It may be the 'operations' I'm thinking of and the things that are being
called 'message patterns' are different things. In a sense you use
operations to construct message patterns. What I'm trying to establish are
the properties of those 'primitive' operations.

regards

Stuart

Received on Thursday, 1 February 2001 05:38:08 UTC