RE: Causality/Correlation

Ray,

Firstly, just to pick on the first of the two messages you reference which
is your agreement with a statement of mine:

> "Williams, Stuart" wrote:
>
> > I happen to believe that it (request/response) is and should be
primitive in
> > our case [...]

I would still be happy with model that present UNITDATA and DATA as they
were. However, there are some around who are not at all happy with that
position. I do not believe that you can model SOAP as it is today without
some element of message correlation in your abstraction - simple one-way
messaging IMO is not up to it - you would have to put more machinery in on
top.

One-way plus request/response would do it. 

One-way with correlation would also do it - and yes I think I do agree that
modeling/specifying the thing that sits above XMLP becomes more complex than
it would if you have a direct model of request/response.

So, we have two possible ways of presenting the model - the second arose
because I was trying to find away to address the strongly held issues
against the first without lossing a facit (request/response correlation)
that IMO is present in SOAP despite protestations to the contrary.

Certainly on can engineer request/response on top of plain one-way, but that
is different from modelling. You would just get the question of modelling
that derived functionality (assuming you wanted to). Thinking of building
request/response ontop of one-way is more about HOW than WHAT - but I know
you know that.

In regard of your descriptive complexity issue, I don't think it would be
too hard to construct a kind of shim that gives you back request/response
from one-way+correlation - and of course externally, on the wire you would
not know the difference.

I actually found myself coming to the position that one-way+correlation was
a better basis for building different exchange patterns than 'simple'
one-way or simple one-way + request-response.

There may be three different 'camps' out there

	One-way only
	One-way+request/response
	One-way+correlation

I could live with either of the last two as the basis of our model.

Best regards,

Stuart
[1] http://lists.w3.org/Archives/Public/xml-dist-app/2001Mar/0054.html


> -----Original Message-----
> From: Ray Denenberg [mailto:rden@loc.gov]
> Sent: 29 March 2001 17:35
> To: Williams, Stuart
> Cc: marwan sabbouh; Ray Denenberg; David Fallside (E-mail);
> w3c-archive@w3.org
> Subject: Re: Causality/Correlation
> 
> 
> "Williams, Stuart" wrote:
> 
> > Q. What would we loose if we removed the XMLP_DATA operation from the
> > abstract service model?
> > A. Causality.
> >
> 
> Stuart -- I don't think that causality is the only issue.  See:
> 
> http://lists.w3.org/Archives/Public/xml-dist-app/2001Mar/0054.html
> 
> It was Noah who subsequently introduced the issue of "causality":
> http://lists.w3.org/Archives/Public/xml-dist-app/2001Mar/0092.html
> 
> But to elaborate on my view: I certainly agree that we need the
XMLP_Unitdata
> operation but I also think that the XMLP_Data  is useful, and that the two
can and
> should co-exist. The prupose of these primitives is to serve as tools to
describe
> protocols that sit on top of XMLP. A given protocol might use one or the
other or both
> (Z39.50 for example would use both). There are a number of different
message patterns
> to be supported, and all except the request/response pattern would employ
the Unitdata
> operation -- only request/response operations where a response is
mandatory, and where
> only a single response is allowed, would use XMLP_Data (otherwise, use
Unitdata with
> the "causality parameter").  But in reality, this is probably going to be
the
> predominant pattern, and so singling out a primitive to support it isn't
an
> unreasonable thing to do. So the question then becomes does XMLP_Data ease
the
> description process and provide better clarity?  I think it does both, for
reasons
> I've stated (in the message cited above).   I can live without this, I
just think it
> merits more discussion.
> 
> Feel free to forward this to the list.
> 
> --Ray
> 
> --
> Ray Denenberg
> Library of Congress
> rden@loc.gov
> 202-707-5795
>

Received on Thursday, 29 March 2001 14:09:24 UTC