RE: Reqs/AM - Comments/Questions

Hi Doug,

Apologies that it has taken a while for me to get around to responding.

> -----Original Message-----
> From: Doug Davis [mailto:dug@us.ibm.com]
> Sent: 19 April 2001 12:16
> To: xml-dist-app@w3c.org
> Subject: Reqs/AM - Comments/Questions
> 
> 
> 
> I recently joined the W3C XMLP WG so forgive me for the lateness
> of my note but I have a few questions (and comments) about the
> Requirements and Abstract Model documents.

No problem... 

<snip/>

> Abstract Model:
> - Overall
>   I'm a bit confused about the purpose of this document.  I read
>   the abstract and it seems like it implies that this _isn't_ an
>   API definition doc, but then what is it?  This doc seems like a
>   really good starting point for either the spec or an API doc
>   (or both), but if we're going to say that its not then who's
>   going to use this doc in the future?

Ok... so I'm the guilty party that started off the Abstract Modelling work
partly out of a sense of frustration over the apparent lack of an
articulated conceptual model for *what* SOAP does, particularly with the
inclusion of intermediaries. If I think of TCP, I can think of a model of
pipes with ends - I can operate on the pipe from its ends; I can bring
endpoints into existence, connect them to other endpoints, push data
(bytesteam) data through them and I can disconnect them when I'm done. This
(to me) is a fairly visual model that could be documented, it would contain
diagrams and elaborate on concepts like endpoints, the naming of endpoints
the operations that can be performed at endpoints etc. And... all of this
can be done without resorting describing the TCP state machines, protocol
messages and their encoding. 

How are such models useful? As an expression of what a protocol does (rather
than how it does it) they can be useful in determining the validity of a
protocol design; they can be useful in communicating the *what* of the
protocol to application designers/developers that intend to use the
protocol, but have no wish to delve into the detail; they can be useful to
spec. writers as a means to enable description.

From my POV, if we are defining a protocol, we ought to be able to abstract
*what* protocol does for the entities that *use* the services of the
protocol. I owned up to a layerist viewpoint when I floated the original
strawman [1]. In this view there is a boundary between the user of a layer
and the provider of a layer and the services of the layer (what it does) are
characterised by the service interface at the boundary.


   +------------------------+
   | Layer Service User(s)  |
   +------------------------+
                ^
                |
   =============+============= Layer Service Boundary
                | Service Primitives
                V
   +------------------------+
   | Layer Service Provider |
   +------------------------+

These of course are abstract notions. A real implementation may partition a
system differently. The protocol implementation and the application may all
be globbed together or whatever. However, the layer service boundary also
delimits what the protocol spec. needs to define.

