Re: Other message patterns

Perhaps you have already considered this...Another way of thinking about this
would be that one-way is a primitive and message correlation is a primitive.

With these 2 primitives, you can build synchronous or asynchronous RPC,
conversations, et al.

However, this would mean that we would have to make correlation a part of
the basic model, which so far we have resisted.

"Williams, Stuart" wrote:

> Hi Mark,
>
> > -----Original Message-----
> > From: Mark Nottingham [mailto:mnot@akamai.com]
> > Sent: 08 March 2001 03:07
> > To: Williams, Stuart
> > Cc: 'Randy Waldrop'; xml-dist-app@w3.org
> > Subject: Re: Other message patterns
> >
> > If we abstract (bad choice of words? ;) out the subtleties of RPC
> > (request-response) over HTTP (request-response) into a
> > 'request-response' primitive, it seems to me that we'll be able to
> > model RPC-over-HTTP, but won't be able to leverage this to
> > other_MEPs-over-other_transports.
>
> I think/hope folks would at least agree that request/response is a
> generically useful message exchange pattern (MEP - BTW in Europe that's a
> Member of the European Parliament :-)). It has broader utility than 'just
> for RPC'.
>
> I also hope folks haven't failed to notice that the abstract model does
> include one-way messaging as primitive - which can certainly be leveraged to
> create a variety of MEPs.
>
> So I think the question/debate is over whether request/response should also
> be primitive in the model, or abstracted by construction from one-way.
>
> I happen to believe that it (request/response) is and should be primitive in
> our case - and the principle reason I believe that is because SOAP1.1 as it
> is today, which our chartered starting point DOES do request/response at
> least in support of RPC, AND it DOESN'T do request/response by construction
> of 2 one-way messages.
>
> One of the tasks, the AMG has on it's work-item's list is to map our
> abstract-model to SOAP 1.1 (and SOAP 1.1 with attachments). I do NOT believe
> we can do that without request/response as a primitive.
>
> If you believe that you can relate the functionality of what SOAP1.1 (over
> HTTP) does today to an Abstract Model that contains just the one-way message
> primitive please show me how... I would be delighted to receive that
> contribution - but don't just tell me it can be done and leave it at that.
>
> > I'd think a robust abstract model should be able to encompass these
> > applications without catering to them specifically.
>
> Too oblique... I think you need to spell it out for me.
>
> > The HTTP binding was chartered because it was obvious, existant and
> convenient; I'd
> > argue that it wasn't put in to predispose the XMLP world to a certain way
> of thinking.
>
> I think that there is a strong desire to inflict minimal change on SOAP and
> to build forward from it. If that is indeed the case then I think the
> abstract model needs to be as accomodating of SOAP as it is today as it can
> be - warts and all.
>
> <snip/>
> >
> > --
> > Mark Nottingham, Research Scientist
> > Akamai Technologies (San Mateo, CA USA)
> >
>
> Regards
>
> Stuart

Received on Friday, 9 March 2001 13:42:21 UTC