RE: Other message patterns

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 Thursday, 8 March 2001 08:20:53 UTC