RE: Strawman Abstract Model for XP

Aren't these abstact models fun!  We have to balance simplicity/abstaction on one side and complexity/obfuscation on the other.

For #1, perhaps we could just go with something very generic like the old OSI "Application Entity".  I agree we do want move away from client/server implications.  XP User is fine.  XP User Agent (to remove the human implication) is also OK by me.  The Requirments doc uses XP Sender, XP Receiver, XP Module, XP Processor, and Application.  We should either stick with these and clean it up if that is wrong.  What is the relationship of the abstract model to section 6.3 of the requirments doc.   I like XP_Layer Entity.

#2 I agree with Ray's suggestions.

Other comments about the strawman abstract model

#3. The requirements doc uses terms like "one-way" and "two-way" message patterns.  The strawman model introduces "unidirectional datagram" and "bidirectional reqest/response" services.  I think that we should stay with patterns rather than services.    I don't want to use the term "datagram" at this level. We should keep the language as consistent as possible.

#4 The "Operation of XP_UnitData Service: One-way datagram operation" graphically illustrates the discussion about the use case we were having the other day about acknowledgements.  The XP_Data operation shows the ack coming back at the application layer from the other XP Client (to be renamed).  The XP_UnitData service shows the ack coming back from some element within the XP Layer.  Both are valid and we have modeled both which is good.  Can we/Should we model other layers of acks (i.e., 1) .request didn't even make it through the XP layer 2) .request made it through the XP layer down through the local binding, but did not make it out of the local host, 3) .request made it off the local host, but did not reach even the first remote XP Client's host, 4) .request made it half way through the path, but not to the ultimate receiver).  We probably don't need to do this detail in the absract model, but the model needs to be consistent with  the ultimate reality of what we come up with.  Like all good designs, Iam sure that this will be iterative.

#5 Regarding BindingContext.  Has the following question already been answered?  "Is the absraction of XP high enough that perhaps with the help of intermediaries will an XP Client using one binding be able to communicate with another XP Client using some other binding"  If no, then does the binding surface in the identifier used for "To" and "From" and the "Path" fields so that a sender can determine if it can communicate with a receiver or does the sender just try and get back some error indicating a binding mis-match.

#6 Service Access Point. Are these the addresses used in the "To" and "From" and "Path" fields?  The model introduces them but then they are not mentioned at all later in the message parameter abstractions.

#7  In section 2, your note asks about fattening the XP Layer with XP module processing, or leaving it at the application layer.  I agree with your initial recommendation to leave it at the application layer.  I am new so I don't really understand section 6.3 from the requirements document that shows an XP Processor being ABOVE  the XP sender and receiver.  The requirments doc says tat and XP sender and receiver are at the application layer, but I would think the XP Processor would be the entity that handles wrapping and XP header processing and that would be at the XP layer, not above the application layer.

Scott

Scott A. Isaacson
801.861.7366
sisaacson@novell.com 


>>> "Williams, Stuart" <skw@hplb.hpl.hp.com> 01/19/01 06:39AM >>>
Ray,

Thanks for your two suggestions which I'm more than happy to roll into the
next revision of the model. 

#1 is one that I was sensitive to, but decided to write with teminology that
was 'natural' to me. I have tried to use 'XP layer client' to try to
emphasis the different sense of client (and it did exist first, before
client server computing afterall! - now I'll probably get a history lesson
form elsewhere ;->). XP Service-user is fine by me, but it would be nice to
loose all vestige of ambiguity with "Service" provided by a server in
Client/Server.

#2 feels like a very comfortable change.

Regards

Stuart
PS. can we continue on xml-dist-app?

> -----Original Message-----
> From: Ray Denenberg [mailto:rden@loc.gov] 
> Sent: 18 January 2001 22:26
> To: Williams, Stuart
> Cc: w3c-xml-protocol-wg@w3.org 
> Subject: Re: Strawman Abstract Model for XP
> 
> 
> Stuart -- I've read through the draft quickly, don't have 
> detailed comments yet, but I do
> have two pragmatic observations/suggestions.
> 
> 1.  XP Client:  This is a useful abstraction but please don't 
> use "client". There will be
> client/server protocols layered on top of XP (e.g. Z39.50) 
> and this will cause serious
> confusion -- both the client and server would be an "XP 
> Client".  I would be happy with
> "XP User", but other people may object because "user" has 
> human connotations. How about
> XP Service-user?
> 
> 
> 2. XP_Data and XP_UnitData. This is a very valuable 
> distinction.  The primitives for
> XP_Data (request, indication, response, and confirm) are 
> fine.  However, for
> XP_UnitData,  I suggest not using "request" and "indication" 
> .  This suggestion is based
> on my earlier experiences trying to sell OSI protocols, and 
> failing, due, in large part,
> to the excessive abstraction and formalism in the OSI model 
> and service conventions. I
> was never able to explain to anyone why a datagram was 
> modelled as a request. How about
> "XP_UnitData.send" and  "XP_UnitData.receive"  instead of 
> "XP_UnitData.request" and
> "XP_UnitData.indication".
> 
> --Ray
> 
> 
> 
> 
> "Williams, Stuart" wrote:
> 
> > Folks,
> >
> > I've been trying to formulate an abstract model for XP and 
> I thought I'd
> > share what I have so far with the WG membership. Attached 
> are PDF and HTML
> > (zipped) versions of the document I've been working on.
> >
> > My intent in circulating this (just to WG members for the 
> moment) is to
> > invite feedback, flames and discussion on whether a model 
> like this one is
> > thought useful by WG members (this one *is* a strawman). I'd also be
> > interested in whether any of you would like to collaborate 
> on improving it.
> > In the longer term I would hope that we can develop an 
> abstract model that
> > becomes a companion to, if not (an introductory) part of, 
> the XP protocol
> > spec (cf R300).
> >
> > I come from a 'layerist' point of view which causes me to 
> want to sit on top
> > of XP, look down and ask the question... "what does it do 
> (for the client or
> > user of the XP layer)?" The question of how it does what it 
> does seems to me
> > to be a secondary question after we have decided what we 
> want it to do.
> >
> > I've tried to be sympathetic to our evolving glossary, but 
> its not an exact
> > match (I started on this before the glossary was published).
> >
> > I hope at least some of you find this appealing...
> >
> > Happy New Year and best regards
> >
> > Stuart Williams
> > +44 117 3128285
> >
> >   xan happy to roll into the
next re
> --------------------------------------------------------------
> ------------------
> >                         Name: AbstractModel.zip
> >    AbstractModel.zip    Type: Zip Compressed Data 
> (application/x-zip-compressed)
> >                     Encoding: base64
> >
> >                                            Name: 2001-01-02 
> Abstract Model for XP.pdf
> >    2001-01-02 Abstract Model for XP.pdf    Type: Acrobat 
> (application/pdf)
> >                                        Encoding: base64
> 
> --
> Ray Denenberg
> Library of Congress
> rden@loc.gov 
> 202-707-5795
> 
>

Received on Friday, 19 January 2001 14:48:53 UTC