In general Layer Service Providers are 'state-ful' beast that can and often
are defined and implemented as Finite State Machines (FSMs). FSMs tend to be
driven by events and respond with actions (which can give rise to further
events). The events that drive the protocol then arise: from the entities
that 'use' the services of the protocol; and from the underlying layers that
entities that 'provide' the services of the protocol. The AM stops short of
defining statemachines and message formats - that is very much the domain of
the protocol design and specification. That said, I guess I am doubtful that
we will see an XMLP specification that describes the behaviour of XMLP in
terms either of an FSMs or a simple event handler (single state FSM!) - I
expect XMLP will likely be specified in a more narrative style :-(.

>   Assuming I'm just missing the point  8-)  and there is a need for
>   this doc, and its not defining an API then I'm really confused by
>   things like the XMLP_UnitData Operation section.  When it talks
>   about things like the XMLP_UnitData.receive being invoked by the
>   receiving XMLP processor this seems to imply an implementation
>   detail (or API) rather than an abstract view of things.

Ok... so we're going to describe the behaviour of a protocol in a way that
is neutral to any particular implementation - in the ideal/or the abstract,
we are trying to describe the behaviour of something that hasn't been built.
To do that one constructs a model - an abstract implementation if you like -
and then you animate that model by describing how it behaves. It is abstract
in the sense that it has no material existence. It is created as a mean to
enable description of behaviour. It is not created to constrain
implementation. The designers of a concrete system of which XMLP is a part
may choose to partition their system differently.

Section 3 of the AM describes the interface between two abstract entities.
It models the interface as a the exchange of a sequence of events. It uses
the word 'invoke' to denote the sending of an event - if you can think of a
better word I'm very open to suggestions. Earlier versions of the document
described the interface to a request/response operation and to a one-way
operation. The 'execution' of an operation spans many nodes, hence it gets
broken down into the more primitive (abstract) events that flow across the
interface(s) between the (abstract) layer service user(s) and layer service
provider(s).

As to the need for the document... It started as a contribution I felt
motivated to make at the beginning of this year [1]. It gathered some
momenetum from with in the WG and spawned a subgroup; the process of working
on it has generated a deal of interesting and necessary technical
discussion; it may proved to be a useful artifact of itself into the future.
Personnally I, and I believe others, have found the process of working on
the AM and the discussion it has provoked useful. But I also feel that it
becomes counter-productive to force it on folks that don't find it helpful.
It is the place I would start if I were designing anything new... but of
course were not starting from scratch.

> - 2. XML Protocol Abstract Model Overview
>   - XMLP Handlers should be an implementation detail.  XML blocks
>     should be targeted by using the XMLP equivalent of the SOAP
>     ActorURI and it should be up to each XML Processor to decide how
>     that Actor is interpreted.  It could be the entire processor or
>     a particular module (ie. handler) in that processor or even a
>     group of handlers.

There is some history behind the terms [2] and we've tried to work with
those that we seem to have agreed upon. I think that there are some
interesting questions about spec. centric and implementation centric
viewpoints. The idealist in me imagines that folks will develop extensions
to the XML protocol. These will now doubt involve the creation and/or reuse
of syntactic pieces elements (schema for XMLP Blocks) and the definition of
rules for the generation and processing XMLP blocks associated with the
extension. I would hope that these extensions get documented and that some
of those documented extensions get standardised. The terms I think we have
come to use for such extensions is an XMLP Module.

I am moderately happy that an XMLP application entity realises the
behavioural rules of one or more XMLP Module so that finest grain thing that
gets referenced by an 'actor' attribute is an XMLP application entity.

That said I have not properly caught up on any recent developments on the
Handlers, Block, Module discussions.

>     We need to be very careful about this one - defining handlers
>     could lead to some problems, lets say we have an XMLP message
>     like:
>     <env>
>       <header mustUnderstand=1>...DigSig stuff...</header>
>       <body>...</body>
>     </env>
>     and neither the header nor the body are targeted (ie. no actors).
>     This means that they're implicitly targeted for the final
>     destination of the message - is this the final XMLP processor or
>     the final XMLP handler?  From the Abstract Model doc it seems like
>     its the final XMLP handler.  But people may choose to implement
>     pluggable handler to process (and remove) certain headers.  So
>     a DigSig handler sees a MustUnderstand header and processed it, but
>     since it wasn't targeted for him (that handler) the DigSig
>     handler should not remove the header.  So when the final handler
>     gets the message it will fault because 1) it will see an MU header
>     that it doesn't understand and 2) because the message will have
>     already been DigSig processed.  The only other choice would be
>     to put all of that logic in the final XML handler which makes it
>     much less pluggable/clean.

I think the thing that MustUnderstand is whatever the thing is that is
referenced by an actor. I don't think that SOAP makes a clear distinction
between a SOAP user and a SOAP provider, the two seem to be aggregated in
the term SOAP processor. I think that the value carried in a SOAP actor
attribute references a SOAP processor - ie coarse grain.

I think that there are also interesting questions about 'evaluation' order
with respect to application of rules from multiple XMLP modules implemented
at a given actor/XMLP Application/Processor.
 
