RE: Strawman Abstract Model for XP

Scott,

Thanks for taking the time to put all this down. I guess at the moment this
opens up more discussion than it closes... comments interspersed below.

> -----Original Message-----
> From: Scott Isaacson [mailto:SISAACSON@novell.com]
> Sent: 19 January 2001 19:48
> To: xml-dist-app@w3.org
> Subject: RE: Strawman Abstract Model for XP
> 
> 
> Aren't these abstact models fun!

Certainly...

> We have to balance 
> simplicity/abstaction on one side and complexity/obfuscation 
> on the other.

Yep... kind of forces us to think about the things we might be taking for
granted or mysteriously waving our hands over in the expectation that things
will turn out fine :-)

> 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.

I'm minded to go with "XP User" or XP User Agent" as you suggest. 

[Extracts from Requirements Document]

"XP processor: An XP Processor processes an XP message according to the
formal set of conventions defined by the XML Protocol and generates an XP
fault if the conventions are not followed. Insufficient or wrong data
carried in an XP block can cause an XP processor to generate a fault (see
also XP receiver and XP sender).

...
"XP sender: An application that can generate an XP message and perform an XP
binding to a specific protocol for the purpose of transmitting the message. 

XP receiver: An application that can accept an incoming XP message
transmitted using some XP binding, extract the message from the XP binding
and pass the message to an XP processor."

[End of extract]

XP Processor and XP_Layer Entity would seem reasonably aligned, although I
have some questions over whether the processing of XP Modules can happen
within the XP layer or whether they really are things that the application
has to deal with. I think there are some that deal with delivery semantics
that we may have to make provision for within our model of the XP layer,
whereas there are others that will affect the application semantics of the
payload (eg. whether it's signed or not) that are probably best handled by
the XP User (XP User Agent, XP Client, XP Layer Client...).

XP Sender and XP Receiver seem more to be aligned with the user of the XP
layer, however, I am troubled by the reference to bindings in their
descriptions because that would suggest that they also reach quite deep into
the XP layer and have detailed knowledge of the layers below XP that we're
trying to abstract away from.

Slightly more generally, I'd be a little concerned if the terminology in the
glossary section of a requirements document became constraining on the
process of abstracting and ultimately designing XP rather than be there to
help explain what we require of it.

> #2 I agree with Ray's suggestions.

That's fine... I'd already remarked to Ray that I thought this was a
comfortable change.

> 
> 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.

Ok..ish... Personally I'm much more comfortable with the terms I used (but I
would say that wouldn't I), and I'd have similar qualms about being
terminologically boxed in by terms in a requirements document rather than
terms in an architecture document or a design document.

That said, I'll experiment with changing to "one-way" and "two-way", which
seem less precise, next time I roll the draft. "Datagrams" are "one-way" but
not all "one-way" is "datagram", likewise "request/response" is two-way, but
not all "two-way" is request response. 

> #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.

I'm a bit behind on my mail.
 
>  The XP_Data operation shows the ack coming back at the 
> application layer from the other XP Client (to be renamed).  

Being picky... it shows a 'response' coming back, and the 'ack' being
implicit. 

> The XP_UnitData service shows the ack coming back from some 
> element within the XP Layer.

That's not the way I view it. The semantics of the UnitData.confirm say
nothing about successful delivery to the remote end. The strongest thing
they can say is that the message was definitely NOT sent due to some error
that arose early enough in the trasnmission process. The next strongest
thing it can say is that the message was successfully transmitted - which
says nothing about whether the message was successfully received.

>  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 

These would come back as .confirm with appropriate error and status
information.

> 2) .request made it through the XP layer down 
> through the local binding, but did not make it out of the 
> local host, 

Ditto... again with distinguished error and status.

> 3) .request made it off the local host, but did 
> not reach even the first remote XP Client's host, 

Basically, a strong assertion of a failure to send... again a .confirm with
error and status.

> 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 !

This one is harder... and requires more work on sorting out our intermediary
model. There are also some really had questions about backing-out (or not)
of bits of processing done at intermediaries and bits of processing already
done at the node that fails (if its a node failure).

Depending on how we do things we could use something like the SOAP fault
mechanism for application (ie. XP User) level failures - in which case an
application level fault flows in the response path. Or we can pickup an
infrastructure failure and include it in a way that generates error and
status at the originator.

> !
> with.  Like all good designs, I am 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.

The way I see it is that an XP layer entity can may bind to several
underlying protocols. On a hop-by-hop basis, then the bindings must match...
however, at an intermediary the message can get unpacked and re-packed to be
bound to a different underlying protocol for the next hop... and so on.

One of the purposes of the BindingContext is to try to abstract away from
having to deal with authetication requests from the underlying protocol. It
would be nice not to have to expose those upstairs, other than as a generic
transport failure with some pragmatic structures to rummage around in if you
really want to find out what went wrong. The binding context is a way of
carrying authentication information for the current operation down so that
the XP binding to HTTP, say, can deal with authentication when asked.
Likewise, on the inbound side its away of encapsulating certificate
information that may have been exchanged to get the underlying protocol
going and which may help establish a context for generating a response.

> #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.

Basically, yes. Just a little care, in that a SAP and the address of a SAP
are different things (and of course this is abstract so they probably don't
exist in any real sense anyway!). You can think of a SAP as being like an
object where the methods of the object represent the service primitives. A
property of the object is it's name or address. I need to think a little bit
about URI semantics, because the way I'm thinking at the moment is that its
the SAP itself that's named by the URI. The XP User layer thing bound to the
SAP is also implicitly identified by the name of the SAP.

> #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.

I guess see my ramble at #1. I think you're hitting on the same
terminology/model problems that I'm hopeful an abstract model can address.

There are some things that I'm finding particularly problematic as I think
about them. Imagine that you wanted to invent an XP module that provided
reliable, inorder, exactly once delivery semantics. That's easy to imagine,
and close to being something that the ebXML folks would like to have. It's
certainly easy to see how that works in a simple case between a source and a
sink. Now, cross that set of needs with intermediaries. Are the same
delivery semantics required to apply at the intermediaries? Do successive
messages in a conversation follow the same path? 

If SMTP is used as the underlying protocol, certainly the SMTP message
router may re-order messages, and mail-loops can cause multiple delivery...

So... as I'm thinking today... XP_Modules that have to do with message
delivery semantics may very much need to be handled as part of the XP layer,
whereas XP Modules that are concerned with the post-delivery application
semantics of the message should probably be pushed upward to the "XP User".

So, even if we only take on bestEffort one-way(datagram) and
two-way(request/response) message patterned right now, we should perhaps
structure the model so that we can easily model (from a layer service point
of view) reliable variants of these patterns and more conversationally
orient patterns for more length sequences of exchanges (with and without
order delivery? with and without reliable delivery).

> Scott
> 
> Scott A. Isaacson
> 801.861.7366
> sisaacson@novell.com 

I'll be interested in your thoughts

Best regards

Stuart

Received on Monday, 22 January 2001 11:54:13 UTC