RE: [AMG] Comments on strawman: Service Abstraction

> -----Original Message-----
> From: Mark Baker [mailto:mark.baker@Canada.Sun.COM]
> Sent: 25 January 2001 20:38
> To: xml-dist-app@w3.org
> Subject: [AMG] Comments on strawman
> 
> 
> Greetings,
> 
> Here's my comments on the strawman;

<snip/>

> - unclear why an SAP - an implementation construct that isn't part of
> any interface - needs to be identified in an abstract model

Service access point is an abstract concept. They lie at the layer boundary
as a place where service primitives are applied (or if you prefer are a
point in the interface through which events pass) . The notes in the text
beneath its introduction are intended to give a feel for how it relates to
implementation.

That said, I'm not at all sure that a service access point is a useful
concept here, its one I was playing with. 

I've tended to use SAP to group end-points that share something in common...
eg. in TCP/IP several connections can terminate at the same TCP/IP port
(which is conceptually like a SAP) - however they are each independent
connections. When you establish a TCP connection you address a TCP/IP port
which acts as a factory to create an endpoint for the resulting connection.
A second connection attempt (from a different port) addressing the same
TCP/IP port establishes a different connection endpoint. I suppose that you
could also argue that in TCP/IP you do actually address an endpoint when
establishing a connection because it is effectively named by the combination
of source and destination port addresses.

The way I'm seeing it is that messages are addressed by (destination) URI -
which identifies a conceptual point in the boundary between XP and a thing
that uses XP - it would be useful to have a name for such a point. 

> - also unclear on the value of such a complex model as described in
> sections 3.[123] at this time.  This much detail extracted 
> from a set of requirements is likely going to be found brittle later.

This is very much a strawman. My hope is that it might help us focus on the
questions of how a user of XP might see XP (from above). I certainly agree
that this abstraction should not be rigidly fixed right now. But it is
perhaps a useful vehicle to ask questions about the nature of the delivery
contract between the user of XP and the XP layer (as I've called it).

We could be set our ambitions to simply provide a core that does just
bestEffort, single-hop one-way and two-way/request-response. Personally, I
think we couldn't really do anything less - which is why there is a 'proto'
description of those. We might want to address multi-hop through
intermediatiaries as part of the core of XP, or we might want to take the
view that intermediatiaries are users of the XP core (rather than providers
of it). This later would make the XP core very easy to describe, and
separate out the description of intermediataries to a separate XP module (or
modules) that describe a path model and the manipulations an intermediary
can perform on XP blocks to maybe log the actual route taken by a message.

We might want to provide reliable variants of one-way and request/response
patterns. Depending on the intrinsic capabilities of an underlying protocol,
this may require more mechanism to be created somewhere between the bottom
of the XP_client and the top of underlying protocol. Or again we might push
that up out of the core definition of XP to further modules.


>  3.4 is fine,
> but the bulk of it might better be described as "message transfer
> metadata".

Ok... 

[1] http://www.w3.org/2000/xp/Group/1/01/15-abstract-model/

Received on Friday, 26 January 2001 07:18:29 UTC