>     I would really prefer if we leave the notion of handlers up to the
>     specific implementation and make the XMLP version of Actors be
>     just a URI that is up to the XMLP processors to interpret as they
>     see fit.
> 
> - 3.1.1 Correlation of Sending and Receiving XML Protocol Applications
>   - Why is Correlation special?  Why is this one field pulled out
>     into the APIs?  Can't the same argument be made for any field (ie.
>     user-id)?  Would it be cleaner to define "well-known" headers or
>     Actor URIs for this purpose - that way everything about the message
>     is kept inside of the SOAP Envelope.

SOAP today correlate responses with requests and it does it without making
use of syntactic elements within the SOAP envelope. Modelling things as
'strict' one way messaging doesn't give you back request/response
correlation (see also [3]).

Prior to Correlation we had separate request/response and one-way
operations. Those two also got a mixed reception!

> - 3.2 Operation Parameters
>   - ImmediateDestination - is this like the SOAP Actor URI?

Yes... its there so that an Application entity may 'influence' where a
message goes to next. I say influence because we really have not bottomed
out on how message paths are determined. If we postuate some XMLP extension
header (possibly standarised, possibly proprietary) that support the routing
of an XMLP application along a path, intermediary XMLP applications and
possibly sending XMLP applications that understand that particular path
extension need to be able to instruct the XMLP layer where the message
should be forwarded to next (because the XMLP layer intrinsically doesn't
understand particular extension).

There has been some debate of this topic and whether the WG should or should
not define a path model for XMLP. I have lost track of the state of that
debate, but there are certainly strong proponents of the view that the WG
should not define a particular path model.

Sections  4 and 5 were largely contributed by others so I'll mostly refrain
from responding on those.

> - 4.1 XML Protocol Message Routing and Targeting
>   - One XMLP block could be "processed" by more than one handler.  This
>     M-N relationship needs to be allowed/discussed.  This is true in
>     SOAP as well, except when blocks are targeted.
> - 4.2 XML Protocol Modules and Message Processing
>   - Bullet 5 - "When a block is selected for processing...it is
>     removed" - this is a much stronger statement than in 
> SOAP.  This is
>     only true for targeted blocks not all blocks, do we really want to
>     say this?  But then I guess it depends on how we define
>     "processing".  A logging header may be processed by many different
>     XMLP processors but may never get removed until the final
>     destination - is this an error?
>     Need to define "referenced" vs "processed".  Does that imply read-
>     only?  What about Digital Signature/Encryption processors - they
>     need to be able to rewrite blocks that are not targeted them.
>   - Bullet 6 - the order of the XML Blocks defines the order of
>     processing?  Very strong statement - do we really want to 
> say this?
>   - Bullet 7 - Does the fault happen immediately or can we wait until
>     the end of the current XMLP handler/processor?  Do we 
> allow multiple
>     faults to be returned?
> - 5.1.1 Introduction
>   - Figure 5.1 should show XMLP Handlers may generate output 
> -  ie. may
>     talk directly to the bindings.  For example, in a multi-cast XMLP
>     processor a message may be sent out over several 
> different binding,
>     each one done by a different XMLP handler - the XML processor
>     doesn't really get involved since it probably only knows about the
>     single incoming and single out-going message - but that's probably
>     an implementation choice.
> - 5.3 Attachment of Arbitrary Content
>   - "The core XML protocol messaging services intrinsically handle
>     arbitrary attachments through the use of the Attachments 
> parameter".
>     Unless I missed it we don't ever really talk about this parameter
>     any place else - its in Operation Parameters chart but not in the
>     APIs themselves.

This one's a bug... attachments were originally modeled as separate
parameter as were headers, bodies and faults. Now they've all become
subfields of Message.

> 
> thanks,
> -Dug

Thanks for the work you've put into reviewing this so far. It's much
appreciated.

Best regards,

Stuart
[1]
http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2001Jan/0004.html
[2]
http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2001Mar/0117.html
[3] http://lists.w3.org/Archives/Public/xml-dist-app/2001Apr/0140.html
(Apologies to xml-dist-app for references to WG postings).

Received on Wednesday, 25 April 2001 10:35:29 UTC